Generic Xbox 360 File Container
From Free60 Project
| Table of contents |
Generic Xbox 360 File Container Info
PIRS or LIVE are the magic bytes that start most files on the Xbox 360. This is a generic container file that holds the real files along with metadata that the dashboard reads like title, description and icon.
LIVE files come from Xbox Live. PIRS files are used to store information like gamer tags or themes. The console itself also creates files. These files start with the string 'CON '. They are slightly different from LIVE and PIRS files, mainly at the begin.
Some CON files have multiple revisions of the directory listing and the embedded files. In such cases, the information below is incorrect.
Tool
A free tool (Python 2.5+ required) to analyze and extract these archive files is available at extract360.py (ftp://rene-ladan.nl/pub/distfiles/extract360.py) (2008-08-03, 23056 bytes, MD5 = 3aa517c83d01c618927b78d0ca665d02)
2008-08-03 : add support for XUIZ files
Serious contributions are welcome.
Format
Titles and Descriptions are Unicode strings, start with 2 nulls and are null padded. Some PIRS files do not have the icon data at 0x5714 and onwards. It is unknown if this data is relocated or simply not included in these PIRS files.
For LIVE/PIRS files :
| Offset | Size | Description |
|---|---|---|
| 0x0000 | 4 | 'PIRS' or 'LIVE' Magic Int |
| 0x0004 | 256 | 2048-bit Certificate (signed SHA1 hash of the entire file?) |
| 0x0104 | 552 | Data |
For CON files :
| Offset | Size | Description |
|---|---|---|
| 0x0000 | 4 | 'CON ' Magic Int |
| 0x0004 | 424 | Constant header/certificate, console specific ? |
| 0x01A8 | 388 | File specific data |
The CON file contains readable text, console specific
| Offset | Size | Description |
|---|---|---|
| 0x000A | 3X80345-001 | Serial? |
| 0x0020 | 12-07-05 | Manufacturing date |
| 0x03FD | OS8A1JY00C4313 | Device id |
The format below is common for LIVE/PIRS.
The following table is completely wrong for CON files.
| Offset | Size | Description |
|---|---|---|
| 0x032C | 20 | SHA1 hash of 0x0344 - 0xB000 (0x0344-0xA000 for CON files) |
| 0x340 | 4 | Entry id for above hash |
| 0x344 | 4 | Content type (see below) |
| 0x0410 | 256 | English Title |
| 0x0510 | 256 | Japanese Title |
| 0x0610 | 256 | German Title |
| 0x0710 | 256 | French Title |
| 0x0810 | 256 | Spanish Title |
| 0x0910 | 256 | Italian Title |
| 0x0A10 | 256 | Korean Title |
| 0x0B10 | 256 | Chinese Title |
| 0x0C10 | 256 | Portuguese Title |
| 0x0D10 | 256 | English Description |
| 0x0E10 | 256 | Japanese Description |
| 0x0F10 | 256 | German Description |
| 0x1010 | 256 | French Description |
| 0x1110 | 256 | Spanish Description |
| 0x1210 | 256 | Italian Description |
| 0x1310 | 256 | Korean Description |
| 0x1410 | 256 | Chinese Description |
| 0x1510 | 256 | Portuguese Description |
| 0x1610 | 128 | Publisher (one language only) |
| 0x1690 | 128 | Filename (one language only) |
| 0x1710 | 2 | Value, either 0 or 0x00c0 |
| 0x1712 | 4 | Icon length of first icon |
| 0x1716 | 4 | Icon length of second icon |
| 0x171A | Null padded big icon | |
| 0x571A | Null padded small icon | |
| ss | sl | table of SHA1 hashes of payload of file (see below) |
| ls | ll | File listing |
| cs | cl | Content start |
The content type is a or-ed value of the following flags, it is also the name of the subdirectory which must contain the file.
| 0x00000001 | game saves |
| 0x00000002 | game add-ons |
| 0x00010000 | gamer profile |
| 0x00020000 | gamer pictures |
| 0x00030000 | themes |
| 0x00040000 | SYSTEM (updates) |
| 0x00080000 | Full game demo |
| 0x00090000 | Video clip |
| 0x000C0000 | game trailer |
| 0x000D0000 | Xbox Live Arcade |
The values of ss and sl are:
- for LIVE/PIRS files: 0xB000 and 4096
- for CON files: 0xA000 and 8192 (sometimes only the first 4096 bytes are used).
The value of ls is:
- For CON files: 0xC000
- For LIVE/PIRS files: 0xC000 or 0xD000 if the word value at 0xC032 is unequal to 0xFFFF (indicating an entry in the root directory). The value 0xD000 is only used on kiosk discs.
The value of cs is equal to ls + the word value at (ls + 0x2F). The value of ll is equal to cs-ls. The value of cl is equal to the file length minus cs, meaning that the rest of the file contains the contents.
Each embedded file starts at a 4096 byte boundary. The optional space between embedded files is filled with null bytes.
The file listing consists of entries which have the format below. The listing ends with an entry consisting of only null bytes.
| Offset | Size | Description |
|---|---|---|
| 0x00 | 40 | File name, null-padded |
| 0x28 | 1 | Length of file name, plus flags |
| 0x29 | 3 | Size of file in 4096 byte blocks (little endian) |
| 0x2C | 3 | Copy of 0x29 |
| 0x2F | 3 | Starting cluster number of file (little endian) |
| 0x32 | 2 | Path indicator (big endian) |
| 0x34 | 4 | Size of file in bytes (big endian) |
| 0x38 | 4 | Update date/time stamp of file |
| 0x3C | 4 | Access date/time stamp of file |
Byte 0x28 also has two flags: bit 6 and bit 7. The meaning of bit 6 is unknown, bit 7 indicates that the file is a directory.
The starting cluster number is relative to ls and counts in 4096 byte blocks. This means that ls+4096 is cluster 1, ls+8192 is cluster 2, etc.
The path indicator indicates the path of the file. 0xFFFF means that the file is in the 'root' directory, any other value V refers to the (sub)directory which is listed as the Vth entry in the listing (counting from 0). Directories can nest.
The FAT (http://en.wikipedia.org/wiki/File_Allocation_Table#Directory_table) format is used for the date/time stamps of the files.
Note that the starting cluster as given in the directory (sc) entry might not be the real starting cluster. The following algorithm should be used to obtain the real starting cluster:
unsigned v0, offset;
offset = (filetype == LIVE || filetype == PIRS) && (ls == 0xC000) ? 0x1000 : 0x2000;
v0 = sc * 0x1000 + ls;
while (sc >= 170) {
sc /= 170;
v0 += (sc + 1) * offset;
}
return v0;
This algorithm was reverse engineered from a disassembly of wxPirs. To extract a file, sc and all clusters after sc (i.e. sc + 1, sc + 2, etc.) have to be calculated using the above algorithm.
The data between the clusters consists of the continuation of table T below. The cluster at 0xB6000 is an exception to this rule, as it is the first master table of SHA1 hashes. This master table contains 170SHA1 hashes of the first 170 sub hash tables (the 170-entry sub hash tables contain SHA1 hashes for each 4096 byte cluster).
The first entry at 0xB6000 is an SHA1 hash of the sub hash table at 0xB000 (ss). The DWORD at 0xB6FF0 is a count of valid entries in the combined sub hash tables (0x70E4 would be a full count, and an indicator that extra master hash tables exist).
If the file is large enough to warrant extra master hash tables, they are found roughly every 169*171*4096 bytes. For instance, the master hash entry #171 (second master table, first entry) is located at 0x719A000, and the DWORD at 0x719AFF0 is the total count of valid entries in the combined sub hash tables to this point.
EDIT: It's not 170*170*4096. It's 169*171*4096 (169 is the number of hash tables following the table, since the 1st one in each table hashes the previous master hash table. 171 is the number of clusters that every table hashes (1 cluster for the table + 170 for the data). 4096 is the size of a cluster. The result of that (118.370.304) is the data between master hash tables. (With the old formula, there was a difference of 1 cluster, so it was also "including" the hash table). Is this right?
- A. Header
- B. SubHash 0 (0xB000) (entries for data clusters 0-169)
- C. Directory Structure (0xC000)
- D. Data 0 ... Data 169 (next block after end of directory structure?)
- E. MasterHash 0 (0xB6000) (entries for subhash blocks 0-169)
- F. SubHash 1 (0xB7000) (entries for data clusters 170-339)
- G. Data 170 .. Data 339
- H. SubHash 2, Data ... Data (170 * 170)-1
- I. Certificate Extension? (0x719A000)
- J. MasterHash 1 (0x719B000)
- K. SubHash 170 (0x719C000)
- L. Data (170 * 170) ..........
Authentication
If the Xbox 360 needs to verify the value at 0x4, a calculation of a 1GB demo at 12X DVD speed would be horrendously slow. It is likely not to validate the entire file when launching a demo. This certificate may only sign the header portion of the file, which contains the master hash table for the rest of the file.
At ss, there is a table T of format:
typedef struct {
uint8_t hash[20];
uint32_t entryID;
} hashEntry;
The hash entry in each struct is an SHA-1 hash of a 4096 byte block B starting at ls. The entryID value gives the location of B relative to cs. The values of bit 31-28 are:
- LIVE/PIRS files: 1, 0, 0, 0
- CON files: 0/1, 1, 0, 0
The entryID value 0xX0FFFFFF indicates that this block either starts a new file or is the last block in the archive file.
Because 4096 mod 24 == 16, the last 16 bytes of each block B are set to 0x00.
Resign tool
Resign tools use keys obtained from the decrypted keyvault of an Xbox 360 console.
Public resign tools are available from Xploder and also freely at http://xss.ath.cx. The first resign tool was created by Roofus from 360gamesaves. Some people have a stolen resign tool. (The_Dark_One, haxalot88PlasmaGrunt, Stevo)
Most resign apps are written to only patch specific parts of a container file. This is due to the fact that the ability to sign arbitrary data may have some adverse impact on the enjoyment of xbox live ( as per the original xbox resigner ).
Some people have used these resign tools to abuse the system. Many people have released modified halo 3 map variants, and (sadly) screenshots have also been released.
The site http://xss.ath.cx only offer a profile and device id "reigner" like 360gamesaves. No CON resigner.
You can get a free, fully featured CON resigner at http://blueshadowz.info/download.php?view.328 but you will have to sign up first.
