Choosing a Protection Strategy

This is the last lesson of the Academy, and it does not introduce a new technique. It assembles everything you already know into a method you can actually follow the next time you have code to protect. The whole course has been building toward a single skill: making protection decisions deliberately, priced honestly, instead of buying adjectives from a feature list. Here is the procedure, step by step.

Step 1: name the attacker and the prize

Start where Level 8 started. Who actually attacks this, and what do they gain? Match the tier to the reward. A niche personal tool draws casual copiers; a commercial product with a resale market draws skilled and occasionally professional attention. Every later decision depends on this one, because a defense is only ever strong against a specific attacker doing a specific thing.

Step 2: decide what must ship at all

Before you obfuscate anything, ask the question from the server-side lesson: does this secret have to ship? Anything you can keep on a server the attacker cannot reach escapes the run-and-dump ceiling entirely and should live there if you can afford the connectivity and latency. Only what genuinely must run on the client is a candidate for obfuscation at all. This step alone prevents the most expensive mistake in the field: hiding, behind heavy obfuscation, a secret that never needed to ship.

Step 3: cover every attack step, and nothing else

For the code that must ship, list your attacker's workflow from Level 5 and assign each step a layer whose job is to make it expensive: strings, names, control flow, sensitive core. Then apply the discipline from the layering lesson in reverse: any layer that maps to no step is decoration you should drop, because it costs performance and correctness risk for nothing. The dead-code view below is a reminder that removing what does no work is itself a legitimate, behaviour-preserving transformation.

Step 4: deny amortization

Whatever layers you chose, vary them per build in the details an attack would key on, so that breaking one output does not transfer for free to the next. This is the single decision that separates a defense the attacker pays for once from one they pay for every time. Judge the whole scheme by the ratio from the economics lesson: the cost of the second break over the cost of the first.

Step 5: verify correctness, always

None of this matters if the protected program does not work. A layer that breaks your code has infinite cost and zero benefit, so test protected output exactly as hard as unprotected output, across every environment it will run in. Correctness is not a step you do after choosing a strategy. It is the precondition that makes any strategy worth having.

Try the accounting yourself. The challenge below models the decision from step 1 and step 4: a defense is only worth it when it pushes the attack cost above the attacker's reward, and if it does not, more variance or a server boundary is where you look next.

Step 6: claim only what you can defend

Finally, describe what you built the way a reverse engineer would test it. Not undumpable, not unbreakable, because those are counterexamples waiting to happen. Say what is true: static extraction is defeated, runtime recovery is slow and expensive, and the cost is paid per build. That claim survives contact with an attacker, and it is the only kind worth making.

The whole method in one breath: name the attacker, keep off the client what you can, cover every attack step and nothing extra, vary each build to deny amortization, verify correctness without exception, and claim only raised cost. Do that and you are engineering protection instead of buying adjectives. That is the entire point of this Academy, and you now hold it.

Frequently asked questions