Dump Wii Nand

[Eloisa Stawasz]

TheSHA1 hash of the nand.bin will not match the hash stored in nand.bin.sha1. This is because dumpTool adds additional data known as a no$gba footer to the nand.bin file after the SHA1 hash is calculated. You can use the hiyaCFW Helperopen in new window to create a copy without the footer.

sadly my bricked router is not booting from any dump I provide and flash to the NAND and my options are coming to the end, since the soldering points are getting damaged on the board already.

I already gathered some info on how the NAND layout should look like, but something is not ok with the configuration of the pages/oob, or maybe the tools I have for the NAND flasher are incorrect somehow.

I only have a full NAND image without the oob data i.e. "dd" of the full NAND.

The empty 8 bytes should be for the bad block indication (FDM) I believe, but since my replacement chips I use have so far no bad blocks at all, this are can be empty (correct me if wrong?)

Since the tool creates 7 bytes ECC, the last byte should be unused (correct me again if wrong).

Also have to tell, that wherever I talk about empty byte(s), they are not touched by the util, thus these bytes will be 0xFF. Can this be a problem too i.e. should I provide somehow 0x00-s instead?

You're not even supposed to be writing OOB-data. Taking a dump without OOB and then writing it back at some later point is perfectly fine as long as you're using NAND-aware tools and you erase the flash first, and your settings are correct.

I dumped my ZTE MF286D's NAND without OOB-data, I installed OpenWrt and messed around with the NAND's contents otherwise as well, and yet it worked perfectly well, when I erased the relevant portions of the flash and then flashed the dump back with nandwrite.

The router is not working anymore, so I had to desolder and flash the NAND externally. This means I'm currently not even sure, how it should be prepared, i.e. so far I understand, the flash tool is expecting an image with data + spare data.

In this case it is even more complicated, because regarding to MTK SDK document, the MT7621 is using 512/16 bytes subpages within the normal 2048/64 pages.

So far I didn't find an option to ignore the spare data, so I have the feeling something has to be there. Or maybe you mean I should completely ignore the spare data (ignore oob completely) and just try to leave it empty? Note that from the aspect of the flash tool, empty means 0xFF-s.

NAND Flash Memory is the built in memory of the Wii console. It houses save data, downloaded channels, and the Wii Menu. Some games may require files only found in a full NAND dump to work correctly. The easiest way to do that is with BootMii. For alternate methods, see the forum thread.

Access BootMii through the Homebrew Channel. Use a GameCube Controller or the Power and Reset buttons to navigate through the BootMii menus, as detailed here. Select Options (gears icon) on the far right. Select Backup NAND (Green arrow from chip to the SD card), and wait until it completes. Once completed, remove the SD card and put it into your system. You should see a file named nand.bin on the SD Card. If you do, your NAND has been backed up.

Place the files nand.bin and keys.bin that you've acquired from the last section into the working directory, open cmd.lnk (A shortcut file that will open a command prompt in the current directory), and then type the following commands into the prompt:

I love to reverse engineer many things I can access to and learn from the ingeniosity of engineers who worked on the things I study. In this one I was surprised because this was my first hardware reverse engineering experience and the vendor had done a pretty neat job securing it.

I had to desolder the NAND Flash memory and do a bare read on it. I first thought that once I had my NAND Flash dump it would be easy to recover the firmware. I was wrong, and I struggled several weeks to recover data, Error Code Correction (ECC) bytes and to understand the ECC used to correct bytes (I really needed it).

After struggling several weeks with this, I finally obtained valid data decoding the PMECC codes left by the processor in the spare areas of my chip. Because the PMECC mechanism lacks online documentation allowing to reimplement it in software, this post is like a memo for me if encounter this situation again and a technical description on the dumping process for anyone interested.

Fortunately, the vendor marks bad blocks into a special area of some pages of the blocks affected. I learned how it works with the datasheet obtained by typing the chip reference in my favorite search engine. In my case, this marker is integrated in the first byte of the magical spare area of the first, the second or the last page of the block. If none of these bytes is set to 0xFF, the block is bad.

Oh by the way in my case pages are 2048-byte long, spare area is a 64-byte long space after each page and a block is 64 pages. A standard, the ONFI interface, allows to query the chip to know its capabilities and properties.

And this is why NAND Flash controllers implement a Error Correcting Code when managing such devices. So the board I was analyzing had an AT91SAMA5D31 SoC as main CPU. This model (according to the datasheet) accelerates ECC with an hardware implementation of the BCH algorithm.

As I said earlier, the blocks in a NAND flash have a limited supported erase/program cycle number. So to balance the writing load on the memory chip, a process known as wear leveling is used. In my case, this is implemented at software level in the Linux kernel.

The modern technique, implemented in my case, is the UBI (Unsorted Block Image) volume management system. This system adds information to each block that includes volume number, erase cycle number of the block or the Logical Erase Block correspondance with Physical Erase Block.

To achieve the wear leveling, the UBI system maps LEB to PEB in order to allow relocation of LEB on another physical block in the event of a write operation. Each of these blocks can then be attached to a particular volume containing a filesystem.

But it is impossible to use classical filesystems in this case because Flash Memory are not a classical block device. And in fact, USB sticks and SD cards trick the OS into making it think they are block devices with a dedicated microcontroller on the chip. This is not the case here and I observed 4 types of (not always) filesystem in my case :

The ECC logic required by NAND (discussed above) is the main reason you MUST use NAND-aware tools like nanddump and nandwrite instead of the more common dd tool to create or restore a backup of the flash partitions on NAND.

I'd like to dump my current firmware from NAND flash via uboot + serial but I don't know which parameters to use. Count number seems to be the size of the flash in bytes.

But how do you get the offset values? bootm according to the link is at 0x9f020000

but pepe2k starts dumping at 0x9F000000. Is this just a typo or is there a specific reason?

I'm also wondering why you don't start at offset 0x00000000. According to mtdparts uboot starts at this address, with ubootenv, config, kernel ... following.

U-boot starts at 0 relative to the flash start. Where the flash itself is located it hardware dependent. If you want to know the offset values for your hardware, have a look in the dts file for your hardware.

So the uboot address which I get from mtdparts is not the real address, uboot does not really start at 0x0 (beginning of the NAND flash?) ?

I could not find any dts. Is there some other way to get the address. uboot env shows the address for bootm which at least according to the link should be the address where the flash starts.

Depending on the architecture, it may have a first-stage bootloader in the chip, which calls a second-stage boot loader (sometimes called "SBL") from flash (typically at 0x0), which may then call something like U-Boot at another location.

When I run "mtdparts default" (not sure if this is the correct procedure) and then "mtdparts" it will show uboot starts at 0x0. So I guess the SBL in this case is uboot.

Are the addresses for RAM memory and flash memory in any way related?

Currently I run "md.b 0x20200000 134217728" which is supposed to dump the whole flash. When using the wrong offset could I dump accidently the RAM region?

The dump is currently around 100 MB so at least I'm sure I did not just dump the RAM somehow up to now.

Typically, no. Flash is generally copied to RAM prior to execution. For something like a kernel, it needs to be placed somewhere that it won't overwrite itself as it extracts itself and begins to execute.

The methods listed in this guide require a working modified console that can run homebrew programs. If you need to dump the NAND of a retail or bricked console, you need to follow the corresponding guides for a 4 GB Corona/Waitsburg/Stingray NAND or all other NAND types.

By default, if you boot XeLL with an ethernet cable is plugged in, it will either pull an IP from your router via DHCP or it will use the default IP of 192.168.1.99 if you are not connected to a router. You must unplug any wireless USB adapters if you have them plugged in, as it will halt the boot process. By entering the IP address shown toward the bottom of XeLL on a web browser, it should pull up a XeLL Reloaded web page. The following are displayed:

The first thing we typically do with a NAND dump is run it through a carvingtool like binwalk to get an overall idea of its contents. This image wasfairly small, and only came back with a few results.

3a8082e126