Probe journal listener route callbacks

This commit is contained in:
2026-06-20 00:40:34 -05:00
parent 451e84beb1
commit 3b0a66a87a
3 changed files with 264 additions and 0 deletions
+45
View File
@@ -217,6 +217,51 @@ The GPS query helpers appear to be exposed helper/test surfaces, not the route
path used by the world map. `TrackEntry` is now the highest-confidence native
handoff for quest/objective route plotting.
## Journal Listener Fanout
`JournalManager.TrackEntry` at RVA `0x5944fc` is now confirmed at runtime as the
quest/objective route-plot entry point. A controlled test produced route-plot
calls at `06:32:44`, `06:32:50`, and `06:32:56`, all from return RVA
`0x26ac34e`, which is the script/native wrapper path for `TrackEntry`.
The native `TrackEntry` implementation updates the tracked-entry state and then
fans out through a listener array:
```text
JournalManager + 0x210: listener pointer array
JournalManager + 0x21c: listener count
listener vtable + 0x28: one tracked-entry callback path
listener vtable + 0x30: another tracked-entry callback path
listener vtable + 0x50: untrack/default path
```
Before the save is fully loaded the listener count is small. After the world map
is opened it rises to 254. Most entries use the no-op callback `0x14a700`, but
the live route test repeatedly exposed this small non-default set:
```text
0xea89a8 / 0xea8958
0xe63f80 / 0xe63e6c
0xe63f00 / 0x8d136c
0x431a34 / 0x55a4e4
0x14de238
```
Static disassembly of these callbacks suggests the following split:
- `0x14a700` is a plain empty return.
- `0xea89a8` and `0xea8958` are objective/story tracking callbacks; their vtable
lives beside a `quests/street_stories/.../generic_sts_objective` string.
- `0x431a34`, `0x55a4e4`, and `0x14de238` are heavy UI/tracker state callbacks.
- `0xe63f80` and `0xe63e6c` remain the most promising route-refresh callbacks:
they read nested listener fields at `+0x70` and `+0x78` and call high vtable
slots such as `0x218`, `0x230`, `0x240`, `0x340`, and `0x348`.
The installed probe now hooks those non-default callbacks directly and logs the
nested owner/service vtables. The next target is to identify which nested vtable
slot performs the route query or route cache update, then disassemble or patch
that function.
## Native False Positives
Static string scans found a tempting traffic/pathfinding cluster around RVA