Homebrew [DSi] The full arm7 BootROM has been dumped

[Valery0p]

At last, it's here

Full statement by PoroCYon/K2^TTN: (emphasis mine)

Spoiler

We finally managed to dump the BootROM of the ARM7 core of the Nintendo DSi.

Not much time has been spent on reversing it yet, but expect more to come in the following days/weeks/months.

SHA256 hashes

The sha256 of the raw dump is 12a03016ba07cfd874fc002df49a2c6eb2414eb7cfa395c2043035ec5e9193e8 , but this is probably unique to the device we have.

Setting all crypto keys etc. (that we know of) to 0, the sha256 becomes 2d0039f0c9e1149df171839e65510bd8371be110198b8bdf1eb97a9cdb148158 . This one should be global.

(this is of the full 64k dump btw, not just the upper 32k)

This was achieved by:

1. poisoning the undefined instruction handler of the ARM7 to make it point to our payload
2. filling ALL of ARM7 (SoC-internal) WRAM with NOP sleds to our code
3. rebooting the device
4. right after it reboots, we inject an EMFI glitch which does the magic
5. the ARM7 jumps to our code
6. the payload then prints out the entire dump over I2C, which we then sniff out using a logic analyzer

I can't thank the people in the uni lab enough who have helped me with the physical setup of the attack during the entire process. They made this possible.

"Now, why only the ARM7 boot ROM and not the ARM9 one?", you might ask.

The thing is, in the attack, we poisoned the exception vectors, which reside in SoC-internal WRAM for the ARM7.

The ARM9 puts these in main RAM. Main RAM is disabled at reset (and disabled by the bus address decoder!), and only reenabled during the second boot stage, which resides in eMMC. Adapting the current attack to this situation is, not trivial to say the least. Therefore it is probably a better avenue to try to find software bugs in it, which we may be able to exploit from the ARM7 side.

Also, a note on which exact areas have been zeroed out in the "keyless/IDless" dump:

* 0x8188..0x8388
* 0xb5d8..0xb618
* 0xb618..0xcd60
* 0xc6d0..0xd718
* 0xd718..0xe760

These values can already be extracted making a so-called "Nocash enhanced dump", which reads these values from internal memory at boot-time (because the boot ROM leaks them there).

And, to get some misunderstandings out of the way:

Back when those huge Ninty source code leaks happened, press releases often claimed that this cointained the DSi boot ROMs as well.

This is not true. It only contains the *second*-stage boot ROM, which can be read out trivially (it's in the eMMC).

Oh, and, if you're interested in how the software side of this looks, here's all the code that ran on the DSi for this: the payload, the payload installer, etc.: [see gitlab link]

[reply to another comment:]
it took a while (we started working on this in middle august), but most setbacks were due to the pandemic (which forbade us to work in the lab for several months), and, initially we used a relatively weak, commercial glitching device, but couldn't get it to make the ARM7 to jump to our payload in a test setup. It spent another month scanning for possible parameters (strength/duration/location in the SoC/...). But luckily the people in the lab had a custom-built probe lying around that's quite a bit more powerful, and had success with that pretty quickly.

Sources:
https://icosahedron.website/@pcy/105872478665346643
https://git.titandemo.org/PoroCYon/dsi-bios-payload

This could bring to the discovery of new vulnerabilities for the DSi (NTR/TWL boot anyone? ) and improvements to DSi emulation, both for no$gba and MelonDS. If the dump gets somehow shared by the group that is.

Thanks to all parties involved, and please don't go spam the devs obviously.

Spoiler

I'm over hyping it a bit? Who cares!

Edit: update on the arm9 bootrom dumping

 

[Searinox]

So they're finally here! Performing for you!

 

[MyDePain]

Wow ! Amazing !

 

[KokoseiJ]

So they're finally here! Performing for you!

If you know the ASM, You can join in too!

jokes aside, Stunning news! Really looking forward to things it will bring to DS homebrew scene

 

[DinohScene]

Nice!

Took less time then the Wonderswan or GBC.

 

[Flame]

Oh yes baby!

 

[RupeeClock]

I'm surprised this news isn't bigger than it is, huge development potential here.

 

[FAST6191]

Always nice to see new hacks.

For those wanting a bit less jargon.

1. poisoning the undefined instruction handler of the ARM7 to make it point to our payload
2. filling ALL of ARM7 (SoC-internal) WRAM with NOP sleds to our code
3. rebooting the device
4. right after it reboots, we inject an EMFI glitch which does the magic
5. the ARM7 jumps to our code
6. the payload then prints out the entire dump over I2C, which we then sniff out using a logic analyzer

1) CPUs (like the ARM7) run instructions. However they don't encompass every single value from 0000 to FFFFFFFF and there are combinations that mean nothing, aka are undefined to the processor. In older devices you might skip things or have it crash, newer ones will attempt to jump to a safe location to do something. Change where this "safe location" is to be an area you control and we are off to the races.
2) The ARM7 itself (the SoC = system on a chip and actually meaning it here as it has its own memory onboard) is loaded up with NOP (no-operation) runs such that it does nothing but eventually lands on the code they want to run.
3) Much as it says, do a reboot.
4) EMFI = electromagnetic fault injection. You get a big pulse of electromagnetic energy (big capacitor going through a coil maybe) and stick it next to the chip. Unlike your everyday interference that might make your headphone wire a bit noisy or VGA/analogue signal wire a bit blurry this can cause all sorts of fun and games inside the chip and make it behave in odd ways (this would be a somewhat newer class of side channel attack as far as things out in the wild, earlier ones include powering down at the wrong moment to skip instructions, like the GBC one referenced above https://hackaday.com/2009/09/18/super-game-boy-boot-rom-dumped/ https://hackaday.com/2009/09/28/gameboy-color-boot-rom/ , and massively changing the input frequency), possibly including trying to execute an undefined instruction.
5) as noted above the undefined instruction handler is loaded with where they want it to land and everything else geared to it. Prepare for takeover.
6) i2c = a communications protocol used by chips to speak to each other. Been around for many years and is used all the time, nothing too special there. logic analyser is much as it sounds and takes in logic signals and analyses/decodes/reads them such that you can look at them later. I don't know what the kids are suggesting these days but if you want a basic idea go have a look at the buspirate, somewhat older but does good stuff. Likely just easier than trying to set up wifi or dumping to an SD card, or using headphone jack or pulsing a LED a few thousand times or displaying a few hundred QR codes on screen and having a camera decode it like we have seen for some other hacks.

 

[jeffyTheHomebrewer]

If you know the ASM, You can join in too!

ARM 7! BOOT ROM DUMP! HUH!

 

[Valery0p]

Always nice to see new hacks.

For those wanting a bit less jargon.



1) CPUs (like the ARM7) run instructions. However they don't encompass every single value from 0000 to FFFFFFFF and there are combinations that mean nothing, aka are undefined to the processor. In older devices you might skip things or have it crash, newer ones will attempt to jump to a safe location to do something. Change where this "safe location" is to be an area you control and we are off to the races.
2) The ARM7 itself (the SoC = system on a chip and actually meaning it here as it has its own memory onboard) is loaded up with NOP (no-operation) runs such that it does nothing but eventually lands on the code they want to run.
3) Much as it says, do a reboot.
4) EMFI = electromagnetic fault injection. You get a big pulse of electromagnetic energy (big capacitor going through a coil maybe) and stick it next to the chip. Unlike your everyday interference that might make your headphone wire a bit noisy or VGA/analogue signal wire a bit blurry this can cause all sorts of fun and games inside the chip and make it behave in odd ways (this would be a somewhat newer class of side channel attack as far as things out in the wild, earlier ones include powering down at the wrong moment to skip instructions, like the GBC one referenced above https://hackaday.com/2009/09/18/super-game-boy-boot-rom-dumped/ https://hackaday.com/2009/09/28/gameboy-color-boot-rom/ , and massively changing the input frequency), possibly including trying to execute an undefined instruction.
5) as noted above the undefined instruction handler is loaded with where they want it to land and everything else geared to it. Prepare for takeover.
6) i2c = a communications protocol used by chips to speak to each other. Been around for many years and is used all the time, nothing too special there. logic analyser is much as it sounds and takes in logic signals and analyses/decodes/reads them such that you can look at them later. I don't know what the kids are suggesting these days but if you want a basic idea go have a look at the buspirate, somewhat older but does good stuff. Likely just easier than trying to set up wifi or dumping to an SD card, or using headphone jack or pulsing a LED a few thousand times or displaying a few hundred QR codes on screen and having a camera decode it like we have seen for some other hacks.

Thanks for your extended explanation I wish I knew at least some of this stuff in the past when I used to ask the same questions around over and over again xD I mean I still do, but at least I know a bit more now...

Something even more important from my point of view is the fact that they are creating a small network of "new" developers with a constructive mindset ; a small quote from a longer thread (which also tackles a lot of what I've observed by looking at the situation as an outsider), posted two hours ago:

The reason I started with this endeavor was actually because Arisotura, the main melonDS lead (I was using melonDS back then to test my demoscene stuff because for this it proves to be better than Desmume, as the latter has a lot of commercial game-specific hacks), liked to know more about the boot ROM as she was working on DSi emulation and didn't get booting to work properly yet. So, having access to a uni which has a lab made for these things, I said, why not give it a try.

 

[raxadian]

How this will affect DSi emulation?