hi, after reading a post about someone that had a bad emunand backup to restore after a9lh installation, and something similar happening to me due to a bad sd, but thankfully with a good copy on my pc, i got a little worried, and started thinking. what is the best way, if any, to check in my computer the integrity of the backup file using the .sha generated by the latest versions of otphelper, decrypt9 emunand9 and hourglass9?
Use a sha-calculating utility on PC. This should do the job. https://sourceforge.net/projects/quickhash/ — Posts automatically merged - Please don't double post! — And compare the hashes.
Just compare the hash (open the .sha file in a hex editor) with one generated by a hash tool, on Windows I like to use HashTab since it integrates into the Explorer properties window and is very simple to use: http://implbits.com/products/hashtab/ For HashTab you may need to edit to the settings to enable the hash type that the 3DS tools are using, I'm not sure if it's SHA-1 or SHA-2 256/384/512, but HashTab supports them all.
All that will do is check that the nand.bin's sha matches the bin.sha file; this doesn't really ensure that the bin isn't bad [i.e. a corrupted dump] as the sha's would still match; and besides hourglass9 checks the shas before flashing anyway. What you'd need to do is dump nand twice and check they're identical - via the sha's. Checking the sha's on PC I guess would be useful if you are using a version on decrypt9/hourglass9 that doesn't have sha checks.
Yea, you're probably right. I know that every time a nand is mounted rw; the sha of that nand changes. So if the 3ds nand is mounted rw on boot [at least on cfw] then yea the sha's will be different. Does anyone know if the file-size check is fool-proof or could a corrupted backup still spit out the correct number of bytes [I'm guessing not]
Hourglass9/Decrypt9 probably generate the hash while reading the NAND, so if any corruption occurred on the SD card even if it was during writing, the hashes wouldn't match. The chances of reads failing without an error, leading to corruption, are infinitesimally small, it's much more likely to corrupt during writing. You are right though, if someone is paranoid and wants to be 100% sure then making multiple NAND backups is the only way. But something would have to be wrong with the NAND itself for the reads to fail (unless there is a serious bug in the homebrew apps) and at that point you are pretty much screwed anyway. Anyway, in OP's scenario (bad SD card), the SHA checksums wouldn't match and a checksum tool would tell him that, so I think it answers his question. Verifying the checksum on a PC wouldn't be necessary in most cases, except if someone forgot to copy over the .sha file they wouldn't be able to tell if a backup was corrupted.
This is true. Checking the size is only a way to make sure you didn't get an incomplete dump. A dump can be complete and still be corrupted. Decrypt9 and Hourglass9 have been perfected to such a degree that it should never happen, though a faulty or fake SD card can cause it. Personally, I'm more worried about the restore process failing/glitching up than the dump itself being corrupted. But I always overthink things and worry a lot.
Yea didn't want to post too much possibly stuff in 1 go; but I had figured if hourglass reads/writes in batches then if the last batch writing fritzes out it could write garbage/00s/FFs and still give the right number of total bytes. @The Real Jdbye I think the OPs question was more theoretical; as they have a backup on PC prior to the sd corruption.
