# FriiDump on Linux ## Exact-release hardware status The exact FriiDump 0.5.3.16-pf1 Linux executable has completed controlled hardware validation on both required GameCube paths: - `HL-DT-ST CDRW/DVD GCC4244 B101`; - physical GDR-8163B hardware that identifies as `HL-DT-ST DVD-ROM GDR8050L 0012` after a cross-flash with modified GDR-8050L firmware. Both runs used the exact executable with SHA-256 `ac58e427b59ba98018c8c1ed4f07fbf736cc887f3e74fefe0d04a43409d88561` and effective `cap_sys_rawio=ep`. Both runs completed profile selection, all 20 seed blocks, a controlled partial read, cancellation, native reporting, profile reporting, and STOP UNIT. The GCC-4244 B101 exact-release run supplements the earlier Candidate11 full dump, which remains the full-image hash authority. The GDR-8050L exact-release run validates the modified `0xE7` GameCube path; it does not claim a new full GameCube image. See [`reports/FRIIDUMP_LINUX_EXACT_RELEASE_HARDWARE_VALIDATION_0.5.3.16-pf1.md`](reports/FRIIDUMP_LINUX_EXACT_RELEASE_HARDWARE_VALIDATION_0.5.3.16-pf1.md). ## Candidate21 status FriiDump builds natively with GCC/CMake and uses Linux optical-drive packet commands through the existing `dvd_drive` transport. Candidate21 makes the Linux privilege boundary explicit and reproducible. Candidate21 also corrects the Linux GDR-8050L software tray cycle. Linux may lock an optical door while the device is open (`CDO_LOCK`). Before each required Xbox media cycle, FriiDump now releases that lock with `CDROM_LOCKDOOR`, sends the software eject/load sequence, waits for readiness, and restores the door lock after a successful load. On a cycle failure it deliberately leaves the door unlocked so the disc can be recovered without power-cycling the external drive. The Linux workflow uses two separate permissions: 1. **Device-node access** — the normal user must be able to open `/dev/sr*` and, where applicable, the corresponding `/dev/sg*`. On Ubuntu this normally comes from membership in the `cdrom` group. 2. **Vendor-command authorization** — GameCube/Wii memory-dump methods and Xbox vendor-unlock paths issue commands outside Linux's ordinary unprivileged SCSI allowlist. Those operations require effective `CAP_SYS_RAWIO`. Membership in `cdrom` is necessary but does not replace `CAP_SYS_RAWIO`. ## Candidate21 DMI and media-ID boundary Candidate20 proved the Linux SG_IO handshake and XDVDFS data path but left the media ID empty because its standard READ DVD STRUCTURE helper wrote Format to CDB byte 11. Candidate21 uses byte 7, matching the copied Windows `GetMediaID()` request. Live runs log `[XBOX-DVD-STRUCTURE]` PFI and DMI capture results. The expected Red Faction II media ID is `TQ00501A`. The step-9 sticky-descrambling transport result remains visible. Final READ CAPACITY and readable XDVDFS data are authoritative for game-view success. ## Build ```bash cmake -S . -B build \ -DBUILD_STATIC_BINARY=ON \ -DBUILD_NATIVE_REPORT_TESTS=ON \ -DFRIIDUMP_BUILD_COMMIT="$(git rev-parse HEAD)" cmake --build build --parallel ./build/src/friidump-xbox-portable-metadata-test ./build/src/friidump-linux-rawio-test ./build/src/friidump --help ``` Linux configuration and the Candidate21 build validator print a warning that a normal build does **not** install file capabilities. This is intentional: a compiler invocation must not silently elevate its output or invoke `sudo`. ## Install the minimum raw-I/O authority Do not run FriiDump itself with `sudo`, and do not install it setuid-root. Grant only `CAP_SYS_RAWIO` to the exact validated executable: ```bash BIN="$(readlink -f ./build/src/friidump)" sudo setcap cap_sys_rawio=ep "$BIN" getcap "$BIN" ``` Expected output: ```text /path/to/friidump cap_sys_rawio=ep ``` The maintained helper performs identity checks, applies the capability, verifies that the executable bytes did not change, and confirms the resulting xattr: ```bash bash ./validation/friidump-linux-rawio-capability.sh install \ ./build/src/friidump ``` Status and removal operations are also available: ```bash bash ./validation/friidump-linux-rawio-capability.sh status \ ./build/src/friidump bash ./validation/friidump-linux-rawio-capability.sh remove \ ./build/src/friidump ``` The maintained release helper applies the capability only to the exact validated executable: ```bash bash ./validation/friidump-linux-rawio-capability.sh \ install ./build/src/friidump ``` ### Capability lifetime Linux file capabilities are extended attributes. They are not reliably preserved by ZIP extraction, ordinary copying, source packaging, or rebuilding. Replacing or relinking the executable clears the capability. Reapply and verify `cap_sys_rawio=ep` after every build that will be used for vendor-command hardware work. Never assume that a newer candidate inherited the capability from an older binary. Candidate11 worked because its exact executable carried `cap_sys_rawio=ep`; Candidate12 and Candidate13 initially did not. ## Runtime preflight Before a vendor-command path begins seed retrieval or Xbox unlock, Candidate21 checks the process's effective capability mask from `/proc/self/status`. With the least-privilege configuration it prints: ```text Linux raw-I/O preflight: PASS (CAP_SYS_RAWIO effective; ...). ``` When the capability is absent, FriiDump refuses the vendor operation before seed retrieval, prints exact `setcap` and `getcap` commands for the running executable, writes the failure into the native report, and issues STOP UNIT. This replaces the previous generic transport-level `EPERM` failure. Candidate21 also refuses vendor-command work when the entire process is running as root. Run it as the normal user with the file capability instead. Standard readable-DVD operations that do not use vendor memory-dump or unlock commands do not require `CAP_SYS_RAWIO`. ## Device access Identify the actual optical device dynamically. Do not assume the external validation drive is `/dev/sr0`: ```bash for dev in /sys/class/block/sr*; do printf '%s: ' "/dev/${dev##*/}" xargs < "$dev/device/vendor" xargs < "$dev/device/model" xargs < "$dev/device/rev" done ``` Inspect permissions for the selected block and SCSI-generic device: ```bash id ls -l /dev/sr1 /dev/sg2 getcap "$(readlink -f ./build/src/friidump)" ``` Close media players and file managers, and unmount any filesystem from the selected drive. Linux currently provides no FriiDump-exclusive optical-volume lock equivalent for this path. For the validated cross-flashed GDR-8050L USB path, do not use standalone `sg_turs`, `sg_prevent`, or `friidump -p` commands as readiness or cleanup probes. During validation, separate probe commands blocked in kernel I/O and required a power cycle of the external drive and USB bridge. The accepted run used FriiDump's internal ready-media check and internal STOP UNIT only. ## Cross-flashed GDR-8050L GameCube/Wii procedure The validated physical unit required this sequence before a GameCube/Wii run: 1. Put a readable Video DVD in the tray. 2. Close the tray. 3. Power on and connect the external drive. 4. Wait until Linux identifies it as `HL-DT-ST DVD-ROM GDR8050L 0012`. 5. Keep drive power and USB connected. 6. Use the physical eject button. 7. Replace the Video DVD with the target GameCube or Wii disc. 8. Close the tray and wait for spin-up. 9. Start FriiDump as the normal user with `cap_sys_rawio=ep` on the exact validated executable. This boot-disc requirement is evidence for the validated cross-flashed unit. It is not a general claim for every GDR-8050L. On the validated JMicron `152d:2338` USB bridge, normal host media discovery started background reads that could block the USB/SCSI path before FriiDump opened the drive. The accepted run temporarily stopped UDisks and paused udev rule execution, created private device nodes from sysfs, ran FriiDump, required the external target to be disconnected, and then restored the host state. Do not disable UDisks or udev permanently. Use a reviewed, failure-safe quarantine workflow only when background host probing is proven to interfere. Record the original service state, restore it on every exit path, and disconnect the external target before queued udev work is released. If an optical command remains in process state `D`, signals cannot complete until the blocked kernel request returns. Power-cycle only the external drive and USB bridge. Leave unrelated optical drives installed. ## Xbox XISO ```bash ./build/src/friidump \ -d /dev/sr1 \ -T 4 \ -X "Red Faction II [TQ00501A].xiso" \ --firmware-modified \ "GDR-8163B cross-flashed with modified GDR-8050L firmware; patched to allow 0xE7 memory dumps" ``` Omitting the XISO filename on a GDR-8050L derives `Title[MediaID].xiso` from the unlocked XBE/DMI view on Linux. ## Xbox redump-style ISO ```bash ./build/src/friidump \ -d /dev/sr1 \ -T 4 \ -i "Red Faction II [TQ00501A].iso" \ --firmware-modified \ "GDR-8163B cross-flashed with modified GDR-8050L firmware; patched to allow 0xE7 memory dumps" ``` ## Exact-release evidence identities The accepted external evidence archives are not stored in Git: - `friidump-v0.5.3.16-pf1-gcc4244-b101-linux-smoke-v4-20260803T223910Z.tar.gz` - SHA-256: `7c9573d7dddf6381d8847626d0a45e96e57f2b64d79967a041d8acf4affebef5` - classification: `ACCEPTED_PASS_WITH_WRAPPER_POSTPROCESSING_DEFECT` - `friidump-v0.5.3.16-pf1-gdr8050l-0012-host-probe-quarantine-v2-20260804T031108Z.tar.gz` - SHA-256: `872b8144b8cc55601b268867ad8cc74cc7266a514cf015e24cd2fe3a450ee602` - classification: `ACCEPTED_PASS_WITH_OUTPUT_ASSERTION_DEFECT` The wrapper defects occurred after or outside the validated hardware gates. No additional hardware run is required only to correct those wrapper defects. ## Validation boundary A Linux build is not considered ready for vendor-command hardware validation until all of these are recorded: - exact executable SHA-256; - `getcap` output proving `cap_sys_rawio=ep` on that executable; - normal-user process identity; - device-node access through the intended group or ACL; - runtime raw-I/O preflight PASS; - hardware result, native report, and STOP UNIT result. The `--xgd1-layout-probe` and `--xgd1-raw-id-probe` development probes remain Windows-only in this candidate. Their Linux transport port is tracked separately from ordinary ISO/XISO user-path parity. ## Candidate21 GDR-8050L Windows-sequence parity The portable Linux path follows the proven Windows state-aware order: readiness, entry capacity, direct `UnlockDrive()`, `RefreshVolume()`, a 2000 ms settle, readiness and capacity verification, with exactly one tray-cycle retry only if the direct handshake remains in the video view. It then sets maximum speed and proceeds to metadata. The same helper is used after video capture. `RecoveryKick`, repeated synthetic LBA-zero reads, and generic automatic media-auth kicks are not part of this path. They belong only to a separate experimental modified-firmware campaign and are currently out of scope. ## GDR-8050L Xbox handshake transport Candidate21 keeps the proven Windows `UnlockDrive()` command sequence but sends its Linux form with `SG_IO`, the direct Linux SCSI pass-through interface. This preserves each 6-, 10-, and 12-byte CDB length, the Windows 120-second command timeouts, the 10-second sticky-descrambling timeout, transfer direction, sense data, host status, and driver status. Every handshake command emits an `[XBOX-SGIO]` record to both the live console and persistent FriiDump log. This is transport parity only. It does not add `RecoveryKick`, a generic media authentication kick, synthetic LBA-zero reads, or any modified-firmware-only recovery behavior.