# Historical HTML Claim Review — Batch 06

## Scope

Reviewed:

- `HTML-007` — Hitachi GCC-4241N Flashing & Execution Protocol V2
- `HTML-021` — Volume XIX Flash Programming Algorithm & Safety Protocols
- `HTML-025` — Volume XX Flash Status Registers & Error States

The supplied A100, A101, and failed-flash TSOP evidence was analyzed directly.

## Result

New claims: **40**

| Status | Count |
|---|---:|
| Validated | 14 |
| Partially corroborated | 9 |
| Historical/Untrusted | 3 |
| Superseded | 1 |
| Rejected | 9 |
| Open question | 4 |

## Transform Closed

The GCC-4241N A100/A101 TSOP representation uses the exact historical
`0xA7A7A7A7` XOR key and 32-bit GCC bit permutation. Both revisions decrypt to
coherent firmware and re-encrypt byte-exactly. Earlier transform claims
HCLM-B01-028 and HCLM-B01-035 are now **Validated**.

Direct TSOP programming requires the transformed/on-flash representation.

## Failed Flash Finding

The failed A101 image is exact decoded/plaintext A101 outside
`0x04000-0x07FFF`. The 16 KiB window is consistent with preserved unit-specific
OEM/calibration data. This demonstrates wrong-representation programming in
the observed custom flashing path.

The stock OEM updater may perform the static transform either on the host or
inside its uploaded RAM stub; that boundary remains open. The historical AES
seed/hardware-encryption account is rejected.

## Protocol Findings

Validated from current source/log:

- E7 `HL-DT-ST` unlock;
- 4,080-byte setup contract;
- two stub packets with 8-byte headers;
- 256 firmware blocks with countdown `FF..00`;
- subcommand `08` final poll;
- subcommand `09` ignition/execute.

Not validated:

- exact firmware checksum/footer algorithm;
- `02/00/00/00` as successful verification;
- entry offset `0x0859`;
- zero-sum stub checksum formula;
- stock stub implementation and exact timing.

## Flash-Status Correction

The invented register block at `0x9000F000` and derived status values are
rejected. The SST flash datasheet does validate generic Data# Polling and
Toggle Bit completion mechanisms, but not the historical VMA register map.

## CD_READY Correction

Batch 05 was corrected in this revision: `CD_READY` is a media-presence/readiness
signal and does not require authentication or unlock.

## Claim Index

| Claim | Source | Status | Summary |
|---|---|---|---|
| HCLM-B06-001 | HTML-007 | validated | The 512 KiB firmware image is streamed before any RAM-execution diversion can use it. |
| HCLM-B06-002 | HTML-007 | rejected | A security-sector-derived AES seed negotiation occurs before payload transfer. |
| HCLM-B06-003 | HTML-007 | validated | Unknown update-handshake data must be captured rather than guessed. |
| HCLM-B06-004 | HTML-007 | validated | The GCC-4241N flash path uses CDB E7 48 4C 2D 44 54 2D 53 54 00 00 00. |
| HCLM-B06-005 | HTML-007 | validated | The setup command and 16-byte payload declare a 4,080-byte stub contract. |
| HCLM-B06-006 | HTML-007 | validated | The 4,080-byte stub is transferred as two 2,048-byte packets, each with an 8-byte HL header and 2,040 data bytes. |
| HCLM-B06-007 | HTML-007 | validated | The 512 KiB image is sent in 256 2,048-byte blocks with CDB[2] descending from FF to 00. |
| HCLM-B06-008 | HTML-007 | partially_corroborated | Receipt of the final 00 block triggers some form of drive-side completion or validation state. |
| HCLM-B06-009 | HTML-007 | rejected | CHECK CONDITION 02 with sense 00/00/00 means successful verification and ready-to-burn. |
| HCLM-B06-010 | HTML-007 | validated | Vendor subcommand 08 is the final poll command. |
| HCLM-B06-011 | HTML-007 | validated | Vendor subcommand 09 is the ignition/execute command. |
| HCLM-B06-012 | HTML-007 | partially_corroborated | A clean OEM stub erases and programs the TSOP after ignition. |
| HCLM-B06-013 | HTML-007 | historical_untrusted | The Mask ROM enters the uploaded stub at offset 0x0859. |
| HCLM-B06-014 | HTML-007 | open_question | The 4,080-byte stub uses the described first-4,078-byte sum plus little-endian two-byte complement. |
| HCLM-B06-015 | HTML-007 | superseded | A 40-byte MMU-flip payload at 0x0859 safely redirects execution into the streamed hybrid image. |
| HCLM-B06-016 | HTML-007 | validated | A hard-bricked GCC-4241N can be recovered by externally programming a known-good transformed TSOP image. |
| HCLM-B06-017 | HTML-007 | rejected | An invalid AES seed causes the drive to write garbage ciphertext. |
| HCLM-B06-018 | HTML-007 | partially_corroborated | Once IDE initialization is lost, software recovery through the normal host interface is unavailable. |
| HCLM-B06-019 | HTML-007 | validated | Direct TSOP programming must use the transformed/on-flash representation rather than the decoded executable representation. |
| HCLM-B06-020 | HTML-021 | partially_corroborated | The final 00 block is the protocol point associated with firmware validation/completion. |
| HCLM-B06-021 | HTML-021 | open_question | The drive computes a 32-bit big-endian additive sum and compares it with the final four bytes. |
| HCLM-B06-022 | HTML-021 | partially_corroborated | A successful final block returns SCSI GOOD. |
| HCLM-B06-023 | HTML-021 | partially_corroborated | Checksum failure returns CHECK CONDITION. |
| HCLM-B06-024 | HTML-021 | historical_untrusted | Checksum failure specifically reports sense key 05 and a vendor ASC/ASCQ. |
| HCLM-B06-025 | HTML-021 | open_question | The host can issue ignition regardless of the preceding checksum result. |
| HCLM-B06-026 | HTML-021 | partially_corroborated | Issuing ignition after validation failure can burn unusable bytes and brick the drive. |
| HCLM-B06-027 | HTML-021 | partially_corroborated | The uploaded RAM stub performs physical erase/program operations. |
| HCLM-B06-028 | HTML-021 | historical_untrusted | The drive is nonresponsive for exactly about 25 seconds during a burn. |
| HCLM-B06-029 | HTML-021 | rejected | The normal SCSI flash path accepts decoded/plaintext firmware and automatically encrypts it before physical programming. |
| HCLM-B06-030 | HTML-021 | validated | External TSOP programming requires the transformed/on-flash image. |
| HCLM-B06-031 | HTML-021 | validated | The host should fail closed and never proceed to ignition after any unclassified validation error. |
| HCLM-B06-032 | HTML-025 | rejected | GCC-4241N exposes dedicated FLASH_STATUS/CMD/ADDR registers at 0x9000F000/08/0C. |
| HCLM-B06-033 | HTML-025 | rejected | The fixed register at 0x9000F000 uses bits 7, 5, 4, and 1 as the listed ready/program/erase/Vpp flags. |
| HCLM-B06-034 | HTML-025 | validated | The SST39LF/VF flash family provides Data# Polling and Toggle Bit end-of-write detection. |
| HCLM-B06-035 | HTML-025 | rejected | The shown MN103S loop reading 0x9000F000 is the actual GCC-4241N stub verification code. |
| HCLM-B06-036 | HTML-025 | validated | A robust writer should verify flash completion and failure before reporting success. |
| HCLM-B06-037 | HTML-025 | open_question | A failed flash operation should enter an infinite LED panic loop. |
| HCLM-B06-038 | HTML-025 | partially_corroborated | The host cannot directly monitor normal SCSI commands while a RAM stub monopolizes execution. |
| HCLM-B06-039 | HTML-025 | rejected | A bricked drive can be diagnosed by peeking 0x9000F000. |
| HCLM-B06-040 | HTML-025 | rejected | Status values 0x80, 0x90, and 0xA0 at 0x9000F000 identify success, program error, and erase error. |
