Run and Dump: The Ceiling of Every Static Defense

Strings, imports, tracing, debuggers, and memory have all been circling one idea. Here it is, stated plainly. If an attacker can run your protected code, they can let it decode its own secrets and read the results. This is run-and-dump, and it is the ceiling on every software-only obfuscator that has ever existed.

The whole attack in one sentence

The attacker runs the program in an environment they control, waits for it to do the work of decoding, deriving, and assembling whatever it needs, and then reads that materialized result from memory. They do not break your encoding. They make your program break it for them, which it must do to function, and then they simply watch.

It is like handing someone a locked box along with a robot whose only job is to open that box on command. The thief does not pick the lock. They press the robot's button, the box springs open exactly as designed, and they take what is inside. Your program is that robot: to be useful it has to open its own secrets, and once it does, whoever is watching gets to look.

This is why the attack is a ceiling and not merely a strong technique. It does not target any weakness in your specific obfuscation. It targets the one thing all runnable code has in common, which is that it runs, and running means materializing real values. You can make the materialized form ugly, brief, and partial, but you cannot make a functioning program never materialize what it functions on. Any product claiming to defeat run-and-dump outright is claiming to run code that never actually runs, which is a contradiction, not a feature.

Watch a dump happen

The demonstration below walks through a simulated run-and-dump on a generic teaching sample. The file hides its strings perfectly from a static reader, and you get to watch them surface in memory the moment the code runs. Nothing here executes real code; every value shown is canned display data. But the sequence is exactly what a real instrumented sandbox records.

Read back what happened. No cipher was defeated. The program decoded its own strings because it had to use them, and the attacker read the decoded values as they appeared. Every static layer you could have added would have hidden those strings from the file and none of them would have changed a single frame of that dump, because the dump reads the runtime, not the file.

You do not beat it, you price it

Accepting the ceiling is not surrender. It redirects the defense from an impossible goal, making observation impossible, to an achievable one, making each observation expensive and non-reusable. The tools that do this are different in kind from the static layers.

• Per-build uniqueness: every output differs, so an attack developed against one dump does not replay against the next. This is the single most valuable dynamic property, because it denies amortization.
• Integrity and anti-tamper: edited output fails quietly with wrong results instead of a clean, guiding crash, wasting the attacker's time rather than teaching them.
• Server-held keys: keep part of the payload off the machine so the attacker must be online, authenticated, and traceable to run it at all, which makes abuse revocable.
• Virtualization: force the dump to be of VM state and custom operands rather than clean source, so reconstructing readable logic from the trace is real, per-build work.

The economics

The right frame for run-and-dump is economic, and it comes down to one ratio: the cost of attacking the next output divided by the cost of attacking the first. If your builds are all identical, that ratio is nearly zero, because the attacker pays full price once and reuses the result forever. The attack is fully amortized, and you have effectively protected nothing after the first crack. If every build is unique, the ratio approaches one, because the tooling and knowledge from cracking one output barely help with the next, and the attacker pays close to full price every single time.

This reframes what good protection even is. It is not the height of the wall against the first attacker, which run-and-dump guarantees you cannot make infinite. It is the slope of the cost curve across many attacks. A defense that makes the first crack take a week but the second take a minute is weak, because the value stolen is the whole family of outputs. A defense that makes every crack take a day, forever, is strong, even though any single day is affordable, because nothing ever gets cheaper. Per-build variance, not per-family cleverness, is what bends that curve, which is why it is the property worth paying for.

Run-and-dump is the honest ceiling: code that runs can be watched running, and a running program must materialize what it uses. You cannot prevent the first recovery, so the goal is to make every recovery slow, specific to one build, and useless against the next. Anyone selling unbreakable is selling a promise the nature of execution does not allow.

Frequently asked questions