Some time has gone by, and we’ve made a little progress on the DSi — at least, enough for some people to notice — so maybe I should write a little bit about it.
I personally haven’t had much luck with my DSi. I tried to dump the flash on it, and managed to blow a fuse in the process (it’s hard to keep that battery aligned with the case removed…). I can’t run any of the savegame hacks, because there are no DSi-mode cartridge-based games for the Japanese DSi yet. I decided to get a bit more aggressive and see if we could sniff the RAM:
This didn’t actually end up working out so well. The thing stopped powering on, and well, yeah.
I did have a little more luck dumping the SPI flash onboard the WiFi dongle:
I used Travis Goodspeed‘s awesome GoodFET device (thanks Travis!). Some of you may remember FlashMe on the older Nintendo DS — this was the program that let you reflash the “firmware” that was stored on the SPI flash on the WiFi daughtercard to e.g. bypass RSA verification of Wireless MultiBoot games. The DSi has the same chip in the same place, but it only holds a small amount of configuration data, with the “firmware” being stored elsewhere. Bummer.
Meanwhile, at least two people have successfully dumped the 256MB MMC NAND flash; in at least one case, an old SD card reader was just soldered to 4 vias on the PCB! We’ve learned that there is approximately 1MB of that flash chip dedicated to the “firmware” used to boot the DSi — more on that below — and that second-stage loader is encrypted with a key that is shared among all DSis and stored in ROM (much like boot1 on the Wii). Of that 1MB, about 300K is actually used. The remainder of the NAND flash is encrypted uniquely per console, so as with the Wii, you can’t take the contents of one flash chip and boot it on another console. (However, like with the Wii, it IS possible to back up your encrypted flash, upgrade or modify it, and then reflash back your old image to restore the old state. The nice part is that it only requires 4 wires to do so on the DSi, as compared to 16 on the Wii.)
Once it became clear that something was seriously wrong with my DSi and it was never going to be useful in its current form, it gave its life to science. From that, we were able to find points to solder to all of the address, data and control lines on the DSi’s Pseudo-SRAM chip without removing any chips, and a promising new member of our close-knit community was able to successfully wire up a working DSi to an FPGA:
scanlime really does some excellent work; through a bit of EE cleverness, he was able to slow down the clock of the DSi enough such that he could sniff all of the RAM traffic and dump it over USB to his computer for analysis.
We have no grand master exploit, but have learned the following things:
- There is a considerable amount of ROM (128K+?) and RAM (1MB+?) inside the CPU
- The internal ROM is quite sophisticated, compared to that of the Starlet (boot0) — it is able to initialize both LCD panels, read from the SPI flash and the MMC NAND flash, and decrypt the contents of the 2nd-stage bootloader from NAND into internal RAM. If there is an error, it can display an error code on the top LCD.
- The second stage bootloader is analogous to boot2 on the Wii — it can read the TMD for the System Menu from the NAND filesystem and load the contents into memory. Like the Wii, the code seems to be stored in NAND unencrypted (inside an encrypted filesystem). Unlike the Wii, it seems to actually verify the contents and signature of the TMD before executing it.
- Most of the interesting keys seem to be stored inside internal RAM, safely out of reach from us. They are cleared when a cartridge is loaded, and probably even when a DSiWare app is loaded.
While this is a tremendous boon, there are still many challenges ahead. We have not yet found keys to decrypt most of the system software, and even finding those will not be enough to actually let us execute code; that will require a further exploit. Furthermore, we are currently drowning in data — a full RAM trace from scanlime’s setup from startup to installation of a channel is over 10 gigabytes. We have some software that can convert this into a RAM dump — please don’t even ask me for it — but most of the interesting bits are only stored in memory temporarily. Work is still ongoing to let us analyze the flow of memory accesses and pick out those interesting, ephemeral bits.
In some ways, this is similar to what happened with the Wii — fiddling with the RAM gave us much greater insight into how the system worked, but it still took several months of dedicated reverse-engineering before we had a usable exploit. Maybe this one will be faster, or maybe Nintendo will have learned a thing or two from their previous mistakes.