Software vendors ship “protected” binaries: packers, virtualisation obfuscators, anti-debug checks, white-box crypto sketches. Marketing language sometimes implies that the program’s secrets are safe. Under standard threat models, that implication is false. This essay separates cost imposition from confidentiality.
Threat model first#
Define the adversary before the tool:
- Remote attacker — no code execution on the client; network-facing surface only
- Malicious client — full control of the machine that runs the binary
- Insiders / supply chain — access before shipping
Executable protection almost always targets (2). For (2), the attacker has CPU, memory, and patience. Anything the CPU must decrypt to execute, the attacker can eventually observe.
What protection can do#
Honest goals include:
- Delay reverse engineering enough to outlast a business need (short-lived keys, seasonal content)
- Deter casual copying and script-kiddie patches
- Detect some tampering and refuse to run (integrity checks)
- Bind execution to environment signals (licenses, secure elements)—with caveats
These are economic and operational goods. They are real. They are not mathematical secrecy for general program logic.
What protection cannot do#
If \(P\) is a program that the client must run, and \(S\) is a secret embedded such that correct execution reveals \(S\)’s functional effect, then a sufficiently patient adversary with a debugger can recover behaviour equivalent to \(S\). Formally, white-box attackers model the implementation as an oracle they can inspect.
Obfuscation may hide how; it does not remove that the behaviour is available.
| Claim | Status under malicious client |
|---|---|
| “Logic cannot be recovered” | Generally false |
| “Recovery is expensive” | Often true |
| “Secrets never in RAM” | False if CPU uses them |
| “DRM is cryptographically solved” | False in general |
Design implications#
- Put real secrets on servers or hardware you control, not only in client binaries.
- Use protection as friction, not as a root of trust.
- Measure against skilled reverse engineers, not only against
strings. - Plan for failure: assume client-side checks will be bypassed.
Good: server holds master key; client holds capability token
Bad: master key encrypted in .rodata with fixed XOR "for safety"Closing position#
Executable protection is a legitimate engineering tool for raising analysis cost. It becomes harmful when it substitutes for sound architecture. The sentence to keep is simple: you cannot hide from the computer that must run your code.
Notes and references#
Demonstration essay. Specific commercial packers and attacks change; treat product claims skeptically and consult current reverse-engineering literature for concrete techniques.