docs/reports/FRIIDUMP_CANDIDATE20_LINUX_XBOX_SGIO_PARITY.md

   1 # FriiDump Candidate20: Linux Xbox SG_IO Transport Parity
   2
   3 Candidate19 reproduced the Windows state-machine order, but its Linux
   4 `UnlockDrive()` implementation still sent the challenge sequence through the
   5 legacy `CDROM_SEND_PACKET` wrapper. That wrapper does not carry an explicit CDB
   6 length and applied FriiDump's generic 10-second timeout to every command.
   7
   8 The physical Candidate19 run remained at the 6,992-sector DVD-video view after
   9 both the direct handshake and the one permitted tray-cycle retry. Because the
  10 mode-select transport statuses were not recorded, Candidate19 could not prove
  11 that the partition-unlock and sticky-descrambling commands reached the USB
  12 target with Windows-equivalent boundaries.
  13
  14 Candidate20 keeps the exact Candidate19 state-machine order and replaces only
  15 the Linux GDR-8050L handshake transport with `SG_IO`:
  16
  17 - explicit 10-byte READ CAPACITY;
  18 - explicit 10-byte MODE SENSE and MODE SELECT;
  19 - explicit 12-byte challenge-table commands;
  20 - explicit 6-byte sticky-descrambling MODE SELECT;
  21 - 120-second Windows-equivalent timeout for steps 1-8 and 10;
  22 - 10-second timeout for sticky descrambling;
  23 - data-in/data-out direction preserved;
  24 - SCSI status, host status, driver status, sense, residual, timeout, CDB, and
  25   transfer length logged for every step.
  26
  27 The tray-cycle messages now use the persistent Xbox reference logger.
  28
  29 Candidate20 does not contain or invoke `RecoveryKick`, generic media-auth kicks,
  30 or synthetic LBA-zero recovery reads.