A Lua script, a controller input, and a network message can all ask a game to change health. Lesson 1.3 used the rule 0 less than or equal to health less than or equal to max_health to decide whether a player record made sense. Now imagine one of those requests arrives when health is 5 and asks for 20 damage. The game should produce health 0, not -15, and its displayed health bar should eventually agree. This chapter asks where that rule is enforced, which copy of health the game trusts, and how to notice when one route around the rule still changes the game.
The earlier chapters established how to recover an object layout and keep a live hook valid. Advanced game hacking now asks what the observed behavior means: record the decision and effect, then inspect integrity and environment checks and encoded values. The final control cases ask whether each check protects the authoritative state it claims to protect.
Four pieces of evidence keep this question answerable: the value and the address temporarily holding it, the exact game build, a timestamped sequence of state changes, and whether the tool observed state or changed it. The following model connects those pieces before looking for a control gap.
Section: An invariant is a property that must stay true.
An invariant is a statement that must be true whenever the system is in a valid state. Examples include:
ammunition never becomes negative;
an entity ID refers to at most one live entity in a snapshot;
a patch is applied only to the exact build and bytes it was made for;
a rendering hook is either fully installed or fully removed;
a read-only observer never changes the game state.
An invariant does not live at one address. The health bound 0 less than or equal to health less than or equal to max_health can be enforced by a clamp instruction, depend on a max_health field, and be reported by a log line, all at the same time. Each of those is a place where the rule is kept or reported, and a bug in one of them leaves the rule itself unchanged: a state with health equals 120 and max_health equals 100 is invalid whichever of the three failed to catch it.
Predict first
A damage routine guards health with max(new health, 0), and the same routine applies heals as positive changes. Health is 90 and max_health is 100.
A heal of 30 arrives. What health does the game store?
Answer: 120, which breaks the invariant. 90 + 30 equals 120, and max(120, 0) equals 120 because 120 is not below 0. The rule 0 less than or equal to health less than or equal to 100 is now false, and the health bar copies 120 as well.
Section: State, transitions, controls, and detectors.
A control keeps an invariant true, usually by refusing or limiting a transition before it takes effect. A damage routine that stops health at 0 instead of letting it go negative is a control. A detector reports that an invariant may already have failed, such as a scan that logs any entity whose health exceeds its maximum. The two are separate pieces of code, so they fail separately: a detector can be noisy while the control still works, or quiet while the control is incomplete.
In brief: A control limits a state change before it happens; a detector reports evidence that a condition may already have failed.
Section: What bypass analysis means in this chapter.
A bypass is a path that reaches an outcome without satisfying the control, the code that was supposed to guard it. In a game, the mismatch is often between a convenient proxy and the real rule:
The analysis pattern is always the same: state the promised rule, trace the branch that claims to enforce it, follow every path to the effect, and look for a path where the proxy and the real property disagree. Later lessons apply that pattern to integrity checks, anti-debug behavior, encoded values, and requests that cross game or system boundaries. The hook and layout contracts remain the foundation that makes those observations trustworthy.
Section: A control guards one copy of the state.
A game keeps several copies of the same fact. The simulation’s entity object holds health, the health bar keeps its own copy for drawing, a script receives one in a snapshot, and in a networked game the server keeps a record while each client keeps a prediction of it. Exactly one copy is authoritative: the one whose value decides what happens next. In a single-player game that is usually the simulation object. In a multiplayer game with an authoritative server it is the server’s record, and each client’s copy is a prediction that the server can overwrite.
Alternative: The health bar is a scoreboard copy; the simulation record is the scorekeeper. Changing or checking the display does not necessarily change the deciding value.
A control protects only the copy it runs against. Code that validates the health bar’s copy and then applies damage to the simulation object has checked one copy and changed another; Lesson 14.7 calls this the wrong source of truth. Server authority is the same rule at network scale: the server validates every client request against its own record, because anything a client computed can be altered on the client’s machine before it is sent.
The copies hold the same number most of the time, so reading a matching value does not say which copy was read. Timing does. The authoritative copy changes first and decides the next transition; every other copy catches up afterward, on its own schedule.
Section: Draw the state machine.
Suppose an entity can be alive, downed, or removed. A state diagram lists every allowed transition:
The diagram raises a question that one memory sample cannot answer: does the stored health field change before or after the Alive to Downed transition? A sample shows one moment. A trace of timestamped events shows the order.
Narration: One snapshot can show zero health and a downed state without revealing which changed first. Ordering needs events from the same observed transition.
Section: Trace state changes as typed events.
A trace is a list of events in the order they were logged, each saying what changed, when, and which observer saw it. Typed fields let a program check the trace:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
sequence gives log order. tick connects the event to the game clock. source names the observer that produced the event. Because an event carries typed fields rather than a sentence, a test can ask directly whether a HealthWrite ending at 0 comes before the ModeChanged to Downed for the same entity. A short trace for entity 7:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Health reaches 0 at tick 900 and the mode changes in the same tick. The health bar, which draws from a copy, shows 0 only at tick 901, one tick later.
Log order is not cause. Event 41 appearing before event 42 fits the damage causing the transition, but it also fits both events sharing one cause, or two observers that flushed their output at different times. Lesson 14.6 adds correlation IDs, which tie together the events of one action even when log order misleads.
Section: Use the same model for a different rule.
Health is an easy starting example because its valid range is visible. The same questions transfer to a rendering hook, though the fields are different:
The analogy has a limit: health is one value, while a hook changes executable bytes that other threads may be using. Lesson 8.10 handles that concurrency. The transferable method is to name the state, permitted transition, invariant, control, and observable failure before choosing an implementation.
Section: Glossary terms introduced here.
Invariant: a property required of every valid state or transition.
Control: logic intended to preserve an invariant.
Detector: logic that reports a possible invariant failure.
Authoritative state: the one copy of a value whose contents decide what happens next.
Server authority: a design in which the server’s record is authoritative and every client request is validated against it.
Trace: events listed in the order they were logged, each with its time and source.
The useful model is state changing through transitions under an invariant. A control must guard the authoritative copy when a transition takes effect; a detector can report a violation but does not enforce that rule. Lesson 14.7 uses this distinction to examine what an integrity check actually covers.