# Project Frankenstein: Implementation & Finalization Guide

This final volume provides the end-to-end technical workflow for constructing the GCC-4241N Hybrid Firmware. It details the payload assembly, binary patching, security finalization, and deployment strategy for original Xbox hardware compatibility [cite: User Summary, User Correction Ledger].

## 1. Payload Assembly Workflow

The "Brain" transplant begins with compiling the `xbox_hybrid_payload.s` into a raw binary for injection into the 4241N's SRAM cave [cite: User Summary, 129_perfect_trampoline_v18.py].

### Step 1: Assembly (MN10300-ELF-AS)

    mn10300-elf-as -o payload.o xbox_hybrid_payload.s

### Step 2: Linking (MN10300-ELF-LD)

We link the object using the custom `payload.ld` script and define the native 4241N stubs [cite: 4241N_Final_Stub_Map.txt, 129_perfect_trampoline_v18.py].

    mn10300-elf-ld -T payload.ld --defsym memcpy=0x11de --defsym memset=0x1111 -o payload.elf payload.o

### Step 3: Binary Extraction (OBJCOPY)

Strip the ELF headers to create the raw `payload.bin` [cite: User Summary].

    mn10300-elf-objcopy -O binary payload.elf payload.bin

## 2. Binary Patching Logic (V18 Protocol)

The `129_perfect_trampoline_v18.py` script performs the surgical modifications to the 4241N plaintext binary [cite: 129_perfect_trampoline_v18.py].

### A. Handshake Trampolines

Target Handler | ROM Offset | Trampoline OpCodes (MN103S)
--- | --- | ---
Mode Sense ($5A) | `0x27198` | `FC DC 10 07 03 90 F0 91 CB` [cite: 129_perfect_trampoline_v18.py]
DVD Structure ($AD) | `0x30249` | `FC DC 60 07 03 90 F0 91 CB CB` [cite: 129_perfect_trampoline_v18.py]

### B. LBA Wall Neutralization (NOP Overwrites)

Replace these offsets with `0xCBCB` to unlock physical tracking to the security sector [cite: 129_perfect_trampoline_v18.py].

- LBA Logic: `0x3034E`, `0x2C2CC`, `0x31A85`, `0x3781A`, `0x3782A` [cite: 129_perfect_trampoline_v18.py]

### C. Jump Table Injection (OpCode $E7)

Modify the Group 7 jump table at `0x72282` to point to the RAM cave address `0x40008200` [cite: 4241N_Corrected_Jump_Table.txt, 129_perfect_trampoline_v18.py].

## 3. Security Finalization (AES & Checksum)

Before deployment, the patched binary must be returned to its encrypted state [cite: 01_hitachi_cipher.py].

### The Checksum Equation

Checksum = Σ (Data[0] ... Data[Size-5]) mod 232

The resulting 32-bit big-endian value must be appended to the end of the file [cite: 01_hitachi_cipher.py].

### Critical: The "Double Encryption" Trap

When flashing via the Windows Flasher, send PLAINTEXT. The drive hardware will encrypt it automatically [cite: User Summary, gcc_hitachi_flasher.c]. When using a Hardware Adapter to burn the ROM directly, send ENCRYPTED data [cite: 01_hitachi_cipher.py]. Double-encryption (E(E(P))) results in a bricked unit [cite: 01_hitachi_cipher.py].

## 4. Forensic Un-Bricking Strategy

If a drive is bricked due to double-encryption, follow this recovery loop [cite: User Summary, 01_hitachi_cipher.py]:

1. Dump: Extract ROM via hardware adapter.
2. Analyze: Decrypt once with `XBOX_HITACHI_KEY` to find if encrypted V18 patterns emerge [cite: 01_hitachi_cipher.py].
3. Restore: Flash the single-encrypted binary directly to the chip [cite: User Summary].

## 5. Diagnostic Verification

Once deployed, use the custom `0xE7` command to verify the RAM cave's status [cite: User Summary, gcc_hitachi_flasher.c]:

    SCSI Command: E7 00 40 00 80 7A 00 00 20 00

The drive should return 32 bytes from your payload's entry point, confirming the "Holy Grail" is active [cite: 129_perfect_trampoline_v18.py].