Detect-It-Easy

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

• 💎 Download release/beta
• 🧪 DiE API Library (for Developers)
• 📋 Changelog
• 💬 Contribute to Translations

[!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 <you@example.com>

// 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 redeclared:

Field	Purpose
bDetected	Marks the rule as matched. This is the field a normal rule must set when its conditions succeed.
sName	Overrides the default name from meta() when the exact variant is only known at runtime.
sVersion	Version, build, generation, or another short version-like value.
sOptions	Architecture, mode, modification state, or other useful qualifiers.
sLang	Adds a programming-language result. It is intentionally uncommon, used mostly by compiler rules, and conventionally assigned at the end of detect(), immediately before the blank line preceding return result();.
sType	Rare runtime override for the result category; reserve it for multi-purpose modules.

meta("type", "name") supplies the normal result category and default name. Optional shared helpers are loaded with includeScript("module") between meta() and detect(). Simple rules finish with return result();; keep one empty line immediately before it.

Before submitting a rule or script module, follow the complete DiE-JS code-formatting standard.

Before writing a real rule

The skeleton above is only the wrapper. DiE determines the file class first and then runs the rules from the matching directory, so format-specific logic belongs beside that format: PE rules use db/PE, ELF rules use db/ELF, and so on. db/Binary is intended for unclassified or genuinely format-independent data, not as a shortcut for code that belongs to a more specific parser.

The scripting API is documented in help. Start with the global functions, the common Binary API, and the signature-pattern reference, then use the class reference for the format being inspected: PE, .NET metadata, ELF, Mach-O, or another document from the same directory.

DiE byte signatures are a small pattern language embedded inside JavaScript strings. Hex bytes match literally, .. and ?? are byte wildcards, text is written inside single quotes, and $/# forms describe relative or address-dependent values. They are not regular expressions. The complete syntax and examples live in the signature reference.

Rules can inspect the scan mode with isHeuristicScan(), isDeepScan(), isAggressiveScan(), and isVerbose(). These calls reflect options selected by the user; they do not make an unnecessarily expensive rule acceptable. Even optional code must use cheap structural gates and antipatterns before bounded signature searches.

Repository placement also carries a quality meaning. db is the reviewed main database. db_extra contains rules that were not approved for the main database and is explicitly not recommended as a quality or performance reference. dbs_min is generated output and must not be edited by hand.

Finally, a rule that works on one private sample is not yet maintainable coverage. The contribution requirements require reproducible samples, expected DiE output, independently checkable sources, and relevant false-positive material. The same document explains the performance requirements that are enforced during review.

📄 Supported file types

Detect It Easy supports a wide range of executable and archive types, including:

• PE (Portable Executable format for Windows)
• ELF (Executable and Linkable Format for Linux)
• APK (Android Application Package)
• IPA (iOS Application Package)
• JAR (Java Archive)
• ZIP (Compressed archives)
• ISO9660 (Optical media format)
• DEX (Dalvik Executable for Android)
• MS-DOS (MS-DOS executable files)
• COM (Simple executable format for DOS)
• LE/LX (Linear Executable for OS/2)
• MACH (Mach-O files for MacOS)
• NPM (JavaScript packages)
• Amiga (Executable format for Amiga computers)
• Binary (Other unclassified files)

And that's not all... The list is expanding as the tool is updated

Unknown formats undergo heuristic analysis, providing identification for both known and unrecognized files.

🔑 Key features

• Flexible Signature Management: Define or modify detection rules.
• Scripted Detection: Use a JavaScript-like scripting language (DiE-JS ES5 runtime) for custom detection algorithms.
• Cross-Platform Compatibility: Available for Windows, Linux, and MacOS.
• Reduced False Positives: Combines signature and heuristic scanning for accuracy.

📥 Installation

📦 Install via package managers

• Windows:

  • Chocolatey
  • Microsoft Store

• Linux:

  • Parrot OS: Package name detect-it-easy
  • Arch Linux: AUR package detect-it-easy-git
  • openSUSE: OBS
  • REMnux: Malware analysis distribution

  

[!NOTE] Use Detect It Easy bot via Telegram to quickly check files: @detectiteasy_bot

⚙️ Build from source

See the BUILD.md for detailed instructions.

🐳 Docker installation

Run DiE in a Docker container:

git clone --recursive https://github.com/horsicq/Detect-It-Easy
cd Detect-It-Easy/
docker build . -t horsicq:diec

🖥️ Usage

Detect It Easy offers three versions:

• die - Graphical interface.
• diec - Command-line version for batch processing.
• diel - Lightweight GUI version. (scanner only)

For detailed usage, refer to the RUN.md.

🔎 Example use cases

• 🦠 Malware Analysis: Identify file types, packers, or protections. Heuristic engine detects multiple malware and file virus families.
• 🛡 Security Audits: Determine executable potential security risks.
• 🔎 Software Forensics: Inspect software components and validate compliance.

💬 Our community

👋 Hello! / Привет! Welcome to the Detect It Easy community!

Have questions, ideas, or just want to chat? Here's where to find us:

• GitHub Discussions: Start a conversation in Discussions
• GitHub Issues: Report bugs or request features via Issues

🏆 Special thanks

• ⭐️ Thanks to DosX

• ⭐️ Thanks to PELock

🤝 Thanks to all contributors

---