Posted By: wraggster
New from Bushing
Work with the Homebrew Channel has taken more time than I’d hoped — but I don’t want to lose momentum, so let’s press forward here, too.
In a comment in my previous post, Galtor correctly picked up the path I was planning to go down, based on the files I linked to at the end. There are two different ways we can look at Wii dumps, even if we don’t know any of the crypto keys:
Compare two dumps against each other
Compare different filesystem versions against each other within one dump
If you just naively try to compare data between dumps, you see an overwhelming amount of changes. Let’s try the second approach. Galtor writes:
Based on “mkart-sffs.zip” this is the timeline:
Create /tmp/sys/00000000/iplsave.bin (empty)
Create /tmp/www.arc (empty)
This is a big change:
Move /tmp/sys/00000000/iplsave.bin to /title/00000001/00000002/data/iplsave.bin (overwriting old one)
Modify /title/00010002/48414341/data/NigaoeCh.dat (a savegame?)
Create /tmp/sys/00000001/www.arc (empty)
Move /tmp/sys/00000001/www.arc to /tmp/www.arc (overwriting, its a U8 file with opera config files)
The last four megabytes of the NAND dump contain an unencrypted block of filesystem metadata, which we can divide into 16 pieces. Every time the filesystem changes, it rotates to use the next of the 16 blocks, and when it gets to the last one, it goes back to the first one. Thus, we can see the last 16 things that happened in the NAND fs.
We can see a few common themes here:
Background writes to the nwc24 stuff — I do not think there is any correlation between these and anything else that’s happening. They just happen from time to time. It’s probably updating timestamps or something
Many file writes are done by creating a file in /tmp, writing it, and then moving it to its final location. This is actually good design. Yay, Nintendo! (Hey, we have to give them props when we can…)
Something not noted here, but I believe that /tmp is erased whenever the Wii reboots (or more correctly, whenever IOS reboots, meaning that it is cleared when you load a channel or a disc).
One hope I had here was that maybe we could actually see the bricking take place here, but I’m not so sure. We’re only seeing a few seconds’ worth of writes, and it may just all take place during every single boot to the system menu.
Another idea which I don’t think will work would have been trying to “roll back” to an earlier of the 16 generations, but again that wouldn’t help, because the damage has already happened.