Good news, everyone! I’ve just completed and submitted my MSc dissertation.
I’ve also invented a device which makes you read all 20,000 words of it in your head, in Professor Hubert J. Farnsworth’s voice!
Well, only part of that is true. I have submitted my dissertation. It may or may not appear on here in some point in the future. At the very least, I’ll probably write up a summary of the main findings though.
Okay. For some unknown reason you want to explore the internals of the Nintendo Wii. The plan goes something like this:
Hopefully this post will shed some light on step 2.
When imaging the NAND BootMii creates two files, nand.bin and keys.bin. The keys.bin file, obviously enough, comprises of a hex dump of all of the console encryption keys. The other file (nand.bin) contains a block-for-block copy of the data stored on the console NAND with, just to be helpful, keys.bin tacked onto the end.
Before you can do anything useful with your NAND image you need to extract the NAND key from dump and put it in a new file. That’s where this post comes in!
getwiinandkey is a simple command-line program, written in C, which reads a BootMii NAND or key dump, extracts the NAND key, and writes it to a new file ready for use.
Usage: getwiinandkey <dump> <output>
The archive contains the source code for compilation on linux/OS X boxes, as well as a pre-compiled binary for Windows XP. I tend to do all my Wii-hacking work on a linux machine so I’m unsure just how useful a Windows binary will be, but for the sake of completeness it’s there!
This is the initial release (read: a bit of a hack which has undergone minimal testing) so please be gentle with it!
That having been said, it has been a while since I wrote anything in C and if you happen to spot something obviously wrong with the code I’d appreciate it if you let me know.
Download:
getwiinandkey-0.1.zip (SHA256: f5fd02faa801508ed0d9a7144036ee790301628d3cd6a35e37b284c10f7b8b57)
Earlier this week Nintendo released System Menu 4.3 – the sole purpose of which seems to be disabling homebrew software. It’s a bit of a pain because until some new bugs are found, the success of any procedure I come up is subject to the Wii running System Menu 4.2 or lower. Still it could be worse.
My black Wii came with System Menu 4.2 installed by default. Bannerbomb and the HackMii installer still work, so I can continue with the project pretty much as I had planned.
Installing BootMii is relatively straightforward but there are quite a few steps involved.
If Bannerbomb has worked correctly a pop-up will appear asking to load boot.elf/dol. If you don’t see this, start again using another version of Bannerbomb.
The WiiMote will not work in BootMii. The console buttons can be used to navigate the menus though. Press the “Power” button to move the cursor, and the “Reset” button to select an option.
BootMii will now create a block-by-block copy of the NAND on the SD card. A number of factory “bad blocks” are to be expected. There were seven reported on my Wii. Once written, you will be given the option to verify the copy – this may not be absolutely necessary, but it’s a good idea anyway.
The imaging process, including verification, took about 20 minutes. Afterward, I exited BootMii and was returned to the System Menu.
That’s it. Simple enough really. Definitely easier that pulling the console apart and playing with wire and needles!
In short, I’ve had no success getting the Wii to speak to my Infectus chip.
The first obstacle was finding wire small enough to fit securely into the vias on the motherboard. I started by using Kynar wire wrap, but moved on to stripping an IDE hard drive ribbon cable and trying that instead. Still no luck! The best solution seemed to be to insert small pins (or needles) into the vias and solder them to the Infectus.
I managed to find very fine sewing needles (size 12 beading needles), but it’s still far too delicate and time consuming (in my opinion) an operation to carry out every time I want to image the NAND. Including the time to disassemble the console and put it back together again, it would take the best part of a day to acquire an image.
The next problem is that the software used to operate the Infectus doesn’t recognise the console NAND chip.
Off the top of my head there are 5 possible reasons for this:
I’ve powered up the Infectus before without issue, and continuity testing seems to suggest that the solder joints are fine so barring the development of a fault while I was re-soldering I think I can rule out 1) & 2).
I’m more concerned about 3) & 4). I think a specially built “frame” for the needles/pins would be the best solution (ideally using proper PCB testing gear), but I don’t have the knowledge or equipment to make something suitable quickly enough for it to be of much use.
Finally, I’ve read on a couple of forums that the Samsung NAND chips used in the Wii (as opposed to the Hynix ones) often don’t like to play with external controllers while they’re still attached to the Wii motherboard. The only solution in this case seems to be to desolder the chip and put it in a TSOP type adapter with a dedicated power supply.
I’m concerned about soldering anything to the Wii itself, so I really don’t want to try removing chips from the motherboard!
I’m coming to the opinion that the best way to continue with the hardware method is to document the progress I’ve made so far, but ultimately write it off as a failure and move on to software.
Given the lack of success with the hardware, I’ve made some changes to the software procedure. Rather than using a hardware-acquired image as a baseline, I’m planning on installing BootMii before creating any user data (other than what is required by the initial set-up of the console) to acquire an image with as little modification as possible. From that point the project could continue pretty much as I had proposed originally, although verification of the data is going to be difficult without the hardware method.
I could spend weeks trying to make this thing work and still end up in the same position that I’m in now, so at this point I think the best use of my time is just to acquire a copy of the NAND and see if anything worthwhile can be extracted from it.
The title tells you pretty much all you need to know about this post. I spent this afternoon disassembling the Wii and documenting the process. It wasn’t nearly as nerve-wracking as I had thought it would be mostly thanks to this helpful guide (with photos). The whole process (including photos and note-taking) took a little over 2 hours.
I have one of the newer, black Wii consoles. There aren’t any major differences in the disassembly process (other than some black screws which were previously silver), but it does use an updated motherboard – labelled C/RVL-CPU-50. Thankfully it still uses the same Samsung NAND flash chip as in earlier models, but at first glance the area around the NAND looks like it has changed a bit.
And finally, the part I’m most interested in…
Yesterday I received an email stating that the university exam board had met, and that I was officially allowed to progress to MSc. Good stuff!
The computer science department have kindly agreed to supply a Wii console, but it needs to be power tested before I’m allowed to take it to pieces. I have my Infectus chip ready for soldering, although ideally I’ll be able to attach it to the vias rather than soldering it directly to the NAND chip. The less soldering I have to do, the lower the possibility of me damaging the chipset! Obviously though, using the vias is unlikely to give as steady a connection as soldering to the NAND, but I’d like to work as far away from the NAND as I can and only go as close as I need to.
I’d been hoping that I could formulate a process that only needed a hardware or a software approach to image and decrypt the NAND. Now I’m almost certain that I’ll need a combination of both.
Hopefully I can use the Infectus to take an image of the NAND without modifying the data it contains. However, the resulting image will be encrypted. This is where the software solution comes in. The BootMii homebrew software installer has the ability to dump the NAND to an SD card and (more importantly) extract the relevant encryption keys from the running system (from volatile memory, I presume). From reading a number of homebrew forums, I know that it is possible to decrypt a BootMii NAND dump. What I would like to do is decrypt and examine an unmodified NAND dump created with my Infectus chip. I don’t currently see any reason why decrypting an Infectus dump with keys extracted using BootMii shouldn’t work, but I’m mindful of that saying about theory and practice being the same in theory, but not in practice.
Thinking about the software side of things, I’m a little reluctant to use BootMii as a final solution. It should do what I need it to do as a proof-of-concept, but it seems a bit too bulky and heavy handed to be used as a forensics tool (I’m a little worried about its installation footprint). Following from a paper regarding the use of a buffer-overflow to imageRAM in the Xbox, I’d quite like to modify an existing exploit to extract the encryption keys and dump them to an SD card. That might be beyond the scope of the project at the moment, but I’d like to know if it’s at least in the realms of possibility.
Another issue is verification that any data captured during either of the imaging processes actually represents what is stored on the NAND chip. I can’t think of any way of using the Infectus to hash what is on the chip while it is dumping (although if repeated dumps have the same hash value the process can be said to be consistent, at least). BootMii isn’t concerned with forensics at all, but it does show that unsigned software can interact with the NAND, so what I’m planning on doing over the next couple of days is to investigate the capabilities of Whiite-Linux.
If Whiite-Linux can be run completely from an SD card (Think live-cd for the Wii), and if it can “see” the internal NAND, it might be possible to hash the contents of the chip and even use a standard dd-like tool to dump an image. There’re a lot of ifs there, and I think running dd in particular is a bit of a long-shot, but it’s probably worth a go just to see what it can do. I’d rather write code for a Debian linux than have to hack around an exploit in assembly!
My big file server had been making strange noises for a while so last week I decided to “retire” it and use my Mac Mini instead. Unfortunately the changeover wasn’t quite as straight forward as I had hoped.
Ubuntu Server has always treated me well in the past, so I stuck with it and downloaded the 10.04 Long Term Support release. The installation went ahead as normal, but when I came to boot the newly installed system for the first time, nothing happened. The box powered-on of course, but it couldn’t find any boot records for Ubuntu. Even worse, the hard disk seemed to be so mangled that the only way I could get the system to recognise it was to open the case, remove the drive and use a SATA to USB adaptor to reformat it! I’m not sure what the issue was. Perhaps something to do with Apple’s insistence on using EFI instead of BIOS. Or possibly something related to Ubuntu using LVM by default now (I disabled it and things started working).
Anyway. Once I got it to boot I found another problem: the Mac Mini will not boot into Linux unless there is a monitor attached – not ideal when the box is hidden away in a cupboard! Fortunately, it’s relatively simple to trick the Mac Mini into acting as though there is a monitor.
Basically, what is needed is a way of connecting pins 2 and 7 of the VGA adaptor in the same way as a monitor cable would. Using a 75Ω resistor to bridge the connection was recommended, but 155Ω (the lowest I had in my bits box) seems to work pretty well. The last thing I did was to wrap a piece of insulating tape around the resistor in case anything metallic comes into contact with it. It shouldn’t, but it doesn’t hurt to make sure.
So now I have a small, fully-functioning, almost silent file server that is happy enough to boot without a keyboard or monitor! It’s not a pretty solution by any means, but it’s not as though I spend a lot of time looking at the back of my server anyway.
I had my last university exam yesterday, so barring any major disasters I should be starting work on my MSc project in the next few weeks. I’d like to get going on this as soon as possible but there’s still quite a lot of administrative stuff to sort out first.
Firstly, the placement I applied for has fallen through as the company have stated that they aren’t in a position to take on placement students this year after all. I was beginning to suspect that the placement wasn’t going to happen given the complete lack of communication over the last 4 months, but it was only confirmed at the beginning of this week. It’s a bit of a pain but I suppose it can’t be helped.
Secondly, I need to get my hands on some hardware. This is a bit of fallout from the placement collapsing in on itself, but again, something I was beginning to expect. Getting hold of a Wii shouldn’t be too difficult, although there might be ethical considerations if I’m potentially recovering someone else’s data from a pre-owned (read: cheaper) console.
The other hardware issue might be a little bit tricky. JTAG is out as far as pulling data from the NAND goes, but I’m pretty sure that I can do something similar with a modchip. The Infectus 2 chip seems to be the gold standard here but I’ve been having trouble sourcing one. I’m starting to suspect that they’re not in production anymore because they don’t appear to be in stock anywhere other than in dodgy-looking posts on forums. I found a reseller with chips in stock this morning though. They seem to be pretty reputable at first glance, but I’ve asked around a few forums for any recommendations (or alternatives based in the UK). This is the part that I want to get sorted as soon as possible. I only have 12 weeks to complete the project so if it takes 6 weeks to get a chip delivered from overseas… well… that would be bad.
Pandora’s Xbox: The changing community of the modern console
It was written back in January apparently, but I saw it just now on the HackMii blog. It makes me wonder if I should get in touch with Nintendo about my project. I’m not too sure what their opinion of it would be!
Apparently tomorrow’s PS3 firmware update is going to remove the OtherOS feature from original-model consoles. I’m not sure why. Sony mentioned security concerns, presumably due to George Hotz, but from what I understand of that it’s a pretty tricky hardware hack. I saw some speculation that it was an April Fool’s joke. If it is, it’s not a very good one! I doubt that annoying a bunch of customers then saying “Ha, we fooled you!” is likely to have a positive outcome for Sony.
If it happens I’ll be interested to see what the forensic implications are. There may be none of course, but the OtherOS features pretty highly in all of the research papers I’ve seen, as the GameOS is heavily encrypted. Even then, the OtherOS is only of any help if the user chose to enable it. I haven’t seen any statistics but I doubt that the number of people running Linux on their PS3 is very high.
I think Sony have made a pretty stupid decision here, but I suppose it could be argued that it’s a good thing from a forensics standpoint. Locking-down a device and having a very clearly defined application set means that the scope for abuse is limited, but it means that getting any useful forensics data out of it is a bit of struggle!
It’ll be interesting to see what happens if George Hotz follows through with his custom firmware idea. He’s always said that he’s not interested in opening the PS3 for piracy but if he releases custom firmware, when it gets into the hands of the cracking community it’ll probably hurt Sony far more than had they left Hotz alone. It’s never a good idea to provoke a guy who has the skills, time and motivation to hurt you!
