HackMii

Notes from inside your Wii

HackMii header image 1

Anatomy of a Mario-Kart Brick, pt 2

May 13th, 2008 by bushing · 11 Comments

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:

  1. Compare two dumps against each other
  2. 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:

  1. Create /shared2/wc24/nwc24dl.bin
  2. Fill /shared2/wc24/nwc24dl.bin
  3. CreateDir /tmp/sys
  4. CreateDir /tmp/sys/00000000
  5. Create /tmp/sys/00000000/iplsave.bin (empty)
  6. Fill /tmp/sys/00000000/iplsave.bin
  7. Create /tmp/www.arc (empty)
  8. This is a big change:
    1. Move /tmp/sys/00000000/iplsave.bin to /title/00000001/00000002/data/iplsave.bin (overwriting old one)
    2. Modify /title/00000001/00000002/data/tmds.sys
    3. Modify /shared2/wc24/nwc24dl.bin
    4. Modify /shared2/wc24/nwc24fls.bin
    5. Modify /shared2/sys/net/02/config.dat
    6. Modify /title/00010002/48414341/data/NigaoeCh.dat (a savegame?)
  10. DeleteDir /tmp/sys/00000000
  11. CreateDir /tmp/sys/00000001
  12. Create /tmp/sys/00000001/www.arc (empty)
  13. Fill /tmp/sys/00000001/www.arc
  14. Move /tmp/sys/00000001/www.arc to /tmp/www.arc (overwriting, its a U8 file with opera config files)
  15. DeleteDir /tmp/sys/00000001
  16. 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 CommentsTags: · , , ,

Autopsy of a Mario-Kart brick (part 1)

May 8th, 2008 by bushing · 61 Comments

I have a “bitch” Wii — a Wii that I use specifically for testing out NAND flash hacks.  I bought it on eBay, and it came with a broken drive — not a modchip disaster, but an actual launch-day Wii with an expired warranty.  It had never been connected to the network, and had only played 4 or 5 games — so it only contained IOS9.  It’s about as close to a “virgin” Wii as I ever expect to see.  (I’ll refer to this often as my “ios9wii”).

Before playing, I backed up all of the contents with my Infectus.  I then booted a PAL copy of Mario Kart.  It recognized the disc, and told me it needed to install an update.  It started to update, but never finished — after about 30 minutes, I decided it was probably a lost cause, and power-cycled it.  I was greeted with this, a slight variation on a theme:

Mario Kart-PAL brick (NTSC system)

I then dumped the flash again (90 mins), and then flashed back to the original dump (6 hours 🙁 🙁 :().   We can now compare the two to see what happened.

This may not be the best comparison possible, since so many other changes happened between IOS9 and IOS36 — if I need to, I’ll pick a different route to brick.

The easiest way to start is by extracting the contents of each dump — before and after — with Segher’s zestig utility.  Then, we compare the two.  We get:

Only in ios9wii:

  • /shared2/sys/net/config.dat
  • /title/00010000: 0000dead, 00555044, 3132314a, 31323245, 3132334a, 52504c45, 52544845
  • /title/00000001/00000100/00000000.app
  • /title/00000001/00000101/00000000.app

Only in mkart-bricked:

  • /shared1: 00000001.app – 00000025.app
  • /shared2/sys/net/02/config.dat
  • /shared2/test2/nanderr.log
  • /shared2/wc24: nwc24dl.bin, nwc24fls.bin
  • /ticket/00000001: 0000000b.tik – 00000024.tik
  • /ticket/00010008/48414b50.tik
  • /title/00000001/00000002/content: 000000{3b,3c,3d}.app
  • /title/00000001/00000002/data/tmds.sys
  • /title/00000001/00000100/content: 00000001.app, 00000002.app
  • /title/00000001/00000101/content: 00000005.app, 00000006.app
  • /title/00000001: 0000000b – 00000024
  • /tmp/sys
  • /tmp/www.arc

Modified between dumps:

  • /shared1/content.map
  • /shared2/sys/SYSCONF
  • /shared2/wc24/mbox: wc24recv.ctl, wc24recv.mbx
  • /shared2/wc24: nwc24msg.cbk, nwc24msg.cfg
  • /sys: space.sys, uid.sys
  • /ticket/00000001: 00000002.tik, 00000100.tik, 00000101.tik
  • /title/00000001/00000{002,100,101}/content/title.tmd
  • /title/00000001/00000002/data: cache.dat, cdb.vff, iplsave.bin, state.dat

 
There are so many new files in the mkart dump because it installed all of the new versions of IOS. Also, in the process, it moved some files (e.g. config.data). Titles 1-2 (System Menu), 1-100 (BC) and 1-101 (MIOS) were upgraded. These also placed files in /shared1.

We can safely ignore the WC24 stuff. We can also ignore the added tmds and tickets for the new IOS versions, and all the files associated with the upgrades for 1-2, 1-100, 1-101. The title directory for 48414b50 has no data or contents. The /tmp files are interesting, because it shows we were in the middle of an operation — more on that later.

It’s getting late and I’m tired, so I will have to continue this later. However, I do have some goodies for those of you that want to dig into this yourselves:

ios9wii dump skeleton (zip file)
mkart-bricked directory skeleton (zip file)

(Note, the above archives have some of the “content” files removed to avoid legal issues and to save on bandwidth. They aren’t relevant to this discussion, anyway.)

I’d welcome any theories as to what the specific problem is, based on the contents of those two zip files.

Here are the files I will be talking about tomorrow — take a look and see what useful data you can extract from them:
ios9_fs_metadatabin.bz2
mkart_fs_metadatabin.bz2
mkart-sffs.zip

→ 61 CommentsTags: · , ,

amoxiflash binary for win32

May 6th, 2008 by bushing · 15 Comments

Just a quick post on my way to bed:

 

I did some hacking around, and was able to get amoxiflash to build under XP.  I’ve posted a binary for Windows here: amoxiflash-win32-02.   In order to run it, you will also need to install the libusb-win32 filter from here: libusb-win32 filter driver

Of course, the source is included there (for what I’m calling “Version v0.2”), and you can compile it under Mac OS X and Linux, too!  I’ve tested it a bit under Windows, but I make no promises.  On my MacBook Pro using VMWare and XP, it seems to run at about half speed under Windows as compared to natively under OS X.  Ideas for improving the speed would be greatly appreciated.

Here’s the current usage info:

 

 

amoxiflash version 0.2, (c) 2008 bushing
Usage: ./amoxiflash command -[tvwdf] [-b blocksize] filename
          -t            test mode -- do not erase or write
          -v            verify every byte of written data
          -w            wait for status after programming
          -f            force: ignore safety checks. Dangerous!
          -d            debug (enable debugging output)
          -b blocksize  set blocksize; see docs for more info.  Default: 0x2c0
          -s blockno    start block -- skip this number of blocks
                        before proceeding

Valid commands are:
         check        check ECC data in file
         strip        strip ECC data from file
         dump         read from flash chip and dump to file
         program      compare file to flash contents, reprogram flash
                        to match file

 

 

It seems to be a bit fragile under Windows — if you see something like this, then unplug the Infectus from your computer, power the Wii off, turn the Wii back on (shorting D0 while doing so), plug the USB cable back in, and try again:
amoxiflash bad

Here’s what you want to see:

amoxiflash good

 

As always, the source is available in Subversion.

 

→ 15 CommentsTags: · ,