Hacking Updating sysnand without FIRM protection...

[metroid maniac]

What happens of you update the sysnand of a console with a9lh while funning a CFW that does not protect the FIRM0/1 regions of NAND?

Does the console update normally, and effectively become unhacked? Does it brick because of the tampered keystore, or some other reason? Does it depend on 3DS model (old/new)?

I'd try but my console is not NAND modded!

 

[Space_Goddess_Samus_Aran]

it becomes unhacked

--------------------- MERGED ---------------------------

you have then ofw 11.1 (you cant hack it anymore until you make a dsiware dgrade)

 

[Garro]

I think it bricks, there were some issues back with CakesFW since the Firmware Protection feature could be enabled/disabled, plus, pressing B in the features menu would quit the menu without saving changes so many people enabled the option and pressed B without realizing the option was still off and ended bricking their 3DS when they updated. You might find old threads about this if you search deep enough.

EDIT: Post I found in reddit: AKA. Only n3DS would brick:

EDIT2: Ninja'd by the post below :X

 

[Goombi]

On O3DS you won't brick, just have an updated console (because O3DS FIRM doesn't care about the keystore). However a N3DS will brick, because of that tampered keystore that is not set back to normal when you update.

 

[metroid maniac]

On O3DS you won't brick, just have an updated console (because O3DS FIRM doesn't care about the keystore). However a N3DS will brick, because of that tampered keystore that is not set back to normal when you update.

Thank you, that's exactly what I thought would happen.

So let's consider the N3DS. If you restore a clean secret sector then the console will boot the clean FIRM1 and you can proceed to update to remove a9lh. Right?

 

[Goombi]

Would be much safer to use the uninstall function of SafeA9LHInstaller imho. But in theory, just restoring the keystore would boot FIRM1 (since FIRM0 is still invalid). And from there, updating without FIRM-write protection would restore FIRM0 and FIRM1 to legit states. The only thing left would the the stage_2 payload, written in FIRM1 (iirc) partition but beyond the actual space used by the FIRM (= in some NAND sectors never read in legit uses of the console).
Keep in mind this is theory and I wouldn't attempt it without hardmod

 

[metroid maniac]

I wasn't actually aware SA9LHI had an uninstall function, I guess I never found it. O.o

So stage2 is just stored in some of the extra space allocated to FIRM1, but not used by the currently installed FIRM1? That's another mystery that was bothering me solved.

 

[Goombi]

I wasn't actually aware SA9LHI had an uninstall function, I guess I never found it. O.o

So stage2 is just stored in some of the extra space allocated to FIRM1, but not used by the currently installed FIRM1? That's another mystery that was bothering me solved.

Yep. stage1's only job is to read the sectors where stage 2 is and jump to it (since stage 1 is extremly contrained in space).
Side note: stage1 is encrypted on NAND as being in the FIRM0 loaded. stage2 is cleartext since stage 1 has to be so small, it currently did not bother to embed the ARM9 crypto lib. That means a hardmod can dump your nand and change stage 2 (I'm a paranoid, currently looking into a secured boot chain from A9LH).

 

[metroid maniac]

Yep. stage1's only job is to read the sectors where stage 2 is and jump to it (since stage 1 is extremly contrained in space).
Side note: stage1 is encrypted on NAND as being in the FIRM0 loaded. stage2 is cleartext since stage 1 has to be so small, it currently did not bother to embed the ARM9 crypto lib. That means a hardmod can dump your nand and change stage 2 (I'm a paranoid, currently looking into a secured boot chain from A9LH).

How big is the crypto lib? Last time I checked there's about a ~2KB difference between the FIRM0 and FIRM1 and the current stage1 is about 1.5KB big.

That's not much wiggle room. But it'd be really cool if stage2 were encrypted with the OTP hash to ensure a secure boot process.

 

[Goombi]

How big is the crypto lib? Last time I checked there's about a ~2KB difference between the FIRM0 and FIRM1 and the current stage1 is about 1.5KB big.

That's not much wiggle room. But it'd be really cool if stage2 were encrypted with the OTP hash to ensure a secure boot process.

According to SafeA9LHI MAX_STAGE1_SIZE (0x1E70 ~ 7.5KB), it should be fine to add it. I don't have my dev env right now but I'm sure it will fit.

 

[metroid maniac]

According to SafeA9LHI MAX_STAGE1_SIZE (0x1E70 ~ 7.5KB), it should be fine to add it. I don't have my dev env right now but I'm sure it will fit.

Oh right, I was just checking the firm bins in the a9lh install directory I had from before. I now see that it's a 4KB difference, unlike what I thought I saw before... Either way, 4KB or 7.5KB, it's significant and I think it'll be possible to implement some stage2 crypto in there.

I'm excited to see what comes of that idea anyway.