# FriiDump Candidate20: Linux Xbox SG_IO Transport Parity

Candidate19 reproduced the Windows state-machine order, but its Linux
`UnlockDrive()` implementation still sent the challenge sequence through the
legacy `CDROM_SEND_PACKET` wrapper. That wrapper does not carry an explicit CDB
length and applied FriiDump's generic 10-second timeout to every command.

The physical Candidate19 run remained at the 6,992-sector DVD-video view after
both the direct handshake and the one permitted tray-cycle retry. Because the
mode-select transport statuses were not recorded, Candidate19 could not prove
that the partition-unlock and sticky-descrambling commands reached the USB
target with Windows-equivalent boundaries.

Candidate20 keeps the exact Candidate19 state-machine order and replaces only
the Linux GDR-8050L handshake transport with `SG_IO`:

- explicit 10-byte READ CAPACITY;
- explicit 10-byte MODE SENSE and MODE SELECT;
- explicit 12-byte challenge-table commands;
- explicit 6-byte sticky-descrambling MODE SELECT;
- 120-second Windows-equivalent timeout for steps 1-8 and 10;
- 10-second timeout for sticky descrambling;
- data-in/data-out direction preserved;
- SCSI status, host status, driver status, sense, residual, timeout, CDB, and
  transfer length logged for every step.

The tray-cycle messages now use the persistent Xbox reference logger.

Candidate20 does not contain or invoke `RecoveryKick`, generic media-auth kicks,
or synthetic LBA-zero recovery reads.