mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-29 07:10:32 -04:00
Drew T
264fe6c115
The whole-binary byte-gate is structurally blind to code nobody onboarded (R34): check-all is
green over the onboarded set no matter what code sits unbuilt on the disc. This reconciles the
onboarded set against every code-bearing PAC payload.
- new_overlay.sh: optional [ENTRY] arg (default 0.4) reaches a non-0.4.dec payload. Onboarded
ov_SC07_{006,007,010,011} from 1.4.dec (they put graphics at PAC entry 0, the code overlay at
entry 1 — invisible to the 0.4 hardcode for a month). Each byte-identical (7ca772be / b3b95547 /
d7b5875d / 9885af74). FLEET 136 -> 140; check-all 140/140 (T2's pass==N re-baselined cleanly).
difficulty.py NOT in the insertion set anymore (it derives, T6) -> only 3 tool dicts touched.
- tools/disc_code_sweep.py: decode every payload (reusing sig_image.make_insn) and gate code on
BOTH valid>=0.90 AND jr_$ra density>=0.01. The jr_$ra gate is decisive: isValid() alone flags
389 false hits (type-0/2 structured data decodes ~100% valid but has ZERO returns); jr_$ra
separates code (~2.9-3.4%) from data (0.000%), validated on positive+negative controls.
- FINDING (docs/disc-completeness.md): type-4 location overlays are COMPLETE (138/138). All other
types are data EXCEPT type-1 = 40 code payloads, 1 onboarded (the resident), 39 HIDDEN
resident-class modules (mostly MAIN.CD/FILE_XXX/1.1). They load at UNKNOWN addresses (not the
shared overlay slot), so they are NOT mechanically onboardable — byte-verifying a build binary
needs its load address (P9), knowable only by runtime RE (the Phase-3 method). Deferred with
evidence, NOT force-onboarded at a guess.
- CONSEQUENCE: game-code TRUE 100% now spans 140 onboarded binaries PLUS ~39 type-1 modules
pending load-address RE. The roadmap assumed 136 — this is a real re-baselining (the +4 overlays
also add ~2.45 MB to the denominator; every family propagation is now x138). Flows to T10/T11.
- SETUP §6.3 tool inventory updated (R21).
65 lines
4.0 KiB
Markdown
65 lines
4.0 KiB
Markdown
# Disc-completeness audit (Phase-27 T7)
|
||
|
||
> **Generated 2026-07-15.** Reproduce: `tools/disc_code_sweep.py` (committed). The question this
|
||
> answers is the one the whole-binary byte-gate is structurally blind to (R34): `make check-all` only
|
||
> touches binaries someone ONBOARDED, so a code payload nobody onboarded is invisible to it however
|
||
> green the fleet is. This reconciles the ONBOARDED set against every code-bearing payload ON THE DISC.
|
||
|
||
## What the disc holds (extracted PAC payloads, by type)
|
||
|
||
`extracted/retail/**` holds **1189** raw PAC payloads across 8 types (`docs/formats.md`):
|
||
|
||
| type | payloads | code-bearing | onboarded | note |
|
||
|---|---|---|---|---|
|
||
| 0 | 301 | 0 | 0 | data (graphics/blobs) |
|
||
| 1 | 166 | **40** | 1 | **resident-class code modules** — the resident is one; 39 more are NOT onboarded |
|
||
| 2 | 201 | 0 | 0 | data (decodes ~100% "valid" but 0% `jr $ra` — the false-positive class) |
|
||
| 3 | 201 | 0 | 0 | data |
|
||
| 4 | 138 | 138 | **138** | location overlays — **COMPLETE** (134 at PAC entry 0 + 4 SC07 at entry 1) |
|
||
| 6 | 29 | 0 | 0 | data |
|
||
| 7 | 139 | 0 | 0 | data |
|
||
| 8 | 14 | 0 | 0 | data |
|
||
|
||
**Code detection (`disc_code_sweep.py`):** decode the first 4096 words as MIPS-LE (reusing
|
||
`sig_image.make_insn`, GTE-aware) and require BOTH `valid ≥ 0.90` AND `jr $ra` density `≥ 0.01`.
|
||
The `jr $ra` gate is decisive: `isValid()` alone is far too permissive (structured type-0/type-2 data
|
||
decodes ~100% valid), but real MIPS code carries a `jr $ra` roughly once per function — **2.9–3.4%** of
|
||
words across the onboarded overlays + the resident, versus **0.000%** for the data blobs. Validated
|
||
against positive controls (`SC01/077/0.4.dec` 3.39%, resident `MAIN/FILE_010/1.1` 2.91%) and negative
|
||
controls (type-2 `0.00%`, type-0 `0.00%`).
|
||
|
||
## The finding
|
||
|
||
**Type-4 (location overlays) is complete.** All 138 type-4 payloads are onboarded and build
|
||
byte-identical. The 4 that were invisible for a month — `ov_SC07_{006,007,010,011}` — put graphics at
|
||
PAC entry 0 and the code overlay at entry 1 (`1.4.dec`); `new_overlay.sh` hardcoded `0.4.dec`. They are
|
||
now onboarded (byte-verified: `7ca772be`, `b3b95547`, `d7b5875d`, `9885af74`). **Fleet: 136 → 140.**
|
||
|
||
**Type-1 holds 39 additional, un-onboarded code modules.** These are resident-class code (the resident
|
||
`MAIN.CD/FILE_010/1.1` is the one already onboarded), the largest being `MAIN/FILE_027` (1318 w),
|
||
`FILE_036` (1229 w), `FILE_028` (1115 w). Full ranked list: `.run/disc_code_sweep.txt` (regenerate with
|
||
the tool). They are **NOT location overlays** — they do not load at the shared slot `0x80128158`; each
|
||
loads at its own address, the way the resident loads at `0x800CEDF8`. So — unlike the SC07 overlays —
|
||
**they cannot be onboarded mechanically:** a build binary needs its load address to byte-verify (P9), and
|
||
that address is only knowable by runtime RE (a PCSX-Redux RAM-dump proof, the Phase-3 method). Onboarding
|
||
them is a Gen2 RE task, deferred with this evidence — NOT a false "complete" while code sits unbuilt.
|
||
|
||
## Consequence for the completion contract (roadmap §1)
|
||
|
||
The contract's binary count is **no longer "136"**. Two corrections:
|
||
1. **140 binaries onboarded now** (main + resident + 138 overlays) — the number `check-all` verifies.
|
||
2. **A documented backlog of 39 type-1 code modules** pending load-address RE before they can be
|
||
onboarded and counted. Game-code TRUE 100% (the contract's bar) is only honest once these are either
|
||
onboarded-and-matched or explicitly excluded with a reason. They are recorded here so the "100%"
|
||
claim cannot be made while they sit un-onboarded and unexamined (R34 — the byte-gate cannot see them).
|
||
|
||
**This is a re-baselining event, expected to LOWER the headline %** (the 4 SC07 overlays add ~2.45 MB of
|
||
mostly-unmatched code to the denominator; every "×134" family propagation is now "×138"). That is the
|
||
honest direction — the prior number was measured over an incomplete disc.
|
||
|
||
## Reproduce
|
||
```
|
||
tools/disc_code_sweep.py # the table above + the ranked hidden list
|
||
tools/disc_code_sweep.py --types 1 # just the type-1 code modules
|
||
```
|