# Hitachi GCC-4241N Architecture

Comprehensive Analysis of the Masked ROM Protocol & Tethered Execution
DOCUMENT REVISION 2: Corrected the RAM Sandbox execution flow. The 512KB payload MUST be streamed during Stage 5 so the MMU flip has executable code to jump to in SDRAM. The flasher codebase remains agnostic.

This document serves as the formal technical record for the Hitachi GCC-4241N reverse engineering effort. It details the complete SCSI communication protocol required to interact with the A101 Masked ROM, establishing a reliable pathway for both permanent firmware flashing and volatile SDRAM payload execution.

## 1. The OEM Flashing Protocol

The standard firmware update process is handled via custom SCSI Pass-Through Direct (`IOCTL_SCSI_PASS_THROUGH_DIRECT`) commands over the IDE/ATAPI interface. The process is strictly sequential.

### Stage 0: Key Negotiation & Security Sector Initialization

Status: Requires Capture
This stage occurs prior to any payload transfer. The OEM flasher negotiates a cryptographic seed derived directly from the security sector. Absolutely no guessing is allowed here; this data MUST be verified 100% from live USB traces. This seed establishes the AES key used by the drive's hardware decryptor. Without this exact sequence, the drive will encrypt the incoming plaintext firmware with a null/garbage key, resulting in a bricked state upon reboot.

### Stage 1: Vendor Unlock

The host signals the drive to enter diagnostic/flash mode by transmitting a specific vendor string.

CDB: E7 48 4C 2D 44 54 2D 53 54 00 00 00
String: "HL-DT-ST"

### Stage 2: Setup Contract

The host transmits the Setup CDB to define the boundaries of the pre-flash stub. The drive enforces a strict 4080-byte (0x0FF0) hardware contract for this stub.

CDB: 55 10 00 00 00 00 00 00 10 00 00 00
Payload (16 bytes): 00 00 00 00 00 00 00 00 00 06 48 4C 00 00 0F F0

### Stages 3 & 4: Stub Upload

The 4080-byte stub is transmitted across two 2048-byte chunks. To align the 4080 bytes within the 4096-byte transfer window, each 2048-byte chunk is prefixed with an 8-byte Hitachi Magic Header (00 00 00 00 48 4C 00 00), resulting in exactly 2040 bytes of executable stub data per chunk.

CDB: 55 10 00 00 00 00 00 08 00 00 00 00 (x2 iterations)

### Stage 5: Firmware Streaming

The 512KB firmware binary is streamed into the drive's SDRAM over 256 individual chunks of 2048 bytes. The drive utilizes a reverse hexadecimal counter for block tracking, starting at 0xFF and concluding at 0x00.

CDB: 55 10 [COUNTDOWN] 48 4C 07 01 08 00 00 00 00

Upon receiving the final 0x00 block, the drive verifies the integrity of the uploaded data. A successful verification yields a SCSI Check Condition: Status 0x02 | Sense 00/00/00. This specific combination is a hardware state-change notification indicating "Ready to Burn," not a true error.

### Stages 6 & 7: Polling and Ignition

The host polls the drive's state using command 0x08, followed by the critical command 0x09 (Ignition).

Poll: 5A 10 00 48 4C 08 00 00 12 00 00 00
Ignition: 5A 10 00 48 4C 09 00 00 00 00 00 00

If a clean OEM stub is loaded, 0x09 triggers the internal Masked ROM routine to erase the TSOP flash chip and burn the AES-encrypted SDRAM buffer into non-volatile memory.

## 2. The Tethered Stub Loader (RAM Sandbox)

To safely test the hybrid firmware (integrating GDR-8050L capabilities into the GCC-4241N framework) without risking hardware destruction, we intercept the execution flow prior to the flash burn cycle.

### The Execution Vector

When the 0x09 Ignition command is received, the Masked ROM jumps to a specific offset within the uploaded 4080-byte stub (identified as 0x0859) to begin the flash routine. By injecting a custom 40-byte Memory Management Unit (MMU) flip payload at this exact offset, we hijack the program counter.

### The Zero-Sum Checksum Algorithm

The Masked ROM refuses to jump to the execution vector unless the 4080-byte stub passes cryptographic validation. The algorithm is an 8-bit Two's Complement Zero-Sum.

Validation Math:
The drive calculates the 8-bit sum of the first 4078 bytes of the payload. It then reads the final 2 bytes as a 16-bit Little-Endian integer. If the sum of the payload plus the 16-bit checksum equals exactly 0x0000 (in truncated 16-bit space), the file is authorized for execution.

To inject a payload, the entire 4080-byte file must be perfectly zero-balanced:

1. Calculate the 16-bit masked sum of the 4078-byte poisoned payload: Σ(bytes) & 0xFFFF
2. Calculate the Two's Complement: (0x10000 - Σ) & 0xFFFF
3. Append this value as the final 2 bytes in Little-Endian format.

### Execution Flow for Tethered Payload

The beauty of this exploit is that the host-side C flasher remains completely agnostic. The execution divergence happens entirely inside the drive's memory.

1. Execute Stage 0 (Key Exchange) through Stage 4 (Stub Upload) using the zero-balanced, poisoned stub.
2. Execute Stage 5 (Firmware Upload): Stream the entire 512KB hybrid firmware payload into the drive's SDRAM over 256 chunks.
3. Transmit Stage 6 (Poll) and Stage 7 (Ignition).
4. The Hijack: The Masked ROM jumps to 0x0859 inside the stub. Instead of the OEM flash routine, it hits the injected MMU flip payload.
5. Execution: The payload flips the MMU, kills the flash chip erase routine, and executes a jump instruction pointing directly to the SDRAM address where Stage 5 just finished streaming the hybrid firmware.

## 3. Hardware Recovery Protocol

In the event of a cryptographic failure (e.g., executing the 0x09 burn command with an invalid AES seed), the TSOP flash will be overwritten with garbage ciphertext. This results in a hard fault of the Panasonic MN103S processor upon boot.

Software recovery is impossible in this state as the IDE interface will not initialize. Recovery requires physically desoldering the TSOP flash chip, seating it in a hardware programmer via a TSOP48 adapter, and directly writing a clean, pre-encrypted `A100/A101` firmware dump to the IC.