Homebrew NAND dump verification

[McHaggis]

With the importance of NAND backups in the 3DS hacking scene, I'm somewhat paranoid that a corrupt NAND dump will destroy my chances of recovery if something bad happens. I'm wondering, therefore, if any of the current NAND dumping options offer post-dump verification, like BootMii did on the Wii.

I currently have a backup for each of the consoles in my household, plus backups of my backups in a couple of places. My first Wii was corrupted and I'd lost the original NAND backup I made, so I'm not taking any chances with the 3DS consoles. Any backup is useless, however, if the original dump had any hiccups.

 

[zoogie]

Test it as an emunand. Decrypt9 can restore a nand backup as such.

 

[d0k3]

With the importance of NAND backups in the 3DS hacking scene, I'm somewhat paranoid that a corrupt NAND dump will destroy my chances of recovery if something bad happens. I'm wondering, therefore, if any of the current NAND dumping options offer post-dump verification, like BootMii did on the Wii.

I currently have a backup for each of the consoles in my household, plus backups of my backups in a couple of places. My first Wii was corrupted and I'd lost the original NAND backup I made, so I'm not taking any chances with the 3DS consoles. Any backup is useless, however, if the original dump had any hiccups.

To my knowledge, there are only limited possibilities of verifying a 3DS NAND dump. Decrypt9 (my signature) applies some of them when restoring your NAND dump:

• Size check - in the best case the NAND backup has exactly the same size as the internal NAND flash chip. This check is in Decrypt9 (when dumping and restoring), but some other NAND dumpers (GW, f.e.) don't care the least for the correct size, so a mismatching size must not mean a bad dump.
• "NCSD" magic number check - A good NAND backup has the magic number "NCSD" at byte 0x100 - this is checked in Decrypt9.
• NAND partitions magic number check - TWLN, TWLP, FIRM0, FIRM1 and CTRNAND partitions (when decrypted) are recognizable by their first 8 bytes (also checked in Decrypt9). AGBSAVE doesn't have a unique magic number, but a broken AGBSAVE partition won't hurt much.
• FAT file system integrity check - only possible for decrypted TWLN, TWLP and CTRNAND. Not easy to do and not in Decrypt9.
• Actual checking of files on FAT partitions - only possible for decrypted TWLN / CTRNAND and needs a database of valid files. Would require a ton of work, also not in Decrypt9.

If anyone wants to pick up that task, I guess the list above is a good starting point. For you, @McHaggis, I don't want to self promote too much, but there is no known case of a broken NAND backup from Decrypt9 (my signature). This is in part due to that code in Decrypt9 being deliberately simple and somewhat "unbreakable". I could think about adding a second verification step to the dump option for the extra paranoid, but that would mean the process would take double as long.

EDIT: Have to add to this, even if all the checks above pass, that's still not a 100% guarantee your NAND dump is fine. It is just very unlikely that it is not.

 

[McHaggis]

Test it as an emunand. Decrypt9 can restore a nand backup as such.

That seems like a sensible approach to the problem, thanks.

To my knowledge, there are only limited possibilities of verifying a 3DS NAND dump. Decrypt9 (my signature) applies some of them when restoring your NAND dump:

• Size check - in the best case the NAND backup has exactly the same size as the internal NAND flash chip. This check is in Decrypt9 (when dumping and restoring), but some other NAND dumpers (GW, f.e.) don't care the least for the correct size, so a mismatching size must not mean a bad dump.
• "NCSD" magic number check - A good NAND backup has the magic number "NCSD" at byte 0x100 - this is checked in Decrypt9.
• NAND partitions magic number check - TWLN, TWLP, FIRM0, FIRM1 and CTRNAND partitions (when decrypted) are recognizable by their first 8 bytes (also checked in Decrypt9). AGBSAVE doesn't have a unique magic number, but a broken AGBSAVE partition won't hurt much.
• FAT file system integrity check - only possible for decrypted TWLN, TWLP and CTRNAND. Not easy to do and not in Decrypt9.
• Actual checking of files on FAT partitions - only possible for decrypted TWLN / CTRNAND and needs a database of valid files. Would require a ton of work, also not in Decrypt9.

If anyone wants to pick up that task, I guess the list above is a good starting point. For you, @McHaggis, I don't want to self promote too much, but there is no known case of a broken NAND backup from Decrypt9 (my signature). This is in part due to that code in Decrypt9 being deliberately simple and somewhat "unbreakable". I could think about adding a second verification step to teh dump option for the extra paranoid, but that would mean the process would take double as long.

Thanks for the detailed response, knowing that Decrypt9 doesn't just blindly write the dump back to the NAND puts my mind at ease a little.

 

[d0k3]

Thanks for the detailed response, knowing that Decrypt9 doesn't just blindly write the dump back to the NAND puts my mind at ease a little.

No, writing it back blindly is a beyond bad idea. I have to add though that NAND partition magic numbers are only checked if you inject individual partitions, not for the complete restore. If I checked that, users wouldn't be able to set up the new ARM9LoaderHax with Decrypt9 anymore. It should be safe enough, though, as there where never any reports of problems.