Section: Obfuscation changes the representation.
A game does not have to store health as the obvious integer 125. It might XOR the value with a key, rotate the bits, split it across fields, or store both a value and a check value.
This is obfuscation: it makes a value less obvious. If the running program can decode it, an analyst can usually trace that decoding logic too. Obfuscation is not the same as encryption, and neither one automatically makes a program fair or secure.
Predict first
Health is 125, but the game stores 125 XOR 90. A memory scan for 125 finds nothing.
Which number does memory hold?
Answer: 39. 125 is 0111 1101 and 90 is 0101 1010. XOR puts a 1 only where the two bits differ, giving 0010 0111 equals 32 + 4 + 2 + 1 equals 39.
In brief: An encoded value looks different in memory, but the program must decode it to use it. So the decoding code is where the real value shows up.
We use the book’s own toy type. Do not use this lesson to defeat protection in a third-party competitive game.
Section: Start at where meaning appears.
Searching memory for the number 125 may fail because that representation never exists for long. A better question is:
Which instruction produces the value that the health bar displays or the damage calculation reads?
In a debug build, place a breakpoint near the rendering or gameplay function, then step backward through the data flow. A small decode might compile into operations like:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Follow e d x too. A transform without its key is only half the formula.
Section: Write the formula in both directions.
The lab uses:
The inverse relationship is easy to test:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
That last property is the important one: decoding the encoded value must recover the starting value for many inputs, not only one lucky example.
Follow the loop’s 100 case with its key shown here. The changing numbers below are all 32-bit values; the final result must return to the starting one:
Section: An integrity value is another clue.
The lab also stores a toy tag calculated from the encoded value and key. When one bit changes, the tag no longer agrees:
The code makes the two exits explicit. It recomputes the tag from the stored encoded value and the supplied key; a mismatch returns IntegrityError without decoding. A match permits the inverse transformation and returns the logical value in Ok.
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
This tag is educational, not cryptographically secure. An attacker who understands make_tag can calculate a matching tag. The useful lesson is structural: if a changed value is immediately rejected, look for another field or function that validates it.
Section: Dynamic keys change over time.
Some programs change a key when a level loads, an object is created, or a value is written. Reading the same field at several moments shows which events change the key:
Do not assume a value has “random encryption” merely because its bytes change. The cause may be an ordinary per-object key, a pointer-relative cookie, a checksum, or unrelated neighboring data.
Alternative: Picture a message re-written each day with a new shift. The meaning stays the same and only the writing changes, so track the key and the meaning separately.
Section: Run the complete lab.
The full implementation lives in advanced-memory-labs/src/obfuscation.rs, with a small executable in src/bin/obfuscation_lab.rs:
Terminal window
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
The demo prints a transformed value, decodes it, flips one bit, and shows the integrity failure. Its tests prove both the round trip and the failure case.
Section: The analysis, step by step.
Start from the exact build and one object address.
Trigger one controlled change in your own target.
Capture the encoded field before and after.
Find the code that reads the field for a meaningful decision.
Trace every operand feeding the decoded result.
Express the operations as a small pure function.
Test the inverse over many inputs.
Look for validation or duplicate fields.
Section: What not to conclude.
❌ “XOR means this is secure encryption.”
✅ XOR can be one reversible step; security depends on a complete, reviewed construction and key handling.
❌ “The value changed, so my offset is wrong.”
✅ The representation or key may have changed.
❌ “One successful decode proves the formula.”
✅ Test several values, sessions, and objects.
❌ “An integrity field is impossible to reproduce.”
✅ First determine whether it is a checksum, a keyed MAC (message authentication code, which needs a secret key), or an authenticated-encryption tag.
The next lesson returns to game text and its byte encoding. For the deeper distinction between checksums, signatures, encryption, and authenticated formats, continue to Chapter 9’s integrity and protection lessons.