Identifying a packer or protector
with PEiD, Detect It Easy and Exeinfo PE

What does a packer or protector identifier do?

A packer or protector identifier tells you what a file was built with and what it is wrapped in, before you spend time in a disassembler. It reads the file on disk without running it, so it is safe to use as the first step of triage.

Most identifiers work from signatures. A signature describes byte patterns, section layouts or entry-point code that a particular compiler, packer or protector leaves behind. When the file matches, the tool prints that name. Newer tools add heuristics, which combine several weaker clues into a conclusion and label it as an inference rather than an exact match.

The result usually lands in one of three groups:

• Compiler or linker: what produced the program, such as a C++ compiler or a .NET runtime.
• Packer: a tool that compresses or encrypts the program and unpacks it in memory at run time.
• Protector: a tool built to resist analysis, which can add anti-debugging checks, import protection and, in the strongest products, code virtualization.

PEiD, Detect It Easy and Exeinfo PE compared

PEiD, Detect It Easy and Exeinfo PE all identify packers, protectors and compilers, but they differ in reach and in how current they are.

The sources are the aldeid PEiD page, the Detect It Easy repository and the Exeinfo PE repository.

PEiD still appears in older tutorials and write-ups, which is why people keep searching for it. Detect It Easy is the more current choice: it covers more formats and is actively developed. Its README also warns that detectiteasy.com is not affiliated with the project; download Detect It Easy only from the project’s own release links.

How to read an identifier’s result

An identifier’s result is a list of labels, and each label is a claim with a strength. Read it top to bottom, and keep exact matches separate from inferences.

1. File type and architecture. Confirm the tool parsed the file as what you expected, such as a 64-bit PE executable. A wrong file type makes every label below it unreliable.
2. Compiler and linker. These tell you what normal code should look like. A compiler label with no packer or protector label fits an unprotected file, but read step 5 before you rely on it.
3. Packer or protector labels. These are the labels that change your plan. Note the exact name.
4. Heuristic labels. In Detect It Easy, anything marked “(Heur)” came from the heuristic engine, not an exact rule. Treat it as a lead to verify.
5. What is missing. No packer label does not prove the file is unpacked. It means no rule matched.

Supporting evidence helps. Lenny Zeltser’s SANS guide to learning malware analysis lists entropy as a check for packed or obfuscated code, and strings, header details and embedded resources are among the static properties worth reading alongside the label. If those signs disagree with the label, trust the disagreement and look closer.

Can a packer detector be wrong?

A packer detector can be wrong in both directions, because it only reports the evidence its rules recognize. Detect It Easy’s own documentation says it is not an antivirus, and that a clean report only means the enabled rules did not find the static evidence they know how to recognize.

The common failure cases:

• Missed protection. A modified, custom or very new protector may match no rule, so the file looks clean.
• Wrong name. A signature written for one product can match a file built with another. Detect It Easy’s heuristic engine can even reject a misleading signature result and replace it with a more precise conclusion.
• Layered files. A file packed twice, or packed and then protected, may show only the outer layer.
• Detection names in antivirus results. When an antivirus engine names a protector, that name identifies the protector, not what the program does. Legitimate protected programs are sometimes reported as false positives.

The practical rule: an identifier result is a starting hypothesis. Confirm it in a disassembler before you plan the work around it.

Packed, protected or virtualized: what the result means next

The label tells you which analysis path comes next, and identifying a protector does not remove it. Identification is triage; recovery is separate work.

• Packed only. The original instructions come back in memory when the program runs, so the usual path is static and dynamic analysis once the code is reachable.
• Protected, without virtualization. Anti-debugging checks, import protection and obfuscation slow the work down, but the code stays in the processor’s own instruction set.
• Virtualized. Protectors such as VMProtect and Themida can convert selected functions into bytecode for their own virtual machine. A decompiler then shows the virtual machine’s interpreter instead of the function. Unpacking alone never removes VMProtect virtualization.

So when an identifier reports VMProtect or Themida, the next question is whether the functions you care about are virtualized or only packed. Our comparison of VMProtect unpacking and devirtualization explains why an unpacked file can still be unreadable, and the protected binary analysis workflow places identification as the first of six stages. For the protectors themselves, see the research on VMProtect and Themida, and our comparison of devirtualization, deobfuscation and unpacking.

Checking a file in your browser

Devirt’s homepage includes a free browser check that runs the same first look without installing a tool. Your file stays on your device and nothing is uploaded. The check identifies file details and protection indicators for PE, ELF and Mach-O files up to 500 MiB. It does not recover code or replace a feasibility assessment.

If the file turns out to be VM-protected and you are authorized to analyze it, the supported protectors page lists what Devirt automates, and VMProtect devirtualization covers the recovery itself. You don’t need to identify the protector before asking for an assessment; intake does that for the exact file.

Questions about packer identification

Is PEiD still worth using?

PEiD still works as a quick first look at older Windows PE files, but its official site has been discontinued. For current files, Detect It Easy covers more formats and is actively developed. Use PEiD when an older tutorial expects it, and confirm its result with a second tool.

What is the difference between a packer and a protector?

A packer is built to compress or encrypt a program, while a protector is built to resist analysis. Packers restore the original code in memory when the program runs. Protectors add defenses such as anti-debugging checks and import protection, and the strongest ones virtualize code so the original instructions never come back.

Does a packer or protector mean a file is malicious?

A packer or protector does not by itself mean a file is malicious. Legitimate software uses commercial protectors too. Themida’s maker notes in its own documentation that malware writers use software protectors to hide from antivirus products, so antivirus companies are stricter with packed files and legitimate programs are sometimes reported as false positives. Whether a file is malicious takes analysis of what it does.

To check a file before planning the work, use the free browser check on the homepage, or create an account and request an assessment for a file you own or are authorized to analyze.