Original Xbox Compatibility

Original Xbox Compatibility

Working, confirmed on hardware. An original Xbox game runs on a retail Xbox 360 from a drive that never passed the security-sector check — first try, no disc in the drive.

This is the single biggest thing the fork enables that a stock console cannot do, and it comes for free from the bypass: the emulator lives on a partition that only exists on a mounted internal disk.

First time you run a game, it may report a dirty disc. That is expected — run it again. The console builds the emulator's cache on that first attempt. See below.

The console's own format does not create this partition. Confirmed on hardware: a drive formatted from System Settings comes back with the data partition only — Aurora shows Hdd1 and no HddX. You need a PC tool for this one step. See below.

Why it needs this fork

The original Xbox emulator, internally XeFu (Xenon Fusion), is not in the console. It lives on the hard disk, in the partition Microsoft calls partition 2 and this project calls SystemPartition. So:

• No internal disk, no compatibility. It cannot be run from USB — that partition does not exist on removable storage, by design.
• Microsoft only ever wrote it at the factory, onto drives it sold. A third-party drive has an empty partition there.

The fork mounts SystemPartition on a drive that does not authenticate, which is what makes the emulator reachable at all. Nothing beyond that was needed — no extra patch, no special mode.

What the public Bad Storage would do

Nothing, on an unsigned drive. Upstream stops early:

if ((XboxHardwareInfo->Flags & XBOX_HW_FLAG_HDD) != XBOX_HW_FLAG_HDD)
{
    ... "Disk not genuine/flashed. Flash using FATXplorer."
    return FALSE;
}

A drive that does not authenticate never sets that flag, so upstream exits before touching anything, and it additionally requires a BSTOR marker that only FATXplorer's SSD Maker writes.

On a drive that does authenticate, compatibility already works without any of this — the console mounts every partition itself. Upstream contributes nothing there either way.

So: compatibility on an unsigned drive is this fork's doing. Not a coincidence of it, but the only route to it.

Where the emulator lives

Tool	Name	Offset	Length
fusefatx	x1	0x120EB0000	0x10000000 (256 MB)
FATXplorer	Backwards Compatibility Partition / partition 2	same	same
this project	SystemPartition	same	same

Three names for one thing, which is why it took a while to place. Verified by searching the raw device for the filenames and finding them at 0x120EB0000 + 0xA002.

Contents of a factory drive — 19 files, 194 MB:

Compatibility/xbox.xex            198656   the front end
Compatibility/xefu.xex, xefu1_1, xefu2, xefu3, xefu5, xefu6, xefu7, xefu7b   ~640 KB each
Compatibility/xefutitle5.xex, xefutitle6, xefutitle7, xefutitle7b            8-10 KB
Compatibility/dash/xboxdash.xbe            the original Xbox dashboard
Compatibility/dash/xodash/xonlinedash.xbe
Compatibility/dash/fonts/xbox.xtf, "Xbox Book.xtf"
index                              9558
TDBX/Tdbx.db                  163844745   the title database

Tdbx.db is magic TDBX followed by encrypted data — entropy 7.997 bits/byte, not one ASCII string in the first 4 MB. The supported-title list cannot be read out of it.

The partition has to exist first

Formatting from the console is not enough. Confirmed on hardware 2026-08-10: a drive with a Windows install on it was put in, mounted by the bypass, and formatted from System Settings → Storage → Format. The result is a perfectly good storage drive — and Aurora shows Hdd1 and nothing else. No HddX. The console creates the content partition and leaves the backward compatibility partition without a volume.

That makes sense in hindsight: Microsoft never expected a drive to need one created, because the drives it sold came with the emulator already on it from the factory.

So this is the one step that still wants a PC:

• FATXplorer → Toolkit View → Partition Tools → add the Backwards Compatibility Partition. It is also offered as a checkbox while formatting.

• From Linux, mkfs.fatx knows the partition by name, so the geometry does not have to be spelled out:

  mkfs.fatx -b hd -p x1 /dev/sdX

  Same -b hd as when mounting. It writes the volume at 0x120EB0000, 256 MB. If a build of the tool does not carry the table, --offset 4847927296 --size 268435456 forces the same thing.

Once the volume exists, the emulator files go in as below and nothing else on the drive needs touching.

Installing it

The emulator files are not ours to write, and they are not in this repository. Two versions are published by FATXplorer, no account needed:

https://api.eaton-works.com/download/FATXplorer/MiscFiles/Backwards%20Compatibility%20Files.zip
https://api.eaton-works.com/download/FATXplorer/MiscFiles/Hacked%20Backwards%20Compatibility%20Files.zip

The ConsoleMods wiki hosts the same pack but refuses automated downloads.

Use the hacked one. It is the 2007 xorloser hack brought forward by Mathieulh in 2018, v5832, and its own readme lists what it removes:

* Xbe signature checks removed (lets you run unsigned code)
* Xbe section hash checks removed (lets u run hacked xbes)
* Game region checks removed (region free baby!)
* Game media checks removed (play games from your hard drive)
* Debug/Devkit xbes supported (run your own xbox1 code)
* Attempt to play unsupported games (doesn't mean it will work hehe)

Two of those matter a great deal here:

• Region checks removed. An NTSC game runs on a PAL console. The stock emulator would refuse.
• Media checks removed. Games run from the hard disk. Without this an original Xbox executable refuses to start from anywhere but a DVD, because it says so in its own header — Halo's AllowedMedia is 0x00000002, DVD only. The hack makes patching that unnecessary.

The whitelist goes too, so titles Microsoft never approved will at least attempt to run.

Which variant

The pack ships six: 64MB and 128MB, each as Regular / HUD / HUD_plugins. Start with 64MB/Regular.

The full breakdown — what the memory figure means, what each front end adds, whether your console model matters, and what all those xefu files are — is on its own page: Choosing an Emulator Build.

Writing it to the drive

Copy the Compatibility folder from your chosen variant to the root of the compatibility partition, replacing what is there. Leave index and TDBX alone — the pack does not include them, and with the checks removed the whitelist no longer matters.

From Linux:

fusefatx -b hd -p x1 /dev/sdX /mnt/point
rm -rf /mnt/point/Compatibility
cp -r 64MB/Regular/Compatibility /mnt/point/

Note -b hd, not --drive=hd — with the wrong flag fuse swallows the option and silently mounts the default partition instead, which reads as an empty compatibility partition.

One file will fail: Xbox Book.xtf. fusefatx refuses to create a name containing a space and returns EINVAL, even though FATX allows it and the console itself wrote that exact file. Copy it under a name without the space and then rename the directory entry on the raw device. FATX entries are 0x40 bytes:

Offset	Field
+0x00	name length (0xE5 means deleted)
+0x01	attributes
+0x02	name, 42 bytes, 0x00 padded
+0x2C	first cluster, big-endian
+0x30	size, big-endian

Raise the length byte and rewrite the name. Cluster and size stay untouched, so the file itself does not move.

Back up the factory Compatibility folder first. It is 38 MB and it is the only way back.

If the first attempt says the disc is dirty, run it again

This is expected once, on a drive that has not run an original Xbox game before. It is not a damaged disc, a bad copy or a broken install.

The emulator does not read the game straight off the disk. It copies it into a cache on Cache0 and plays from there, and it keeps the emulated Xbox hard disk in the same place — saved games included. A working Cache0 looks like this:

Xbox0/  Xbox1/  Xbox2/          one folder per title slot
Xbox2/cache000.map   291 MB     the disc cache: the game is copied here
Xbox2/cache001.map   291 MB
Xbox2/cache002..005.map         36-49 MB
Xbox2/savegame.bin
Xbox2/saved/                    the original Xbox's E:\UDATA, verbatim
Xbox2/saved/player_profiles/default_profile/00.sav
Xbox2/saved/playlists/default_playlist/…/blam.lst

The console builds the cache partitions on demand, and the partition device objects the bypass completes are what let it do so. So the first run creates the cache and fails; every run after that works.

While Cache0 carries no volume there is nowhere to put any of the above. The game still boots and plays — that comes off Partition1 and SystemPartition — and then fails the moment it needs the work area, which the emulator reports as a read error on the disc. Halo says the disc is dirty. It is telling the truth, just not about the disc.

Measured on hardware on 2026-08-10: the same drive read Cache0 = 00 00 00 00 in the morning and XTAF in the afternoon, with a failing Halo run in between and a working one after. Nothing was written to the drive by hand; the console did it.

Bad Storage now checks for this and says so rather than letting you guess:

Bad Storage: Cache not built yet. An original Xbox game may report a dirty disc - try it again.

It only warns. Formatting Cache0 from the plugin was considered and rejected for the same reason the on-console formatter was dropped — see Two Builds. The console lays out its own volumes correctly by definition; we would be guessing.

Running a game

With the emulator installed and the fork mounting the drive, run the exploit and the console offers original Xbox titles the same way it always did.

Games can come from the disc, or from the hard disk now that the media check is gone. The documented route for disk copies is XISO (extract-xiso --rewrite) packed to GOD with ISO2GOD, dropped in Hdd1\Content\0000000000000000\ — which is this project's Partition1\Content\0000000000000000\.

Known-good test title

Halo: Combat Evolved, title ID 4D530004 (MS-004). It has its own emulator profile, so it exercises the per-title path rather than just the generic emulator, and its failure modes are documented well enough to tell "compatibility is broken" from "this game is glitchy".

A caveat worth stating

Every guide for the hacked emulator assumes a JTAG/RGH console with permanent patches. This fork runs under Bad Update, where the patches live in RAM. They survive title launches — that is why homebrew launches at all — so it should hold, and in practice it did. But it is a path nobody had walked before this project, so treat surprises as plausible rather than impossible.