I’ve had a few weeks to do some more reading and I think I’ve come up with a rough plan for the project. Well, “plan” may be too strong a word, but at the very least I’ve got a list of objectives.
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 had my first semi-official meeting with my MSc project supervisor today. This is probably as good a place as any to keep track of these sorts of things, so here’s a summary of what I’m planning at this point.
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.
There have been some very odd things going on in computer forensics over the last few weeks.
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.
Throughout our forensic informatics lectures we have been somberly informed that a career in digital forensics and avoiding child pornography are, to all intents and purposes, mutually exclusive. It isn’t very nice but sooner or later anyone involved in digital investigations is going to have to deal with it at some level.
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.
Toward the end of the first year of my undergraduate degree I read a book by Neil Barrett called Traces of Guilt, which describes the author’s involvement in computer-related crime as a security consultant and expert witness. It is written as a series of case-studies showing Barrett’s involvement in criminal cases ranging from paedophilia to murder, as well as private consultancy work such as dealing with a sociopath systems administrator at a wealthy holding company.
Despite the subject matter, it is surprisingly accessible (After all, it was my mother that recommended it to me!), but still contains enough technical information to keep a computer science student interested.
I read it again recently and even though five years have gone by since I first picked it up, very little of it seems dated. It’s definitely worth a read for anyone with an interest in computer-crime.
Traces of Guilt got me thinking about computer security from the “other side”, and is probably part of the reason that I’m studying computer forensics today.
I think this is quite interesting.
From The Register:
An Australian man who set up an elaborate network of hidden cameras to spy on his flatmates has escaped jail time after police were unable to crack the encryption scheme protecting his computer.
…
But the files were encrypted, and the 39-year-old Wyllie refused to divulge the password. The inability of police to review the files – combined with the fact that a camera he used was unplugged when the raid was commenced – meant prosecutors lacked the hard evidence they needed to prove the man had secretly taped his flatmates.
I’m under the impression that RIPA could be used over here to compel a suspect to give up the password, but it’s quite hard to find information on when Part 3 of the Act has been used, so perhaps I’m mistaken.
