X-Git-Url: https://git.jtryba.com/browse/friidump.git/blobdiff_plain/d44030dfa440b1967ec7dcd3ccfe46fb69934486..refs/heads/main:/README?ds=sidebyside diff --git a/README b/README index 6d7c62b..a9f2616 100644 --- a/README +++ b/README @@ -7,6 +7,16 @@ 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 ` 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, @@ -37,6 +47,10 @@ Furthermore, FriiDump also features some functional improvements over RawDump: - 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. @@ -146,23 +160,27 @@ $ 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: +Linux-specific note: Run FriiDump as a normal user. Do not run it with `sudo`, +and do not install it setuid-root. + +Linux vendor-command paths need two separate permissions: + +- The normal user needs access to the selected `/dev/sr*` device and, when + applicable, its `/dev/sg*` device. On Ubuntu, membership in the `cdrom` group + normally provides this access. +- GameCube/Wii memory-dump methods and Xbox vendor-unlock paths need effective + `CAP_SYS_RAWIO` on the exact validated FriiDump executable. - $ chown root:root /usr/local/bin/friidump - $ chmod u+s /usr/local/bin/friidump +After you verify the executable, use the maintained helper: + $ bash ./validation/friidump-linux-rawio-capability.sh install \ + ./build/src/friidump + $ getcap ./build/src/friidump + +Rebuilding, relinking, copying, replacing, or re-extracting the executable can +clear its file capability. Verify `cap_sys_rawio=ep` before each +vendor-command hardware run. See `docs/LINUX.md` for the complete Linux +permission and hardware procedure. =============================================================================== Usage @@ -172,6 +190,11 @@ or a command-prompt under Windows. The basic usage is as follows: friidump -d -a +A native compatibility report is created automatically for the same run. +To place it in a different directory: + +friidump -d -a --report-dir reports + For a plain DVD-ROM dump from any readable drive, use `-D` / `--dvd` or the numeric equivalent `-T 3`: @@ -197,6 +220,22 @@ 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, @@ -364,7 +403,7 @@ The Type1 base address comes from the DIC source behavior for GCC-4160N/GCC-4240 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. The hash comparison remains manual: compare the printed hashes against the known-good target for the test disc. +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. @@ -373,6 +412,7 @@ 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. | @@ -455,3 +495,180 @@ 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.