Detect It Easy (DiE) is a powerful tool for file type identification, popular among malware analysts, cybersecurity experts, and reverse engineers worldwide. Supporting both signature-based and heuristic analysis, DiE enables efficient file inspections across a broad range of platforms, including Windows, Linux, and MacOS. Its adaptable, script-driven detection architecture makes it one of the most versatile tools in the field, with a comprehensive list of supported OS images.
🚀 Getting started
[!WARNING]
detectiteasy.com is not affiliated with the Detect It Easy project or its official website. Do not trust it as an official source or use it to download DiE. Use only the release links provided in this repository.
💡 Why use Detect It Easy?
Detect It Easy’s flexible signature system and scripting capabilities make it an essential tool for malware analysis and digital forensics. With traditional static analyzers often limited in scope and prone to false positives, DiE’s customizable design enables precise integration of new detection logic, ensuring reliable results across diverse file types.
Key advantages:
- Flexible Signature Management: Easily create, modify, and optimize detection scripts (rules).
- Cross-Platform Support: Runs on Windows, Linux, and MacOS.
- Conservative Heuristics: Independent evidence, architecture gates, bounded scans, and explicit antipatterns help control false positives.
🧠 Heuristic engine
PE analysis that goes beyond a signature match
A signature can tell you what a file resembles. The Generic Heuristic Analysis engine goes further: it reports concrete structural and behavioral anomalies together with the evidence behind them. The PE heuristic engine is created and maintained by DosX.
With heuristic scanning enabled, DiE makes a series of specialized passes over native and managed PE images. The file is never launched. Instead, the engine works with headers, data directories, sections, imports, exports, resources, .NET metadata, bytecode, overlays, debug records, and reachable startup code rooted at the entry point. The same coverage extends to DLL initialization code, closing a common blind spot when protected or suspicious behavior begins inside a library rather than an application. This makes it useful both when an exact signature is known and when a sample has been modified enough to evade ordinary identification.
Native analysis combines cached linear disassembly with bounded traversal of reachable startup code and purpose-built state machines. It tracks the register, flag, stack, address-provenance, and instruction-boundary facts required by each rule without pretending to be a sandbox or full CPU emulator. This allows DiE to expose opaque and degenerate branches, synthetic and indirect transfers, overlapping instruction streams, position-independent and self-modifying stubs, bitstream unpackers, anti-analysis probes, and irregular control flow used by polymorphic packers and protectors. The checks remain effective across register substitution, neutral padding, equivalent arithmetic forms, and bounded reordering of independent instructions commonly produced by commercial generators and private cryptors.
Managed code receives instruction-aware treatment of its own. An internal MSIL opcode model is used to build operand-aware bytecode patterns for indirect calls and function pointers, control-flow transformations, arithmetic mutations, invalid instruction sequences, and other forms of obfuscation. It is not a CLR emulator, but it allows the engine to reason about executable IL patterns instead of treating a managed assembly as little more than metadata and strings.
Much of the engine's strength comes from joining evidence across layers. It can relate version-resource identity to Authenticode state, Rich build metadata, runtime model, and detected protection; cross-check the file-system extension; interpret mangled import and export symbols used by MSVC, GNU/MinGW, Borland, and Swift; and recognize fingerprints left by dumpers, unpackers, and PE reconstructors. Native checks are architecture-aware across x86/x64 and the ARM family, while security-mitigation flags are checked as meaningful combinations rather than isolated bits.
These are the main passes rather than a complete inventory of every check:
Code, protection, and evasion
(click) 🧩 .NET obfuscation
- Operand-aware MSIL patterns, modified managed entry points, odd CLR constructors and sections, indirect calls, control-flow tricks, integer confusion, encrypted strings, invalid opcodes, anti-tamper, fake metadata, watermarks, and virtualization-like code.
(click) 🕵️ .NET anti-analysis
- Static signs of anti-debugging and anti-dumping, plus checks aimed at dnSpy, ILSpy, SandBoxie, Cuckoo, Wine, VMs, and some security products.
- This gives the analyst fair warning when ordinary debugging, decompilation, or dumping may be deliberately obstructed.
(click) 🛡️ Native anti-analysis
- State-aware inspection of startup code exposes direct
PEB and debug-register access, Trap Flag tricks, low-level system and virtual-environment probes, privileged instructions, direct syscalls, and other attempts to detect or disrupt analysis before the main program begins.
- The engine also recognizes manual, hash-based API resolution that avoids an ordinary import trail, including variants that do not depend on one fixed hash constant.
(click) 🧱 Native anomalies
- Architecture-aware inspection follows reachable control flow around the entry point and recognizes synthetic or indirect transfers, overlapping instructions,
Call/Pop and FPU-based position recovery, self-modifying stubs, bitstream unpackers, opaque branches, and irregular polymorphic control flow.
- Validated x86/x64 stack pivots and concealed
RET-based transfers are covered as part of the same startup-flow analysis.
- Section permissions, declared code size, TLS startup, and the actual placement of executable code are cross-checked with
IAT/EAT, image flags, linker values, and other structural signals.
(click) 📦 Packers and protectors
- Packers, cryptors, SFX archives,
RunPE-like behavior, compression and crypto clues, overlays, high entropy, embedded PE files, and damaged unpacking results.
- A large curated database covers positional import hashes, section and resource names, managed-object sets, and artifacts left by dumpers and reconstructors such as Scylla, ImpRec, and OllyDump.
(click) 🔑 Licensing / DRM
- .NET licensing APIs and attributes, license managers, activation strings, SteamStub, Denuvo markers, and similar traces.
- This context can explain why a commercial application is packed or unusually structured without presenting license enforcement itself as malicious behavior.
Structure, provenance, and triage
(click) 🩺 Format integrity
- Headers, entry points, alignment, relocations,
IAT/EAT/resources, CLR metadata and version strings, and Authenticode placement are checked for damage or tampering.
- Deeper consistency checks cover overlapping sections and data-directory mappings, AMD64 unwind records, Guard CF metadata, and chained
WIN_CERTIFICATE entries.
- Instead of merely calling a file broken, DiE points to the affected structures—useful when deciding whether a sample is original, damaged, dumped from memory, or only partially reconstructed.
(click) 🧾 Debug leftovers
- Debug sections, exported symbols, .NET Native data, absolute, portable, or embedded PDB records, and Costura.Fody artifacts.
- These leftovers can expose build paths and project names, clarify how the image was produced, and give reverse engineers a useful starting point even in an otherwise opaque release build.
(click) ☣️ Malware-related patterns
- Correlations between imports, strings, bytecode, opcodes, metadata, resources, payload markers, and PE structure.
- Identity checks connect version fields, signing state, build metadata, and protection results to expose masquerading, fake system files, and suspicious builds.
(click) 🛠️ Toolchain / platform
- Compiler, linker, and language inference from mangled symbols, Rich records, runtime libraries, section layout, and source-file residue, plus Windows-facing markers such as AppContainer and Game Definition File data.
- Together, these clues can recover useful build provenance even when no exact compiler signature survives.
(click) 🏷️ Filename anomalies
- PE-aware classification instead of a blanket warning for every unusual suffix.
- AutoCAD, Total Commander, 3ds Max, Microsoft Excel, Borland/Delphi, CPython, Node.js, MATLAB, and other ecosystems deliberately use PE modules with specialized extensions.
- DiE names known roles directly—for example,
.bpl as Borland Package, .xll as Microsoft Excel Add-In, .arx as AutoCAD ObjectARX Module, or .wcx as Total Commander Packer Plug-In—while missing, custom, or misleading extensions, application images carrying a .dll suffix, and DLL images presented as .exe files are reported separately.
This is not a black-box malware score. DiE produces a practical evidence map for triage: what probably built the file, whether the image looks original, damaged, dumped, or reconstructed, which protection or DRM may explain its structure, and which artifacts deserve attention next. A heuristic result is a lead, not automatic proof of malicious intent. Verbose scan messages keep general, managed-code, and instruction-derived evidence visibly separated as [HEUR/Any], [HEUR/.NET], and [HEUR/EMU]. Use --heuristicscan together with --verbose to see the fullest report.
Malware clues without pretending to be an antivirus
DiE is not an antivirus, and the PE heuristic engine is not designed to declare a file safe. It provides no real-time protection or disinfection, and a clean report only means that the enabled rules did not find the static evidence they know how to recognize. Reputation services, an antivirus, dynamic analysis, and manual reverse engineering still answer different questions.
What DiE can do is expose a surprisingly broad range of threat-related clues while the file is still on disk. The examples below are only a small part of the actual rule set, not a complete catalogue. The heuristic engine evolves faster than this README and new families, markers, and cross-checks are added regularly.
- Remote-access trojans and backdoors, including generic RAT patterns and families such as NjRAT, AsyncRAT, NanoCore, Orcus, Gh0st RAT, DarkComet, NetWire, Remcos, BitRAT, and many others.
- Stealers and spyware, including generic stealer scoring, Mars Stealer, Echelon Stealer, StormKitty, MAX Spyware, and other family or behavior indicators.
- Ransomware, lockers, and destructive malware, with checks for WannaCry, UX-Locker, Liberium WinLocker, Amp WinLocker, Olympic Destroyer, and related threats.
- File-infecting viruses. Dedicated static infection checks currently cover Ramnit, Neshta, Slugin, Win9X.CIH, Win9X.Dupator, Parite, and Polip, with the list continuing to grow.
- Targeted and unusual threats, including markers associated with Slingshot APT, Equation Group tooling, RAT injectors, maliciously generated assemblies, fake or infected system files, and similar cases.
- Hidden payloads and delivery techniques, from Base64-encoded executables and RunPE-like behavior to PE files concealed in resources, sections, or overlays. A built-in known-plaintext attack (KPA) pass derives repeating XOR/XNOR, ADD/SUB, or reverse-subtraction keys up to 20 bytes from invariant PE-header fields, then validates the decoded image structurally instead of trusting a plain
MZ match. Other payload and build anomalies are covered as well.
These are explainable static detections built from entry-point code, import fingerprints, metadata, strings, resources, section structure, and other relationships inside the image. They are valuable leads, but they are not a promise of complete malware-family coverage: modified samples may evade a rule, and an unusual clean program may share part of a suspicious pattern.
Heuristic results stay visible
Heuristic findings are never silently mixed into ordinary signature matches. Every result produced by the heuristic layer is kept separate and marked with (Heur), so it is always clear which conclusion came from an exact rule and which one was inferred from a combination of evidence.
The engine does more than append extra lines. In a few deliberate cases it can reject a misleading result from the main signature database and replace it with a more precise heuristic conclusion. Programming-language detection is a typical example: a compiler signature may suggest C or C++, while stronger structural and runtime evidence identifies Rust. The replacement still carries (Heur) and never passes itself off as an exact signature match. The same reconciliation mechanism is used to suppress known fake packer, protector, and dongle signatures left behind by obfuscators.
A protected .NET sample may produce a report like this:
PE32
Operation system: Windows (95) [I386, 32-bit, GUI]
Linker: Microsoft Linker (6.0)
Compiler: VB.NET
Language: VB.NET
Library: .NET Framework (CLR 2.0.50727)
Protector: .NET Reactor (4.8-4.9) [Anti-ILDASM]
(Heur) Cryptor: Generic [Assembly invoke + RSACryptoServiceProvider + RunPE + Section #2 (".rsrc") compressed + Section #2 (".rsrc") has wrong size + High entropy]
(Heur) Protection: Obfuscation [Modified managed EP + Anti-ILDASM + Bad namings + Fake .cctor name + Math mutations]
For a native executable, signatures and heuristic evidence can complement each other while remaining visibly distinct:
PE32
Operation system: Windows (95) [I386, 32-bit, GUI]
Linker: Microsoft Linker (6.0)
Compiler: Microsoft Visual C/C++ (12.00.8168) [C++/std]
(Heur) Language: Rust
Protector: HyperTech Crackproof
(Heur) Protection: Generic [Strange sections + Stack-push address near EP + Rdtsc near EP + Section #4 ("naN") has RWX + EP-section #4 ("naN") zero padding + IAT directory empty]
(Heur) Packer: Generic [EntryPoint + Pushal at EP + Last section EP + Imports like UPX (v0.59-0.93) + Sections like fake UPX + Section #0 ("") compressed + High entropy]
(Heur) Debug data: Contains [Embedded PDB (release)]
Smaller heuristics for everyday files
PE is the largest heuristic module, but it is not the only one shipped with DiE:
- The JavaScript heuristic recognizes common JavaScript variants, distinguishes text from bytecode, and spots minified or compiled-looking code without blindly matching content inside ordinary strings.
- The file-extension heuristic provides a broad fallback catalogue of formats and programming languages, cross-checking the extension against whether the file is actually textual or binary.
- The Batch-script heuristic catches UTF-16LE obfuscation and non-textual content hidden inside BAT and CMD files.
🧰 Several engines under one GUI
The desktop version of DiE is not limited to its own scanning engine. It brings several independent analyzers into the same interface, each with a different rule model and a different idea of what constitutes a useful match. On a difficult or unfamiliar file, running them in turn can expose details that one database alone would miss. Their output is complementary rather than a vote: three engines repeating a weak signature do not turn it into proof.
- Detect It Easy (DiE) is the primary, format-aware engine. Its DiE-JS rules can combine executable structures, metadata, imports, sections, entry-point code, antipatterns, and bounded byte searches, while the PE heuristic layer adds broader anomaly and behavioral analysis. The signature database can also recover application context from recognizable .NET dependencies spanning data access, logging and background jobs, HTTP and browser automation, content tooling, cryptography, testing, and more.
- Nauz File Detector (NFD) provides an independent view of linkers, compilers, tools, and packers. It has no user-rule workflow comparable to DiE-JS or YARA, its heuristic logic is much simpler, and its database is updated relatively infrequently. That makes it useful as a second opinion, not as a replacement for the main engine.
- YARA adds direct rule-based matching with textual, binary, and logical conditions. It is a de facto standard for malware researchers and threat hunters, and DiE ships its own basic and enhanced YARA-side heuristics. These provide a lighter cross-check of suspicious PE traits rather than duplicating the full DiE heuristic engine.
- PEiD is included for compatibility with the classic "old-school" detector and its
userdb ecosystem. The bundled database preserves a large amount of historical material imported from the original PEiD rules. It remains useful for reproducing legacy detections, but many signatures are noisy by modern standards and can produce convincing-looking false positives, so its results should be treated as secondary evidence.
🧩 Anatomy of a detection rule
DiE rules are small DiE-JS modules. A typical standalone rule declares the kind of result it produces, inspects the current file through the format API, fills optional result fields, and returns the engine-built result:
// Detect It Easy: detection rule file
// Author: Your Name <[email protected]>
// Optional reference URL
meta("compiler", "Example Compiler");
function detect() {
if (PE.isSectionNamePresent(".lz-algo")) {
sVersion = "1.0";
sOptions = "LZMA";
bDetected = true;
}
sLang = "C/C++";
return result();
}
The result variables are supplied by the DiE engine and must not be re
Detect It Easy (DiE) is a cross-platform tool that identifies file types and inspects executables (PE, ELF, Mach-O) for malware analysts, reverse engineers, and cybersecurity researchers, combining signature-based detection with a deep heuristic engine.