Probe observer1 route service lookup

2026-06-20 01:30:56 -05:00
parent ad4907040a
commit 8c8cc784e0
3 changed files with 149 additions and 2 deletions
@@ -365,6 +365,26 @@ handles/strings under its inner object at offsets around `+0x180`, `+0x1a0`,
 `routeObject + 0x8c` so the next runtime test can tell whether observer1 is
 crossing into GPS/path computation or just updating presentation state.

+The `07:22:14` controlled run confirmed observer1 is in the deliberate route
+click window, not just load-time setup. The three quest route clicks produced
+the expected sequence:
+
+```text
+JournalManager.TrackEntry
+MappinSystem.RouteEventEnqueue old active=0 / new active=1
+MappinSystem.RouteDeactivate old route key
+MappinSystem.RouteActivate new route key
+RouteObserver1 deactivate/activate with the matching routeObject + 0x8c route id
+```
+
+The observer1 service-owner object was stable across those calls
+(`serviceOwner` vtable `0x142b74ea8`, slot `0x08` target `0x140287c44`).
+Static disassembly of `0x140287c44` shows a generic type-to-service lookup, so
+the next probe hooks that function, filters on the runtime type pointer at
+`0x342f6a8`, logs the returned service object, and dynamically hooks the
+returned service's vtable slot `0x220`. That slot is the immediate next native
+call after the lookup and receives the route id from `routeObject + 0x8c`.
+
 The most route-building-looking static candidate currently in this chain is
 `0x5625a4`, called once from the bridge at `0x5984ec`. The bridge resolves
 journal route ids through virtual journal-manager calls, collects several route