Capacity Unlock

Recovering a Flashed Drive's Full Size

Hold LB while the exploit runs to remove the flash signature from a drive SSD Maker made, so the console stops sizing it from the model it pretends to be and starts sizing it from the hardware.

This is permanent without the undo.bin SSD Maker produced at flash time. Read the whole page.

The problem

FATXplorer's SSD Maker makes a drive authenticate by rewriting its ATA identity so it presents itself as an official Xbox 360 model. That works — the console accepts it — but the console then lays the partitions out for that model's capacity. A 240 GB SSD flashed as a 120 GB disk gives about 107 GiB of content partition, and the rest of the drive is never addressed.

This is not the 500 GB ceiling upstream Bad Storage lifts, and it is not a formatting mistake. The layout is derived from the identity, and the identity is a smaller drive.

Measured on a Kingston A400 flashed as a Fujitsu MHW2120BH:

Hardware, to Linux	240,057,409,536 B — 223.6 GiB
Signed sector count, at +0x58 of the signature	234,441,648 — 111.8 GiB
Host Protected Area	none; reads succeed to the last sector
Write and read back at 150 GiB	byte for byte identical

The extra space is real. SSD Maker changes the identity strings, not the capacity. The ceiling lives only in the signed sector count.

What LB does

Blanks the signature: 512 zeroes at offset 0x2000, read back and verified before the plugin claims success. Nothing else on the drive is touched — that sector sits 504 KB below the first FATX partition, which starts at 0x80000.

The drive then stops authenticating, falls to the bypass, and the bypass sizes its partitions from the drive's own sector count.

The offset is the same on every drive, and that is not an assumption. SataDiskAuthenticateDevice asks for it with a load-immediate:

8015D9E4  li  r11, 0x2000        ; literal, not computed
8015D9F8  li  r6, 0x200          ; 512 bytes
8015DA0C  bl  IoSynchronousFsdRequest

Nothing there depends on model, manufacturer or capacity. Confirmed on three drives from three makers and three size classes.

The content volume goes with it

The existing volume was laid out for the smaller size and will not be understood at the larger one, so its FATX header is cleared in the same operation and the console offers to format.

That is not a nicety. An earlier version left the volume alone and merely advised a reformat, reasoning that with no signature there is only ever one layout so nothing can be corrupted. The reasoning was right and the conclusion was wrong: the old volume still carries a valid header, so the console mounts it, reads a root directory from where the larger layout puts it, and finds whatever file data happens to be there. On hardware that was a directory entry claiming a 207 character name, and the dashboard died with E71 twice.

With the header cleared, the console reaches the dashboard and offers the format. Confirmed on hardware.

What it costs

• Avatars. The disk key is installed by a genuine authentication, so a drive that no longer authenticates never gets one. Proven directly: avatars were installed by the console on the signed drive and worked; the signature was removed, leaving SystemExt byte for byte identical — 151 files, the same system.manifest — and they stopped working.
• Booting without the exploit. The drive does not mount at all without it.
• Reversibility. Only SSD Maker can put a signature back, and only on a drive whose controller it supports. If yours is not one of those, there is no way back.

All three are put on screen before anything is written. Nothing happens unless LB is held, and the offer only appears when the hardware is more than 4 GB bigger than the signature admits — so a genuine Microsoft drive is never a candidate.

Why not just resize the partitions in memory

That was the first answer, and it was wrong twice over.

It cannot reach the goal: the console formats to whatever the signed sector count says, regardless of what the partition lengths were patched to, so a full-size volume can never be created that way. Measured — the volume came back at exactly 107.03 GiB, which is the signed count minus the partition offset, to the byte.

And it is dangerous while it lasts. The two layouts overlap at a fixed position near the start of the partition: the unlocked allocation table covers the real one entirely and then 27.9 MB of the real data area. Anything the console writes in that state lands on real files. In a test with 45 copies of a game filling 105 GiB, exactly one file was destroyed — and it was inside the predicted range, with a control copy outside it untouched.

The damage is proportional to what gets written, not automatic and not total. But it is real, and removing the signature avoids it entirely: a drive with no signature does not mount without the exploit, so there is never a second layout to alternate with.

If you would rather not

• Reformat with FATXplorer on a PC, which can size the volume for the real drive up front.
• Leave it alone. A flashed drive at its flashed size authenticates, mounts without the exploit, and has working avatars. That is worth something no unsigned drive can offer.