Understanding Packers and Crypters in Malware and Their Removal Methods

hendryadrian.com

hendryadrian.com

Protectors are specialized tools malware authors use to make analysis harder. At a high level, packers combine one or more files into a single executable—often adding compression—so a disassembler or static inspector sees an opaque binary rather than readable code. This is common for native PE binaries and for script-based malware that must include interpreters or nonstandard libraries. Crypters go further by encrypting code and data, applying runtime decryption, obfuscating control flow, and even virtualizing code so it executes as pseudo-instructions interpreted by a custom VM. In practice, these protections are layered: an SFX installer might deliver a compressed payload, which a crypter then decrypts and injects into a host process at runtime.

Detecting packers and crypters starts with simple static checks. Inspecting PE section names often reveals telltale markers—UPX produces UPX0 and UPX1 sections, MPRESS creates MPRESS1/MPRESS2, VMProtect commonly adds a .vmp0 section, and Themida can add .themida or .taggant sections. Entropy measurements are another red flag: unpacked executables usually show entropy around 5–6.5, while packed or encrypted files push entropy above 7. Sparse or unusual imports are informative too; a tiny import table with functions like LoadLibraryA and GetProcAddress suggests the binary resolves libraries and functions at runtime rather than linking them statically, and the presence of VirtualProtect hints that memory pages may be changed to executable during unpacking. Tools such as DiE (Detect It Easy) rapidly surface many of these artifacts, and ANY.RUN’s Static Discovering view can display sections, entropy and imports for samples run in its interactive sandbox.

Two general unpacking strategies are used: static unpacking, which tries to recover code without executing it, and dynamic unpacking, which runs the sample in a controlled environment and captures the unpacked or decrypted payload from memory. Static methods are safer but often fail against advanced protections; dynamic methods require sandboxes, debuggers and memory dumps, and they are more effective against crypters that decrypt only in memory. ANY.RUN’s interactive sandbox can automate memory dumps for processes of interest, letting analysts download and analyze decrypted payloads locally, or click the DMP button beside a process to retrieve dumps directly.

Many real-world packers and installers have straightforward unpacking workflows. Self-extracting (SFX) archives are typically opened with 7zip or WinRAR to reveal contained files and extraction parameters. MSI packages can sometimes be extracted with msiexec /a, but when that fails utilities like LessMSI reliably list and extract embedded files. Nullsoft installers and many SFX-based Electron installers usually unpack cleanly with 7zip; Electron bundles often contain an app.asar archive that can be extracted using the npm asar tooling (for example via npx @electron/asar extract app.asar extracted), exposing Node.js packages and initial scripts like index.js. InnoSetup archives require specialized extractors such as innoextract or innounp, which recover files, registry entries and the original install script, including the [Run] section that shows what will execute after installation.

UPX deserves special mention because it is widespread and simple to reverse. UPX-marked binaries (look for UPX0/UPX1 in sections) are often statically reversible using the same UPX utility. Running upx -d <file> typically restores a decompressed PE that disassemblers like Ghidra can analyze correctly; failing to remove UPX often causes import and decompiler errors. When working inside a sandbox, upload a matching upx.exe and run the decompression command in a controlled console session so the sample doesn’t auto-execute.

AutoIt-wrapped executables are commonly used as crypters or packaging wrappers. Identification can be as simple as checking the file description in the PE’s version info, and sandbox detectors (including ANY.RUN) often tag AutoIt sessions automatically. Once detected, tools such as AutoIt-Ripper can extract and restore the embedded script (script.au3) and any associated files, enabling direct inspection of the script, which may still require deobfuscation and will often include VM/AV detection checks and embedded unpackers like standalone 7zip binaries.

.NET protectors such as NetReactor, SmartAssembly and other obfuscators add another layer of complexity: they rename identifiers, introduce many delegates that resolve strings at runtime, apply virtualization and sometimes load assemblies directly into memory. For NetReactor-packed samples, NetReactorSlayer combined with dnSpy is an effective workflow: open the sample in dnSpy to inspect type references and namespaces, use NetReactorSlayer to deobfuscate and remove virtualization where possible, and then re-open the _Slayed result in dnSpy. NetReactorSlayer can correct entry points, extract embedded libraries (for example MessagePack.dll), and simplify class names and control flow to make static analysis feasible. For SmartAssembly and other protectors, de4dot (or the improved de4dot-cex) is a powerful deobfuscator that replaces delegate-based GetString calls with actual literals and reveals decrypted strings, greatly improving readability in DiE and dnSpy.

When protectors deliver payloads only at runtime—such as a crypter that decrypts a .NET payload and injects it into another process—dynamic memory extraction is necessary. With dnSpy you can attach a debugger to a running process (use dnSpy x86 for 32-bit or dnSpy x64 for 64-bit processes), pause execution, view Modules, and choose Open Module from Memory to capture an in-memory module. Saving that module and processing it through NetReactorSlayer or de4dot often yields a usable, deobfuscated assembly that can be further debugged or executed in isolation for behavioral analysis.

Commercial packers like Themida and VMProtect add virtualization and mutation that protect code at runtime. Static unpacking rarely succeeds against these products, but analysts often extract partially restored code from memory dumps after execution. For in-depth techniques and case studies on these protectors, refer to focused analyses of VMProtect and Themida, as they require specialized dynamic approaches beyond simple static decryption.

In summary, successful analysis of packed or encrypted malware combines reliable detection signals (section names, entropy, imports), the correct choice of static or dynamic unpacking approach, and a toolkit tailored to the protector and platform: DiE and ANY.RUN for quick identification and sandboxed memory dumps; 7zip, WinRAR, LessMSI, innoextract, innounp and npm/asar for common installers and archives; UPX for easy decompression; AutoIt-Ripper for AutoIt bundles; and dnSpy, NetReactorSlayer and de4dot for deobfuscating .NET protectors. Using these methods together lets analysts recover payloads, reveal runtime behavior, and continue deeper investigation with standard reverse engineering tools.

Read more: https://any.run/cybersecurity-blog/cybersecurity-blog/packers-and-crypters-in-malware/