Project: Project Frankenstein (Payload Injection & Zero-Balancer)
Target Drive: Hitachi-LG GCC-4244N (OEM B104 Firmware)
CPU Architecture: Matsushita MN103S (AM33)
Date: May 10, 2026
The research session conducted today successfully mapped the internal logic of the B104 firmware for the GCC-4244N optical drive. While the firmware demonstrates significantly higher optimization and modularity compared to the earlier 4241N revision, we identified the Vendor-Unique 0xE7 Handler as the primary vector for payload injection. Crucially, hardware audits of the prepstub_4k.asm have confirmed a shift in silicon from SST-style "Unlock Address" flash to Intel/Micron Command-Driven (CFI) flash interface.
Initial efforts attempted to replicate the Format 0x08 region-check discovery used in the 4241N firmware. The rpc_hunter.py tool was deployed against three primary 0xAD (Report RPC State) dispatcher candidates:
40078b90: Handler branch40001e48: Handler branch4007454c: Handler branchRESULT: FAILED. Unlike the linear 4241N code, the B104 compiler modularized the 0xAD handler into disjointed subroutines. An 800-line linear trace from the dispatcher entry points failed to encounter the standard cmp 8, [reg] region-format check.
The auth_hunter.py script identified a single hit for the 0xA3 opcode at address 40026124:. Detailed hex-to-assembly tracing revealed this to be a False Positive. The surrounding instructions (movhu d3,(0xa3b7)) indicated data table alignment rather than executable branch logic.
Because standard cmp dispatchers were obfuscated by the compiler, we pivoted to a Call Cluster Audit to identify functional hubs. Two major clusters were isolated:
| Cluster ID | Location | Size | Inferred Function |
|---|---|---|---|
| Cluster 0 | Line 1845 | 10+ Calls | Main SCSI Functional Pivot |
| Cluster 3 | Line 5122 | 10+ Calls | Media Access / Error Management |
The identity_hunt.py script successfully located the drive's Inquiry Response Table at address 4001c10b. The table contains the following static ASCII identifiers:
4001c10b: 47 43 43 2d 34 32 34 34 4e (GCC-4244N) 4001c11a: 42 31 30 34 (B104)
Audit of the pointer architecture via hunt_pointer.py confirmed that the B104 firmware utilizes Register-Relative Addressing. No absolute long-form pointers to 4001c10b exist in the binary, indicating the use of a base-address register (likely a3 or sp) to reference OEM strings.
The most significant finding of the session was the isolation of the Vendor-Unique 0xE7 Dispatcher. This command is the standard Hitachi-LG backdoor for low-level memory access and flash orchestration.
The 0xE7 dispatcher was identified at line 1587 of the disassembly:
4001719b: fa c0 e7 00 cmp 231,d0 4001719f: f0 39 da 71 beq 0x400171da
The handler at 400171da: demonstrates classic CDB Stack Parsing, pulling arguments for sub-commands. This is the Hijack Point for Project Frankenstein. By leveraging this handler, a payload can be injected into SRAM without modifying the existing RPC-2 lock in the physical ROM.
Comprehensive scanning of the prepstub disassembled code (prepstub_4k.asm) confirmed that the GCC-4244N does not utilize the SST-39LFX00A "Unlock Address" protocol (0x555/0xAAA). Instead, the drive employs an Intel/Micron Command-Driven Interface.
The following hardware-level command sequences were verified within the stub:
| Byte | MN103S Line (Approx) | Function |
|---|---|---|
0xFF |
Line 31 | Read Array / Reset (Initialization) |
0x70 |
Line 42 | Read Status Register |
0x80 / 0x20 |
Lines 53, 94 | Erase Setup / Block Erase |
0x40 |
Line 81 | Word Program (Flash Write) |
0xD0 |
Lines 56, 97 | Operation Confirm |
To successfully execute the RAM-Only Survival Trick on the 4244N, the tethered loader must be modified to bridge the 0xE7 dispatcher specifically to the 0xFF initialization block. The 0x20/0xD0 (Erase/Confirm) cycle must be explicitly avoided to prevent permanent ROM modification while maintaining an active payload in SRAM.
STATUS: READY TO INJECT XBOX FUNCTIONS