# Project Frankenstein: Volume XIX (Revised)

## Flash Programming Algorithm & Safety Protocols

This revised volume details the end-to-end technical sequence for reprogramming the Hitachi-LG GCC-4241N flash memory. It specifically highlights the critical handshakes between the host and drive regarding checksum validation and the dangerous "point of no return" during the ignition phase [cite: gcc_hitachi_flasher.c, User Summary].

## 1. The Checksum Trigger Algorithm

The drive does not use a dedicated checksum command. Instead, validation is triggered by the structure of the firmware stream itself [cite: gcc_hitachi_flasher.c].

- The Sequence Byte: CDB[2] counts down from `0xFF` to `0x00` [cite: gcc_hitachi_flasher.c].
- The Final Trigger: When the drive receives a block with `CDB[2] = 0x00`, its internal state machine automatically initiates a 32-bit Big-Endian summation of the entire 512KB RAM buffer [cite: gcc_hitachi_flasher.c].
- Comparison: The drive compares the calculated sum against the 4-byte footer stored at the end of the transferred binary [cite: gcc_hitachi_flasher.c].

## 2. Handling Checksum Success and Failure

The drive communicates the result of the internal checksum through standard SCSI status codes [cite: gcc_hitachi_flasher.c].

### Communication Protocol

- Success: The `0x00` block command returns `SCSI_STATUS_GOOD (0x00)`. The flasher may safely proceed to ignition [cite: gcc_hitachi_flasher.c].
- Failure: The `0x00` block command returns `CHECK CONDITION (0x02)`. This indicates a data mismatch [cite: gcc_hitachi_flasher.c].
- Diagnostic: In the event of a failure, the Sense Buffer will typically report `Sense Key 0x05` (Illegal Request) with a vendor-specific ASC/ASCQ signifying a checksum mismatch [cite: Volume XIII: Error Dispatcher Mapping, gcc_hitachi_flasher.c].

## 3. Validation Safety Protocol: The Point of No Return

There is no physical interlock between the checksum result and the ignition command. This is the most dangerous aspect of the flashing protocol [cite: gcc_hitachi_flasher.c].

### CRITICAL WARNING

The Ignition Command (0x5A with 'HL' signature) is physically independent of the checksum result. If the host software ignores a Check Condition on the `0x00` block and issues the ignition command anyway, the drive WILL jump to RAM and begin burning the corrupted data to the flash chip [cite: gcc_hitachi_flasher.c]. This results in an immediate and often unrecoverable "Hard Brick" [cite: User Summary, gcc_hitachi_flasher.c].

## 4. The RAM Stub Erase/Write Algorithm

### Theory: Internal Execution

Once ignition occurs, the 4,080-byte RAM Stub takes complete control of the hardware [cite: gcc_hitachi_flasher.c]. It performs the physical `Erase Sector` and `Program Page` operations required for the specific flash chip [cite: gcc_hitachi_flasher.c]. During this 25-second window, the drive is non-responsive to the SCSI bus [cite: gcc_hitachi_flasher.c].

## 5. Data State (Plaintext vs Encrypted)

- SCSI Flash: Use Plaintext binaries. The drive controller encrypts the data as it moves it from RAM to the physical flash cells [cite: gcc_hitachi_flasher.c, User Summary].
- External Burn: Use Pre-Encrypted binaries for direct-to-chip programming with a hardware adapter [cite: User Summary, 01_hitachi_cipher.py].