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.
11 responses so far ↓
1 James B. // May 13, 2008 at 5:38 am
Nintendo always get something right.
Too bad the rest of the system is pretty messed up :P.
Good luck, I don’t think you need it though!
2 svenk91 // May 13, 2008 at 5:48 am
is there a list with all things nintendo have done right? (the list with done wrong would be to big to read i geus :X)
is there naything we noobs can do to help with finding out more about this?
3 Jespertje // May 13, 2008 at 8:31 am
Yes, you could make a list with all thing nintendo did wrong! That would be fun to read…
4 Newbie // May 13, 2008 at 8:57 am
Every time the filesystem changes, it rotates to use the next of the 16 blocks
Sounds like a circular transaction/redo log. Although the design is well known I don’t remember Nintendo being among leading database or even file system developers…
Background writes to the nwc24 stuff
Another conclusion from here – if nwc24 is disabled, would it stop changing NAND [every twenty minutes or so]? Sorry for distracting from main topic again…
Another idea … “roll back” … the damage has already happened.
They might had this idea in initial design and realized later they don’t have unlimited transaction log 🙂 So it’s good for postmortem analysis only…
5 wurst2000 // May 13, 2008 at 1:11 pm
> They might had this idea in initial
> design and realized later they don’t
> have unlimited transaction log
I don’t think that they aimed for a roll-back feature (Aka SnapShot) while developing the FS.. They just wanted to create a filesystem for flash devices. (…and in the end, flash-filesystems almost always turn out to be WAFL/LogFS like)
6 dorkbot // May 15, 2008 at 4:33 am
the metadata rotates to avoid flash device decay
If they write on the same spot they reach the x00000 times of write limit
7 nerdyone255 // May 15, 2008 at 9:55 am
@bushing: from another post you said;
“Superken7: The one “saving grace” here is that we can download the System Menu contents from the Nintendo server, including the valid, correctly signed TMD, and assemble a WAD that does not need to be fake-signed. If you want to install it using an update partition on a disc, well, yes, we will have to Trucha-sign that — but the part that gets installed on the Wii will have a real, intact signature.
I made one of these ISOs for NTSC for a friend — if people are interested, I could make some for the other regions, too.”
would said iso fix a mkw brick? ive got a semi, my nstc was semied with mkw pal. im guessing 3.2u would fix it, but obviously cant get online to dl it…
8 Newbie // May 15, 2008 at 10:10 am
@dorkbot
the metadata rotates to avoid flash device decay
If they write on the same spot they reach the x00000 times of write limit
This is called “memory wear”.
It’s interesting to know does Wii NAND perform “wear leveling” itself or does IOS takes care of it?
9 Mark // May 15, 2008 at 11:09 pm
@nerdyone255/bushing: without trying to detract from this important work, I’m also interested in this method of fixing a semi-brick. Maybe after you’ve worked this out?
10 DisizDream // May 17, 2008 at 3:12 am
@nerdyone255/bushing/Mark : I would also be interested in this, just like nerdyone255 I need the 3.2u update because of a mkwii semi brick
11 bushing // May 17, 2008 at 6:22 am
@5-7 — yes, we are all talking about the same thing. It’s for wear-leveling but also probably to help with data integrity in case of a partial write. And at least I had hoped we could roll-back, but yes, all we can do is post-mortem. Oh well.
You must log in to post a comment.