HackMii

boot1 is the second stage of the Wii’s bootloader. It lives at the beginning of flash; it is encrypted by AES, using a fixed key. It is hashed using SHA1, and verified against a hash that is burned into OTP memory inside the Hollywood during manufacturing. Therefore, boot1 can be changed in a Wii before it leaves the factory, and new Wiis could have a new version of boot1 — but it’s not possible to upgrade or modify boot1 in an existing Wii.

Fortunately, there is at least one bug in boot1 — the strncmp / hash verification bug — and this is what makes all of our firmware hackery possible.

If you want to look at boot1 yourself (to follow along), grab the first few kilobytes of any Wii NAND Flash dump, strip out the spare data (0x40 of ECC data after every 0x800 block), and then decrypt it with a command like:

openssl enc -d -aes-128-cbc -K 9258a75264960d82676f904456882a73 -iv 0 -nopad -i boot1-encrypted.bin -o boot1-decrypted.bin

You should end up with 17184 bytes. This is much much larger than boot0, and is already to the point where it’s difficult to follow all of the code by just staring at a disassembly. That space is broken down about like so:

1167: initialization code; AES, SHA, signature checking, NAND, ECC functions
2336 bytes: main(), described below
6134 bytes: low-level hardware setup code (to configure the DRAM, talk to the SEEPROM, initialize GPIO pins, etc)
3850 bytes: RSA verification code
2816 bytes: Library code: strncmp, memcpy, printf (!)
872 bytes: Data, including jumptables, the common key (why?!) and the public half of the Root key.

boot1 is interesting to us because it is the first vulnerable code in the Wii. It’s what decides whether or not a hacked boot2 will run. So, we must understand all of the checks it makes if we want to construct a boot2 that will be allowed to run.

[… several days pass …]
Analyzing boot1 has proven much more difficult than I had feared, so I’m just going to post my disassembly for those who are interested. I’ll follow up soon with the output of SkyEye, which I will post with an explanation of what is actually happening.

Disassembly: boot1.txt

Update: I’ve had some requests for it, so here’s the binary of boot1: boot1-dec.bin

And here’s an IDC file: boot1.idc

Load boot1-dec.bin into IDA Pro (I use 5.2) as an “unknown” file, set processor type to ARMB (ARM Big-Endian), and set it to load the file to 0x0d400000. Once it has loaded, run the IDC file, and you should have something resembling my IDB file. Feel free to post with any questions or ideas.

Something that has caught my obsession has been the question — How are Wiis made? Specifically, after the parts are soldered down, how are they programmed? There do not seem to be any data ports which could be used to upload data, nor download output. (My motivation here, of course, is that we might be able to use the same technology for unbricking.)

I’ve found a few hints (but nothing to get excited about) — some may find this interesting. [Read more →]

(This is a continuation of boot0)

One of the medium-to-long-term projects that Marcan and I have been working is hacking Skyeye to get it to emulate the Starlet.  I don’t think will ever be useful as more than a tool for debugging the lowest-level hacks to boot2 that we plan to attempt, but it’s neat to actually see this code really running.

Skyeye is a generic ARM emulator, and it happens to emulate a lot of devices that we don’t need and can’t use (LCD panels, keyboards, networking, etc…).  So, we’ve been coding drivers for the other parts of the Starlet that we know about — OTP and SEEPROM for keys, NAND flash driver, AES and SHA engines, GPIO ports, debug port … 

At this point, it can either boot a modified version of boot2 (directly from a specially-crafted ELF), or it can boot from a specially-crafted ELF of boot0, its bootrom.  After months of hacking on it, if I give it a real NAND flash dump, boot0 can load and run boot1, and boot1 can load, verify, and run boot2 (which then dies when it tries to load the FS driver due to an MMU problem — we’ll get there eventually).  
[Read more →]