Two Builds

Two Builds

The fork ships in two flavours from the same source. Which one you want is easy: unless you are investigating something, you want the normal one.

	Normal	Debug
Configuration	Release	Debug_Retail
Size (DLL)	28 KB	120 KB
Mounts an unauthenticated disk	yes	yes
Capacity unlock on LB	yes	yes
Original Xbox compatibility	yes	yes
Log written to the USB stick	no	yes
On-console formatter (LT / LT+RT / LT+RT+LB)	no	yes
Console probes — content enumeration, updater, device records	no	yes

Both are built from the same tree; the difference is _DEBUG.

Build Debug_Retail, not Debug. The project carries three configurations and only two of them run on a retail console. Debug also defines _XDK, which switches SetMemory over to DmSetMemory — an export of xbdm.xex, the debug monitor, which exists only on development kits. The resulting DLL declares an import a retail console cannot resolve, so it never loads and XeUnshackle reports it as Missing. Debug_Retail defines _DEBUG;_XBOX without _XDK and imports the same two libraries the normal build does: xam.xex and xboxkrnl.exe.

This was shipped wrong once. The check is one command:

# the import table of a XEX should name xam.xex and xboxkrnl.exe, and nothing else

Why the formatter is not in the normal build

It was in earlier versions and it has been taken out on purpose.

Formatting from the plugin means deciding the partition layout ourselves and writing FATX volumes by hand. Everything about that is a guess that has to stay right: cluster size, allocation table size, where the data area starts, what the console expects to find in a system partition. Get one of them wrong on someone else's drive and it is their data.

The console already does this correctly, by definition — its own kernel is the thing the layout has to satisfy. And it will do it for any drive the bypass has mounted, whatever was on it before: NTFS, FAT32, a Windows install, nothing at all. Run the exploit, then:

System Settings → Storage → Hard Drive → Format

Confirmed on hardware with a drive that still had a Windows 7 install on it: the console showed it as unformatted and formatted it without complaint.

That is simpler, safer, and produces a better result than anything this project could write.

With one exception, and it is worth knowing. The console formats the content partition and nothing else — it does not create a volume on the backward compatibility partition, so a drive prepared this way shows Hdd1 in Aurora and no HddX, and original Xbox games have nowhere to live. Creating that one partition still wants FATXplorer on a PC, or mkfs.fatx -b hd -p x1 from Linux. See Original Xbox Compatibility.

This is a genuine limit on the argument above rather than a detail: the console is the right tool for the volume it knows about, and silent about the one it never expected to be missing.

So the normal build has no formatter, and the recommended way to prepare a drive is to let the console do it. FATXplorer on a PC remains fine too.

The formatter stays in the debug build because it is still useful for research — in particular for producing deliberately odd layouts to test against.

Why the probes are not in the normal build

Diagnostics, XamProbe and the survey calls exist for the avatar and updater investigation. They write a log to the USB stick, enumerate content devices, poke at the updater interface and launch UI. None of it helps a user, and some of it changes console state.

They are still in the tree, still compiled in debug, and their findings are in Research Notes.

Using the debug build

Both files can sit on the USB stick at once. XeUnshackle loads BadStorage.xex.dll, so swap the one you want into that name:

BadUpdatePayload/BadStorage.xex.dll         <- the one that runs
BadUpdatePayload/BadStorage.debug.xex.dll   <- swap in when you need the log

The debug build writes BadUpdatePayload/BadStorage_diag.txt.