Hacking Downgrading sysnand: what are the issues?

[mashers]

I gather there is a question over whether downgrading sysnand is even possible, and this has made me curious. NAND is just flash memory, so it should be possible to write anything to it. The system clearly already has write access to this (for updating). If a flashcart is used to enable running homebrew, could homebrew software write to the NAND flash? Alternatively, if this wouldn't work, could the flash memory be physically accessed and written to directly? In any case, if there were a method of writing to the NAND would it even work to flash it with a dump of an older FW version?

 

[dedChar]

Well, it would need to be an older fw, which was on the 3ds before already, because every NAND is 'married' to one console.
But on the other hand, gateway has an ability to downgrade an o3ds to 4.5 (the o3ds needs to be on =<9.2 to launch gw menu, to perform the downgrade.)

 

[mashers]

Ahh ok, so you can't use a 'generic' NAND image?

 

[dedChar]

Ahh ok, so you can't use a 'generic' NAND image?

No, you can't.

Maybe if we get a NAND dump from a never launched console, it could be possible somehow, but I'm only speculating here and could be completely wrong.

 

[mashers]

Or perhaps a method of taking an existing NAND dump and changing it so it's linked to another console using whatever method indicates that the correct NAND is booting on the console. Surely comparing the NANDs from several systems would give clues about what the difference between them is and how they can be modified to boot on a different console? Hopefully these investigations are already underway with some of the teams.

 

[Typhin]

The contents of the NAND memory are encrypted using console-specific information and with security keys known only to Nintendo. Any alteration renders the signature invalid, which will prevent the system from booting, preventing a "generic" or custom firmware from being installed. Because it includes console-specific information, it is impossible to use a NAND backup from any other console.

I believe Gateway's downgrading uses the official update process to "trick" it into "updating" to the lowered firmware, but the firmware still has to be the official version that comes from Nintendo and has been signed with their security keys. (However, I'm not an expert, so that's just my personal theory.)

If Nintendo's keys were ever discovered, it would be the "holy grail" for both piracy and homebrew, as it would allow any outside code to be signed as if it came from Nintendo, and thus able to run on any system, any firmware. The only way to block it would be for a later System Version to both change the key used AND include a thorough whitelist of every single officially-released software with checksums, and even that wouldn't work too well since an older, compromised system can basically run something like emuNand to get around that restriction. The Chain of Trust would be shattered from the beginning.

 

[mashers]

Thanks for the details info Typhin! That was very interesting. So essentially the only hope for a downgrade option would be for somebody to discover the encryption keys

 

[Typhin]

Thanks for the details info Typhin! That was very interesting. So essentially the only hope for a downgrade option would be for somebody to discover the encryption keys

For a true downgrade, that's mostly correct. A new exploit could be found that would allow downgrading in the same way Gateway currently does it, but there's no telling when or if that will ever happen. There would likely be some limitations, depending on the nature of the exploit, though. Discovering the keys would allow arbitrary code to be executed as sysNand, whether it's any desired official firmware or a custom firmware.

 

[EmceeKerser]

You do of course have the Hardmod method too, but you need your own NAND dump for this too.
Hopefully someday we get the keys to allow for CFW autobooting.

 

[froggestspirit]

If hypothetically, 3 people all dumped their nand after updating to the latest firmware, and formatting their nand, Would the location of MSET be the same in all 3 dumps? Basically, if we know the location of MSET, even if it's encrypted, we can create an xor pad for that region because we know what mset is when decrypted, and... with an xor pad, could encrypt mset 4.x?
This could be tested by updating a few emunands, and formatting them, then decrypting them to see where MSET resides