wraggster
May 13th, 2008, 16:06
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 /shared2/wc24/nwc24dl.bin
Fill /shared2/wc24/nwc24dl.bin
CreateDir /tmp/sys
CreateDir /tmp/sys/00000000
Create /tmp/sys/00000000/iplsave.bin (empty)
Fill /tmp/sys/00000000/iplsave.bin
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/00000001/00000002/data/tmds.sys
Modify /shared2/wc24/nwc24dl.bin
Modify /shared2/wc24/nwc24fls.bin
Modify /shared2/sys/net/02/config.dat
Modify /title/00010002/48414341/data/NigaoeCh.dat (a savegame?)
DeleteDir /tmp/sys/00000000
CreateDir /tmp/sys/00000001
Create /tmp/sys/00000001/www.arc (empty)
Fill /tmp/sys/00000001/www.arc
Move /tmp/sys/00000001/www.arc to /tmp/www.arc (overwriting, its a U8 file with opera config files)
DeleteDir /tmp/sys/00000001
Modify /shared2/sys/SYSCONF
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.
http://hackmii.com/2008/05/anatomy-of-a-mario-kart-brick-pt-2/
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 /shared2/wc24/nwc24dl.bin
Fill /shared2/wc24/nwc24dl.bin
CreateDir /tmp/sys
CreateDir /tmp/sys/00000000
Create /tmp/sys/00000000/iplsave.bin (empty)
Fill /tmp/sys/00000000/iplsave.bin
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/00000001/00000002/data/tmds.sys
Modify /shared2/wc24/nwc24dl.bin
Modify /shared2/wc24/nwc24fls.bin
Modify /shared2/sys/net/02/config.dat
Modify /title/00010002/48414341/data/NigaoeCh.dat (a savegame?)
DeleteDir /tmp/sys/00000000
CreateDir /tmp/sys/00000001
Create /tmp/sys/00000001/www.arc (empty)
Fill /tmp/sys/00000001/www.arc
Move /tmp/sys/00000001/www.arc to /tmp/www.arc (overwriting, its a U8 file with opera config files)
DeleteDir /tmp/sys/00000001
Modify /shared2/sys/SYSCONF
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.
http://hackmii.com/2008/05/anatomy-of-a-mario-kart-brick-pt-2/