Hacking Check nand integrity on pc using the .SHA files?

[Altairseven]

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?

 

[gnmmarechal]

Use a sha-calculating utility on PC.
This should do the job.
https://sourceforge.net/projects/quickhash/

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

And compare the hashes.

 

[The Real Jdbye]

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?

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.

 

[Altairseven]

(open the .sha file in a hex editor)

ahhhhh. that was the part that i had issue with, thanxs

 

[gnmmarechal]

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.

It's SHA-256 iirc

Sent from my Nokia 3310 using Tapatalk

 

[HyperT]

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.

 

[gnmmarechal]

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.

Twice in a row, as well. The NAND changes between boots, doesn't it?

 

[HyperT]

Twice in a row, as well. The NAND changes between boots, doesn't it?

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]

 

[The Real Jdbye]

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.

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.

 

[gnmmarechal]

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]

It *could* have the same number of bytes, and still be corrupt.

 

[The Real Jdbye]

It *could* have the same number of bytes, and still be corrupt.

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.

 

[HyperT]

It *could* have the same number of bytes, and still be corrupt.

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.