From 743107e8641efd10631a146162a8c31ccd15ffbd Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Wed, 14 Oct 2026 05:13:02 +0200 Subject: [PATCH] moby_anim: the class table is not the loader Ruled out the cheap approach: moby_classes (offset 0xc0, count 238 in level 0) holds float-shaped values, and only 120 of the first 4,096 u32s land inside the overlay .text against ~259 expected by chance. Fewer than chance, so the loader is not dispatched from a pointer here. Not concluded what the 238 entries are -- the float reading is suggestive but was taken at one stride on one level. --- docs/plan/level-assets.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index 6531adb..2d78445 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -1909,3 +1909,33 @@ the class's own tie packet blocks. What they address remains unknown, and the earlier finding that the packet's control region is not a tag stream still stands -- it was measured by uniformity within the packet, not by comparison to somewhere else in core_data. + + +## moby_anim: the class table is not the loader (negative result) + +`moby_anim` needs the moby class loader. The obvious place to look for a loader +is the moby class table, since a loader is usually dispatched from one. Checked +that first and it is ruled out. + +`moby_classes` is an `ArrayRange`: offset `0xc0`, count 238, in level 0. The +words there are not pointers. Read as floats they are + + 0x4846a9e3 0x47f40000 0x46d0b0de -> ~50,986 61,000 26,671 + +which is position/scale-shaped data. And scanning every u32 in the first +`0x4000` bytes for values landing inside the overlay's `.text` +(`0x2a3b80..0x447900`) gives **120 hits out of 4,096**, against roughly **259** +expected if the values were unrelated to the region. + +So the table holds *fewer* .text-range values than chance, not more. Whatever the +moby class loader is, it is not dispatched from a pointer in this table. + +That rules out the cheap approach. Finding the loader means cross-referencing +from somewhere else -- most likely a constructor that reads the class table and +returns runtime state, which is in `.text` and has to be found by scanning for +code that touches both `moby_classes.offset` and the class spans. That is a +larger search than a bounded probe, and it is the unblock condition already +recorded for `moby_anim`. + +Not concluded: what the 238 entries *are*. The float reading is suggestive, not +established -- it was read at one stride, on one level, and rule 3a applies.