FriiDump - A program to dump Nintendo Wii, GameCube, DVD, and Xbox discs =============================================================================== This version adds native Xbox/XGD disc support for selected Xbox optical drives, including the GDR-8050L challenge-table handshake path, the GDR-3120L FF 08 01 vendor lock-state path, redump-style metadata output, optional XISO output, and a convenient forced-DVD mode (`-D` / `--dvd`). See docs/XBOX.md for Xbox-specific details. FriiDump is a program that lets you dump Nintendo Wii and GameCube disc from your computer, without using original Nintendo hardware. It basically performs the same functions as the famous "RawDump" program, but with a big difference, which should be clear straight from its name: FriiDump is free software, where "free" is to be intended both as in "free speech" and in "free beer". As such, FriiDump is distributed with its sources. This leads to a number of good consequences: - Having the sources available, it can be easily ported to different operating systems and hardware platforms. At the moment it is developed under a GNU/Linux system, but it also runs natively on Windows. A MacOS X version can be easily created, although I don't have a Mac, so I can't do it myself. - Also, having the sources and these being well-organized (I know I'm a modest guy) allows support for new DVD-ROM drives to be added relatively easily. At the moment the same drives as RawDump are supported, but this might improve in the future, if anyone takes the effort... See README.technical for details. - The sources might also be used as a reference for several things regarding Nintendo Wii/GameCube discs and the hacks used to read them on an ordinary drive. Furthermore, FriiDump also features some functional improvements over RawDump: - FriiDump can use 4 different methods to read the disc, with different performance. - FriiDump dumps a lot of useful information about the discs it dumps, such as whether the disc contains an update or not, which can help avoid bricking your Wii ;). - FriiDump calculates CRC32, MD5, SHA-1, and SHA-256 hashes of dumped discs, so you can immediately know if your dump is good or not, by comparing the hashes with the well-known ones available on several Internet sites. - FriiDump can now verify completed ISO hashes automatically against bundled Redump Logiqx XML DAT files for GameCube, Wii, and Xbox. Verification matches output size, CRC32, MD5, and SHA-1; SHA-256 remains printed as an additional local integrity hash because the supplied Redump DAT entries do not contain it. - FriiDump comes in the form of a library and a command-line front-end, which allows its functions to be easily reused in other programs. Unfortunately, there is also a main downfall: - Even the fastest dump method used by FriiDump is not as fast as RawDump (but not that much slower, either, see the table below). Anyway, I'm sure that people who cannot use RawDump (i.e.: GNU/Linux, *BSD and MacOS X users) will be happy anyway. Besides, you get the sources, so you can improve them yourself. Note that FriiDump is primarily useful for dumping original Nintendo discs, standard DVD-ROM media, and selected Xbox/XGD media through supported or forced drive profiles. To dump ordinary backup copies you can also use a generic DVD dumping program (i.e.: dd under UNIX ;)). FriiDump came to existance thanks to the work by a lot of people, most of which are probably not aware of this fact ;). Please see the AUTHORS file for the credits. =============================================================================== Supported drives =============================================================================== At the moment the same drives as RawDump are supported. This is due to various reasons, explained in the README.technical file, which also contains information about what is needed to add support for more drives. Currently supported drives are: Nintendo GC/Wii supported-drive list: - Hitachi-LG GDR-8082N, GDR-8083N, GDR-8084N - Hitachi-LG GDR-8161B, GDR-8162B, GDR-8163B, GDR-8164B - Hitachi-LG GCC-4160N, GCC-4240N, GCC-4243N, GCC-4244N, GCC-4247N - Hitachi-LG GDR-8085N, GDR-8087N, and GCC-4246N are listed as probable but untested GC/Wii-capable candidates. - Hitachi-LG GCC-4241N and GCC-4242N are listed as capable but error-prone. Additional drive profiles recognized in this branch: - HL-DT-ST GSA-4163B as a Hitachi-LG/GC-Wii experimental profile. - HL-DT-ST GDR-3120L 0046 as an experimental read-only GC/Wii candidate when the HLDS 0xE7 profile is selected; it remains historically an Xbox reference drive until live GC/Wii dumps validate it. - TSSTcorp/Samsung TS-H352C, TS-H353A, SH-D162C, SH-D162D, SH-D163A, and SH-D163B as Samsung/Kreon-style Xbox-capable candidates when firmware supports the FF 08 01 command family. Stage5B-promoted HLDS 0xE7 profile metadata recognized in this branch: - GCC-4244N B103: CDB 0x894, gate 0x900386FB, tokens HL;IT;RPC;RPC_JCS3;RPC_SUFFIX; full Sonic Mega Collection GameCube dump validated on a live drive. - GDR-8163B 0B30: CDB 0x5E0, gate 0x90025030, tokens HL;IT;RPC;RPC_JD4_SPACE;RPC_SUFFIX; full Sonic Mega Collection GameCube dump validated on a live drive. - GDR-8163B 0D20: CDB 0x5E0, gate 0x90024AE7, tokens HL;IT;RPC;RPC_JD4_SPACE;RPC_SUFFIX; full Sonic Mega Collection GameCube dump validated on a live drive. - GDR-8163B 0E15: CDB 0x5D8, gate 0x900247D1, tokens HL;IT;RPC;RPC_JD4_SPACE;RPC_SUFFIX; full Sonic Mega Collection GameCube dump validated on a live drive. - GDR-8163B 0L20: CDB 0x5E0, gate 0x90024C8F, tokens HL;IT;RPC;RPC_JD4_SPACE;RPC_SUFFIX; full Sonic Mega Collection GameCube dump validated on a live drive. - GDR-8163B 0L23: CDB 0x5E0, gate 0x90024D5A, tokens HL;IT;RPC;RPC_JD4_SPACE;RPC_SUFFIX; full Sonic Mega Collection GameCube dump validated on a live drive. - GDR-8163B 0L30: CDB 0x5E0, gate 0x90025021, tokens HL;IT;RPC;RPC_JD4_SPACE;RPC_SUFFIX; full Sonic Mega Collection GameCube dump validated on a live drive. - GDR-8163B 0M26: CDB 0x5E0, gate 0x90024FF7, tokens HL;IT;RPC;RPC_JD4_SPACE;RPC_SUFFIX. The static CDB/gate values above are firmware-analysis evidence used for profile reporting and confidence. They are not host-side commands and are not used as runtime addresses by FriiDump. Xbox/XGD native profiles: - Xbox GDR-8050L (HL-DT-ST/DVD-ROM GDR8050L, challenge-table handshake). - Xbox GDR-3120L (HL-DT-ST/DVD-ROM GDR3120L or GDR-3120L, FF 08 01 vendor feature-list and lock-state unlock path). HD-DVD and BD dumping are documented as DiscImageCreator reference areas, but FriiDump remains a DVD/GC/Wii/Xbox-focused tool in this branch; no full BD or HD-DVD feature set is claimed here. Other drives might work, most likely those based on the Hitachi MN103 microcontroller. If you find any of them, please report so that they can be added to the compatibility list. =============================================================================== Installation =============================================================================== If you are a Windows user, probably you will have downloaded the binaries, either zipped or together with an installer, so the installation should be straightforward. If you downloaded the sources, you will need to compile them. FriiDump uses CMake, for easy portability, so you will need to get it from cmake.org. On Windows you will also need a compiler like Visual Studio (the only tested one, so far) or CygWin/MinGW. On UNIX just do the following, from the directory where you unpacked the sources into: $ mkdir BUILD $ cd BUILD $ cmake .. $ make $ make install Linux-specific note: You need root privileges to issue certain commands to the DVD-ROM drive. Hence you have the following possibilities: - Run FriiDump as root: discouraged. - Run it through sudo: better but nevertheless discouraged. - Set the setuid bit on the executable: this is the recommended way to run FriiDump under Linux. This way, the code run with superuser privileges will be reduced to a minimum, guaranteeing a certain level of security (note that security-related bugs might exist anyway!!!). Also note that, even when the setuid bit is set, the attempt to open the drive for reading will be done after privileges have been dropped, so you will need explicit read access to the DVD-ROM drive. Usually having the system administrator add you to the "cdrom" group is enough. To set the setuid bit on the executable, run as root: $ chown root:root /usr/local/bin/friidump $ chmod u+s /usr/local/bin/friidump =============================================================================== Usage =============================================================================== FriiDump is a command-line program, so you will need to run it from a terminal or a command-prompt under Windows. The basic usage is as follows: friidump -d -a For a plain DVD-ROM dump from any readable drive, use `-D` / `--dvd` or the numeric equivalent `-T 3`: friidump -d -D -i dvd.iso For Xbox discs, use automatic detection on known Xbox drives or force Xbox mode with `-T 4`. Xbox mode is fail-fast on drives that are not wired into the Xbox unlock backend; it does not fall back to GC/Wii methods. To make a redump-style Original Xbox/XGD1 ISO, use: friidump -d -T 4 -i On GDR-8050L, bare `-i` derives `Title[MediaID].iso` from the XBE title and DMI media ID, matching the reference dumper. Use `-i xbox.iso` only when you want to override that filename. For Xbox/XGD media, `-i` is not just a game-partition copy. It reconstructs the full redump-style 2048-byte-sector layout: visible DVD-video L0, pregame padding, 32-sector game lead-in, unlocked game/XDVDFS data, postgame padding, and visible DVD-video L1. FriiDump also attempts to save `xbox.pfi.bin`, `xbox.dmi.bin`, and `xbox.redump.json` next to the ISO. The redump-style layout constants are checked against DiscImageCreator's Original Xbox/XGD1 model: total size 3,820,880 sectors, layer break LBA 1,913,776, DVD start PSN 0x30000, and Xbox/game start PSN 0x60600. FriiDump 0.5.3.11 adds a read-only evidence mode for the unresolved synthetic XGD1 ranges: ```powershell friidump -d --xgd1-layout-probe xgd1-layout-probe.json ``` This mode creates no ISO. On the GDR-8050L challenge-handshake profile it establishes locked/video and unlocked/game states, reads selected boundary LBAs with READ(10) and READ(12), verifies the exact expected capacities, and writes an atomic JSON report containing SCSI status/sense evidence, SHA-1, nullable failed-read classifications, explicit command comparability, and the complete sector data for successful reads. The current pregame padding, postgame padding, and 32-sector game lead-in remain unresolved; probe success must not be represented as an exact Redump image. On a GDR-8050L, FriiDump follows the original dumper's state order and timing: primary handshake, media-cycle, re-handshake, RefreshVolume plus full settle delays, metadata/XBE probe, media-cycle back to the visible DVD-video view, video capture, final handshake, game data write, metadata write, and STOP UNIT cleanup. The 32-sector game lead-in in this path is zero-filled like the original option-1 dumper. To dump only the Xbox game partition as an XISO-style image, use: friidump -d -T 4 -X On GDR-8050L, bare `-X` derives `Title[MediaID].xiso`; use `-X xbox.xiso` only when you want to override that filename. where will usually be something like "/dev/hda" on Unix-like systems, and something like "e:" for Windows users. With -a, the disc will be dumped to an ISO image file with an automatically-chosen name. Drop -a and use the -i option if you prefer to specify the filename yourself. If you want to resume an existing dump, use -s. Xbox redump-style `-i` does not support resume because the drive view changes from visible DVD-video to unlocked/game during one run. If you want to dump a Nintendo disc to a raw format image file, use -r. Note that you can create a raw and an ISO image at the same time for Nintendo disc types; Xbox redump-style ISO output should be run with `-i` only, and Xbox XISO output (-X) is a separate output mode that cannot be combined with -r, -i, or -a. Other options you might want to use are -1 through -4, to set the dump method, although the default is method 4, which is the fastest one, so most likely you will not need them. The -A/--allmethods option tries every supported command/method combination. It reopens the drive for each command so vendor-specific memory-dump handlers are rebound before each method is tested. This is useful for experimental drive profiles, but it can be slow and noisy. For HLDS 0xE7 testing, `--hlds-profile-report ` writes the selected profile, support tier, parser-token family, Stage5B record tag, static CDB/gate evidence, cache base, memory-window count, selected method, and safety note to a JSON file next to the run logs. This is intended for fleet validation and should be included with test-result ZIPs. Finally, use -h for a listing of all available options. =============================================================================== Performance =============================================================================== As stated above, FriiDump is not as fast as RawDump. On my PC (Athlon64 3200+), performance is as follows: ------------------------------------------------------------------------------- | Method | Dump speed | GameCube disc dump time | Wii disc dump time | ------------------------------------------------------------------------------- | 1 | Too slow ;) | Eternity | More than eternity | | 2 | ~570 MB/h | 2.5 hours | 8 hours | | 3 | ~740 MB/h | 2 hours | 6 hours | | 4 | ~1250 MB/h | 1.2 hours | 3.5 hours | ------------------------------------------------------------------------------- =============================================================================== Support =============================================================================== I'm releasing this program under the nickname of "Arep". This is because I am not sure about the legal status of the program, and I do not want to encounter any consequences. Actually, I'm pretty sure FriiDump goes against the DMCA, being a program that circumvents copy-protection, but it might be objected that the format used by Nintendo discs is not a copy-protection method, but just their own, undocumented, disc format. Although, I think it can be freely used in Europe and other coutries without laws similar to the DMCA. For the same reason, I am not putting an e-mail address here (that @no.net you find in the program is obviously a pun), but support will be provided through the forums of the Italian ConsoleTribe forum, at http://wii.console-tribe.com. If you need help, just open a thread in any section there, even in English: I will *not* reply, but you might stand assured I will read everything you write. FriiDump users are encouraged to help each other there ;). Patches are welcome, too: just attach them to your post, and maybe put something like "[PATCH]" in the topic subject, so that I can easily spot them. New releases will be announced on that forum, and also on QJ.net, if I find a good way to notify them. If you want to donate to the project, do not do it, and donate to one of the free Wii modchip projects out there, such as OpenWii, WiiFree or YAOSM. =============================================================================== Disclaimer =============================================================================== FriiDump is distributed under the GNU General Public License version 2. See the COPYING file for details. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Also, please note that this program is not meant to be used to spread game piracy, but rather to be instrument to make backups of your own precious legally-bought games. Windows MSVC32 build shortcut ----------------------------- A VS Code task file is included for the direct cl.exe build used by this working tree. It uses .vscode\msvc32.cmd to initialize the Visual Studio 2019 32-bit compiler environment and then compiles FriiDump directly, without requiring CMake or NMake for the normal Windows test build. From VS Code: Terminal -> Run Build Task... -> build-friidump-msvc32 or press Ctrl+Shift+B. From PowerShell or cmd: .\build_msvc32.cmd The build writes friidump.exe to the source root, runs friidump.exe --help, and creates friidump_msvc32_build_results.zip. GCC-4243N/GCC-4244N Method 8 split-recovery note -------------------------------------------------- For HLDS GCC-4243N and GCC-4244N GameCube/Wii dumping, the default Hitachi command-2 / Method-8 path now has three visible recovery layers: the existing Method-8 5-block/window read reconstruction retry loop, the dump-level retry envelope, and a Method-8 split-recovery path for a failed 16-sector block. The split-recovery path reconstructs the failed block by trying 8-sector, 4-sector, 2-sector, then 1-sector streaming chunks, validates the rebuilt 16-sector raw block with the normal unscrambler/EDC check, and only caches/writes it if validation succeeds. All retry and split-recovery messages are mirrored through the shared FriiDump log file, so a failure such as `Dump failed at sectors: N..N+15` should now include whether 8/4/2/1 chunk recovery was attempted and where it failed. Existing Xbox logging remains on the same shared log path; GDR-3120L Xbox support remains on the explicit vendor lock/unlock path. HLDS 0xE7 DIC profile-layer update ------------------------------------ This branch now classifies HLDS/MN103 0xE7 GC/Wii dumping drives into DIC-style profiles before assigning the FriiDump Hitachi cache reader. The selected profile is printed in the run log after Command/Method: - Type1: GCC-4160N/GCC-4240N, cache base 0x00a13000, one 16-sector memory window. - Type3: GCC-4243N/GCC-4244N/GCC-4246N/GCC-4247N and GDR8083N/GDR8084N, cache base 0x80000000, five 16-sector memory windows. - Type4: GDR8082N/GDR8161B/GDR8162B/GDR8163B/GDR8164B and related DVD-ROM profiles, cache base 0x80000000, five 16-sector memory windows. - GDR-8050L modified 0xE7 speed-probe/fallback: GDR8050L/GDR-8050L with cross-flashed or modified firmware that adds 0xE7 memdump, cache base 0x80000000. Single-window is proven; this build probes guarded 3-window, 2-window, and 5-window no-prefetch schedules before falling back to the proven one-window Method 8 profile. - Type2_1/Type2_2: GCC-4241N/GCC-4242N are identified as experimental DIC Type2 shapes, but this branch does not yet claim DIC parity for their moving-cache behavior. The Type1 base address comes from the DIC source behavior for GCC-4160N/GCC-4240N. Method 8 now honors the selected profile's memory-window count, so Type1 reads/cache-validates one 16-sector block per request instead of assuming the Type3/Type4 five-window cache layout. GCC-4243N and GCC-4244N remain on Method 8 by default. GDR-8050L is split into a modified-firmware GC/Wii 0xE7 path: stock GDR-8050L firmware is still expected to use the Xbox path only, while a cross-flashed/modified GDR-8050L with 0xE7 memdump added can use Method 8. The proven GDR-8050L fallback is one window/no-prefetch; this build probes guarded multi-window no-prefetch speed profiles and reverts to the proven single-window path if an accelerated read fails. GDR-3120L Xbox ripping support remains on the separate explicit vendor lock/unlock path and is not described as GC/Wii support. 2026-06-29 / HLDS 0xE7 Windows volume guard --------------------------------------------- * The existing Xbox FSCTL_LOCK_VOLUME-style guard is now exposed as a shared FriiDump volume lock helper. * HLDS 0xE7 GC/Wii paths apply the guard before disc seed retrieval, so Windows Explorer/AutoPlay is less likely to interrupt GCC-4160N/GCC-4240N Type1 seed reads with an "insert a disc" prompt. * The guard is warning-only: if Windows already owns a transient handle, FriiDump logs the failure and continues so the hardware read result remains authoritative. 2026-06-29 / HLDS 0xE7 AutoPlay warning ------------------------------------------------ * Added an explicit Windows AutoPlay warning before the HLDS 0xE7 GC/Wii volume-lock and seed-retrieval phase. * GCC-4160N Type1 testing showed the volume lock works, but Windows AutoPlay can still open an "insert a disc" dialog and interfere until AutoPlay is disabled and File Explorer/dialogs are closed. * The warning is printed for all non-Xbox HLDS 0xE7 GC/Wii profiles before FriiDump attempts the shared volume guard. HLDS 0xE7 validation summary and observed speeds -------------------------------------------------- For HLDS 0xE7 GC/Wii runs, FriiDump now prints a compact validation summary at the end of the run. The summary records the selected profile, cache base, memory-window count, seed-read status, seed-retrieval elapsed time, dump status, STOP UNIT status, duration, and an observed average speed computed from the ISO payload size and elapsed dump time. Completed ISO outputs are also checked automatically against the canonical Redump DAT for the selected disc type unless `--no-redump-verify` is used. Seed retrieval timing note: normal GC/Wii seed cracking is usually a seconds-to-tens-of-seconds step, with the original technical note describing the brute-force portion as roughly 30 seconds on the old reference path. Experimental HLDS 0xE7 profiles can take longer because this fork may also probe cache profiles and guard against Windows polling. This build does not add a hard seed timeout because aborting a blocked optical-drive command from inside FriiDump is less safe than letting Windows/drive firmware return or letting the user cancel with Ctrl+C. As an operational rule, a seed phase above about 5 minutes is suspicious, and above about 10-15 minutes should usually be treated as a failed profile/drive state: cancel, confirm AutoPlay/File Explorer are closed, power-cycle or tray-cycle the drive if needed, and rerun with the log preserved. Observed Sonic Mega Collection (US) fleet results so far: | Model | Firmware | HLDS profile | Cache base | Windows | Result | FriiDump final displayed rate | Duration | Notes | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | GCC-4244N | B103 | promoted GCC_424x profile | 0x80000000 | 5 | PASS | 2152.04 MiB/h | 2329.16 s | Live INQUIRY `GCC4244/B103`; exact profile; media preflight, seed read, full Sonic dump, STOP UNIT, and Redump hashes confirmed. | | GCC-4244 | B101 | Type3 legacy fallback | 0x80000000 | 5 | PASS | 2156.33 MiB/h | 2324.52 s | Live INQUIRY `GCC4244/B101`; exact parser metadata remains pending analyzer results; Sonic Mega Collection and Super Smash Bros. Melee Rev 2 both completed with exact automatic Redump verification. | | GCC-4243N | A102 | Type3 | 0x80000000 | 5 | PASS | 2534.09 MB/h | 1522.95 s | Confirmed matching Sonic hashes after resume/retry work. | | GCC-4160N | 0010 | Type1 | 0x00a13000 | 1 | PASS | 1613.08 MB/h | 3127.98 s | AutoPlay had to be disabled; volume guard OK; hashes matched known-good Sonic dump. | | GDR-8050L modified | 0012 | GDR-8050L modified 0xE7 single-window proven fallback | 0x80000000 | 1 | PASS | 776.49 MiB/h / 782.59 MB/h | 6455.22 s | Cross-flashed/modified firmware with 0xE7 memdump; hashes matched Sonic. Current build adds guarded speed probes. | | GDR-8163B | 0L30 | Type4 / promoted GDR_816x profile | 0x80000000 | 5 | PASS | 678.55 MiB/h | 7387.03 s | Germany-batch drive with case label 0L23 but inquiry 0L30; full Sonic dump validated; Stage5B parser signature recovered at CDB 0x5E0 / gate 0x90025021. | Known-good Sonic Mega Collection (US) target hashes: ``` CRC32 01b52739 MD5 85a525df1481d0ad67d8761f832dca12 SHA-1 06eb6d15b4d7f90ec0fed9ce9a77db41358d74ed SHA-256 30098da93f5de9ece8da44f8afdfb85cf9bcdc24d77131221e64e3038a529010 ``` Use this table as an observed fleet log, not a promise that every firmware revision of a model behaves identically. HLDS GDR-8050L modified 0xE7 note (2026-06-30): A cross-flashed GDR-8163B running modified GDR-8050L firmware with 0xE7 memdump added reached seed retrieval and dumped the first 320 sectors, then failed at sectors 320..335 when treated as a normal five-window Type4 cache. A later single-window/no-prefetch run completed Sonic Mega Collection and matched the known hashes at roughly 776.49 MiB/h / 782.59 MB/h. This build keeps that single-window path as the proven fallback, but adds a speed probe before seed cracking: 3-window no-prefetch, 2-window no-prefetch, 5-window guarded no-prefetch, then fallback to one window. If an accelerated GDR-8050L profile later fails during a dump, FriiDump logs the failure and reverts to the proven one-window profile for the rest of the run. Stock GDR-8050L remains an Xbox path, not a GC/Wii memdump drive. GDR-8081N experimental 0xE7 probe layer ----------------------------------------- GDR-8081N is now recognized as an experimental HLDS 0xE7 GC/Wii candidate. Unlike GDR8082N/GDR816x, it was not in the confirmed DIC dump list, so FriiDump does not hard-code it as a normal Type4 drive. It starts as `GDR-8081N experimental 0xE7 probe` and, during seed retrieval, tries small sector-0 validation reads across these cache profiles: - Probe A Type4-derived: base 0x80000000, 5 windows. - Probe B single-window: base 0x80000000, 1 window. - Probe C Type1-base: base 0x00a13000, 1 window. - Probe D moving-cache candidate: base 0x7fff7f00, 1 window. The first candidate that can read/validate sector 0 is selected for the rest of the run and logged. If all candidates fail, seed retrieval stops and the log records each failed probe. Unsupported/non-HLDS drives now keep zeroed HLDS profile fields so stale cache-base/window values are not printed. GDR-8050L speed-probe visibility note: Builds after the seed-timer package report the modified GDR-8050L as `speed-probe pending` at initial drive-info time, then print each guarded candidate during seed retrieval. If all accelerated candidates fail, the run visibly selects the proven single-window fallback. Probe v2 note: The GDR-8050L speed-probe-pending profile now defaults to Method 8, so the probe branch is actually exercised by default. Seed cracking now fails the run if the experimental 0xE7 profile probe cannot validate a cache candidate, instead of continuing after an unsupported/failed probe. The first visible probe message starts on a fresh line after the seed-retrieval prompt for easier log review. HLDS 0xE7 logging note: GDR-8050L modified-0xE7 read schedule selection is logged once per run/profile selection, not once per read chunk, to keep long dump logs readable. FriiDump HLDS 0xE7 probe-v2 log-once cleanup ------------------------------------------------ The GDR-8050L modified 0xE7 selected schedule is now reported by the profile probe only. The per-read Method 8 path no longer prints the schedule line for every 16-sector chunk. ### Experimental HLDS 0xE7 scan mode For drives such as GDR-8081N where the HIT 0xE7 command surface appears plausible but the cache base is not known, use scan mode before attempting a full dump: ```powershell .\friidump.exe -d f: --hlds-e7-scan -T 0 --scan-log "gdr8081n_e7_scan.json" $zip = "friidump_gdr8081n_e7_scan_results.zip" if (Test-Path $zip) { Remove-Item $zip -Force } Compress-Archive -Path .\gdr8081n_e7_scan.json,.\friidump.log -DestinationPath $zip -Force ``` This mode writes a JSON report and stops; it does not crack seeds or dump the disc. FriiDump 0.5.3.4 HLDS media-preflight correction ---------------------------------------- This build corrects the media-ready preflight before GameCube/Wii/Xbox disc initialization and seed retrieval. FriiDump now treats non-GOOD SCSI status as failure even when the Windows pass-through ioctl itself succeeds, then requires both TEST UNIT READY and a valid READ CAPACITY(10) result before vendor seed/cache commands are allowed. This covers optical drives and USB bridges that report TEST UNIT READY=GOOD with an empty tray. The live SCSI INQUIRY identity `HL-DT-ST CDRW/DVD GCC4244 B103` is normalized to the promoted GCC-4244N B103 Stage5B profile (CDB evidence 0x894, gate evidence 0x900386FB). Static firmware addresses remain reporting evidence only and are never emitted as host-side write/update commands. See `docs/reports/FRIIDUMP_HLDS_LIVE_VALIDATION_0.5.3.5.md` for the real-hardware validation matrix and reference hashes. FriiDump 0.5.3.5 GCC-4244N B103 live validation ------------------------------------------------ The live SCSI INQUIRY identity `HL-DT-ST CDRW/DVD GCC4244 B103` is now marked `known_supported_profile_hardening_live_validated`. Using the exact promoted JCS3 parser profile (CDB evidence `0x894`, gate evidence `0x900386FB`), FriiDump completed Sonic Mega Collection (US) with media preflight OK, seed retrieval in 4 seconds, full dump OK, STOP UNIT OK, and hashes matching the Redump reference. The observed average was `2152.04 MiB/h` over `1392.34 MiB`, with a total duration of `2329.16` seconds. See `docs/reports/FRIIDUMP_HLDS_LIVE_VALIDATION_0.5.3.5.md` for the consolidated validation matrix. =============================================================================== Automatic Redump DAT verification and evidence report =============================================================================== FriiDump 0.5.3.10 adds a state-aware GDR-8050L metadata-entry flow. The bridge reads entry capacity first. An already-unlocked game view skips the redundant initial handshake and tray cycle; a locked/video view receives one direct full handshake with READ CAPACITY verification. A tray-cycle retry is retained only as an explicitly logged recovery path. The later media transition that restores the locked/video view for VIDEO-L0/VIDEO-L1 capture remains, as does the final handshake for game/XDVDFS data. FriiDump 0.5.3.9 also closes the Xbox live-summary boundary: the copied GDR-8050L path now returns title, media ID, finalized output sectors, and elapsed evidence to the final validation summary, and final STOP UNIT ownership is singular. FriiDump checks each successfully completed ISO against the canonical Redump DAT selected for the detected or forced disc type. Verification begins only after CRC32, MD5, SHA-1, and SHA-256 have been finalized. Stable DAT paths: - `redump_dat/Nintendo - GameCube.dat` - `redump_dat/Nintendo - Wii.dat` - `redump_dat/Microsoft - Xbox.dat` The verifier is active for GameCube/Wii ISO dumps and for full-disc Xbox ISO outputs. On Windows, the copied GDR-8050L reference-dumper bridge now returns its actual finalized output path, byte count, CRC32, MD5, SHA-1, and SHA-256 to the shared verifier. FriiDump therefore reuses the reference path's existing full-file hash pass rather than reading the 7.29 GiB image a second time. Xbox `-X` output remains intentionally excluded: an XISO is a game-partition representation, not a full Redump disc image. An exact archive verification requires all four Redump identity fields to agree with one DAT entry: - output byte size - CRC32 - MD5 - SHA-1 SHA-256 is retained as local integrity evidence in the JSON report even though the supplied Logiqx DAT records do not contain SHA-256. The console now presents the evidence directly: ```text Redump verification ------------------------------------------------------------ DAT redump_dat/Nintendo - GameCube.dat Entries scanned 2019 Matched entry Sonic Mega Collection (USA) ROM Sonic Mega Collection (USA).iso Image size PASS CRC32 PASS MD5 PASS SHA-1 PASS Overall VERIFIED AGAINST REDUMP Confidence Exact archive match ``` For a non-match, FriiDump shows the closest candidate only when at least one hash correlates. It then prints PASS/FAIL for size, CRC32, MD5, and SHA-1. When no hash-correlated candidate exists, it reports aggregate per-field match counts instead of presenting an arbitrary same-size disc as meaningful evidence. `--redump-report ` writes schema-2 JSON containing the observed hashes, SHA-256, hash source, representation note, expected DAT fields, per-field PASS/FAIL evidence, match counts, overall conclusion, and confidence statement. The report is written to `.tmp`, flushed and synchronized, closed, and then atomically replaces the final path. A failed write never exposes a partial final JSON document and does not overwrite a previous complete report. The JSON writer uses unlogged file output. Report contents therefore remain in the JSON artifact and are no longer mirrored into the human-readable run log as an incomplete object with missing string values. For the GDR-8050L/cross-flashed GDR-8163B full-ISO path, the report identifies `GDR-8050L reference finalized full-file hashes` as the hash source. FriiDump also records that XGD1 acquisition success and exact Redump hash identity are separate claims. The current reconstruction contains unresolved zero-filled pregame and postgame spans, so a clean physical read can legitimately produce `NO EXACT MATCH`. That result must not be promoted to archive identity. Options: - `--redump-dat-dir ` explicitly selects a directory containing the three stable DAT filenames above. Without it, FriiDump checks `redump_dat` beside the executable and then under the current working directory. - `--redump-report ` writes the atomic machine-readable evidence report. - `--no-redump-verify` disables DAT lookup for a run. - `--nohash` also prevents DAT verification because the required hashes are not calculated. - `--xgd1-layout-probe ` is a separate read-only Windows diagnostic for the GDR-8050L challenge-handshake profile. It cannot be combined with image output, conversion, all-methods, or HLDS 0xE7 probe options. Example: ```powershell .\friidump.exe ` -d E: ` -T 0 ` -8 ` -s ` -i "sonic.iso" ` --redump-report "docs\debug\sonic.redump.json" ``` The DAT files are data inputs, not compiled into the executable. Replace the three files in the executable-relative `redump_dat` directory with newer Redump exports while keeping the stable filenames, or point `--redump-dat-dir` at an alternate set. The current-working-directory lookup is retained as a fallback for source-tree and legacy workflows. FriiDump 0.5.3.12 adds a second read-only XGD1 evidence mode for the user's modified GDR-8050L firmware: --xgd1-raw-id-probe The probe establishes the locked/video and unlocked/game views, performs controlled 16-sector READ(12) cache fills, then uses the accepted HIT 0xE7 memdump command at cache base 0x80000000 to capture the selected 2064-byte raw sector. The report records the raw ID field and decodes its 24-bit physical sector number. This is intended to test logical-to-physical geometry; it does not read inaccessible filler sectors, does not modify the current XGD1 image layout, and requires the modified 0xE7 firmware profile. The 0.5.3.11 live logical probe found 17 successful READ(10)/READ(12) pairs, all byte-identical. Both active capacities rejected the sampled out-of-range LBAs with 05/21/00. Therefore ordinary logical reads do not supply the current synthetic pregame/postgame filler bytes. FriiDump 0.5.3.13 corrects the raw-ID probe after the first live v68 run showed that arbitrary request LBAs could leave cache base 0x80000000 pointing at an earlier or block-start window. The corrected probe aligns every request to a 16-sector block, issues the proven zero-transfer READ(12) cache flush, and dumps only the target slot's 12-byte header and four-byte EDC. It validates layer bits and raw/normalized PSNs against the current full-output geometry. Raw-cache user-data equality is no longer treated as evidence because Method 8 reconstructs that field from READ(12) data before unscrambling. Geometry may be resolved by a complete match; inaccessible filler bytes remain unresolved. FriiDump 0.5.3.14 drive-captured XGD1 game lead-in ---------------------------------------------------- The 0.5.3.13 live cache-aligned raw-ID run matched all 13 selected locked/video and unlocked/game samples. It proved that unlocked source LBA 0..31 occupies full-output LBA 198144..198175 and immediately precedes the XDVDFS header at unlocked source LBA 32. FriiDump therefore no longer synthesizes the 32-sector game lead-in for the GDR-8050L redump-style path. The reference Xbox path now reads unlocked source LBA 0..31 strictly before copying source LBA 32..3431263. The native libfriidump path uses the same source mapping and retains per-sector zero-fill only as an explicitly counted fallback for a genuinely unreadable lead-in sector. Pregame and postgame physical locations are resolved, but their inaccessible content remains zero-filled and must not be described as exact without independent evidence. FriiDump 0.5.3.15 release cleanup ----------------------------------- The 0.5.3.15 release candidate consolidates the XGD1 investigation into a repository-ready tree. Local build logs, runner transcripts, package rehearsals, duplicate stdout/stderr captures, and full logical-sector byte dumps are not retained as source authority. Compact evidence is stored under `docs/evidence/xgd1`. Automatic DAT discovery is now executable-relative first, with the historical current-working-directory lookup retained as a fallback. An explicit `--redump-dat-dir` remains authoritative. The reference and native full-output mappings remain those validated in 0.5.3.14. No XGD1 output bytes changed in this cleanup.