FATX

FATX is the file system used by the Xbox and the Xbox 360, it is unsupported natively by Windows but has some functionality in Linux.

Explorers

Several FATX file system explorers have been created by various individuals. Unfortunately, nearly all of them fell apart or were abandoned early in development, leaving the Xbox community without a quality explorer application.

Fortunately, on Thanksgiving Day 2009, the first quality explorer application was released, 4 years after the Xbox 360 entered the market. This application is called FATXplorer and was created by Eaton, a reasonably well known member of the Xbox community. The application is stunning. It features a beautiful interface that makes it extremely easy for newer users to navigate as well as providing advanced features for more knowledgeable users.

FATXplorer is recommended over any other explorer, as all of the others, as mentioned earlier, are buggy and very incomplete.

Click here to jump into the exploring experience.

Partition Locations

Memory Unit

Offset	Length	Information	Format
0x0	0x7FF000	System Cache	STFC (Secure Transacted File Cache)
0x7FF000	end of drive	Data	FATX

Xbox 360 Hard Drive

Offset	Length	Information	Format
0x2000	0x204 - 0x80000	Security Sector	Binary
0x80000	0x80000000	System Cache	STFC (Secure Transacted File Cache)
0x80080000	0xA0E30000	Game Cache	STFC (Secure Transacted File Cache)
0x120eb0000	0x10000000	Xbox 1 Backwards Compatibility	FATX
0x130eb0000	end of drive	Data	FATX

"Josh" Sector

The "Josh" Sector is located on the 4th sector (0x800). It's purpose is currently unknown. It may be used just to identify the Xbox that previously formatted it.

Offset	Length	Type	Information
0x0	0x4	ascii string	"Josh" magic

The Console Security Certificate then follows, continuing with a pair of entries, the format of which is below:

Offset	Length	Type	Information
0x0	0x8	(un?)signed long	Unknown (ID of some kind?)
0x8	0x14	bytes	Unknown (0x14 bytes... SHA1 hash?)
0x1C	0x4	(un?)signed int	Unknown
0x20	0x4	(un?)signed int	Unknown

The sector then ends with the following format:

Offset	Length	Type	Information
0x0	0x4	(un?)signed int	Unknown
0x4	0x4	(un?)signed int	Unknown
0x8	0x4	(un?)signed int	Unknown
0xC	0x4	(un?)signed int	Unknown

Another possible entry format is below, this disregards the end-sector format:

Offset	Length	Type	Information
0x0	0x2	(un?)signed short	Unknown (ID of some kind?)
0x2	0x2	(un?)signed short	Number of extra ints at end of entry
0x4	0x4	(un?)signed int	Unknown
0x8	0x14	bytes	Unknown (0x14 bytes... SHA1 hash?)
0x1C	0x4	(un?)signed int	Unknown
0x20	0x4 * Number of extra ints at end of entry	(un?)signed int	Unknown

I've uploaded my own "Josh" sector to here (644 bytes) - Stoker25 19:48, 6 August 2010 (UTC)

All of the info above was gained using this sector, can anybody provide another one to make sure the format matches?

Security Sector

The Security Sector is used by Microsoft to verify that the harddrive is an original Microsoft product. The Security Sector holds details such as drive sector count, drive serial number and the Microsoft logo (to stop other companies using it)

It begins at the 16th sector on the drive (0x2000).

Offset	Length	Type	Information
0x0	0x14	ascii string	Serial Number
0x14	0x8	ascii string	Firmware Revision
0x1C	0x28	ascii string	Model Number
0x44	0x14	bytes	MS Logo Hash
0x58	0x4	unsigned int	Number of Sectors on drive
0x5C	0x100	bytes	RSA Signature
0x200	0x4	signed int	MS Logo Size
0x204	MS Logo Size	image	MS Logo

If a Security Sector from a smaller hard drive is used on a bigger one, the Xbox will only see the number of sectors defined in the Security Sector.

Partition Header

For each offset, add the offset of the partition.

Offset	Length	Type	Information
0x0	0x4	ascii string	Partition magic (XTAF)
0x4	0x4	unsigned int	Partition ID
0x8	0x4	unsigned int	Sectors per Cluster
0xC	0x4	unsigned int	Root directory cluster

Chainmap and directories

To find the offset of the chainmap, take the offset of the position and add 4096 (0x1000) to it. Each entry in the chainmap is either an unsigned int or a unsigned short, depending on the number of clusters inside the partition.

To work out the cluster size, take the Sectors per Cluster value and multiply it by 512 (0x200).

To work out the number of clusters, divide the partitions size by the cluster size and that's have the number of clusters.

If the number of clusters is below 65520 (0xFFF0), then the drive uses 2-byte chainmap entries, otherwise it uses 4-byte chainmap entries. The size of the chainmap is the size of the chainmap entries multiplied by the partitions cluster count.

To get a clusters offset, you need to work out the offset of the file data area. This is determined by taking the chainmap offset and adding it's size to it. You then simply times the cluster index (minus 1) by the cluster size and add it to the file data offset.

To get a clusters chainmap entrys offset, times the cluster index by the chain map entry size and add that to the chainmap offset.

To work the FAT Size, do the following:

       public long FATSize
       {
           get
           {
               //This gets the size
               long size = ((PartitionSize / ClusterSize) * EntrySize);
               //We need to round up to the nearest 0x1000 byte boundary.
               size += (0x1000 - (size % 0x1000));
               //Return the size.
               return size;
           }
       }

Files

The file contents is stored per cluster as indicated by the chainmap and the starting cluster (see below). If the file is larger than one cluster, it is stored in multiple clusters. If the length of the file is not a multiple of the cluster size, then the last cluster is only partially used. If the file covers more than 1 cluster, the next cluster must be determined by finding the current cluster's entry in the chainmap and using the value as the next cluster.

Directories

Directories are stored in a tabular format. Because directories are normal files with the "directory" bit set, they are allocated in the FAT and may therefore cover multiple clusters. This makes it possible to have many files in one directory.

Each entry of the directory table is 64 bytes long.

An entry can be set to all 0xFF bytes, which means that this entry is unused and probably marks the end of the directory contents. Used entries are filled as follows:

Offset	Size	Description
0x00	1	length of the file name, or 0xE5 for deleted files
0x01	1	file flags
0x02	0x2A	file name, padded with either 0x00 or 0xFF bytes
0x2C	4	starting cluster of file, 0 for empty files
0x30	4	file size, 0 for directories
0x34	2	creation date
0x36	2	creation time
0x38	2	access date
0x3A	2	access time
0x3C	2	update date
0x3E	2	update time

The file flags and the date and time fields are in the same format as the one used in the FAT file system.

The order of the creation/access/update stamps is not completely certain, but empirical evidence shows that the above order is the most likely one.

The volume bit is unused, the volume label is instead stored in a file "name.txt" in the root directory. The contents of this file is big-endian UTF16 (I guess), for example "ren� hd" is stored as:

0xFE 0xFF 0x00 0x65 0x00 0x6E 0x00 0xE9 0x00 0x20 0x00 0x68 0x00 0x64

The following characters are found in XTAF file names from actual disk images:

• 0x20, 0x24, 0x2e ( SPACE $ . )
• 0x30-0x39 (digits 0-9)
• 0x41-0x5a (letters A-Z)
• 0x5f ( _ )
• 0x61-0x7a (letters a-z)

Unlike the FAT file system, XTAF has no "." and ".." entries in the directory tables. This means that it's only possible to go to the parent directory by remembering its cluster number.