Hacking [IDEA]arm9loaderhax boot without SD

[gudenau]

I do believe this is doable and being worked on. Since it's ARM9 you have access to the NAND, just need a FS driver and the ability to write files onto the NAND. Just updating would be a pain.

 

[Shadowhand]

Check CTRNAND for an A9LH payload. If it has one, great, boot it. If not, shutdown the console.

This is rather risky to do so. And stage2 gives us 500kb of work space, to put it in the perspective, SaltFW is about 32kb.

 

[daxtsu]

This is rather risky to do so. And stage2 gives us 500kb of work space, to put it in the perspective, SaltFW is about 32kb.

How is it risky, especially if you give first priority to the SD card? Also, where does 500k come from? When I was messing around with this stuff, SafeA9LHInstaller refused to install a stage 2 that was over 20K if I recall..

 

[mathieulh]

At least you read delebile's writeup - that's some amazing progress right there. The problem is that BOTH FIRM0 AND FIRM1 are modded. Maybe there's some trickery with n3DS, but with o3DS it's outright impossible.

And by the way, do you even know what *the* (not *a*) CTRNAND is?

EDIT: Also, please check out the arm9loaderhax source, it'll all become clear at that point.

No, FIRM1 is not "modded" otherwise it wouldn't pass the bootrom's signature checks, FIRM1 however contains the Kernel9loader which uses the bogus key (at 0x20 from the start of the nand keystore) to decrypt the rest of the FIRM binary (K9L is part of the FIRM container) it will therefore decrypt to garbage, but the nand keystore key has been especially forged/bruteforced so one of the first instructions of said garbage happens to be a jump instruction which branches to an address where our payload (from the previously modified FIRM0) is in memory.

 

[mgrev]

this is a bad idea. say your 3ds bricks, then you're fucked. saltfw doesnt have other payload loading, which is required for restoring nand. when it loads from system, you have no chance at all to load something else if you brick

 

[daxtsu]

this is a bad idea. say your 3ds bricks, then you're fucked. saltfw doesnt have other payload loading, which is required for restoring nand. when it loads from system, you have no chance at all to load something else if you brick

That's why you'd keep the SD loading functionality of stage2, so you can boot something else in an emergency. Or install a CFW that has basic chainloading capabilities. NAND loading of payloads and SD loading of payloads don't have to be mutually exclusive at all.

 

[Wolfvak]

No, FIRM1 is not "modded" otherwise it wouldn't pass the bootrom's signature checks, FIRM1 however contains the Kernel9loader which uses the bogus key (at 0x20 from the start of the nand keystore) to decrypt the rest of the FIRM binary (K9L is part of the FIRM container) it will therefore decrypt to garbage, but the nand keystore key has been especially forged/bruteforced so one of the first instructions of said garbage happens to be a jump instruction which branches to an address where our payload (from the previously modified FIRM0) is in memory.

Language barrier, it's hard sometimes to get the idea accross. Already corrected myself here

 

[mathieulh]

Language barrier, it's hard sometimes to get the idea accross. Already corrected myself here

I have just read your updated post. Decrypting FIRM with the right key seems appealing but you need to remember that for the sake of the exploit, a specific version of FIRM1 is used (not to mention a new FIRM with a fixed Kernel9 Loader could be released someday, in which case we couldn't update it to the latest version, not to mention it's a bad idea to keep updating the FIRM partition in the first place as if anything goes wrong, you can't recover (you broke the a9lh), for these reason FIRM is actually loaded from its CXI "container". (you can be sure the first thing that was thought of was to decrypt the FIRM partition)

Either way, there is plenty of space in FIRM0 to add a whole a9lh payload it could also be added to some unused nand area in RAW format I guess.

 

[Wolfvak]

I have just read your updated post. Decrypting FIRM with the right key seems appealing but you need to remember that for the sake of the exploit, a specific version of FIRM1 is used (not to mention a new FIRM with a fixed Kernel9 Loader could be released someday, in which case we couldn't update it to the latest version, not to mention it's a bad idea to keep updating the FIRM partition in the first place as if anything goes wrong, you can't recover (you broke the a9lh), for these reason FIRM is actually loaded from its CXI "container". (you can be sure the first thing that was thought of was to decrypt the FIRM partition)

Either way, there is plenty of space in FIRM0 to add a whole a9lh payload it could also be added to some unused nand area in RAW format I guess.

Exactly why I said somewhere around here (too lazy to find the post now...) that it's *literally* impossible for o3DS users, because you're using a n3DS FIRM, and that you could get it working in n3DS with some trickery, but Luma's approach is way better and works for all systems.

And yeah, I saw AuReiNAND's issues page (it was ARN back then) and some guy was begging for FIRM loading from system...

EDIT: lol the n3ds vs o3ds thing is actually in the first post you replied from me