Not knowing japanese is part of the problem. The other parts are the 3DS boot delays and the whole 3DS GUI in general, I would rather avoid dealing with that, and prefer to patch the console to boot my own code. Hmmmm, translated photos? Knowing how to "click [image] for OK and [image] for Cancel" could be useful, but only when knowing what I am accepting when clicking OK. I guess that would require loads of photos, plus some huge poster-sized neon photos saying "Never click [image] or [image] because that would block all exploits or delete all data". So, no, I don't think that's practicable.
The spreadsheet is nice for verifying that my key generator has put the keys into correct keyslots. Though there seem to be a few bugs in the spreadsheet (I think the normal key in keyslot 38h should be in keyslot 38h only, not also in keyslot 3Ah. And the DSi keyX in keyslot 03h should be console unique). Anyways, the spreadsheet doesn't help on patching eMMC because I don't have OTP dump for generating all the console unique keys.
At the moment, I could see three DIY hacking approaches (or combinations thereof):
Patching firm0 at eMMC offset 0B130000h
For XORing without knowing the AES key: Is there anything known about how many firm0 versions exist? And does somebody know how to get hold of those version(s)?
I think there must be at least two versions (one for Old3DS, one for New3DS). Possibly with about 30 variations for the different firmware updates, and 6 more variants for 6 regions, and possibly 2 more variants for debug/retail? In worst case that would be up to 1440 different versions (2*30*6*2).
I have one decrypted firm0 dump (unfortunately not the one installed on the actual console). That dump contains some zerofilled areas - that would make XORing much easier (if one knows where the zerofilled area is located in each version). But to do that, one would also need to patch the NCSD header with RSA slot 3 sighax signature, and then redirect firm0 it to the zerofilled area.
The bootrom uses three RSA keys in RSA slot 1,2,3:
- RSA slot 1: For FIRM signature in eMMC
- RSA slot 2: For FIRM signature in WifiFlash/Ntrcard
- RSA slot 3: For NCSD signature in eMMC
So that would require three different sighax signatures (and another three for debug version). Unfortunately, the .bin file download on http://www.sighax.com/
contains only one of those brute-forced signatures (and doesn't even tell which one... probably the retail RSA slot 1 one, as that would be most commonly used).
This tool might be capable of brute-forcing missing signatures: https://github.com/Myriachan/sighax
did anybody already do that brute work? I've read that it would take 1 week with a fast GPU (or presumably several months with my own old PC).
Booting from Wifi-Flash (from flash offset 400h)
Wifi-Flash boot uses a fixed AES key. So that would work without needing any OTP-based console unique keys. The main issue would be the missing sighax signature for RSA slot 2. Another issue is that the 3DS Wifi-Flash chip probably doesn't have any write-able memory at offset 400h (but I have a spare bigger chip from a DSi wifi board, so I could use that instead; and rewire the write-protect pin, of course).