Home

Unauthenticated Disk Support

This fork of Bad Storage lets a hard disk or SSD that never passed the Xbox 360's security-sector check be used as internal storage, on a retail console running kernel 17559 with the Bad Update exploit.

No Microsoft signature, no SSD Maker, no HDD Maker. Any drive, formatted by the console itself.

Status: working, confirmed on real hardware. Runs natively — XeUnshackle loads it on every boot and the disk mounts on its own, with no button press. Tested across a range of drives from a 240 GB SSD up to 1 TB mechanical disks, all at full capacity.

What it gives you

• Any internal drive. Capacity comes from the drive's own sector count, so there is no retail-style size ceiling and no dependence on which controller SSD Maker happens to support.
• Original Xbox games. The backward compatibility emulator lives on a partition that only exists on a mounted internal disk, so an unsigned drive could never reach it before. Now it can — confirmed on hardware, first try. See Original Xbox Compatibility.
• The rest of a flashed drive. Hold LB to remove the flash signature, so the drive is sized from its hardware instead of from the model it pretends to be. Permanent without SSD Maker's undo.bin. See Capacity Unlock.
• No PC needed to prepare a drive. Put in a disk with anything on it at all — NTFS, FAT32, a Windows install — run the exploit, and format it from System Settings. Confirmed on hardware. (The one exception is the backward compatibility partition, which the console does not create.)

Pages

Page	What it covers
Installation	How to install it and what you should see
Original Xbox Compatibility	Running original Xbox games, and how to install the emulator
Choosing an Emulator Build	Which of the six emulator variants to install, and why
Capacity Unlock	Recovering a flashed drive's full size by removing its signature
Two Builds	Normal versus debug, and why the formatter left the normal build
How It Works	The actual root cause, and why the obvious fix does not work
Kernel Internals	Addresses, structures, partition map for retail 17559
Scope and Limitations	What this does and does not fix
Research Notes	How this was found, including the wrong turns

The short version

During boot, SataDiskInitialize creates all twelve hard disk device objects before it checks whether the disk is authentic, and only fills in their geometry and marks them ready after. When authentication fails, that second half is skipped.

So the partition device objects were always there. They were just left half-initialised — a zeroed PartitionInformation and DO_DEVICE_INITIALIZING still set — which makes the kernel answer STATUS_NO_SUCH_DEVICE for them.

This fork finishes that initialisation instead of trying to defeat the authentication check.

The one real limitation

Avatars do not work on a drive that never authenticated, and they cannot be made to. A genuine authentication is what installs the disk key, that key slot can only be written once per boot, and the write happens before any exploit payload can run. Every route around it has been tried and measured — see Scope and Limitations, which also covers the one configuration where avatars are reported to work.

Related: a drive with no signature cannot serve an exploit entry point that reads from the internal disk, such as BadAvatarHDD, because that entry point would have to be readable before the exploit runs. USB entry points are unaffected.