# PFES-ENG-020 — Media Acquisition

**Status:** Active  
**Knowledge Cycle Stages:** Acquire, Preserve, Validate

## Purpose

Acquire engineering-quality optical-media artifacts for reverse engineering, validation, emulation, and preservation.

## Engineering Problem

A mountable or playable image can omit authentication data, descriptors, physical topology, provenance, and firmware-specific evidence.

## Historical Engineering Evolution

Firmware understanding enabled vendor-command dumping and better Xbox, GameCube, and Wii acquisition. Those images then became inputs for emulator and firmware research, creating a feedback loop.

## Engineering Discoveries

- Firmware understanding directly improves media acquisition.
- Engineering-quality acquisition exceeds consumer-quality acquisition.

## Architectural Decisions

- Preserve acquisition provenance.
- Prefer complete engineering packages over isolated images.
- Use independent references such as Redump when applicable.

## Knowledge Produced

- Disc images
- Sidecars
- Authentication resources
- Acquisition logs
- Validation evidence

## Knowledge Consumed

- Firmware capabilities
- Hardware tools
- Media-interface knowledge

## Current Engineering State

Current emphasis includes Xbox optical media, DVD, CD, GameCube, and Wii. Future optical-disc types may be added after real engineering support exists.

## Engineering Lessons

- A valid Xbox image is required for meaningful emulator behavior.
- Reference databases strengthen confidence but do not replace project-specific evidence.

## Negative Knowledge

Project Frankenstein no longer assumes:

- A playable ISO is engineering-complete.
- Filesystem extraction is sufficient.

## Current Implementations

- FriiDump
- unlockdrive
- Firmware-assisted dumps
- Hardware drive workflows

## Future Implementations

- Automatic media-type detection
- Additional optical-disc families
- Acquisition confidence models

## Open Questions

To be expanded during engineering review.

## Why This Chapter Exists

Firmware engineering requires representative media, and media engineering depends on firmware understanding.

## Migrated Engineering Knowledge — FriiDump HLDS Validation

Project Frankenstein now has a validated firmware-analysis-to-media-acquisition loop:

1. Stage 5B recovers HLDS vendor-command parser characteristics.
2. FriiDump converts those findings into exact drive/firmware profiles.
3. Real hardware performs read-only seed retrieval and complete GameCube dumps.
4. Resulting hashes are compared against Redump.
5. Validation results feed back into analyzer confidence and profile handling.

This loop has been validated across seven GDR-8163B firmware revisions: `0L30`, `0E15`, `0B30`, `0M26`, `0L20`, `0D20`, and `0L23`. Every completed Sonic Mega Collection (US) dump produced the same Redump-matching hashes.

GCC-4244 live firmware identity `GCC4244/B103` was also validated using an exact promoted parser profile. The complete dump matched Redump and completed substantially faster than the tested GDR-8163B variants.

**Source evidence**

- `friidump-handoff.md`
- `docs/reports/FRIIDUMP_HLDS_LIVE_VALIDATION_0.5.3.5.md`
- `libfriidump/dvd_drive.c`

## Media Preflight

TEST UNIT READY alone is not sufficient to establish that readable media is present. A USB bridge may return GOOD while the tray is empty.

The current FriiDump preflight therefore requires:

- successful TEST UNIT READY;
- a valid READ CAPACITY(10) response;
- more than one 2048-byte logical block;
- rejection of explicit no-medium, invalid-capacity, becoming-ready, and unit-attention states before vendor seed/cache commands are issued.

This is both a correctness and safety requirement: media acquisition must fail before specialized firmware-assisted reads begin when no valid disc is available.

## Open Experiment — Security-Sector Retrieval via 0xE7 Memory Dump

A real GDR-8163B in the hardware fleet is cross-flashed with GDR-8050L firmware and patched to permit vendor `0xE7` memory-dump commands.

This creates an untested but credible acquisition path for Xbox security-sector or related firmware-resident data:

1. authenticate or otherwise place the drive into the relevant disc state;
2. identify the firmware buffers or MMIO/SRAM regions that receive security-sector material;
3. use the patched `0xE7` memdump path to retrieve those regions;
4. compare the recovered data against existing sidecars, command responses, and known disc structures.

**Current status:** not yet attempted.

This remains an open experimental avenue, not a validated acquisition method. Any future test should preserve full command transcripts, firmware revision, patch provenance, memory ranges, timing/state assumptions, and disc identity.

