Event Proxy Version Profiles

An Event Proxy should treat every executable build as a profile, even when later clients descend from the same source tree. Function signatures can relocate well-understood symbols across nearby builds, but they cannot by themselves prove object field offsets, allocation sizes, ownership, or calling conventions.

The recommended strategy for 5.x and 7.x is to reverse one representative executable from each build family, establish the same lifecycle, Event, Socket, pane, and state roots, and generate signatures from that ground truth. Signature remapping can then handle close patch revisions. It should not replace the first semantic analysis of a major client family.

High-level operation

Exact profiles first

The resolver should fingerprint the loaded image before it installs any hook. The strongest identity is a hash of the file or its mapped immutable sections. PE timestamp, image size, section sizes, and version resources are useful secondary properties but are not unique enough alone.

The analyzed sample has SHA-256 36093dc1572521ea8c4c5f25548068c971a3d41c7722ef9fe0c05c94e24d6979. Its project identification is 4.21 Stone, while its Windows version resource reports 360, 0, 0, 0; the mismatch is documented in Analyzed Binary.

For an exact match, the profile supplies RVAs, expected instructions, vtables, globals, calling conventions, object fields, and capability-specific validators. The runtime address is always:

loaded_module_base + profile_rva

Do not store a process-specific absolute address in controller configuration.

Dark Ages 4.21 core profile

This table is the core hook profile, not the complete memory profile. UI vtables, roots, and fields remain in Runtime UI Memory Map and Pane Virtual Table Inventory.

What a profile must contain

A useful profile contains more than symbol addresses:

A controller should receive the active profile identifier during HELLO_REPLY and repeat it in diagnostic logs and captured metadata. This prevents a memory path from one build being silently applied to another.

Signature scanning

A function signature is useful only when it survives relocations and still has enough structure to be unique. Generate signatures from decoded instructions, not by copying a long unexamined byte range.

The scanner should:

1. Restrict the search to the expected PE section and executable or read-only data class.
2. Wildcard absolute image addresses, import pointers, relative-call displacements, jump-table addresses, and other relocation-sensitive operands.
3. Preserve stable opcodes, constants, stack cleanup, field displacements, queue codes, and branch relationships when they are part of the established contract.
4. Require a unique candidate before semantic validation.
5. Decode the candidate and verify its control flow, callees, globals, object fields, and ownership behavior.
6. Resolve related symbols as a group and verify their cross-references.

A generic function prologue such as register saves and stack allocation is not a signature. A source filename or nearby assertion string is a useful anchor but is not proof. The final candidate must perform the mapped data flow.

Semantic validators for the core hooks

Validation should also confirm the expected vtable at each live root. A matching function body with a mismatched owner layout is not enough to enable mutation.

Capability gating

Resolve capabilities independently, then expose only the ones whose complete dependency set passed:

If a required mutation dependency fails, disable that capability. Do not fall back to an unvalidated nearest address. Passive build diagnostics can remain available without client hooks.

Porting to 5.x and 7.x

Why one-time reversing is still required

Shared source lineage is valuable because queue codes, class roles, packet actions, assertion text, vtable shapes, and ownership patterns may remain recognizable. It does not guarantee stable machine code or memory layouts. These changes can invalidate a 4.21 profile while leaving the game visibly similar:

• compiler or optimization changes;
• inserted class fields that shift every later offset;
• new virtual methods that shift vtable slots;
• inlining or outlining of queue wrappers;
• different static initialization and linker ordering;
• larger packet, map, UI, or transport buffers;
• changed ownership or thread-affinity rules;
• security additions around packet processing.

Function scanning also does not find heap fields automatically. Character statistics, inventory, and world-object walking require profile-specific owner roots, object discriminators, container layouts, and deletion rules. These should be established once for each family and then compared structurally with 4.21.

Recommended porting order

1. Identify the exact executable and record its hash without adding it to the repository.
2. Map WinMain, app_initialize, the message procedure, and app_shutdown.
3. Locate the generic worker queue and distinguish the dispatcher, EventMan, and Socket objects.
4. Trace decoded receive bytes into pane delivery and packet builders into the logical send queue.
5. Establish Event type layout, Event cleanup, pane handler vslots, and timer delivery.
6. Find EventMan, Socket, dispatcher, Screen, MapPane, and persistent character-pane roots.
7. Map state fields from packet handlers and multiple callers, not from string proximity.
8. Update IDA names, types, comments, and vtable slots.
9. Produce an exact profile and instruction-aware signatures from the established functions.
10. Run passive telemetry first. Enable blocking, injection, and writes only after runtime observations agree with the static model.

Start with one representative 5.x build and one representative 7.x build. If several patch revisions differ only slightly, signatures and semantic validators can likely cover them. If allocation sizes, vtable layouts, or packet ownership change, split them into separate profiles even when the major version is the same.

Comparing profiles

Use semantic identifiers across profiles while storing version-specific details beneath them. For example, all profiles can export logical_client_send, but each entry supplies its own RVA, ABI, transfer-gate offset, sentinel rule, and validators. The IPC command stays stable while the injected adapter changes by profile.

For memory, compare paths rather than absolute offsets alone:

semantic root -> owner relationship -> container kind -> element discriminator -> field

If EventMan -> owned Socket remains true but the owner offset changes, the profile records the new offset. If a later client moves the Socket to another singleton, the semantic path changes and must be re-established rather than forced into the old shape.

Code-level flow

Resolver flow

load image metadata
  -> exact immutable-section hash match
      -> load exact profile
  -> otherwise scan instruction-aware signatures
      -> collect unique candidates
      -> run per-symbol semantic validators
      -> validate roots, vtables, and cross-references
      -> build a temporary resolved profile
  -> evaluate capability dependency sets
  -> install only fully validated capabilities

The temporary resolved profile should be exportable as diagnostic data, but it should not be promoted to a maintained profile until the same addresses and layouts are confirmed in IDA and, where needed, by controlled runtime observation.

Normalized instruction matching

For matching purposes, represent each instruction by opcode class and stable operand properties. Relative targets can be expressed as “call to candidate with validator X” rather than a fixed displacement. Absolute globals can be expressed as “writable image address published by constructor Y.” This is more durable than a byte mask alone and permits cross-symbol validation.

A byte mask can remain the fast first stage. The instruction model is the proof stage before hook installation.

Field-offset recovery

Do not copy 4.21 offsets into an unknown profile. Recover offsets from established functions and require agreement across independent uses. Examples include:

• Event type reads in all three classifier functions;
• packet pointer and size writes in socket Event construction and reads in dispatcher cleanup;
• Socket transfer-gate reads in logical send queueing;
• Socket connection flag writes in connect, receive-zero, and disconnect paths;
• Pane visibility reads, show writes, and hide writes;
• parent slot-array reads in add, remove, destructor, and activation paths.

Only publish a field after its owner, width, signedness, and lifecycle agree across the relevant sites.

Function table