NAND File System

General

The Xbox 360 NAND uses a proprietary format created by Microsoft. The format is used to store console-specific data (keyvault, config blocks, etc) and system data (bootloaders, kernel/hypervisor, dashboard files). The NAND is split into two sections - one for storing the keyvault, bootloaders and config blocks and one for storing the dashboard files. The file are stored using a format which is designed to be transactional (each change can be reverted).

NAND Basic Format

The NAND uses a series of pages to combine into blocks, which are small snippets of data (usually 512 bytes) which each have an EDC tag at the end (an extra 16 bytes or 64 in bigblock). These pages are each part of a specific block (which can be identified with the EDC), which is usually made with 16 pages (or 32 for bigblock NANDs)

Error Detection Code

All NANDs have a specific EDC for each page inside the NAND. Sometimes the EDC will not be dumped with the NAND, so it has to either be added back or redumped. The EDC contains the pages block number, a series of flags and a checksum. The specific format is unknown (anybody know it?) but a basic idea of the format is below:

Offset	Length	Type	Information
0x2	0x1	bytes	Version
0x8	0x1	bytes	Unk1
0x9	0x1	bytes	Unk2
0xC	0x4	EDC	Checksum

The checksum uses a custom algorithm, which has successfully been reversed, hopefully someone will post that on here soon.

The version field specifies the revision of the data inside (used for things such as the multiple file tables), if Unk1 and Unk2 are 0 and the version of the block is higher than 0 then that block contains a file table, the highest versioned file table is the latest one.

NAND Format

The first byte of a NAND image should always be 0xFF. If it isn't 0xFF this isn't a valid image. Another thing which should be checked is the copyright header, which is located at 0x10 in the NAND. This string should be read in two parts (skipping the year out, as it changes depending when that xbox was made) and then checked against a control string (although some valid images have this string changed to zeropair).

At 0x2 in the NAND the version of the flash is stored (2bytes). Further on at 0x8 the offset of the CB is stored, followed by the CF1 offset (4bytes each).

At 0x6C the offset to the keyvault is located (4bytes). Up from that at 0x78 the length of the SMC and offset to the SMC are stored (4bytes each).

System Management Controller

finish later

XeLL Image Layout

The whole XeLL Image is pretty small with 1,3 MB compared to an original Xbox360 NAND-Image which is normally 16 MB or 64 MB.

0x00000000..0x000001ff (0x00000200 bytes) Header
0x00000200..0x000003ff (0x00000200 bytes) Exploit
0x00000400..0x00000fff (0x00000c00 bytes) Padding
0x00001000..0x00003fff (0x00003000 bytes) SMC
0x00004000..0x00007fff (0x00004000 bytes) Keyvault
0x00008000..0x000117ff (0x00009800 bytes) CB 1921
0x00011800..0x00016ebf (0x000056c0 bytes) CD 1921
0x00016ec0..0x0006cf2f (0x00056070 bytes) CE 1888
0x0006cf30..0x0006ffff (0x000030d0 bytes) Padding
0x00070000..0x000744bf (0x000044c0 bytes) CF 4532
0x000744c0..0x000a33ff (0x0002ef40 bytes) CG 4532
0x000a3400..0x000bffff (0x0001cc00 bytes) Padding
0x000c0000..0x000fffff (0x00040000 bytes) Xell (backup)
0x00100000..0x0013ffff (0x00040000 bytes) Xell (main)

• The (hacked) SMC Code is usually seen as Header + Exploit + Padding + the actual SMC, so 0x0000 - 0x3FFF.
• The Keyvault is the unique "System Information" which holds stuff like DVDKey, Console Region, Console Serial and other things. Whole keyvault is crypted with CPUKey.
• After that exploitable CB (2BL) and CD (4BL), matching the console revision, follows.
• After padding CB/CD theres CE (Base-Kernel 1888) followed by exploitable Patchslots CF/CG (4532 or 4548) and again some padding.
• At the end of the Image theres a Backup-XeLL, which gets executed if the original XeLL fails (Bad Update maybe) followed by the original XeLL.