David Robertson

David Robertson

David Robertson

@davidrobertson

May 2

Other than the annoying "disclaimers" seems to get it pretty well Question for GPT-5.5 Pro: "Suppose I want to discover the memory variable behind an in-game value or state transition. Describe the full discovery workflow, then identify cases where the workflow would fail or require prior instrumentation." Answer from 5.5 Pro: Below assumes you are doing this on a game/build you are authorized to inspect: your own game, a debug build, emulator research, QA tooling, modding with permission, or offline reverse engineering. For protected online games, the correct route is dev instrumentation, server logs, replay tools, or engine/debug symbols—not bypassing protections. Core idea There may not be “the” variable behind a visible in-game value. There are usually several layers: Authoritative model state ↓ Client simulation / replicated state ↓ Derived gameplay state ↓ Animation/UI/audio/render cache ↓ Displayed number or visible transition The workflow is therefore not just “find the address.” It is: find candidate memory, prove it represents the thing you care about, find who writes it, distinguish display/cache copies from authoritative state, make the result stable across runs/builds. Full discovery workflow 1. Define the observable precisely Start by naming the thing you are trying to discover. Examples: Visible value: - health shown as 73 HP - ammo count shown as 12 - cooldown ring at 40% - quest counter says 3/5 State transition: - player enters "stunned" - door becomes open - enemy switches from idle to aggro - weapon changes from unloaded to reloading - checkpoint becomes completed Then define: State A: before the value/transition State B: after the value/transition Trigger: the exact action that causes A → B Controls: actions that look similar but should not cause A → B Persistence: does B last for many frames, or only one frame? Visibility: is the value visible directly, rounded, animated, or inferred? This matters because a visible number is much easier than a semantic transition. Finding 73 in memory is straightforward-ish. Finding “enemy is now aggro” may involve AI state, perception state, target pointer, blackboard entries, animation state, navigation state, and replicated network state. 2. Create a repeatable test harness You want the smallest possible scenario where only the target changes. Good setup: - Same level - Same character - Same save point - Same camera position - Same enemy/item/object - Same trigger input - Minimal background simulation - Ability to repeat A → B many times For a visible value, create controlled deltas: health: 100 → 97 → 84 → 84 → 80 ammo: 30 → 29 → 28 coins: 150 → 175 For a state transition, create repeated pairs: A: enemy idle B: enemy aggro A: door closed B: door open A: weapon ready B: weapon reloading Also create negative controls: same amount of time passes, but transition does not occur same animation plays, but state does not change same UI updates, but gameplay state does not change Negative controls are what prevent you from accidentally identifying a timer, animation flag, frame counter, UI cache, or unrelated effect. 3. Infer possible representations The visible thing may not be stored in the format you expect. A displayed integer may be stored as: 73 int32 73.0 float 0.73 normalized float 7300 fixed-point 72.6 rounded to 73 float with display rounding "73" string/UI text 100 - damageTaken derived value baseHP buffs - damage encrypted/masked value bitfield flag enum index object reference component state A state transition may be stored as: 0 / 1 boolean enum: 0 = idle, 1 = patrol, 2 = aggro bit flag inside a packed integer pointer to current state object animation graph node ID script VM variable blackboard key event queue entry timer/cooldown component enabled/disabled flag server replication field Before scanning, decide what classes of representation are plausible. 4. First-pass candidate discovery For a visible numeric value, use differential scanning logic. Example for known value: Scan for 100 Take damage Filter for 97 Take damage Filter for 84 Wait without changing Filter for unchanged Heal Filter for increased For unknown representation: Initial scan: unknown Take damage Filter: decreased Wait Filter: unchanged Heal Filter: increased Take damage Filter: decreased For state transitions: Snapshot before transition: A Trigger transition Snapshot after transition: B Find changed addresses Repeat multiple times: A1 → B1 A2 → B2 A3 → B3 Keep addresses that consistently change during A → B. Remove addresses that also change during negative-control windows. Conceptually: candidates = addresses_changed_during_real_transition minus addresses_changed_during_control_windows minus noisy frame/timer/animation/UI-only addresses For persistent states, prefer values that remain stable while the state remains active. For example: enemy idle: candidate = 0 enemy aggro: candidate = 2 enemy stunned: candidate = 5 A candidate that changes every frame during the state is more likely to be a timer, animation progress, interpolation value, or behavior score—not the main state variable. 5. Reduce candidates using structure Once you have candidates, inspect nearby memory. You are looking for field neighborhoods. For example, near a player health candidate you may see: 0x00 entity id 0x04 team id 0x08 health 0x0C max health 0x10 stamina 0x14 armor 0x18 position.x 0x1C position.y 0x20 position.z Nearby values can tell you whether you found: - real gameplay state - UI copy - network replica - save data cache - animation state - temporary calculation buffer - stale previous-frame value For object state, nearby pointers or IDs often reveal the owning object. For an enemy state transition, nearby memory may contain: entity id current target pointer AI state enum perception timer last known player position navmesh path pointer animation state health That is much more convincing than a single isolated changed byte. 6. Test causality carefully Finding a value that correlates is not enough. You need to prove it matters. There are several levels of proof. Weak proof: The address changes whenever the visible value changes. Better proof: Changing the value changes the displayed value. Stronger proof: Changing the value changes actual gameplay behavior. Strongest proof: Blocking or modifying the writer prevents or changes the state transition. Example distinction: UI health copy: - Changing it updates the health bar. - Player still dies at the original health value. Gameplay health: - Changing it affects damage/death logic. Server-authoritative health: - Changing local value may briefly affect display. - Server corrects it immediately. For state transitions, causality tests might look like: Set candidate state from idle to aggro. Does enemy actually aggro? Set candidate state from aggro to idle. Does enemy stop attacking? Prevent the transition write. Does the enemy fail to enter aggro? Force the transition write early. Does the transition happen without the normal trigger? If only the animation changes but gameplay does not, you probably found animation state, not gameplay state. If gameplay changes briefly and then snaps back, you probably found a client-side prediction or replicated copy, not the authority. 7. Find the writer After identifying a candidate address or field, the important step is finding the code that writes it. Use a data watchpoint / write breakpoint / tracepoint on the candidate. Then trigger the change. You want to capture: - instruction/function that writes the value - call stack - owning object pointer - field offset - conditions around the write - previous value - new value - event that triggered it For a value: DamageSystem::ApplyDamage() writes Player.health For a transition: AIController::SetState(Aggro) writes Enemy.currentState Or: DoorInteractable::OnUse() writes Door.flags |= OPEN writes PhysicsCollider.enabled = false writes AnimationGraph.state = Opening This step tells you whether the candidate is a root state variable or just an effect of another state. 8. Find the reader path too The writer tells you who changes the value. The reader tells you who uses it. For example, a health value may be read by: - damage logic - death logic - UI renderer - save system - network serializer - achievement system A state variable may be read by: - AI update loop - animation graph - physics/collision - audio system - UI prompt logic - replication code If only the UI reads your candidate, it is not gameplay-authoritative. If simulation, physics, AI, or damage logic reads it, it is more likely to be real state. 9. Stabilize the address into a durable mapping A raw address is usually useless across launches. You want to turn: 0x000001A7F32C91B8 into something like: PlayerObject 0x138 = currentHealth EnemyAIComponent 0x44 = currentState DoorComponent 0x20 bit 3 = isOpen Then identify how to find the object: module base static offset global singleton → player manager → local player entity list → entity id → component pointer scene object registry → object name/hash → component script VM object handle → field save data object → field network replica table → field id Prefer object/component identity over pointer chains. Pointer chains often work accidentally but break with allocator changes, scene changes, game updates, or different object counts. A better durable result is: Entity[type=Player].HealthComponent.currentHealth not: [[[base 0x123456] 0x20] 0x78] 0x138 10. Confirm across resets, scenes, and versions Before trusting the discovery, test: - reload save - restart game - change level - respawn object - repeat same transition - test another player/enemy/item instance - test another build if relevant A real field should have stable semantics even if its absolute address changes. You should end with a record like: Target: Player current health Representation: float, not int displayed HP = round(currentHealth) Owner: LocalPlayer HealthComponent Field: HealthComponent 0x38 Writer: DamageSystem::ApplyDamage HealSystem::ApplyHeal RespawnSystem::ResetHealth Readers: DeathSystem HUDHealthWidget SaveSerializer Validation: Changing field affects gameplay and UI. UI cache located separately at HUDWidget 0x90. For a transition: Target: Enemy idle → aggro transition Representation: AI state enum Owner: EnemyAIComponent Field: EnemyAIComponent 0x44 Values: 0 = idle 1 = patrol 2 = alert 3 = aggro 4 = stunned Writer: AIController::SetState PerceptionSystem::OnPlayerSeen Readers: AI update loop AnimationGraph Network replication Validation: Forcing 3 causes enemy to attack. Blocking write prevents aggro. Animation state alone is separate and non-authoritative. Special workflow for state transitions State transitions are harder than visible values because the important thing may be semantic, not numeric. A good transition workflow is: 1. Capture stable A state. 2. Capture stable B state. 3. Record A → B several times. 4. Record A → A negative controls. 5. Diff memory across real transitions. 6. Remove values that also change in controls. 7. Look for candidates stable while B persists. 8. Watch writes to those candidates. 9. Identify the writer function. 10. Determine whether the writer is root cause or downstream effect. For noisy transitions, narrow the time window. Instead of: snapshot before fight snapshot after fight use: frame N: enemy idle frame N 1: perception event fires frame N 2: state written frame N 3: animation changes The smaller the window, the fewer false positives. With prior instrumentation, you can log: frame number event name entity id component writes old value new value callsite That often turns a hard reverse-engineering problem into a straightforward trace. Where the workflow fails or needs prior instrumentation 1. The value is not stored as a persistent variable Some values are computed on demand. Example: displayedDamage = weapon.baseDamage * buffMultiplier * armorModifier There may be no single displayedDamage variable. You might only find: baseDamage buffMultiplier armorModifier temporary stack value UI text The computed value may exist briefly in a register or stack slot, then disappear. Requires: - source-level instrumentation - function tracing - render/UI call tracing - record/replay debugger - dynamic analysis around the calculation site 2. You found a UI cache, not gameplay state Common with health, ammo, cooldowns, objectives, stamina bars, and quest text. Symptoms: Changing candidate changes display only. Gameplay logic ignores it. Real value snaps the UI back later. Requires: - reader tracing - writer tracing - identifying the model → UI copy path 3. The authoritative value is server-side In multiplayer or online games, the client often has only: - predicted state - interpolated state - replicated copy - display cache - last known server value The real state may live on the server. Symptoms: Local changes are corrected. State snaps back. Other clients do not observe the change. Server rejects impossible transitions. Requires: - authorized server instrumentation - server logs - replay tools - network schema knowledge - test environment where you control both client and server Without server access, you may be able to find the local representation, but not the authoritative variable. 4. The transition is not represented by one variable “Door opened” may actually mean: quest flag set animation state = opening collider disabled navmesh obstacle removed sound event played save flag written interaction prompt hidden There may be no single doorOpen field. Requires: - system-level tracing - event logs - component write logs - engine inspector - semantic model of the game object 5. The value is packed, encoded, masked, or compressed The value may be stored as: bit 3 of a flags integer fixed-point integer delta from base value XOR-masked value compressed blob encrypted save/state block checksum-protected duplicate Symptoms: Exact scans fail. Changed/unchanged scans produce too many candidates. Changing candidate corrupts state or is reverted. Nearby memory does not look like normal fields. Requires: - knowledge of encoding boundary - instrumentation before encoding or after decoding - tracing serializer/deserializer - source/debug symbols if available 6. The object moves Managed runtimes, scripting VMs, garbage collectors, entity pools, and custom allocators can move or recycle objects. Symptoms: Address works for one run but not after reload. Address points to a different enemy later. Candidate disappears after scene transition. Pointer chain breaks frequently. Requires: - heap/object introspection - entity IDs - component registry access - GC-aware tooling - engine reflection metadata - debug symbols 7. The state exists inside a script VM or blackboard In Unity, Unreal Blueprints, Lua, Python, custom scripting, behavior trees, or AI blackboards, native memory may only show opaque VM structures. The meaningful value may be: Blackboard["TargetActor"] Blackboard["IsAlerted"] ScriptObject.enemyState Blueprint property Lua table entry VM stack slot Requires: - script debugger - VM instrumentation - reflection/property metadata - blackboard/behavior-tree inspector Raw memory scanning can find something, but interpreting it may be very hard. 8. The transition is too noisy Large events change thousands of addresses: level load cutscene start combat start checkpoint activation boss phase transition inventory update quest completion Many unrelated things change at the same time: timers animations particles audio UI physics streaming allocators logs random seeds Requires: - narrower trigger window - deterministic replay - frame-by-frame capture - event instrumentation - component-level write logging Without that, differential scanning may drown in false positives. 9. The value only exists for one frame Some state transitions are edge-triggered, not level-triggered. Example: OnJumpPressed event OnDoorOpened event OnParryWindowStarted event OnQuestAdvanced event There may be no persistent jumpPressed = true. Instead, the game may push an event, consume it, and clear it in the same frame. Requires: - event queue instrumentation - frame stepping - tracepoints - record/replay - input-to-handler tracing Snapshot-based workflows usually miss these. 10. Multithreading makes snapshots misleading Modern games may update systems concurrently: simulation thread render thread network thread audio thread job system physics thread animation thread A snapshot may catch intermediate state. Symptoms: Candidate changes inconsistently. Same transition produces different deltas. Values flicker between old and new. Writer appears unrelated because another job copied the state. Requires: - synchronized frame boundaries - job-system instrumentation - thread-aware tracing - deterministic replay 11. The displayed value is rounded, delayed, or animated A health bar may animate from old value to new value. A number may be rounded. A cooldown may display normalized progress. Example: true health: 72.63 displayed: 73 true cooldown: 1.42 seconds remaining displayed ring: 37% true ammo: 29 displayed ammo: animated text still showing 30 for 100 ms Requires: - tracing UI binding path - scanning approximate values - checking both model and UI animation values 12. Physics, animation, or rendering owns the apparent state Some “state” is visual or physical rather than gameplay-authoritative. Example: ragdoll active animation montage playing shader damage flash enabled IK target set physics body sleeping/awake GPU particle state The variable may live in: animation graph physics engine GPU buffer render command buffer shader constants Requires: - animation debugger - physics debugger - frame debugger - engine-level instrumentation A CPU memory scan may find only command buffers or transient copies. 13. Anti-tamper or protected runtime blocks observation Some software intentionally prevents memory scanning, debugging, or modification. Symptoms: debugger attach fails watchpoints do not trigger reliably process exits or changes behavior memory appears obfuscated values are mirrored/checksummed Requires: - authorized debug build - symbols - built-in telemetry - sanctioned modding/debug tools Trying to work around protection is the wrong workflow. 14. The state is derived from save data, config, or content tables The runtime value may be generated from: save file level data quest table item database enemy archetype balance spreadsheet data asset The runtime memory variable may be temporary. The stable “source of truth” may be a content asset or serialized field. Requires: - asset inspection - save/schema knowledge - content pipeline instrumentation - data table lookup tracing 15. No repeatable trigger exists If the event is rare, random, destructive, or hard to reproduce, differential analysis becomes unreliable. Examples: random crit rare AI behavior one-time quest transition procedural event network race physics glitch Requires: - deterministic replay - controlled RNG seed - save states - test hooks - event injection in a dev build Practical rule of thumb For visible numeric values: scan → filter by value changes → inspect candidates → test causality → find writer → map object/field For semantic state transitions: repeatable A/B setup → transition/control diffs → candidate stability check → write tracing → reader tracing → prove root cause For hard cases: instrument first, scan second The workflow works best when the value is persistent, client-local, unencoded, repeatable, and tied to a small number of writes. It fails or becomes unreliable when the value is derived, transient, server-authoritative, encoded, heavily mirrored, VM-managed, GPU/physics-owned, noisy, or non-repeatable.

4,921