Xbox FATX Hacking
written by Michael Steil, 7 May 2002
Since irregularities in the FATX filesystem might cause errors in the Xbox kernel, I did some modifications on partition 3 (System) to see how the Xbox reacted.
Size/Loop Hack of xboxdash.xbe file
In the FATX directory entry, there is the size of the file in bytes and the first cluster containing the file contents. Subsequent clusters are found by looking at the FAT: there is an entry for each cluster pointing to its successor or to $ffff (or $ffffffff on FATX32, partitions 0,1,2 and 4) if it's the last cluster. There can be two different irregularites in this system:
- There is a loop in the cluster sequence, either with the orginal file size in the directory entry or with a bigger file size
- The size stated in the directory is bigger than the information in the clusters (cluster list end too soon)
I tested the first one on xboxdash.xbe. Just creating a loop in the FAT list changed nothing. The Dashboard booted up normally. The kernel seeps to stop reading when the file size is reached, it ignores the value in the last FAT entry.
I also changed the file size to 64 MB (40:00:00:00h). Again, the Dashboard still worked. Apparently, the XBE loader only loads as much bytes as stated in the XBE header, additional data will be ignored (as it is with Win32 PE executables). xboxdumper correctly dumped a 64 MB file with the contents repeating; but was stuck in an infinite loop afterwards.
TODO:
- Set the size in the XBE header to 64 MB
- Make the FAT chain end too soon (point 2)
- Test the same with data files (xip, xtf); also change size in headers
Subdir Loop
Subdirectories are stored like normal files; the directory entry of a subdirectory contains a start cluster, and its size is always zero, since the filesystem logic always follows the chain in the FAT until the $ffff is reached. Creating an infinitely large subdirectory by a loop in the FAT chain might cause an error in the kernel.
The subdirectory "Audio" starts at cluster 2. I set the entry for the next cluster from $ffff to 2, creating a loop. This changed nothing, since the filesystem logic seems to stop at the first empty directory entry. (Also xboxdumper showed no difference).
So I filled all directory entry slots with the same (fake) entry. xboxdash now correctly looped, but there was still no difference to be seen on the Xbox. This might be because the Dashboard software knows the correct filenames of its WAV files and finds them, so it doesn't read the subdirectory until the end.
I renamed all contents of "Audio", so that the Xbox software wouldn't find its files any more and perhaps read the subdirectory until the end - infinitely. But the Xbox kernel seems to have a protection against this attack: The Dashboard did not play any music any more, but there was no loop in the kernel.
Interestingly, the Dashboard shows no green screen when audio files are missing, but it does if a xip file it needs has been modified. Is it possible to change WAV files without a green screen?
Conclusion
The Xbox kernel seems to be protected agains these simple hacks, but there still a lot more possibilities. To name a few:
- filenames with more than 41 characters (up to 255)
- convert the partition to FATX32
- change cluster size
- change number of FAT copies
- more FAT errors
It would be especially interesting to hack partition number 4 - this is a read/write partition, so there might be kernel errors when writing to a faulty file system.
