[friidump.git] / README

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 0.5.3.16-pf1 also creates native compatibility evidence reports
by default for normal dump invocations using the `friidump-test-result.v1`
contract. The default report is written beside the final FriiDump log and
derives its filename from that log. `--report-json` overrides the pathname,
`--report-dir` overrides the destination directory, and
`--firmware-modified <note>` records modified firmware; omission assumes
stock firmware. Reports are atomic, preserve exact live drive/firmware
identity, and distinguish complete, partial, failed, cancelled, diagnostic,
and resumed runs. See `docs/NATIVE_REPORTS.md`.

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 <drive> -a

A native compatibility report is created automatically for the same run.
To place it in a different directory:

friidump -d <drive> -a --report-dir reports

For a plain DVD-ROM dump from any readable drive, use `-D` / `--dvd` or the
numeric equivalent `-T 3`:

friidump -d <drive> -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 <drive> -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 <drive> --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 <drive> -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 <drive> 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 <file>` 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 <file>` 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
`<file>.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 <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 <file>` 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 <file>` 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 <report.json>

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.