HackMii

Notes from inside your Wii

HackMii header image 2

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

Tags: Wii

61 responses so far ↓

  • 1 Newbie // May 15, 2008 at 10:01 am

    @bushing
    In my experience, when I’ve had interference from IOS trying to access the chip while I was dumping using hardware (before I knew better)
    Do you mean your pushbutton trick with grounding D0 to halt everything?

    Another question:
    Do you read in raw mode 2048 data + 64 ecc and do the math yourself (on PC)
    Or you get 2048 and the error flag?
    Or you can do both?

    I’m not too worried about verifying boot1 / boot2, … it’s easy to fix.
    Agreed, the only thing left is (from post #37):
    0×3F800 – 0×40000 [Filesystem metadata] – not clear if this need to be verified at all. I.e. can Wii still boot if there is complete garbage or all zeros there?

    @bushing && skiddd
    What do you guys think about post #43?

  • 2 Anatomy of a Mario-Kart Brick, pt 2 « Gabriel Steinbach // May 16, 2008 at 7:48 am

    […] Autopsy of a Mario-Kart brick (part 1) Read: Anatomy of a Mario-Kart Brick, pt […]

  • 3 skiddd // May 16, 2008 at 7:07 pm

    @bushing

    I am using the same cpld as the X-board and in
    china it costs about 7 U$D + 2 U$D for the
    FTDI.

    I have started coding for a small 8-bit core that
    will handle the following commands:

    Read 0000 0000 [00h]
    Read ID 1001 0000 [90h]
    Reset 1111 1111 [FFh]
    Page Program 1000 0000 [80h]
    Block Erase 0110 0000 [60h]
    Read Status 0111 0000 [70h]

    I do not plan to put the ECC inside the core as
    I think this could be done on the PC side instead.
    What I plan to do is make the CPLD read each
    page (2048 + 64)bytes and send it over the
    emulated RS232 port of the FTDI in 64byte
    chunks. So it will be 64bytes x 33 RS232 frames.
    I can put an additional 8-bit cheksum on each
    64 byte frame to check on weather errors
    have occured during the rs232 transfers.

    But of course, this will not be the final design as
    something like this will take almost 6 days to
    read the entire device @ 9600 bps heheheh…
    Even at 115200 bps it will take 12 hours for the
    entire device, so I guess I really need to push
    the FTDI’s maximum 1M Baud to get it clocking
    between 1-2 hours. (the computations are just
    off my head.. please correct me if something is
    wrong…)

    The bottleneck here is really the transfer of data
    between the CPLD and the FTDI. I can clock the
    CPLD @ 300Mhz (even faster than the NAND!)
    but still we are limited on the FTDI to PC side ;-(((

    Please click on the link that I put as my homepage
    to see the dev board that I will be using. I am
    sorry about the camera resolution as it is just
    from my phone.

    B.R.
    skiddd

  • 4 skiddd // May 16, 2008 at 9:07 pm

    @bushing

    We can do away with the entire CPLD design
    and use a single FTDI chip with dual UART in
    bit-bang mode.

    http://www.ftdichip.com/Documents/DataSheets/DS_FT2232D.pdf

    We can use Channel A as control signals for
    CLE, ALE, CE, RE, WE, WP, and R/B(input)

    Then we can use Channel B as our IO0-IO7.

    All the 16 IOs from Channel A and Channel B can
    be individually configured and 3.3v logic levels
    of the FTDI requires no further voltage translation
    for the 3.3v Wii NAND.

    I guess this would be the easiest and fastest way
    to do it.

    What do you think?

  • 5 bushing // May 17, 2008 at 6:36 am

    @skidd: It would be awesome to just be able to use the FT2232D by itself — any idea how fast we can push data through it?

    @Newbie: Yes, now that I “know better”, I do that D0 trick. I wonder if turning WC24 off would be enough to prevent that from being necessary — not that that is possible on a bricked Wii.

    As for the 2048 vs 2048+64: You have to read it in 2048 + 64 mode. We know how to calculate the ECC bytes for sectors, but every 8 pages, they add in a 20-byte HMAC into some of the empty space after the ECC inside of the 64-byte spare area.

    The filesystem metadata must not only be there, but it must be almost intact. It tells the Wii where all of the files are in the encrypted section — so without it, the rest of the chip is worthless! This data is unencrypted, but unfortunately it is “signed” with an HMAC as well, which is what currently has me stuck.

  • 6 Newbie // May 17, 2008 at 12:13 pm

    It would be awesome to just be able to use the FT2232D by itself — any idea how fast we can push data through it?
    Cool! And they not very expensive! Do you think we can one of these pre-soldered boards?
    http://www.ftdichip.com/Products/EvaluationKits/DIPModules.htm

    Yes, now that I “know better”, I do that D0 trick. I wonder if turning WC24 off would be enough to prevent that from being necessary – not that that is possible on a bricked Wii.
    From another hand, it might be that on bricked Wii WC24 didn’t even started. Can’t be sure about anything anyway. 🙁

    As for the 2048 vs 2048+64:.. but unfortunately it is “signed” with an HMAC as well, which is what currently has me stuck.
    Does filesystem metadata also has ECC and every 8 pages are HMAC signed?
    I.e. it’s same as filesystem data except it’s not encrypted.

    Back to integrity check algorithm, you would prefer to count on ECC, not on HMAC signature, right?

  • 7 bushing // May 30, 2008 at 3:03 am

    We have to rely on the ECC check when looking at random dumps, because A) we don’t know the HMAC key for random dumps (yet), and B) even if we did know the HMAC key, we still couldn’t use it, because I can’t figure out how to make my HMAC calculations match Ninty’s.

    Anyone know where to find the cheapest FT2232 board?

  • 8 Newbie // May 30, 2008 at 1:40 pm

    Oh boy! I thought you completely forgot about this one!
    I guess both A & B are just a matter of time, right?
    Anyone know where to find the cheapest FT2232 board?
    I did look again still the best price is on the link in post #56.
    For US you can lookup same P/N on http://www.mouser.com
    In general prices are ~30-40$
    In addition there few sites offer “USB to serial” cables based on same chip (20$-30$), but it might be a hassle to solder on their PCB – i.e. isn’t worth it (IMO!).
    I was wondering if skiddd is still there. He might have better ideas!
    I had an impression you were sunken completely in HBC & SbFDfA3R. I’m so happy you are back! 🙂

  • 9 CAP9QD // Jun 7, 2008 at 9:12 pm

    I am working on a PCB for the FT2232D chip in Eagle PCB editor. If anyone is interested I can order multiple PCBs and populate them with the necessary components and FTDI chip.

    Anyway…I am also playing around with the NAND interface above with my Xilinx CPLD devkit. I’m havnt done much VHDL/Veralog since my intro to logic class in college but its an interesting project.

    At any rate…if anyone wants the breakout let me know. It seems to take the PCB fab house quite a bit of time to get my orders back to me but its cheaper; I use http://www.batchpcb.com.

  • 10 CAP9QD // Jun 7, 2008 at 9:12 pm

    Oh…I forgot that it doesnt show my email:

    curtis (dot) parrott (at) gmail (dot) com

  • 11 Anatomy of a Mario-Kart Brick, pt 2 // Jun 12, 2008 at 3:55 am

    […] 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 […]

You must log in to post a comment.