NAND dump verification

Discussion in '3DS - Homebrew Development and Emulators' started by McHaggis, Feb 17, 2016.

  1. McHaggis
    OP

    McHaggis Fackin' Troller

    Member
    1,715
    939
    Oct 24, 2008
    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.
     
  2. zoogie

    zoogie simple pimp tool

    Member
    6,237
    7,896
    Nov 30, 2014
    United States
    Test it as an emunand. Decrypt9 can restore a nand backup as such.
     
    McHaggis likes this.
  3. d0k3

    d0k3 3DS Homebrew Legend

    Member
    2,596
    2,615
    Dec 3, 2004
    Gambia, The
    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.
     
    Last edited by d0k3, Feb 17, 2016
    Thelostrune and McHaggis like this.
  4. McHaggis
    OP

    McHaggis Fackin' Troller

    Member
    1,715
    939
    Oct 24, 2008
    That seems like a sensible approach to the problem, thanks.

    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.
     
  5. d0k3

    d0k3 3DS Homebrew Legend

    Member
    2,596
    2,615
    Dec 3, 2004
    Gambia, The
    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.
     
    Last edited by d0k3, Feb 17, 2016
    McHaggis and Syphurith like this.