Every software protector's website says roughly the same things: virtualization, anti-debugging, anti-tamper, packing. The words won't tell you which product fits your application — testing will. This is a vendor-neutral checklist for evaluating any protector, including ours: what to test hands-on, what to ask, and the red flags that should end a conversation early.
Start from your threat model, not the feature list
Before comparing products, write down three things:
- What you're protecting. A license check? A proprietary algorithm? File integrity? Each points at different layers — license checks want virtualization and string encryption; whole-file integrity wants a packer with anti-tamper.
- Who attacks it. Casual key-sharers, hobbyist crackers, or funded competitors? The bar — and the budget — differ by an order of magnitude.
- What a crack costs you. That number caps what protection is worth and how much runtime overhead you can accept for it.
With that on paper, feature tables become answerable questions instead of marketing.
Test with a demo — on your real application
Never evaluate a protector on the vendor's sample binary; samples are chosen to protect cleanly. Use a real release build of your program, and check:
- It still works. Exercise your app's full surface — file I/O, licensing, plugins, updater. Protection changes how code is stored and run; it must never change what it computes.
- Overhead is acceptable. Measure startup time and the hot paths you care about, protected vs. unprotected. Virtualized code is slower by design — what matters is whether your chosen functions stay within your budget.
- Size impact is acceptable. Compare file sizes before and after; a protector adds a runtime, and compression may offset it.
- Clean machines like it. Test on a fresh Windows machine or VM — not your dev box — and scan the protected build with the antivirus products your customers use. False positives are a real operational cost of any packer-style protection.
- Your toolchain fits. Does it handle your compiler's output, your build flags, your signing step? (Protect first, sign last — a protector that can't slot in before signing breaks your pipeline.)
A vendor that gives you no way to try before buying is asking you to skip all five. Don't.
Strength checks anyone can run
You don't need to be a reverse engineer to sanity-check the protection itself:
- Strings scan. Dump the protected binary's strings. Your license messages, key names and URLs should be gone — if they survive, the fastest attack path is still open.
- Disassembler look. Open the protected build in any free disassembler. Where your protected function used to be, you should find unreadable VM dispatch — not your logic with a new coat of paint.
- Patch test. Change one byte of the protected file with a hex editor. With anti-tamper enabled, it should refuse to run.
- Debugger test. Attach a debugger to the running protected app. With anti-debugging enabled, it should notice.
Questions to ask the vendor
- "What happens when public unpackers catch up?" Protection is an arms race; you're buying the vendor's response cadence as much as today's build. Ask how updates respond to public tooling, and whether each protected build differs from the last.
- "What happens when my update period lapses?" The honest answer is that your tool and your shipped binaries keep working, and you only lose new versions. Anything that stops working when you stop paying is a dependency, not a purchase.
- "Can I automate it?" A CLI that runs in CI is the difference between every release shipping protected and protection quietly skipped under deadline pressure.
- "What does it NOT protect?" Every serious vendor has a clear answer — file formats, languages, attack classes out of scope. A vendor with no stated limits hasn't thought about them or won't tell you.
- "Who answers support?" Protection issues are build-breaking issues. You want a developer on the other end, and a stated response time.
Red flags
- "Uncrackable", "military-grade", "100% secure". No such thing exists; a vendor who says otherwise is either naive about their own field or comfortable misleading you. The honest pitch is that protection raises the attacker's cost.
- No demo, no trial protection run, "contact sales to see it".
- A dead changelog. A protector that hasn't shipped updates in years is a solved puzzle with public solutions.
- No documentation of the layers. If the vendor can't explain what virtualization, packing and anti-debug each do and cost, they can't help you configure them either.
- Vague platform claims. Native x64, .NET, Java and mobile are different protection problems. A tool that claims all of them equally usually does one well.
Practical factors that end up deciding
After strength, most choices come down to fit: does the protector target your binary type (native x64 .exe/.dll vs. managed runtimes), does it integrate with your build, is the license model sane (one-time purchase with an update period beats per-app or per-build metering for most indie vendors), and are renewals priced so staying protected doesn't hurt. Run the numbers over three years, not one.
Running this checklist on Dhaedalida
We built this page to be usable against anyone, so here is our own scorecard. Dhaedalida protects native 64-bit Windows .exe and .dll files — nothing else. The demo is free, feature-limited and never expires, so the test-drive above works on your own build (it covers VM virtualization; the packer and anti-analysis layers are in the paid editions). Every purchase includes 12 months of updates, and everything keeps working if you don't renew. Each protected build gets its own generated VM. And our position on strength is stated plainly on the home page: nothing is unbreakable — protection raises the attacker's cost, and updates reset their progress. For a hands-on picture of the workflow, see protecting a C++ application step by step.