Friday, January 28, 2011

Xbox 360 Forensics: Part 4

In our last episode I had just about given up on x360 after spending a week or so digging around its code base, where did I go from there?

Well I decided to sit down with the Free60.org pages on XTAF and on Xbox 360 File Systems, the source code of a couple of XTAF implementations (x360 and utaf.c), a hex editor and python and I started over. This was a fun project, it turns out that in my time patching x360 I'd learnt almost everything I needed to implement my own parser and some mucking around with a hex editor and the Free60.org docs got me the rest of the way. At that point I started reading about the FUSE bindings for python which are poorly documented but still make filesystem development super easy, I now want to implement everything as a filesystem!

This was the beginnings of my py360 python module (which may one day see public release, bear with me!) and it was good. The first thing I did with my new filesystem and library was to take a recursive directory listing and perform a 'find . -type f -exec sha1sum {} \;' on the filesystem. When this went swimmingly I moved on to the next problem, which was to unleash libmagic (through file) on the filesystem but to my disappointment the mighty libmagic came back with nothing, everything showed as data. This was a problem and certainly not one that I had seriously anticipated. The next step was to see if I could make any sense out of these files quickly and the utility strings is my goto tool in these situations. Strings revealed that while there was a fair amount of ASCII text there was also a very large amount of UTF16 (big-endian) including what looked like the text of game achievements, unfortunately I couldn't find much of a reference to the gamertag of the user on this image nor any other stuff of interest. This is when I resigned myself to doing things the hard way... stay tuned!

Saturday, January 22, 2011

Xbox 360 Forensics: Part 3

I've been on a little bit of a hiatus but we're back for part 3 of the story.

Last we heard I had just (finally) succeeded in taking a dd image of an Xbox 360 hard drive for analysis. I had previously settled on x360 as a platform for analysis and I ran the following series of commands:


svn co http://x360.googlecode.com/svn/trunk x360-read-only
sudo apt-get install libfuse-dev
cd x360-read-only
make
mkdir /tmp/mnt
sudo ./x360 -o debug,uid=1000 /mnt/data/201010.bin /tmp/mnt


This seemed to work ok except that in large directories such as /Cache many of the files would not have any attributes and if I tried to read them I would get a file not found error, also reading other files would cause x360 to crash and to top it all off even when I mounted an image in read only mode one crash ended up damaging the image. I'm sad to say that these problems absorbed a large amount of my time because there were several related bugs that got in the way, including:

  • The type size_t was assumed to always be 64 bits though on my x86 platform it is only 32 bits 
  • An integer overflow cause roughly a quarter of the FAT to be mmaped instead of all of it (see size_t issue)
  • Multi-cluster directory support was implemented in directory listing code but not in the file reading code
  • The mmap call for reading the FAT did not respect read-only options
  • Some read operations caused the file system to crash (possibly due to a pread parameter typing issue)
Except for the last dot point I managed to fix them but without fixing all of the points above I didn't feel confident using x360 for forensics purposes. (Note to the author of x360: I do have some patches that I meant to submit but since I couldn't get everything in a working state I'm not sure if they'd be useful)

The debugging of x360 was useful as I learnt a lot about XTAF by trying to fix the code and my skills with gdb increased significantly as well. This process took almost all of the time available in my first research-sabbatical and the whole project was put on hold for a couple of months while I returned to my day job and contemplated solutions.




Wednesday, January 5, 2011

Xbox 360 Forensics: Part 2

A bit of a detour from my story,  I thought it'd be good to talk about the Xbox 360 file system briefly. The filesystem is called FATX or sometimes XTAF. As the name suggests it's a descendent of the venerable File Allocation Table (FAT) file system that's been around on DOS based operating systems for about 20 years. FATX removes some legacy support and mandates certain values that previously have been optional. FATX is also the file system used by the original Xbox. The only difference between the original and 360 file systems is that due to the processor architecture change Microsoft elected to use big endian numbers for the 360 which is why it sometimes called the XTAF file system.

Quick refresher, what do we mean by big endian? Computers store data as a sequence of zero and one bits usually in groups of 8 bits (a byte) with the right most bit being the least significant. Numbers are stored this way with each bit representing a power of 2. For example 00010000 represents the number 16 since the 5th least significant bit is turned on (2^4 = 16). Easy enough except that using 8 bits the largest number you can represent is 255 (2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0 = 255). The way to represent larger numbers is to add more bytes, unfortunately there isn't a standard on how to represent these numbers. The two options are big endian and little endian which differ by which side the least significant byte is on. For example the 16 bit number 00000001 00000000 could represent the number 1 in a little endian system and 256 in a big endian system. Most personal computers - all Intel and AMD processors including recent Apple computers - are little endian but there is a significant minority of devices that are big endian including the Xbox 360 and older Macs. 


This means that even though the Xbox and Xbox 360 use the same file system you require a different file system driver to interpret them. There are some other quirks to FATX too such as the absence of the '.' and '..' directory entries so that you can't ascend to a parent directory without remembering what it's called which also require some changes to existing FAT drivers. There are a variety of tools available to process FATX drives including the popular Xplorer360 which provides an FTP style interface to the drive for Windows users, the utilitarian uxtaf.c which gives the unix user a custom shell that can access a FATX partition and x360 which uses FUSE to mount a FATX partition on your computer so that you can access it the same way you can access any file on your system. After a bit of reading I decided that x360 was the best choice for me and that's what I started using to look at these file systems but as I hinted in my previous post it didn't go quite to plan.


As an aside it would be amiss of me to fail to mention the Free60.org which taught me almost everything that I know about FATX.



Tuesday, January 4, 2011

Xbox 360 Forensics: Part 1

My research activity is coming to a head and I thought I'd let you all know how it is going. My early explorations were plagued by a plethora of hardware and software failures. The Xbox 360 thoughtfully provided to me by my University had a damaged hard drive which took me longer than it should to diagnose because I had to eliminate my procedure and imaging equipment as possible sources of errors. My setup is a little weird since I'm studying on the road, I'm using an Ubuntu virtual machine on my Dell Laptop and a cheap Xbox 360 -> USB hard drive connector and I was worried about issues arising from the level of indirection. The error that manifested was quite strange, the first 40Gb or so of the image would copy fine and if copying in a reverse order the last 40Gb would also copy fine. I tried imaging from the host OS, tried using a different USB adapter and even directly attached the drive using SATA. My tentative conclusion is that the middle platter of the 120Gb drive was damaged and any reads on it would fail. During this stage I voided some warranties (always fun) and learnt that inside the fancy casing Xbox 360 hard drives are standard laptop drives. I replaced the pictured drive with a 60Gb drive from a local games store and I was in business. A quick:

       dd if=/dev/sdc of=/mnt/data/image.bin 
   ./x360 /mnt/data/image.bin /mnt/xbox -o uid=1000,gid=1000

and I was in business... or so I thought (to be continued!)