At last, it's here
Full statement by PoroCYon/K2^TTN: (emphasis mine)
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.
I'm over hyping it a bit? Who cares!
Edit: update on the arm9 bootrom dumping
Full statement by PoroCYon/K2^TTN: (emphasis mine)
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.
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.
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.
I'm over hyping it a bit? Who cares!
Edit: update on the arm9 bootrom dumping
Last edited by Valery0p,
, Reason: Oops, not a group :P