# GCC-4241N Drive1 Failed-Flash Supplemental Analysis

## Preserved files

- `Drive1_GCC-4241N_TSOP48.bin`
- `oem_diff_drive1.txt`
- `flash_log.txt`
- `flasher_debug.log`

## Dump identity

- size: 524,288 bytes
- raw SHA-256: `7a216767f9aa33866a7bcc714cb68bddf985fd7a6184f5f0671e326a284d3251`
- decoded SHA-256: `6ab34293aed7294f6f28e97e232e545f6205dd715ac0d67c943a51bd5d0ac86a`
- validated GCC transform round trip: exact
- decoded identity: GCC-4241N A101 present

## Representation-correct comparison

Against the accurate A101 reference:

- raw/on-flash comparison differences: **333,253 bytes**
- decoded/plaintext comparison differences: **327,122 bytes**
- exact 4 KiB physical sectors: **36**

The largest exact spans are:

- `0x07000-0x07FFF`
- `0x4F000-0x6EFFF`
- `0x7B000-0x7DFFF`

The main heavily divergent spans are:

- `0x08000-0x4DFFF`
- `0x70000-0x7AFFF`

This is a different failure pattern from Drive2. Drive2 was plaintext across most of the chip with a transformed 16 KiB window preserved. Drive1 remains a transformed-domain image with exact sectors interspersed with severely divergent sectors.

## Difference-log correction

`oem_diff_drive1.txt` reports **522,856** differences, but it compares a raw transformed TSOP image against decoded plaintext. That is a representation mismatch and cannot serve as a corruption map.

## Log boundaries

`flash_log.txt` shows a full plaintext stream, final-poll acknowledgement, ignition acknowledgement, and a 30-second wait, but contains no ROM readback. These host-visible acknowledgements do not prove correct physical programming.

`flasher_debug.log` stops at the second stub packet with status `02`, sense `04/00/00`; firmware streaming did not begin in that attempt.

The user did not assert exact pairing between either log and the Drive1 dump, so both logs remain contextual evidence rather than proven transcripts of the binary.
