XTAF: Difference between revisions

From Xenon Wiki
Jump to navigation Jump to search
imported>Oscar193
mNo edit summary
imported>CLK
(removed everything, redirecting to FATX)
 
Line 1: Line 1:
= <span class="mw-headline"> The Xbox360 file system, also known as XTAF. </span> =
#REDIRECT [[FATX]]
 
The file system is derived from the age-old [http://en.wikipedia.org/wiki/File_Allocation_Table MS-DOS file system] and can be considered as a cleaned-up version of it.
 
Note that, while not part of the file system itself, the media which contain this file system do not have a master file table which describes which file system starts where. It is up to the consumer (Xbox360, [http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107707 geom_xbox360 kernel module], ...) to know this.
 
The file system is divided into 4 parts:
 
* the header (the BOOT sector on FAT file systems)
* the file allocation table
* the ROOT directory cluster
* the rest of the file system (both directories and files)
 
All multi-byte values contained in each part are [http://en.wikipedia.org/wiki/Endianness [1]] big-endian.
 
An example implementation in C is available as [ftp://rene-ladan.nl/pub/distfiles/uxtaf.c uxtaf.c] (18156 bytes, MD5 = 8bf05607ab921b2c68d58c987e8177fd) and is accompanied by [ftp://rene-ladan.nl/pub/distfiles/uxtaf.txt a small text] (998 bytes, MD5 = de783817d847402d0c88a13663ff9d0d).
 
== <span class="mw-headline"> Configuration file </span> ==
 
The configuration is the first 2 sectors (0x400 bytes) of the Data0000 and is created when the device is configured. It contains info about the device and is secured with a signature. The layout is as follows:
 
{| border="1"
! Offset
! Length
! Description
|-
| 0
| 0x1A8
| [[Console Security Certificate]]
|-
| 0x1A8
| 0x80
| Signature (part of the console cert)
|-
| 0x228
| 0x14
| Device ID
|-
| 0x23C
| 4 (UINT32)
| Certificate size (0x228)
|-
| 0x240
| 8 (UINT64)
| Size of device in bytes
|-
| 0x248
| 4 (UINT32)
| Read speed in KBs
|-
| 0x24A
| 4 (UINT32)
| Write speed in KBs
|}
 
The rest of the config section is padding of 0x00 (0x1B2 bytes).
 
The signature is derived from a SHA1 hash taken from the start of the device id (0x228) till the end of the config (0x1D8 bytes) and is signed with the consoles private key and the matching public parameters are present in the console certificate for verification later on.
 
The certificate size is used to determine how to verify the configuration file when the device is mounted. If the value is 0x228 then the device was configured by an Xbox and the signature is verified using the params in the console certificate, if the value is 0x100 then the device was pre-configured by Microsoft and is verified using the SATA public key (also used for HDDSS verification).
 
The last 2 values are written when the device is configured, it is unknown how these are used later on. Perhaps it could be used to determine what connected device would provide best performance for caching.
 
== <span class="mw-headline"> The header </span> ==
 
The header is 1 sector (512 bytes) long and contains :
 
{| border="1"
! Offset
! Length
! Content
! Description
|-
| 0x000
| 4
| XTAF
| Magic identifier
|-
| 0x004
| 4
|
| Serial number of the file system, could also be 0 or -1
|-
| 0x008
| 4
|
| Number of sectors per cluster
|-
| 0x00C
| 4
| 1
| Number of copies of the file allocation table
|-
| 0x010
| 2
| 0
| Unknown
|-
| 0x012
| 0xFEE
| 0xFF
| Unused / unknown
|}
 
== <span class="mw-headline"> The file allocation table </span> ==
 
This table is equivalent to its ancestor in the FAT file system, except that all values are big-endian.
 
The first two entries are possibly slightly different:
 
* Entry 0 contains a copy of the media descriptor (0xF8, hard disk), but the clean/ok bits might not be used. Note that on the cache partition, the value seems to be reversed: 0xFFF8 instead of 0xF8FF
* Entry 1 is always set to 16 or 32 1-bits.
 
The size of the FAT (in bytes) is calculated as
 
uint64_t file_system_size;
uint32_t spc; /* sectors per cluster */
uint32_t numclusters = file_system_size / (512 * spc);
uint8_t fatmult = numclusters &gt;= 0xfff4Â ? 4Â : 2;
uint32_t fatsize = numclusters * fatmult;
if (fatsize % 4096 != 0)
        fatsize = ((fatsize / 4096  1) * 4096; /* round up if not multiple of 4 kB */
 
The cache and the compatibility partition have a 4096-byte hole of 0-bytes right after the FAT.
 
The above algorithm already shows that the file system is 32-bits if the number of clusters is at least 0xFFF4, and 16 bits otherwise. It seems likely that bits 28-31 are unused on 32-bits file systems.
 
== <span class="mw-headline"> The ROOT directory cluster </span> ==
 
The root directory is located right after the FAT and the possible 4096-byte hole. This cluster is not covered by the FAT.
 
The size of the root directory is 1 cluster. Its syntax and semantics are the same as that of normal directories.
 
Also of note is that the ROOT cluster is numbered "cluster 1", not cluster 0. This means that the next cluster, the first data cluster, is referred to as "cluster 2" in the FAT entries.
 
== <span class="mw-headline"> The actual data </span> ==
 
The actual data is located after the root directory cluster (i.e. cluster 2). Cluster 2 is the first entry covered by the FAT.
 
=== <span class="mw-headline"> Files </span> ===
 
The file contents is stored per cluster as indicated by the FAT 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.
 
=== <span class="mw-headline"> Directories </span> ===
 
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:
 
{| border="1"
! 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 is only possible to go to the parent directory by remembering its cluster number.
 
More information on Xbox360 storage devices is available at http://free60.org/FATX.

Latest revision as of 07:11, 7 September 2011

Redirect to:

Retrieved from "https://www.xenonwiki.com/index.php?title=XTAF&oldid=5175"