wraggster
June 1st, 2008, 10:41
Article from bushing;
This post is part of a several-part series on fixing a “bricked“ Wii:
UnBrickMii - Introduction, explanation of a 4-part plan to unbrick any Wii
amoxiflash - Part 1, a way to modify the NAND Flash of a bricked Wii
Mario-Kart Autopsy 1 and 2 - Part 2, a (partial) analysis of what happens to the filesystem of a Wii to make it “brick”
(tbd) - Part 3, a way to recover the necessary per-console unique keys (NAND AES, NAND HMAC) using a hacked boot2 on a bricked Wii
(tbd) - Part 4, software to modify the contents of the Wii’s filesystem on a host computer, making use of those two NAND keys.
I’ve focused my recent energy and time into Part 4. It’s turned out to be more difficult than I’d feared. In order to modify the filesystem to unbrick a Wii, we need to do the following things:
Isolate an existing file in the NAND dump (done)
Decrypt it using the proper AES key, modify it, and then encrypt it again using the same key (done, doable, and straightforward)
Sign each 0×4000-byte block using the correct HMAC key, so that the Wii will recognize it as valid.
The HMAC has proven to be the most difficult part. HMAC is a standard algorithm, and I know the HMAC key for my Wii, but I can’t get my calculated HMAC to match the Wii’s stored HMAC. This means I can’t modify the filesystem, which is a fairly serious obstacle.
I’ve spent weeks staring at the disassembly of boot2 — the first piece of code that performs the HMAC check — and I can’t figure out what it’s doing by pure static analysis. Unfortunately, we don’t have any (useful) debug facilities.
It’s time to fall back to first principles. Marcan and I have been working on modifying SkyEye to emulate the Starlet core. It’s a very frustrating and tedious process, because we have no documentation for how most of this works, so we’re guessing and seeing how well code ends up running. I don’t think it is something that will ever be useful for, say, a Wii emulator — there are far easier ways to emulate IOS — but I’m hoping I will be able to use it to debug the HMAC algorithm, and also perhaps firmware patches.
boot0 is the first part of the Starlet boot chain. It is hardcoded in mask rom in every Hollywood chip; it will never change. It is designed to be small and simple, because it’s impossible to fix any bugs that are found there. I’ve chosen to start there in trying to emulate the chip — although it is only about 1300 bytes of code, it manages to talk to:
OTP storage area (to retrieve a hash to compare boot1 against
NAND Flash controller (to read the encrypted boot1)
SRAM (to store the decrypted boot1)
AES engine (to decrypt boot1)
SHA engine (to authenticate boot1)
I don’t expect this to be of much use to people, but if you’re curious, take a look at my analysis of boot0. If you see anything i missed, please let me know!
Future articles will discuss boot1 and boot2.
http://hackmii.com/2008/05/boot0/
This post is part of a several-part series on fixing a “bricked“ Wii:
UnBrickMii - Introduction, explanation of a 4-part plan to unbrick any Wii
amoxiflash - Part 1, a way to modify the NAND Flash of a bricked Wii
Mario-Kart Autopsy 1 and 2 - Part 2, a (partial) analysis of what happens to the filesystem of a Wii to make it “brick”
(tbd) - Part 3, a way to recover the necessary per-console unique keys (NAND AES, NAND HMAC) using a hacked boot2 on a bricked Wii
(tbd) - Part 4, software to modify the contents of the Wii’s filesystem on a host computer, making use of those two NAND keys.
I’ve focused my recent energy and time into Part 4. It’s turned out to be more difficult than I’d feared. In order to modify the filesystem to unbrick a Wii, we need to do the following things:
Isolate an existing file in the NAND dump (done)
Decrypt it using the proper AES key, modify it, and then encrypt it again using the same key (done, doable, and straightforward)
Sign each 0×4000-byte block using the correct HMAC key, so that the Wii will recognize it as valid.
The HMAC has proven to be the most difficult part. HMAC is a standard algorithm, and I know the HMAC key for my Wii, but I can’t get my calculated HMAC to match the Wii’s stored HMAC. This means I can’t modify the filesystem, which is a fairly serious obstacle.
I’ve spent weeks staring at the disassembly of boot2 — the first piece of code that performs the HMAC check — and I can’t figure out what it’s doing by pure static analysis. Unfortunately, we don’t have any (useful) debug facilities.
It’s time to fall back to first principles. Marcan and I have been working on modifying SkyEye to emulate the Starlet core. It’s a very frustrating and tedious process, because we have no documentation for how most of this works, so we’re guessing and seeing how well code ends up running. I don’t think it is something that will ever be useful for, say, a Wii emulator — there are far easier ways to emulate IOS — but I’m hoping I will be able to use it to debug the HMAC algorithm, and also perhaps firmware patches.
boot0 is the first part of the Starlet boot chain. It is hardcoded in mask rom in every Hollywood chip; it will never change. It is designed to be small and simple, because it’s impossible to fix any bugs that are found there. I’ve chosen to start there in trying to emulate the chip — although it is only about 1300 bytes of code, it manages to talk to:
OTP storage area (to retrieve a hash to compare boot1 against
NAND Flash controller (to read the encrypted boot1)
SRAM (to store the decrypted boot1)
AES engine (to decrypt boot1)
SHA engine (to authenticate boot1)
I don’t expect this to be of much use to people, but if you’re curious, take a look at my analysis of boot0. If you see anything i missed, please let me know!
Future articles will discuss boot1 and boot2.
http://hackmii.com/2008/05/boot0/