You ship a paid Windows program, and at some point a copy of it lands in front of someone with a disassembler and a free evening. This guide is about making that evening unproductive. It covers how an .exe actually gets cracked, which defenses genuinely raise the attacker's cost, which popular ones don't, and a checklist you can run before every release.
Know the attack before you buy the defense
Most cracks of unprotected software follow the same short loop:
- Scan the strings. A plain
stringsdump of your binary usually contains "License invalid", "Trial expired" or the name of your key file — a signpost pointing straight at the check. (Why this leak exists: why your binary's strings betray it.) - Follow the reference. The disassembler lists every place that string is used. One of them is your license routine.
- Flip a branch. The check almost always ends in a conditional jump — valid or not valid. Patching that one instruction turns every key into a valid key. The full playbook has variations (API breakpoints, loader patches), but the jump-flip is the classic ending.
Notice what this means: the attacker never needs to understand your program. They need to find one branch in it. Protection, therefore, is mostly about making that finding and patching expensive.
The honest premise: raise the cost, don't chase "uncrackable"
No protection makes a program impossible to crack — anyone selling "uncrackable" is selling something else. Given enough skill and time, any binary that runs on an attacker's machine can be analyzed. What a serious protector does is change the economics: an attack that took an evening now takes weeks of specialist effort, and when you ship your next protected update, much of that effort has to be repeated. For most paid software, that is the whole game — pirates move on to easier targets, and paying customers stay the cheaper option.
Layer 1: make the critical code unreadable
Code virtualization is the strongest tool available for this. The protector compiles your chosen functions into bytecode for a custom virtual machine that is generated for that build, and the original x64 instructions are gone. Where the attacker expected a readable comparison and a branch, they find VM dispatch code — and before they can even look for your license check, they must first reverse-engineer an entire unfamiliar CPU. How code virtualization works covers the mechanics.
You don't virtualize everything — virtualized code runs slower, so you spend it on the functions whose secrecy pays your bills: license validation, key derivation, the core of your proprietary algorithm. A handful of well-chosen functions is normal.
Layer 2: close the string leak
String encryption removes the signposts. Your literals — error messages, registry keys, file names — are stored as ciphertext and only decrypted at run time, inside protected code. The strings-scan shortcut in step 1 above simply stops working: the fastest route into your binary is closed before the attacker has opened a disassembler.
Layer 3: wrap the file and defend the runtime
Virtualization protects chosen functions; the packer protects the file as a whole and carries the runtime defenses. A protector's packer compresses and encrypts the program on disk, hides its imports (the Windows API calls that would otherwise map out your program's behavior), and unpacks in memory at launch — with anti-debugging and anti-tamper watching while it runs. Debuggers get detected, patched files refuse to start, and memory dumps stop yielding a clean copy. See what an exe packer actually does and anti-debugging on Windows for what each layer contributes.
The layers matter because they cover each other. A packer alone can be unpacked; readable code then falls to the standard loop. Virtualization alone leaves your strings and imports in the clear. Together, the attacker has to defeat the shell, the runtime defenses and a custom CPU — each with the others interfering.
What doesn't work on its own
- Hand-rolled tricks around the license check. XOR-ing your key string, checking
IsDebuggerPresent, duplicating the check in two places — these are the first things every tutorial teaches attackers to bypass, and they age badly as your code evolves. - Compression-only packing. Generic packers without runtime defenses are undone by off-the-shelf unpackers, often in seconds.
- Secrecy of method. Hoping nobody looks is not a layer. Assume the attacker has your binary, forever, on hardware you don't control.
- Legal text. Your EULA matters for many reasons, but it has never stopped a keygen.
The pre-release checklist
- Pick the functions that matter. License validation, key handling, core algorithms. Few and deliberate beats many and vague.
- Virtualize them, with string encryption on. The unreadable code and the missing signposts should land in the same build.
- Pack the file with anti-debug and anti-tamper enabled. Test anti-VM and similar aggressive options carefully — they also affect legitimate users in virtual desktops.
- Protect first, sign last. Protection rewrites the file, so code-sign the final protected binary, never the other way around.
- Verify like an attacker. Run a strings scan and open the result in a disassembler — your literals and logic should be gone:
# Unprotected build — the check is signposted: > strings app.exe | findstr /i licen Enter license key License invalid or expired license.dat # Protected build — nothing to follow: > strings app.protected.exe | findstr /i licen >
- Make it a build step, and re-protect every release. Each protected build gets a fresh VM, so work done cracking the last version doesn't transfer. A protector that offers a CLI can run in your pipeline so no release ships bare.
Doing it in practice
Everything above is tool-agnostic — it is simply what a layered defense of a native Windows binary looks like. If you want to see the concrete steps with a real protector, protecting a C++ application step by step walks the same checklist through Dhaedalida's GUI and CLI: mark the functions in source, virtualize, encrypt strings, pack, verify. The features page maps each layer in this guide to the option that provides it.