From db1e69c0abaaad40f032f2d27a028fab6c042b2c Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Wed, 14 Oct 2026 05:30:07 +0200 Subject: [PATCH] Ranking the 394 by size is backwards; record the confound Ranking the moby_classes candidates largest-first is the wrong first cut. The top entries are 34,316 and 26,432 bytes with 631 and 421 distinct immediates, median candidate 852. A function with 631 distinct immediates is far more likely to contain any given value, 0xc0 included, than one with 80, purely by pigeonhole. Sorting by size therefore selects for the functions most likely to be false positives, and the 34,316-byte outlier is probably a mis-bounded extent -- the decomp corrects three level-00 entries -- rather than a 34 KB loader. The 394 needs a size-independent statistic: whether a function contains 0xc0 more often than its immediate count predicts, not whether it contains it at all. Not measured. Recorded as a negative about the method rather than committed as progress. No test -- there is no assertion here to make. 283 passing with the disc present, clippy clean. --- docs/plan/level-assets.md | 32 +++++++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index 5566639..78b0c55 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -2045,8 +2045,30 @@ and `tie_classes` offsets, so there is no single function that indexes both chun tables by immediate. The moby loader, if it exists in this form, does not reach the tie table the same way. -**Next step, now concrete:** the 394 is a real shortlist. Take the ones whose -immediates also include chunk offsets that *do* look like class-table references, -or the largest ones -- the 34,316-byte outlier is the most promising single -target -- and disassemble those. That is bounded work, unlike the four probes -that produced nothing. +### Ranking by size does not narrow, and biases toward false positives + +The obvious next move was to rank the 394 largest-first and start with the +biggest. Ranked, over 2,323 functions, median candidate size 852: + + 0x2ba7d8 34,316 bytes 631 distinct immediates + 0x2cb3a8 26,432 421 + 0x300618 11,348 155 + 0x3ae900 8,440 208 + ... median 852 + +**This ranking is probably backwards.** A function with 631 distinct immediates +is far more likely to contain any given value -- including `0xc0` -- than one with +80, purely by pigeonhole. Sorting by size therefore selects *for* the very +functions most likely to be false positives, and the 34,316-byte outlier is +probably a mis-bounded extent (the decomp corrects three level-00 entries, per +`docs/LEVELS.md`) rather than a 34 KB loader. + +So the 394 needs a size-independent statistic before it is a shortlist. The right +measure is whether a function contains `0xc0` **more often than its immediate +count predicts** -- expected count from the neighbourhood rate, observed count +inside that function -- rather than whether it contains it at all. That has not +been measured. + +Recorded rather than claimed as progress: ranking by size is the wrong first cut, +and the reason is a confound that would have made the result look better than it +was.