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.

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.

• Create a FAT16/32 filesystem on a SD memory card (<2GB seems to work best)
• Copy Bannerbomb’s “private” directory to the SD card root
• Copy “boot.elf” from the HackMii archive to the SD card root
• Turn the Wii on, click the SD card icon in the System Menu & insert the SD card

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.

• Follow the onscreen instructions to install the Homebrew Channel and BootMii (and DVDX if that sort of thing is useful to you)
• Press “Home” on the WiiMote & launch BootMii

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.

• Select option 4 (on the far right hand side of the screen)
• Select option 1

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!

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:

1. The Infectus chip may be faulty
2. Bad solder joints on the Infectus
3. Connecting wires may be too long
4. Electrical resistance of the sewing needles may be too high
5. Some unknown issue with the console NAND chip

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.

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…

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!

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.

Disclaimer: This may change significantly before I actually start the project!

• Acquire the contents of the internal NAND chip

There are a couple of ways I think I can do this. The JTAG method isn’t really an option, as it doesn’t look as if the Wii actually has a JTAG port (I currently don’t have access to a Wii to check for myself). There’s another hardware approach I’m considering, but I’ll leave that until I’ve properly assessed its feasibility. If all else fails there’s a software approach. I read an interesting paper about using a software exploit to dump Xbox memory and I’m fairly confident that could be modified for the Wii, but at this stage a hardware solution is preferable.

• Write an image back to the NAND

If an image can be written back to the NAND it may provide a sort of “reset button” for doing live analysis work. Obviously, this depends on the process for reading and writing the NAND being forensically sound.

• Decrypt the NAND image
• Perform a physical search of the image

All indications so far point to the Wii using AES encryption on the NAND, though the key may well be accessible. Once the image is decrypted I can have at string extraction and the likes.

• Analysis of the Wii filesystem

This is unlikely, but if everything up to this point goes stunningly well I might take a look at the filesystem. An undocumented, proprietary filesystem is probably a project in itself though!

I’d like to get at least as far as attempting to decrypt the contents of the NAND, but I suppose it’ll depend on how much time the first couple of steps take.

I’ve decided to focus on the Nintendo Wii. The placement that I’ve applied for isn’t likely to be confirmed until sometime in April, but so far the signs are good. It’s just a case of wait-and-see at the moment.

There isn’t very much published research relating to forensic analysis of the Wii. In fact I’ve only managed to find one paper dealing specifically with the subject. It proposes a process for live analysis, which would ideally be recorded through screen-capture or an external video camera.

With regards to storage the Wii has an SD-card slot, which might contain something useful, but in any case should be possible to image/analyse in the usual method. The main issue in my mind is the internal flash storage (Unlike the PS3/Xbox, the Wii doesn’t have a hard drive). I’ve been doing some reading about Wii homebrew and Wii/Gamecube linux which might allow direct access to the internal flash, but tend to rely on exploiting a buffer overflow to execute unsigned code. It may well be technically possible, but I have my doubts about it being forensically sound. Another issue I have is that any method of dumping the internal flash through software is at the mercy of Nintendo patching the Wii system software.

This leads me on nicely to a suggestion by my supervisor. If we can get inside the Wii without doing any serious damage (The availability of 3rd party modchips suggests that it’s possible), and if it has the connections to support a JTAG port, and if we can do some low-level magic with said hypothetical JTAG port, it may be possible to dump the internal flash out through a PC parallel port. There are a lot of “ifs” there, but my supervisor had some success with dumping PDA memory though a JTAG port on a previous project. It didn’t work perfectly, but it could be a good place to start.

It’s a little bit scary seeing as my electronics experience only extends to playing with 555 timer chips when I was in school!

However all of this depends on the Wii even having the connections to support JTAG, which though I’m told is likely, is not guaranteed.

First, Microsoft’s COFEE incident response tool leaked onto the internet. COFEE had previously only been available to law enforcement organisations, so having it leak to the public kicked up a bit of storm with people trying to work out just exactly what it is capable of doing. The answer turned out to be “not very much”. Rather than being the ultimate secret backdoor that some early media reports made it out to be, COFEE is more like a glorified shell script that pulls down volatile memory to a USB stick.

Inevitably, someone released a tool aiming to disrupt COFEE’s execution. DECAF was released earlier this week, but a couple of things about it seemed a little strange. It’s website offered the tool for download, but in a binary only distribution. Perhaps it’s just me, but I find it quite hard to trust security tools that don’t release their source code. Another quirk was that the DECAF website contained an EULA for the software prohibiting reverse engineering or disassembly (Which also contained references to Skype of all things!). It all seemed to go against the ethos of full disclosure in computer security.

I downloaded a copy, and planned to play with it over this weekend (I’ve just handed in my final piece of MSc coursework for the semester today!), but there’s another twist:

The DECAF website has been updated to remove any links to the software and instead shows an odd message claiming that all copies of DECAF have been disabled, ending with a passage from the Bible!

As I’ve been writing this I’ve been listening to an interview with DECAF’s developer on the Cyberspeak podcast which seems to have been recorded before the tool was taken down. It’s interesting, but it doesn’t really make things any clearer with regard to the developers motivations or the manner in which the tool was released.

I recently had a conversation with some friends where we discussed various scenarios where “evidence” could be planted on a computer without the owner’s knowledge. We came up with a few hypothetical situations in which it would be trivial for a motivated party with a bit of technical knowledge to cause a lot of trouble for an unsuspecting victim. Especially as child pornography is nasty enough that possession alone is all that’s needed to cause some serious legal difficulties.

I was reminded of that conversation by a post on Slashdot over the weekend concerning malware which, for one reason or another, seems to do just that. One case referred to in the AP article mentions software that hit 40 sites per minute while the defendant was out of the house. That case was eventually dropped but it took 11 months and cost the defendant $250,000 in legal fees, not to mention the damage to his reputation.

I’d like to think that it would be pretty simple to determine if malware is responsible for the presence of an image or video, but that doesn’t always seem to be the case. Another thing is that these seem to be “random infections”. I find it a little depressing to think of the damage that could be done by a properly targeted attack.