-
Notifications
You must be signed in to change notification settings - Fork 2
Scope and Limitations
Security-sector authentication, and only that.
If the console can already talk to the drive — it answers ATA commands and reports its sector count — then it does not matter whether the drive carries a Microsoft signature, what controller it uses, or who made it. That is the point.
Requirements:
- Retail console, kernel 17559
- Bad Update + XeUnshackle
- Drive formatted with FATXplorer's Xbox 360 hard disk format (not SSD Maker, not HDD Maker)
If SataDiskUserAddressableSectors reads zero, no disk was identified on the SATA bus. There are no
half-initialised device objects to complete, so there is nothing here to act on. This is a
lower-level problem than authentication — the drive is not answering the commands the console needs.
EatonZ documented exactly this failure mode for an SM2258XT-based drive: it "doesn't respond to the necessary commands". A drive in that state is out of scope.
The code detects this case and reports it rather than pretending to succeed.
Such a drive authenticates, so the bypass never engages — and it authenticates as whatever official
model it was flashed as, which is usually much smaller than the drive really is. The fork reports
this when it sees it, and holding LB removes the flash signature so the drive is sized from its
hardware. Permanent without SSD Maker's undo.bin. See Capacity Unlock.
Confirmed on hardware: a 240 GB SSD flashed as a 120 GB disk went from 107 GiB to 218 GiB of content partition.
Drives smaller than the fixed system-partition area (~5.2 GB) are rejected outright.
There is no upper limit of the sort retail consoles have. The partition map is computed from the drive's own reported sector count, not from any declared model size, so capacity is simply whatever the drive actually has. Tested up to 1 TB — see below.
An exploit entry point that has to read data from the internal hard disk cannot work on a disk this fork is needed for, and the reason is circular:
- The entry point must be readable while the console is still in its stock state — that is what triggers code execution in the first place.
- On an unauthenticated disk the partition device objects are never published, so there is no filesystem to read from until the bypass has run.
- The bypass only runs after an exploit has already succeeded.
Only PhysicalDisk is reachable before authentication, and that is raw sector access from kernel
context. The dashboard and the avatar system work through files, not sectors, so it does not help.
This is not something better code can fix; the two requirements exclude each other.
An entry point that loads from USB is unaffected, because the internal disk plays no part in it.
The trade-off worth understanding:
| Disk state | Capacity | Usable as an HDD entry point? |
|---|---|---|
| Flashed with SSD Maker | Whatever official model it was flashed as | Yes — it authenticates and reads normally |
| Flashed, then reformatted keeping its signature | The drive's real capacity | Yes — it still authenticates |
| This fork (no signature at all) | The drive's real capacity | No — unreadable until the exploit has run |
Note that a drive only loses capacity to SSD Maker when its real size falls between official model sizes (20/60/120/250/320/500 GB). A 240 GB SSD has to be flashed as 120 GB, losing half. A 250 GB drive flashed as 250 GB loses almost nothing, keeps authenticating, and does not need this fork at all.
Nothing here is persistent. Bad Update is not persistent, and neither is this. Every cold boot needs the exploit run again.
There is no warm reboot that keeps the fix in memory: any reset reloads the hypervisor and kernel clean from NAND. Hot-swapping the drive triggers the boot animation and loses the exploit entirely.
One console on kernel 17559, but a good spread of drives: a Kingston SA400S37 240 GB SSD plus a number of older mechanical drives at 300 GB, 500 GB and various sizes in between, up to 1 TB. All mounted at their full capacity.
That is consistent with how it works — it completes kernel structures that are the same whatever drive is attached, so nothing in it is size or model specific. Reports from drives larger than 1 TB are still welcome, since that is simply the largest that has been tried.
Avatars do not work on a disk that only appears after the exploit. That much is unchanged — but the reason given here previously was wrong, and worth correcting because it led the investigation astray for a long time.
The old explanation, now disproved. It said the console decides what system content exists at power-on and never revisits that decision. It does revisit it: with a flashed drive reformatted so that it still authenticates, inserting the update USB while already in the dashboard brought up the update menu. The updater scans when a device appears, not only at boot.
The actual cause: the disk key. SataDiskAuthenticateDevice (0x8015D9E0) has exactly two
lasting effects, both applied before it decides anything:
8015DA30 bl XeKeysSetKey(0x1001, sector, 0x200) ; install the disk key
... ; copy 20 bytes from sector+0x44 to 0x801A60C0XeKeysSetKey (0x80108E78) is a thin wrapper around a hypervisor call. Measured on hardware:
calling it from the plugin returns 0xC8000002 — and it returns the same on a drive that
authenticated during boot using that very sector. The slot is write-once per boot; whether the
sector is valid is irrelevant.
So nothing running after boot can install a disk key: not this fork, not a kernel patch (XeUnshackle
already patches SataDiskAuthenticateDevice to li r3,1; blr, which is not enough), not a
hypervisor patch — by the time Bad Update runs, the moment has passed. Only a persistent NAND
modification could change it.
Nor can a sector be borrowed from another disk: the kernel compares serial, firmware and model in the sector against the IDENTIFY response of the drive actually present. Making an SSD lie about its identity takes vendor-specific commands, which is exactly what SSD Maker does and why it only supports certain controllers.
Also ruled out by measurement rather than assumption: the DID patch (forcing device ID 1 — which
additionally hides the internal disk from the storage list when a USB drive is connected),
XboxHardwareInfo->Flags |= 0x20, and any theory about missing volumes (all three system
partitions mount, 3 of 3).
Still non-working, for completeness:
- Copying the installed avatar content onto the disk by hand, from a disk where it does work. The files are there; the console still reports nothing.
-
XamResumeUpdaterUI— returns success and does nothing. It resumes an update already in progress, and there is none. -
XamLaunchAvatarEditor(0, 0, NULL)— returns0x8B050008. The editor refuses to start because it believes no assets are installed, which is circular. -
XamAvatarInitialize— initialises the avatar API for the calling title, not the system's content scan. Even called correctly it would not change what the dashboard knows. (It also takes a pointer it dereferences five times with no NULL check, almost certainly an adapter table.)
| Disk state | Capacity | Avatars | Original Xbox games | HDD entry point? |
|---|---|---|---|---|
| Flashed with SSD Maker, left as-is | Whatever model it was flashed as | Yes | Yes | Yes |
| Flashed, unlocked with LB | The drive's real capacity | Yes | Yes | Yes |
| This fork (no signature at all) | The drive's real capacity | No | Yes | No |
The middle row removes the capacity/avatars trade-off this page used to describe as unavoidable — see Capacity Unlock. It only applies to a drive SSD Maker was able to flash in the first place; a drive that never had a signature is the bottom row and stays there.
The compatibility column is the newest result, and it is the interesting one: original Xbox games run on a drive that never authenticated. Avatars and compatibility turn out to be unrelated problems, which was not obvious — both looked like "system content the console will not touch". Compatibility only ever needed the partition mounted. See Original Xbox Compatibility.
Reported by a user of this project, not yet reproduced here.
On an Xbox 360 that has internal flash storage — the 4 GB Slim models — installing the system update to that internal storage gives working avatars and Kinect, with this fork running. The update never touches the unsigned disk at all: it goes to storage the console already considers legitimate.
That fits everything measured below. The obstacle was never the content, nor which route it arrived by. It was that the disk holding it has no key. Put the content somewhere that does not need one and the problem disappears.
Not a limitation of this fork, but the thing most likely to look like one.
FATXplorer's recommended configuration does not format System Extended or System Auxiliary. Those hold the dashboard and system files, so without them the console has nowhere to put the avatar update and never offers it. The disk otherwise works perfectly for storage, which makes it a confusing failure.
Formatting all four partitions fixes it. See Installation.
- A "Fatal crash intercepted" message appeared during development when the fix ran as a manually launched title. It has not been seen since moving to the DLL, which runs before the dashboard comes up and never goes through a title launch/exit cycle.
- The XL HDD patch from Xbox-360-Patch-Collection must not be applied in RAM alongside this. It
rewrites 52 live kernel sites, including
NtReadFile/NtWriteFiledispatch, and upstream applies it by reflashing NAND so that it is present before anything mounts. Patching it into a running system destabilises already-mounted filesystems.