Questions: about NAND dumps

[mariomadproductions]

Online, you can find NAND dumps like "nand-dp-hvc-release-v1.0.5-0-g2f04d11.bin"
I have a few questions (note I don't actually own a NES/SNES/ Classic, but i'm trying to document the different NAND images):

• Where is the info in the filename from? Is this the filename produced by hakchi when dumping the NAND? Are NAND files like these 1:1/encrypted/unmodified NAND images?
• Do NAND images containing the same system version differ between different console instances?
• Does NES/SNES classic contain any non-volatile storage other than the NAND?
• Is the kernel just a portion of the NAND image?

[DanTheMan827]

The files are named based on the information in the /etc/issue file

Welcome to CLOVER dp-hvc-nerd release-v1.0.5-0-g2f04d11
BuildId final.cis.vm-cis-deb9-05.20160830121127CEST

The .hsqs files are a dump of the read-only squashfs partition on the nand, hsqs comes from the start of the file, they're all the same from system to system for each version.

The hakchi wiki has some information about the kernel and squashfs versions... the kernel is technically part of the boot image that also contains a ramdisk, but people called the boot image the kernel and that just stuck...

There's no non-volatile storage other than NAND, but it is possible to solder an SD card internally

The kernel is part of the RAW NAND before the logical partitions start, the same is true of the uboot.

[mariomadproductions]

Thanks for the answers.

Got a few more questions just to clarify

1. Between two instances of an unused console of the same production run, the raw NAND image would be binary identical?
2. How can I tell which region of a full NAND dump contains the kernel, to extract to a seperate file for use with this tool? https://github.com/DeadlySystem/ninspect
3. is there anywhere that lists hashes for the raw NAND dumps?

[DanTheMan827]

raw nand dumps will always be different because they contain information unique to each system, as such there's no hash list for raw dumps either

That's the first time I've actually seen this tool... unless you're using a very old version of hakchi the tool shouldn't need the kernel image beforehand for unpacking the raw image since it could just extract the kernel from the raw image itself, but given the age of that tool I'm guessing it was made before hakchi created the backup kernel on the nand itself and would therefore need a key to decrypt the rootfs or the original kernel backup.

[mariomadproductions]

What unique info is this? Would it be possible to overwrite that data with static data (e.g. 0x00 or 0xFF bytes), or is there encryption that would complicate that?

Is there a newer/different tool that can be used to extract the NAND dumps?

[DanTheMan827]

sorry I didn't respond earlier, but the unique information is stuff like information about the bad blocks present on the nand

raw dumps will also be different every time because they contain the user data partition which stores things like saves and information like the partition GUID and times it has been mounted... things like that.

As far as dumping the information, there are four important parts

• boot0
• uboot
• the boot image containing the kernel + ramdisk
• the root fs squashfs partition

All of these can be obtained from the raw bin file, but for the root fs partition it requires some additional processing that I don't personally know how to do, the other three are just located at different offsets according to the sunxi documentation

There's also two different raw bin formats, the one dumped with the old version of hakchi2, and the one dumped with hakchi2 ce, those two handle placement of bad blocks differently in the output

[PokeyManatee4]

raw nand dumps will always be different because they contain information unique to each system, as such there's no hash list for raw dumps either

That's the first time I've actually seen this tool... unless you're using a very old version of hakchi the tool shouldn't need the kernel image beforehand for unpacking the raw image since it could just extract the kernel from the raw image itself, but given the age of that tool I'm guessing it was made before hakchi created the backup kernel on the nand itself and would therefore need a key to decrypt the rootfs or the original kernel backup.

Its New And Its Own Tool BTW It Uses Kernel And Nand Dumps To View @DanTheMan827
And Srry Im Just Talking Bout It Now BC I Just Learned Bout CE