Implement safety/sanity checks before NAND writing

Nuck-TH / fwTool

Work on improving fwTool and making it a bit more safe

10 stars 3 forks source link

Implement safety/sanity checks before NAND writing #1

Open Nuck-TH opened 7 years ago

Nuck-TH commented 7 years ago

fwTool needs to be more safe when it comes to writing NAND image.

[x] Check if sizes of NAND and file are same
[x] Check and notify if NO$GBA footer present if size is correct(yes, such case works in NO$GBA!)
[x] Check for presence of MBR (not encrypted file)
[x] Check battery level
- 2/more bars or charger connected

Will leave this open for ideas and tracking.

mariogamer2 commented 7 years ago

I don't see how the third point will help.

Nuck-TH commented 7 years ago

Prevent writing nand with low battery level where shutdown may occur(especially may happen with old worn out batteries). Not entirely my idea btw.

cualquiercosa327 commented 7 years ago

Check if they are plenty space on the sd before begining to dump the nand.

Jimmy-Z commented 7 years ago

Does fwtool currently create a hash file with the dump and verify it before writing? Like similar 3ds tools? If not, should be a necessity I believe?

Sorry I would love to give you a pull request but I don't have a working exploit so I can't test. and also sorry if fwtool already does this.

Jimmy-Z commented 7 years ago

And, is it possible to acquire Console ID on device? If not, force the user to provide it in a file along with the NAND image, then use it to decrypt a little bit(like 16 bytes from 0x1f0 for 00...55aa like you did in the MBR check) of NAND(not the NAND image, read out the NAND on device) to verify the Console ID.

Then it could try to decrypt the NAND image to see if it's indeed correspondent to the Console ID and EMMC CID thus to this DSi.

Then again, use FAT lib to scan the file system.

Then again again, read out dev.kp for another Console ID verification, in case the user provided a (decrypted) dump from another device (and encrypted using correct IDs).

Nuck-TH commented 7 years ago

I think that such extensive checking is too much for a simple tool like this, because checking code will outweight code of the tool itself. This changes was intended to save from easy mistakes. And if user is completely oblivious of what they are doing, they still will find a way to screw things up, no checking will help that. As you said on gbatemp - "they are doomed to fail". Btw, i am comlete zero in cryptography, so i won't be able to implement such checks right away. For now i'm not exactly up to digging in that topic. And second btw - scanning filesystem is one step from nand file manager, which is out of scope of this app as well.

Nuck-TH commented 7 years ago

Does fwtool currently create a hash file with the dump and verify it before writing? Like similar 3ds tools? If not, should be a necessity I believe?

No, it doesn't. However, how it is supposed to help, if fwtool if often used to write modified image? Also, computing hash of image takes some time even on computer, so it will make restore process on dsi just annoyingly long.

Jimmy-Z commented 7 years ago

Yeah the code size would be quite bigger, especially the FAT code, but why is that a bad thing?

The hash is mainly for preventing brick from corrupted sd cards, even if you could "check" it before hand, a hash file is better to ensure the dump is good.

Common hashes can't be too slow for such a small size, even on DSi CPU, if you are really afraid of the overhead, a simpler checksum like CRC32 or adler32 could suffice, it's just for integrity check, not authentication.