1 FriiDump Technical info
2 ===============================================================================
4 This document is a reworking and unification of information found all over the
5 net, regarding the structure of Nintendo Gamecube/Wii Optical Discs and how to
6 read them on an ordinary DVD-ROM drive. All the due credits can be found in the
10 ===============================================================================
11 Nintendo Gamecube/Wii Optical Disc (GOD/WOD) structure
12 ===============================================================================
14 In order to understand how a Gamecube or WII Optical Disk is made, let us
15 first take a look at a standard DVD-ROM. The complete standard is explained in
16 the ECMA-267 Standard.
18 The user data stored on the DVD is divided in blocks, each 2048 bytes long.
19 Each 2048-byte block is then encapsulated in a 2064-byte structure, adding some
20 other data needed for error-correction and head positioning. A 2064-byte block
21 is called a "Data frame", and its logical layout is as follows:
23 4bytes 2bytes 6bytes 2048bytes 4bytes
24 - - - - - - - - - - - - - - - - - - - - - - - - - -
25 | ID | IED | CPR_MAI | User Data Frame | EDC |
26 - - - - - - - - - - - - - - - - - - - - - - - - - -
28 - Identification Data (ID): Contains the PSN (Physical Sector Number), info
29 about the sector itself, like the layer, reflectivity, zone, etc.
30 - ID Error Detection Code (IED)
31 - Copyright Management Information (CPR_MAI): Its use is application-specific,
32 for instance it can be used to store a sector key in videos that use CSS, or
33 a scrambling key in the XBox and XBox360 Security Sectors.
34 - User Data: This is the data available for the end user.
35 - Error Detection Code (EDC): It is the checksum data for all the fields above,
36 its polinomial is x^32 + x^31 + x^4 + 1.
38 For various reasons (not related to copy protection), the User Data Frame is
39 XOR'ed with a stream cipher generated by an 15bits LFSR (Linear Feedback Shift
40 Register), with bits 10 and 14 used as taps. The seeds are obtained from a
41 table of the ECMA-267 standard, the index of the seed is the 4 MSB of the last
42 byte of the "ID" field of the Data Frame. The same stream cipher is then used
43 by 16 consecutive Data Frames: for this and other reasons (again related to
44 error correction), data from the DVD are always read in 16-data frame blocks.
46 4bytes 2bytes 6bytes 2048bytes 4bytes
47 - - - - - - - - - - - - - - - - - - - - - - - - - -
48 | ID | IED | CPR_MAI | User Data Frame | EDC |
49 - - - - - - - - - - - - - - - - - - - - - - - - - -
50 ^ | 2048bytes cipher stream |
55 Now, the first problem when dealing with Gamecube/Wii Optical Discs is that
56 they use a different (and yet unknown) set of seeds. This means that when an
57 ordinary DVD-ROM drive tries to read a GOD/WOD disc, it will unscramble the
58 User Data Frame with the wrong seed, causing the EDC check to fail and a read
59 error to be reported to the operating system, which means the inability to read
62 Furthermore, Gamecube/Wii Optical Disks use a slightly different structure for
63 the Data Frame, as shown in the following figure:
65 4bytes 2bytes 2048bytes 6bytes 4bytes
66 - - - - - - - - - - - - - - - - - - - - - - - - - -
67 | ID | IED | User Data Frame | CPR_MAI | EDC |
68 - - - - - - - - - - - - - - - - - - - - - - - - - -
69 | 2048bytes cipher stream |
72 Basically, the User Data Frame and the CPR_MAI fields are swapped, while the
73 scrambled bytes remain the same.
76 ===============================================================================
77 Tricks used to read a GOD/WOD on a standard DVD-ROM drive.
78 ===============================================================================
79 To cope with the above-mentioned problems, some methods have been suggested by
80 many people on the net. They vary in performance, but the basic idea is always
83 1. Issue a read command for the sector of interest (this is actually a
84 16-sector block, not a single sector, as stated above).
85 2. Let the read return failure.
86 3. At this moment, the DVD-ROM drive must have cached the data read from the
87 disc somewhere in its internal memory, to be able to unscramble them and to
88 check the EDC. So, we can dump the data from the drive's internal RAM.
90 Unfortunately, this is not as easy as it seems, due to the fact that there is
91 no standard "Dump drive memory" command. This is probably implemented in many
92 drives for firmware debugging purposes, but, as such, it is a vendor-specific
93 command, which are usually undocumented and vary from vendor to vendor (or even
94 from drive model to drive model).
96 This is where the work that many hackers around the world have done, in order
97 to crack the Microsoft XBox360 console, becomes useful. They needed some way to
98 read and write data to the XBox360 drive's internal memory, so they
99 disassembled the drive's firmware and patiently tried to understand what each
100 of the vendor-specific commands did. This way, they discovered that a certain
101 command could be used to read an arbitrary portion of the drive's internal RAM.
102 They also managed to map the RAM addresses, so that it is known where data
103 read from the disc are temporarily stored.
105 Fortunately, the XBox360 drive is not too different from some retail DVD-ROM
106 drives, namely some models from LG, which means that the discovered command
107 works on them as well. Hence, we now have some sort of access to the disc data.
109 Although, this comes at the price of speed: dumping the drive's internal memory
110 is a slow process, as it uses Programmed I/O (PIO) instead of Direct Memory
111 Access (DMA) to transfer data from the drive to the computer's memory. For this
112 reason, some have proposed the use of the "streaming read" command: it is a
113 standard command thought for those applications where the constant flow of data
114 is more important than its absolute correctness, such as audio or video
115 applications. Thus, this command does not perform the EDC on the data read from
116 the disc, but returns it immediately. Anyway, the command will only return the
117 User Data Frame, which means that only a portion of the data will be read this
118 way, while the rest (i.e.: the first 12 and the last 4 bytes) will have to be
119 read using the memory dump method. Nevertheless, this combined method will be
120 faster overall, as only some dozens of bytes have to be transfered through PIO,
121 instead of the whole sectors.
123 We still have to cope with the unknown seeds. This problem can be easily solved
124 through the use of brute force: as there are only 15 bits to try (and commonly
125 only 17 seeds per GOD/WOD), this approach only takes about 30 seconds. The
126 bruteforce process is very simple: the LFSR is seeded from 0 to 7FFFh and for
127 each seed the corresponding stream cipher is generated and XOR'ed with the
128 proper section of the Data Frame and the EDC is computed. If the EDC is the same
129 as the one in the EDC field then we have the correct seed.
132 ===============================================================================
133 The FriiDump approach
134 ===============================================================================
135 FriiDump can use four different disc dump methods. They have been developed
136 gradually, empirically and heuristically, by experimenting with the PLScsi tool
137 and comparing the retrieved data with a known-good dump. In this section the
138 inner working of every dump method will be described. The code implementing the
139 different methods can be found in the "disc_read_sector_X" functions of disc.c.
141 Please note that the desibed behaviour is that of my LG GDR8164B drive, which I
142 assume to be shared by similar drives. Other, more different drives, might
143 behave differently and require totally different methods.
145 Also note that all of the methods read 16-sector blocks.
150 This method is very slow. So slow that I have never dumped a whole disc with
151 it. Although, it served me to prove that I was going in the right direction and
152 that my efforts could eventually come to a working end. It also showed me that
153 the first versions of RawDump create bad dumps, sometimes.
155 Basically this method is the same used by those early versions of RawDump,
156 which took 50+ hours to dump a whole disc. It works like this:
158 1. Issue a read command for the required sector. This will cause the 16-sector
159 block to which the sector belongs to be placed at the beginning of the
160 drive's cache memory. Do not even bother to see what the read command
161 returns, as it will surely be a data read error.
162 2. Dump the 16-sector block.
167 Method 2 is similar to method 1, but uses the above-mentioned "streaming read"
168 method, which somehow allows us to dump 5 blocks at a time.
170 1. Issue a "streaming read" command for the required sector. This will cause
171 the 16-sector block to which the sector belongs to be placed at the
172 beginning of the drive's cache memory, together with the 4 following
173 16-sector blocks. Do not bother to see what the read command returns.
174 2. Dump the 5 16-sector blocks.
179 This is similar to the previous method, but instead of dumping the whole
180 sectors from memory, it uses the (not EDC checked) data returned by the
181 "streaming read" command. and completes it dumping only the missing bits from
184 1. Issue a "streaming read" command for the required sector. This will cause
185 the 16-sector block to which the sector belongs to be placed at the
186 beginning of the drive's cache memory, together with the 4 following
188 2. For each sector of each block, reconstruct the whole Data Frame, as follows:
189 - Dump 12 bytes from memory.
190 - Use 2048 bytes returned by the read command.
191 - Dump 4 more bytes from memory.
193 Note that this method has a small issue, as sometimes the beginning of the
194 cache will be dirty and contain invalid data, needing the sector to be read
195 again. As this seems to happen quite often, we always read a dummy sector
196 before the requested sector.
201 Method 4 is just method 3 with a trick to use a single dump command for every
202 sector that has to be reconstructed, instead of two. It is the faster dump
203 method currently supported and, as such, the default one.
205 1. Issue a "streaming read" command for the required sector. This will cause
206 the 16-sector block to which the sector belongs to be placed at the
207 beginning of the drive's cache memory, together with the 4 following
209 2. For each sector of each block, reconstruct the whole Data Frame, as follows:
210 - If this is the first sector of a block, dump 12 bytes from memory.
211 Otherwise, use the last 12 bytes of the preceding dump.
212 - Use 2048 bytes returned by the read command.
213 - Dump 16 bytes from memory, and use the first 4. This leaves 12 bytes to be
214 used for the reconstruction of the next sector.
216 Note that the issue of method 3 applies to this method, too.
220 ===============================================================================
221 Xbox/XGD direct-read and redump-style support
222 ===============================================================================
224 Xbox/XGD support is separate from the Nintendo GOD/WOD cache-dump methods above.
225 FriiDump only switches into the Xbox-specific planner when the disc type is
226 forced with `-T 4` or when the drive identifies as one of the two native Xbox
227 profiles currently wired for autodetection:
229 - HL-DT-ST DVD-ROM GDR8050L
230 - HL-DT-ST DVD-ROM GDR3120L / GDR-3120L
232 All other drives continue to use FriiDump's original command/method selection,
233 autodetection, seed cracking, cache reads, and raw/ISO dumping behavior unless
234 the user explicitly forces Xbox mode. This keeps normal GameCube, Wii, Wii DL,
235 and plain DVD workflows on the original FriiDump path.
237 Plain DVD-ROM dumping is also exposed with the convenience flag `-D` / `--dvd`,
238 which is equivalent to forcing disc type `-T 3`. It is available to all drives
239 and deliberately uses the original FriiDump DVD/raw/ISO path; it does not invoke
240 Xbox unlocks, XISO planning, or Xbox metadata output.
242 For Xbox media, FriiDump reads 2048-byte sectors with MMC READ(10). Method 10 is
243 reserved internally for this direct Xbox READ(10) path. The older Nintendo raw
244 2064-byte format is not meaningful for Xbox redump output.
247 GDR-8050L challenge-table handshake
248 -------------------------------------------------------------------------------
250 The GDR-8050L normally exposes a small visible DVD-video view before Xbox
251 authentication. For redump-style output, FriiDump follows the original dumper's
252 state machine rather than a single continuous read: primary handshake,
253 media-cycle, re-handshake, metadata/auth probe, media-cycle back to the visible
254 DVD-video view, video L0/L1 capture, final handshake, game data write, metadata
255 write, and STOP UNIT cleanup.
257 The handshake sequence is based on scsi1.pas / "XBOX 1 DVD-Drive unlocker tool
258 v0.1" by The Specialist and the xboxhacker.net contributors credited there.
261 1. READ CAPACITY(10) to observe the current visible view.
262 2. MODE SENSE(10), page 0x3E.
263 3. READ DVD STRUCTURE, format 0xC0, using this twelve-byte CDB:
265 AD 00 FF 02 FD FF FE 00 06 64 00 C0
267 The requested transfer length is 0x0664 bytes. If this format 0xC0 request
268 does not return a usable table, FriiDump falls back to the Hitachi-family
269 vendor challenge-table command 0xFD.
271 4. Decode the challenge table: copy 0x2C bytes from offset 0x4A3, hash them
272 with SHA-1, use the first seven SHA-1 bytes as the RC4 key, and RC4-decrypt
273 the response table beginning at offset 774.
274 5. Select usable challenge entries whose decoded table entry begins with 0x01.
275 6. MODE SELECT(10), page 0x3E, first challenge.
276 7. MODE SENSE(10), page 0x3E, verify.
277 8. MODE SELECT(10), page 0x3E, second challenge.
278 9. MODE SENSE(10), page 0x3E, verify.
279 10. MODE SELECT(10), page 0x3E, partition-1 unlock.
280 11. MODE SELECT(6), page 0x31, to enable sticky descrambling.
281 12. READ CAPACITY(10) again as an observation. Like the original dumper, this
282 verification is diagnostic; the later XDVDFS probe determines whether the
283 game view is actually available.
286 GDR-3120L / Kreon-style FF 08 01 vendor lock-state path
287 -------------------------------------------------------------------------------
289 The GDR-3120L path is not the GDR-8050L challenge-table handshake and is not a
290 plain direct READ(10) path. DiscImageCreator documents and uses a vendor command
291 family beginning with `FF 08 01`; FriiDump now mirrors the relevant parts:
293 - `FF 08 01 10` - get feature list. A valid reply begins with words
294 `A55A 5AA5` and then feature words such as Xbox unlock-state support.
295 - `FF 08 01 11 00` - set lock state 0, returning the drive to the normal
296 vendor lock state 0 / normal DVD-video state when supported. FriiDump uses this before the
297 redump-style `-i` planner captures the visible/video view.
298 - `FF 08 01 11 02` - set lock state 2 / wxripper state. FriiDump uses this
299 before reading the game/XDVDFS view.
300 - `FF 08 01 15 00` - disable vendor error-skip before dumping so real read
301 failures remain visible to FriiDump.
303 Samsung/Kreon-style drives such as TS-H352C, TS-H353A, SH-D162C, SH-D162D,
304 SH-D163A, and SH-D163B are not autodetected as Xbox mode by default; ordinary
305 FriiDump GC/Wii/DVD behavior remains unchanged. To test those drives with Xbox
306 media, force Xbox mode explicitly with `-T 4`.
310 -------------------------------------------------------------------------------
312 `-i / --iso` writes a redump-style Original Xbox/XGD1 2048-byte-sector image.
313 This is more complex than copying the game partition. For retail dual-layer
314 media FriiDump writes this layout:
316 - output LBA 0..6831: visible DVD-video L0, read from source LBA 0..6831;
317 - output LBA 6832..198143: pregame padding, currently zero-filled;
318 - output LBA 198144..198175: 32-sector game lead-in, read from unlocked source
319 LBA 0..31; the native libfriidump path zero-fills only a genuinely unreadable
320 sector and records the fallback count;
321 - output LBA 198176..3629407: unlocked game/XDVDFS data, normally read from
322 source LBA 32 on GDR-8050L, or from the detected XDVDFS source LBA on other
324 - output LBA 3629408..3820719: postgame padding, currently zero-filled;
325 - output LBA 3820720..3820879: visible DVD-video L1 tail, captured from locked
326 source LBA 6832..6991 before the unlock.
328 The full redump-style output is 3,820,880 sectors. FriiDump also tries to save
329 PFI and DMI READ DVD STRUCTURE captures next to the ISO as `.pfi.bin` and
330 `.dmi.bin`, and writes a `.redump.json` file describing the reconstructed
331 layout, hashes, drive profile, PFI/DMI filenames, lead-in read/zero-fill counts,
332 and DiscImageCreator-compatible layout constants. The code checks the layout
333 against DiscImageCreator's Original Xbox/XGD1 model: `XBOX_SIZE = 3820880`,
334 `XBOX_LAYER_BREAK = 1913776`, DVD start PSN `0x30000`, Xbox start PSN `0x60600`,
335 and therefore game-output start LBA `0x30600` / `198144`. This is dump metadata
336 output, not required input for the ISO or XISO.
338 `-X / --xiso` writes only the game partition as an XISO-style image. FriiDump
339 unlocks first when needed, probes for the XDVDFS descriptor at LBA 306112 first,
340 then falls back to LBA 32. For retail dual-layer media it copies from the
341 detected XDVDFS start LBA through LBA 1913920 and prepends a 32-sector game
342 lead-in. For single-layer/homebrew-style media it treats the XDVDFS VolumeSize
343 field as a byte count and converts it to 2048-byte sectors.
345 Both Xbox output styles preserve the 32-sector game lead-in from unlocked
346 source LBA 0..31. The GDR-8050L reference path fails the dump if this proven
347 range cannot be captured; the native libfriidump path retains a counted
348 per-sector zero-fill fallback for other profiles or transient read failures.
351 Supported-drive notes
352 -------------------------------------------------------------------------------
354 GC/Wii Hitachi-LG list now documented in this branch:
356 - GDR-8082N, GDR-8083N, GDR-8084N
357 - GDR-8161B, GDR-8162B, GDR-8163B, GDR-8164B
358 - GCC-4160N, GCC-4240N, GCC-4243N, GCC-4244N, GCC-4247N
359 - GCC-4243N/GCC4243* and GCC-4244N/GCC4244* default to Method 8.
360 - GDR-8085N, GDR-8087N, and GCC-4246N are probable but not confirmed here.
361 - GCC-4241N and GCC-4242N are capable but known to have many errors.
363 Additional reference candidates from DiscImageCreator:
365 - XBOX/XBOX 360 Kreon firmware candidates: TS-H353A, TS-H352C, SH-D162C,
366 SH-D162D, SH-D163A, SH-D163B.
367 - XBOX/XBOX 360 swap candidate: GSA-4163B.
368 - HD-DVD and BD are DiscImageCreator-supported disc classes, but this FriiDump
369 branch does not claim DiscImageCreator-equivalent HD-DVD/BD coverage.
373 - MMC/SCSI helpers, GDR-8050L challenge-table unlock, and FF 08 01 vendor
374 lock-state helpers: `libfriidump/dvd_drive.c`
375 - Xbox disc detection/unlock timing: `libfriidump/disc.c`
376 - Redump-style ISO and XISO dumping: `libfriidump/dumper.c`
378 ===============================================================================
379 How to add support for a new drive
380 ===============================================================================
381 If you read all the above stuff, it should be clear that, in order to add
382 support for a new DVD-ROM drive, all that is needed is a way to dump the
383 drive's internal memory, in particular the portion where the data read from the
384 disc is cached. As explained above, this function might not be present in all
385 drives, and might not be easy to find or to use. In case you manage to discover
386 it, just copy the file "hitachi.c" to a new one, and modify it opportunely.
388 Some modifications will also be needed in "dvd_drive.c", in order to add
389 autodetection for the new drive, in the "dvd_assign_functions" function.
391 Apart from this, the cache behaviour of the new drive might not be the same
392 as that of the currently supported models, so the program architecture might
393 need radical changes. In this case, please report.
395 Current fleet test notes
396 ------------------------
398 The current uploaded inventory.cvs lists: GDR-8163B x15, GDR-8081N x3,
399 GCC-4241N x5, GCC-4243N x5, GCC-4244N x9, GCC-4160N x3, GWA-4164B x1,
400 GSA-H73N x1, and GH22NS30 x1. The planned validation order remains incremental:
401 first confirm GCC-4243N against the known-good Sonic Mega Collection hash from
402 the GCC-4244N run, then repeat the same disc on GCC-4244N if reinstalled, then
403 move through GCC-4241N/GCC-4160N/GDR-8081N/GDR-8163B and finally the SATA DVD
404 writer family. Do not test the entire fleet at once; keep one drive/disc/hash
407 GCC-4243N/GCC-4244N Method 8 split-recovery note
408 --------------------------------------------------
409 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.
411 HLDS 0xE7 DIC profile-layer update
412 ------------------------------------
413 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:
415 - Type1: GCC-4160N/GCC-4240N, cache base 0x00a13000, one 16-sector memory window.
416 - Type3: GCC-4243N/GCC-4244N/GCC-4246N/GCC-4247N and GDR8083N/GDR8084N, cache base 0x80000000, five 16-sector memory windows.
417 - Type4: GDR8082N/GDR8161B/GDR8162B/GDR8163B/GDR8164B and related DVD-ROM profiles, cache base 0x80000000, five 16-sector memory windows.
418 - 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.
419 - 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.
421 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.
425 2026-06-29 / HLDS 0xE7 Windows volume guard
426 ---------------------------------------------
428 * The existing Xbox FSCTL_LOCK_VOLUME-style guard is now exposed as a shared
429 FriiDump volume lock helper.
430 * HLDS 0xE7 GC/Wii paths apply the guard before disc seed retrieval, so Windows
431 Explorer/AutoPlay is less likely to interrupt GCC-4160N/GCC-4240N Type1 seed
432 reads with an "insert a disc" prompt.
433 * The guard is warning-only: if Windows already owns a transient handle, FriiDump
434 logs the failure and continues so the hardware read result remains authoritative.
437 2026-06-29 / HLDS 0xE7 AutoPlay warning
438 ------------------------------------------------
440 * Added an explicit Windows AutoPlay warning before the HLDS 0xE7 GC/Wii
441 volume-lock and seed-retrieval phase.
442 * GCC-4160N Type1 testing showed the volume lock works, but Windows AutoPlay
443 can still open an "insert a disc" dialog and interfere until AutoPlay is
444 disabled and File Explorer/dialogs are closed.
445 * The warning is printed for all non-Xbox HLDS 0xE7 GC/Wii profiles before
446 FriiDump attempts the shared volume guard.
449 HLDS 0xE7 validation summary and observed speeds
450 --------------------------------------------------
452 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.
454 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.
456 Observed Sonic Mega Collection (US) fleet results so far:
458 | Model | Firmware | HLDS profile | Cache base | Windows | Result | FriiDump final displayed rate | Duration | Notes |
459 | --- | --- | --- | --- | --- | --- | --- | --- | --- |
460 | GCC-4244N | B103 | Type3 | 0x80000000 | 5 | PASS | 2184.83 MB/h | 2294.36 s | First confirmed GC dump; Dolphin playback confirmed. |
461 | GCC-4243N | A102 | Type3 | 0x80000000 | 5 | PASS | 2534.09 MB/h | 1522.95 s | Confirmed matching Sonic hashes after resume/retry work. |
462 | 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. |
463 | 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. |
465 Known-good Sonic Mega Collection (US) target hashes:
469 MD5 85a525df1481d0ad67d8761f832dca12
470 SHA-1 06eb6d15b4d7f90ec0fed9ce9a77db41358d74ed
471 SHA-256 30098da93f5de9ece8da44f8afdfb85cf9bcdc24d77131221e64e3038a529010
474 Use this table as an observed fleet log, not a promise that every firmware revision of a model behaves identically.
477 HLDS GDR-8050L modified 0xE7 note (2026-06-30):
478 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.
481 GDR-8081N experimental 0xE7 probe layer
482 -----------------------------------------
483 GDR-8081N is now recognized as an experimental HLDS 0xE7 GC/Wii candidate.
484 Unlike GDR8082N/GDR816x, it was not in the confirmed DIC dump list, so FriiDump
485 does not hard-code it as a normal Type4 drive. It starts as `GDR-8081N
486 experimental 0xE7 probe` and, during seed retrieval, tries small sector-0
487 validation reads across these cache profiles:
489 - Probe A Type4-derived: base 0x80000000, 5 windows.
490 - Probe B single-window: base 0x80000000, 1 window.
491 - Probe C Type1-base: base 0x00a13000, 1 window.
492 - Probe D moving-cache candidate: base 0x7fff7f00, 1 window.
494 The first candidate that can read/validate sector 0 is selected for the rest of
495 the run and logged. If all candidates fail, seed retrieval stops and the log
496 records each failed probe. Unsupported/non-HLDS drives now keep zeroed HLDS
497 profile fields so stale cache-base/window values are not printed.
499 GDR-8050L speed-probe visibility note:
500 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.
503 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.
505 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.
508 FriiDump HLDS 0xE7 probe-v2 log-once cleanup
509 ------------------------------------------------
510 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.
512 ## HLDS 0xE7 scan mode for GDR-8081N and other experimental drives
514 This branch adds a fast discovery mode for experimental HLDS HIT 0xE7 drives:
517 .\friidump.exe -d f: --hlds-e7-scan -T 0 --scan-log "gdr8081n_e7_scan.json"
519 $zip = "friidump_gdr8081n_e7_scan_results.zip"
520 if (Test-Path $zip) { Remove-Item $zip -Force }
521 Compress-Archive -Path .\gdr8081n_e7_scan.json,.\friidump.log -DestinationPath $zip -Force
524 The scan mode does not crack GameCube/Wii seeds and does not dump disc data. It is intended to avoid long failed seed-retrieval runs while discovering whether a drive exposes a usable HIT 0xE7 cache/memdump base. It performs small cache-fill reads, tries a bounded set of candidate memory bases, captures raw-sector header/tail bytes, scores expected DVD raw sector IDs, and writes a JSON report.
526 For GDR-8081N the first candidate set includes known Type3/Type4 bases, nearby 0x80000000 offsets, Type1/GCC-4160N neighborhood bases, low SRAM aliases, and a firmware-mapping sanity candidate. Future analyzer work should use firmware control-flow around the 0xE7 handler and live scan deltas to rank candidates instead of treating firmware/disassembly mapping base as the drive SRAM cache base.
Return to the FriiDump site / friidump.git / blob