From f2d7e7ecd4486940f447a0812a22b867fc04c323 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Wed, 14 Oct 2026 06:01:54 +0200 Subject: [PATCH] d97e7df was wrong: my section offset was wrong, not the decoder Ran gc-overlay-anchors on 0x2ee138 as d97e7df directed. It reports 6 of 12 words did not decode -- but the words disagree: tool: 0x2ee138 0x4bc00083 my read: 0x2ee138 0xd8a10000 Different bytes at the same address. My offset into the section is wrong, so the 'opcode 0x36 is invalid' finding was about bytes never at that address. That invalidates d97e7df's conclusion and its 'second decode error' framing: the decoder was never the problem. The tool's words are COP2 (0x12), VU1 vector-unit instructions, which capstone will not render under plain MIPS32. So its 'did not decode' is expected for VU code and says nothing either. Four bugs in this investigation, all mine: un-masked branch target, transposed address, invalid opcode read from wrong bytes, and the offset mapping itself. Every one was a self-consistent probe reporting a clean number. The check that catches all four is verifying the tool against a known-correct case before using it to generate a finding -- which d97e7df recommended and I then skipped. Nothing about 0x2ee138 is now known: not VU code, not data, not a function. The address is the correctly decoded jal target; what is there is unestablished. Next step is to fix and verify the address-to-overlay mapping before re-reading anything. Until then no address computed by hand in this investigation is trustworthy, including the 0x3a8060 walk that happened to decode. 284 passing with the disc present, clippy clean. --- docs/plan/level-assets.md | 44 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index d9ed3f9..d711c33 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -2356,3 +2356,47 @@ The chain as far as it is established, with nothing inferred beyond it: Everything above that is verified; what `0x2ee138` returns is **unknown**, and it is the single remaining link between the program and `moby_classes.offset`. + +### d97e7df's conclusion was wrong: my section offset was wrong, not the bytes + +Ran `tools/overlay-anchors --disasm` on `0x2ee138` as `d97e7df` said to. It +reports "6 of 12 words did not decode" -- but compare the *words*: + + tool: 0x2ee138 0x4bc00083 + my read: 0x2ee138 0xd8a10000 + +Different bytes at the same address. **My offset into the section is wrong**, so +the "opcode 0x36 is not a valid MIPS opcode" finding was about bytes that were +never at that address. That invalidates the conclusion in `d97e7df` as well as the +"second decode error" framing in it -- the decoder was never the problem. + +The tool's words are `0x4bc00083` and friends, which are **COP2** (opcode 0x12), +i.e. VU1 vector-unit instructions, which capstone will not render under a plain +MIPS32 configuration. So capstone's "did not decode" is expected for VU code and +carries no information either. + +Four separate bugs in this one investigation now, all mine: + +1. un-masked J-type branch target -> false negative on callers +2. transposed hex address -> disassembled the wrong place +3. concluded "invalid opcode" from bytes that were not at that address +4. the section-offset mapping itself is wrong + +**The one lesson, and it is the same one four times over:** every one of these was +a self-consistent probe reporting a clean number. The discipline that would have +caught all four is the one `d97e7df` recommended and I then skipped -- verify the +tool against a known-correct case *before* using it to generate a finding. The +known-correct case was sitting in the decomp's own extents, and I used my own +arithmetic instead. + +**Nothing about `0x2ee138` is now known.** Not that it is VU code, not that it is +data, not that it is a function. The address `0x2ee138` is the correctly decoded +`jal` target from `0x3a3d70`; what is at that address is unestablished. + +The correct next step is to fix the address-to-overlay mapping in `gc-formats` +(`OverlaySection` gives `dest` and `data`, and the mapping between them is what +has been wrong all along), verify it against a section whose contents are +independently known, and only then re-read `0x2ee138`. Until that mapping is +verified, **no address in this investigation that I computed by hand is +trustworthy** -- including the `0x3a8060` walk, which happened to decode but may +have been read from the wrong bytes.