wtf — gdox

skip to content

wtf

gdox connects physical game discs, supported optical drives, and compatible software.

play reads only what the connected software requests. preservation writes to a user-selected file. neither path writes to the disc.

path

identify the exact drive, firmware, and disc

open the validated reader path

prepare the system's read-only disc view

map each requested byte range back to the physical disc

close the session and restore temporary drive state

limits

support is exact. one drive, firmware, system, or operation does not imply another.

some reader paths use validated changes in volatile drive memory. they do not flash firmware, and removing drive power clears that state.

original xbox

gdox connects a supported dvd drive to xemu. when xemu requests part of the game, gdox reads that part directly from the disc.

the disc stays in the drive for the entire session. nothing is copied or installed first. the validated drive paths use an exact-profile reversible change in the drive's volatile state; they do not flash firmware or physically modify the reader.

analogy

think of the disc as a book with most of its page numbers hidden from a normal dvd drive. gdox makes the full page range available for the session. xemu asks for a page, gdox reads that page from the physical disc, and returns it. the whole book is never photocopied, and nothing is written in it.

visibility

imagine the round floor is the disc. each tile is a small piece of data. the lit tiles are what a normal dvd drive can see. the tiles in shadow are still there, but hidden.

gdox lets the drive see the whole floor for the session. it then reads only the tiles xemu asks for. it does not copy or change the disc.

how it works

data path

desktop: xemu read → localhost NBD → compact virtual disc → SCSI sector read → optical drive.

android: xemu read → in-process block driver → compact virtual disc → SCSI sector read → optical drive.

drive interface

an optical drive is a block device. data is addressed as fixed-size logical sectors rather than files. gdox issues SCSI/MMC commands through the operating system's SCSI passthrough interface or through USB Mass Storage Bulk-Only Transport. reader backends hide those transport differences and provide the same random-access sector interface to the rest of the application.

code: scsi_transport.c, usb_bot_libusb.c.

disc layout

an original xbox disc contains more than the dvd-compatible area exposed by a normal drive. a supported reader backend makes the complete logical address space available, either through compatible reader firmware or a reversible change in volatile drive state. the operation is read-only: gdox does not write to the disc or flash the drive.

code: mt1887_source.c, gp08_source.c, and asus_nr09_source.c.

partition mapping

gdox finds and reads the game partition's XDVDFS filesystem, then builds a conventional compact disc layout in memory. directory sectors are generated for that virtual layout. file sectors are mapped back to their physical locations and read from the original disc when xemu requests them. files are not extracted. compatibility changes, when required, exist only in the virtual view.

code: xdvdfs.c, compact.c.

read requests

gdox validates each byte range and resolves it to virtual metadata or physical file sectors. desktop file-sector requests go to the optical source directly. android combines nearby small requests through one forward-only 256 KiB memory window. that window is never written to storage and disappears when the session ends. there is no full-disc background reader or image fallback, so unused parts of the disc are never copied.

virtual dvd drive

the partition is exported by a small read-only fixed-newstyle Network Block Device server bound to localhost. xemu's QEMU core connects directly to that private NBD export and treats it as a dvd drive. NBD is used only as local block-device transport; no kernel NBD device, filesystem mount, or temporary disc image is created.

code: nbd_tcp.c.

shutdown

when xemu exits, the session ends, or the drive disconnects, the virtual disc closes and the reader backend restores any temporary drive state it still controls. tray eject is used only on mechanisms that support it safely.

preservation

a playable xiso rebuilds the game filesystem into a smaller image for emulators. full-disc mode writes the much larger accessible disc layout and keeps hashes, a manifest, logs, and drive evidence beside it. gdox reports security evidence and unreadable ranges separately: file size alone does not make an image redump-complete, and a stock reader cannot manufacture signed challenge data that the disc or drive did not return.

code: preserve.c.

software stack

C17 for the core, reader backends, parser, virtual-disc mapper, preservation engine, and NBD server

C++20 for the desktop app, with raylib, Dear ImGui, and rlImGui for the interface

libusb, native macos USB transport,...