Actually not quite how that third check works with the whitelist. The 3rd section of the white list was introduced in firmware 1.4 and it seems they rushed it as they forgot to reimplement the RSA sig checks for the white list SRL. The new section they added was supposed to work by loading in specific sections of the cart rom into ram so that arm9 can verify if those sections match a specific hash. (an HMAC-SHA1 hash I believe). They added this to protect against flashcarts that used exploited game roms to fool the DSi into booting it. (was a way around the hash checks the DSI did with the first 2 sections which hash checked the header + arm binaries and the second section which hashed the icon/banner data).
The flaw is that they didn't put bounds checks on how much rom data you can load in. So it overflows. For whatever reason Nintendo decided to have arm7 load in the cart data instead of arm9 despite the fact that arm9 was what was going to do the actual hash checks. So as a result there is no MPU protections to worry about as arm7 doesn't have an MPU. So we can overwrite data anywhere we want so long as it's not in DTCM/ITCM range (as that is internal CPU cache ram only accessible on arm9)
There are actually 2 ways to do this exploit. The current way RocketLauncher payload that we plan to eventually release will overflow into the arm7 interrupt vector address. This tells Arm7 where to jump when it crashes/is interrupted. Refer to gbatek documentation on how that works. The second method is currently undeveloped but also possible. You could instead take over arm9 first by only overwriting into arm9's exception vector. The only real benefit to doing it this way is having a slightly shorter boot time for your exploit since the overflow size is smaller. (it can take over 10+ seconds to actually boot the exploit. Over 7+MB of rom data has to be read before the payload is fully in ram and the arm7 irq vector is overwritten!) The only benefit for taking over arm9 first besides the negligible change in boot time is that a lot of arm7 ram won't be wiped out by the overflow so a special payload could be built to dump a few encryption keys arm7 puts in certain ram ranges in early boot. Even No$GBA doesn't have these keys and normally you needed an expensive physical mod that involved resoldering bypass wires over the ram which was quite an involved process.
Normmatt initially attempted to make a payload for this but arm9 didn't seem to want to cooperate with his initial attempts and haven't seen much further on this. StuckPixel is going to attempt dumping bootrom soon so it may not be needed anyways.
Also StuckPixel was who wrote the RocketLauncher payloads so it's ultimately his decision on when RocketLauncher gets released not mine. I only discovered the exploit and helped do the first beta tests of stuff Stuckpixel wrote to attempt exploiting it. There's not a lot of interest in DSi right now so have no good devs/coders to write the rest of the stuff we need for RocketLauncher to be user friendly.
We need something that can automatically downgrade DSi + install whitelist to nand. Something that doesn't requite dumping nand and writing it back like the older fwtool program that is floating around. Something more akin to GodMode9 on 3DS. We also need a program for PC that will automatically add custom section 3 entries to a white list file for setting up the retail cart method and for future flashcart support. (though already have the major ones setup. DSTT and it's compatible clones and AceKard 2i we've already got supported)
The autoboot method is the best method as you can boot into ROcketLauncher from cold boot with it and even bypass the health and safety screen (as the console doesn't load that until the cart is authenticated and is approved to be booted. But we crash the system and run are exploit during that process.
) But it requires having a flashcart where you can overwrite the rom it shows to the DSi. But most of the flashcarts known to be compatible with NTRBootHax on 3DS will also be supported with this exploit.
In other cases though you can use the retail cart boot method that involves putting our payload in a section of ram that isn't cleared on warmboot/soft-reset. Then put some special data at a specific ram offset and then call a reboot. That was something we gleaned from code meant for dev units for soft resetting into specific game titles. Not sure if this was ever used in SDK with any software eventually released. Might have ever been for testing on dev units or on special koisk units meant for demos in stores. But the support for it was retained in normal retail firmware. Long story short we overflow a retail game's rom data into ram until a specific part of that rom ends up in our arm7 irq jump vector like with how our auto boot method works. Unlike autoboot method though we can't control the data retail cart's present to the system. So instead we put our payload in ram like mentioned above and find a section of rom that happens to have a little endian value that tells arm7 to jump to that address value we found in the rom data. We found a string that's super common that almost every game has somewhere in it's rom. So we just align the overflow so that part of the game's rom ends up in the irq jump vector. So that's how the retail cart method works.
But yeah long story short we need more work done on the user side tools. What we have now isn't really suitable for release yet. Even HiyaCFW I feel needs a reworking with how that works. Currently it's crude and needs to load a hacked together SRL that has the stage2 binaries from DSI's nand (equilivent to FIRM partitions on 3DS mostly. Just more primitive/simpler in design) which is prepached to allow booting Launcher from SD instead of NAND. It has the RSA/SHA1 hash checks patched out. Then after that we use a pre patched Launcher on SD.
So not only do we need to make an autopatcher for the stage2 bootloader we need one for Launcher too. Though for Launcher it won't be that bad as all regions (except maybe Korea/China?) versions of Launcher are virtually identical. Only dev Launcher is different.
We have all the patches for Launcher (and the SD redirect patch that works sorta like emunand is super simple and easy to patch. Plus it's not las hard to use as emunand as you don't even have to setup a hidden partition on your SD card like with 3DS emunands of the past. You can just drop the your extracted nand files on SD and point Launcher to it instead of nand.
)
Just need a few tools prepared and we can release RocketLauncher. (and eventually a proper release of HiyaCFW). So until then StuckPixel has been waiting. When he's had free time he has attempted to write the nand tools I mentioned. Not sure where he is on that though. He might not get back to that after he's done with his bootrom dump attempt though. May also be busy with Switch stuff. So yeah DSI isn't a priority among the dev community right now. So no one around to help us with it.
