NAND File System
||This page needs to be cleaned up, because its either hard to read or contains very little information. You can help Free60 by editing this page and cleaning it up.|
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:
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.
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
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.