Options and levels

Every protection the Obfuscator offers, grouped by what it defends against. Most have a level from Light to Maximum; the rest are on or off.

Open it now:Obfuscator, Protect

How to read the list

In Protect the options are listed by section. A slider option runs from Off through Light, Balanced and Heavy to Maximum, and each level includes everything the lower one does, then more. Under the slider, the line for the chosen level says what it adds. A toggle is on or off. A field takes text or an icon.

Anti-debug

Refuse debugger attach. Detect it. Punish it.

Option	What it does	Take care
Attach brick wall	Debuggers cannot latch on in the first place.
Sabotage on attach	If something does manage to attach, sabotage its state.
Scattered debugger checks	Hundreds of small debugger checks woven throughout your code - every one has to be found and removed to bypass.
Behavioural detection	Detect debuggers by the subtle traces they leave - timing anomalies, page faults, memory access patterns.
Trap the debugger's exceptions	Poison access-violation, single-step and guard-page hits so debuggers stall.
Starve hardware breakpoints	Occupy the 4 hardware breakpoint slots with junk so the debugger cannot set its own.
Break debugger UIs	Throw exceptions inside x64dbg and ScyllaHide that they can't recover from.
Thread hiding	Detection threads run hidden from the debugger.

Anti-inject

Hostile modules cannot load. Injected code gets spotted.

Option	What it does	Take care
Anti-inject baseline	Reject foreign DLLs and manual maps.
Mitigation policy stack	Force Windows' own security features so the operating system itself refuses foreign modules and code.	Higher levels can break plugin systems and injected overlays. Verify with your target Windows versions.
Manual-map detection	Spot modules loaded outside the normal loader path.
Loader hijack defense	Refuse module loads and remote threads from anywhere but Windows' own System32 folder.
Detect inline hooks	Hash critical API bodies. Detect anyone patching in.
Hardware shadow stack	Modern Intel and AMD CPUs keep a protected copy of return addresses. Injected shellcode can't redirect them.	Requires a modern CPU with shadow stack support (Intel Tiger Lake / AMD Zen 3 or newer). Does nothing on older hardware.
Asynchronous injection defense	Reject queued procedure calls that don't come from our own threads. Blocks one of the sneakiest injection tricks.

Anti-analysis

IDA, Ghidra, x64dbg and other static tools fail before they start.

Option	What it does	Take care
Disassembler denial	Overlapping and mis-encoded instructions cause reversing tools to miscount and produce wrong disassembly.
IDA Pro annihilation	IDA and Hex-Rays crash, hang or produce garbage on your binary.
Symbolic-execution denial	Poison paths that Angr and Triton would explore - solvers time out.
API protection brick wall	Zero imports, direct syscalls, indirect gadgets - reversers can't trace API calls.
Keep CRT imports visible	Leave the C-runtime imports alone - improves crash-report symbol quality.
Aggressive techniques (may trip EDR)	Loader-list poisoning, decoy memory regions, dumper-tool fingerprinting, timing channels. Bulletproof, but some EDRs flag them.	These are opt-in. Test with your target EDR / AV before shipping - some may flag as suspicious.
Tool-specific responses	Detect which reversing tool is attached and respond differently - IDA, x64dbg, Cheat Engine, sandboxes.

Anti-sandbox

Detect Cuckoo, AnyRun, VMware, Hyper-V - refuse to run under analysis.

Option	What it does	Take care
Anti-VM	Detect running inside VMware, VirtualBox, Hyper-V, TTD.
Anti-sandbox fingerprinting	Recognise Cuckoo, AnyRun, Joe, HybridAnalysis, VMRay by their fingerprints.

Memory

What lives in memory looks nothing like what shipped on disk. Dumps come back useless.

Option	What it does	Take care
Anti-dump baseline	Refuse memory dumps. Kill on process suspend.
Wipe PE headers in memory	Once you're running, the DOS + PE headers vanish from memory. Dumps come back unusable.
Encrypt code at rest	Your .text section is encrypted on disk. It decrypts one page at a time as you run.
Encrypt data at rest	Sensitive heap and thread-local data is re-encrypted between reads.
Guard-page tripwires	Read a canary page and the process kills itself before you get the dump.
Stack spoofing	Call stacks look like clean Windows internals, not your code.

Code transform

The bytes reversers see are not the bytes you shipped.

Option	What it does	Take care
Instruction mutation	Every build produces different bytes for the same source. Boundary-aware disassembly makes every level safe.
Control-flow flattening	Turn every function into a state machine. Reversers can't follow the graph.
Pre-entry TLS fortress	Detection runs BEFORE main. Fail = the program never starts.
String encryption	Strings are materialised at their call site, then scrubbed. `strings` returns nothing useful.
Import table obfuscation	APIs are resolved by hash at runtime - the import table looks empty.

Virtualization

Critical functions run on a per-build custom CPU. Nobody has your VM specification.

Option	What it does	Take care
Virtualization coverage	Lift x64 code to a per-build custom VM. Nobody has your VM specification.
Per-function VM permutation	Every lifted function gets a different opcode encoding and register layout.
VM handler hardening	Encrypt the VM handlers, sign the bytecode, scatter the dispatcher. Reverse-engineering it takes weeks.
VM end-game	Cascading, encrypted handlers with control-flow integrity. The last word.
Inter-VM dispatch chaining	VM handlers call other VM handlers. No return to native between them.
VM instruction-set coverage	Which x64 extensions the VM knows how to lift. More extensions = more code can be virtualised.
Destroy the original function	After lifting, the original code region is overwritten with decoy bytes.

Integrity

A single patched byte trips a fatal check within milliseconds.

Option	What it does	Take care
Kernel tamper detection	Detect kernel-mode attackers - kernel-mode debuggers, rootkits, hypervisor-based tools. When the OS itself is compromised, we know.	A few of these channels can false-positive inside Windows sandbox / isolated-Chromium environments.
Code hash chain	A chained hash of your .text section. A single patched byte is caught within milliseconds.	Auto-disables the VM garbage collector to preserve trampoline integrity - expected.
Binary fingerprint binding	Runtime state depends on the exact bytes of your binary. Re-signing or repacking invalidates the whole chain.
Sentinel-load probe	Load a decoy module. If someone answers, the process is being manipulated.
Verified system calls	Every Windows API call is triple-checked against a signed table. Fake syscalls get spotted immediately.
Scattered tamper flags	Tamper checks are spread across the memory. There is no single "cheat detected" flag to patch out.
Hardware-bound encryption	Encryption keys derive from the actual CPU features of the running machine. Copies to a different machine don't decrypt.	Binds the build to specific hardware traits. If your users run wildly different hardware, use Balanced or lower.
Brutal Pack mitigations	Ship the full Brutal Pack 1 mitigation stack - thread-hide, PE binding, sentinel probe, mitigation policy stack.	Sets a stronger baseline. If VM lift is also on, ProhibitDynamicCode is auto-excluded so the VM runtime keeps working (unless VM encrypted-handlers are on, which have their own opt-out).
Chained execution proof	Every function call updates a rolling signature. Skip any check and the signature breaks - the binary knows.

Tamper response

When something trips, choose exactly what happens - silent, loud, or catastrophic.

Option	What it does	Take care
Kill on detection	When something trips, terminate the process. This is the safe default.
Stolen-API response	Instead of killing, degrade - APIs return silent failures. Attackers waste hours.
Nanomites	Critical instructions become debug traps. A debugger unpacks them but a real run doesn't.	Some antivirus vendors flag nanomite techniques. Verify with your target AV.
Kill message	What Windows shows the user when tamper is detected.
Decoy work in response paths	How much filler code goes in the tamper-response path. Higher = harder to isolate the real response.
How to kill on tamper	What Windows does the moment tamper is detected. Silent-corrupt is default and hardest to notice.
Redundant kill methods	How many independent kill mechanisms fire in parallel. Debuggers cannot single-step around all of them.
Custom response per attack type	Different behaviour for debug vs dump vs hook vs sandbox - instead of one global response.	Fills in per-attack messages below to override the global kill message.
Per-attack messages	A separate message for each kind of detection: debugger, attach attempt, memory dump, injection, inline hook, integrity failure, sandbox, virtual machine. They replace the global kill message.

Packaging

Product name, icon, version. Compression. What Windows shows the user.

Option	What it does	Take care
Static packer	Compress the binary. Smaller distribution, extra hop for unpackers.	Adds a decompressor stub. Some antivirus vendors flag packers generically - verify with your target AV.
PE header cleanup	Strip symbols, rename sections, wipe reloc and rich headers.
Symbol poison path	Fake PDB path embedded in the binary. Sends reversers to a rabbit hole.
Replace application icon	Upload an .ico to replace the icon Windows Explorer shows.
Message box icon	Which system icon shows on tamper message boxes.
Made-with-Atlas tag	Embed a small "Protected by Atlas" tag in a non-visible section. Helps us track adoption.
Deterministic build seed	Reuse the same seed to reproduce a byte-identical build. Off = fresh random seed each run.
Embed build manifest	Append a signed manifest of which protections were applied. Useful for audit trails.
Product name, Company name, File description, Product version, Original filename, Legal copyright, Embedded watermark, Message box title	Text fields written into the program's version information: what Windows shows in file properties and the process list.

Was this page useful?