horsicq/Detect-It-Easy

Detect It Easy (DiE) is a cross-platform tool for file identification and static inspection, used by malware analysts, cybersecurity experts, and reverse engineers. It combines native format parsers with an extensible DiE-JS analysis layer, supporting both compact signatures and multi-stage static analysis across Windows, Linux, and MacOS.

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

Detect It Easy combines format-aware parsing, signature matching, and programmable analysis for malware analysis, reverse engineering, and digital forensics. DiE-JS modules can use parsed structures and low-level inspection primitives to implement bounded algorithms while keeping detection policy reviewable in the database.

• Extensible Analysis Modules: DiE-JS supports compact signatures as well as stateful, format-aware algorithms.
• Cross-Platform Support: Runs on Windows, Linux, and MacOS.
• Conservative Heuristics: Independent evidence, architecture gates, bounded scans, and explicit antipatterns help control false positives.

A signature can tell you what a file resembles. The Generic Heuristic Analysis engine (__GenericHeuristicAnalysis_By_DosX.7.sg) 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.

Heuristic analysis is not merely a fallback used when signatures fail. When enabled, it runs as a separate higher-level analysis engine and can corroborate, qualify, or reject earlier database results while keeping every heuristic conclusion visibly marked.

With heuristic scanning enabled, the PE heuristic engine makes a series of specialized passes over native and managed 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.

The PE heuristic engine's native-code 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.

For managed code, the PE heuristic engine uses an internal MSIL opcode model 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 analysis comes from joining evidence across layers. The engine 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.

A single scan may independently identify a known protector, recognize its characteristic section layout, describe entry-point transformations, recover toolchain or game-engine provenance, and associate licensing metadata. These findings come from separate analysis paths; no single backend predicate produces the complete report.

These are the main passes rather than a complete inventory of every check:

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.

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 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)]

The PE heuristic engine is accompanied by smaller heuristic modules for other everyday file types:

• 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.

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 scanner. Its native core parses file formats and exposes bounded inspection primitives, while DiE-JS modules range from compact signatures to stateful analysis engines. The PE heuristic engine operates at this higher level, combining executable structures, metadata, imports, sections, entry-point code, antipatterns, and bounded byte searches. 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.

DiE database entries are DiE-JS modules ranging from compact signatures to stateful, multi-stage format analyzers. The example below intentionally demonstrates only the result contract of a minimal standalone rule; it is not representative of the PE heuristic engine.

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:

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.

The skeleton above demonstrates syntax and result construction only. 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.

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.

• Native Format Core: Parse executable structures and expose bounded reading, addressing, searching, and disassembly primitives.
• Extensible Analysis Engines: Use the DiE-JS ES5 runtime for compact signatures or stateful, multi-stage detection algorithms.
• Explainable Heuristics: Keep inferred results separate and report the structural, metadata, or instruction-derived evidence behind them.
• Cross-Platform Compatibility: Available for Windows, Linux, and MacOS.
• False-Positive Controls: Combine independent evidence with architecture gates, bounded scans, and explicit benign-case exclusions.

• 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

  

See the BUILD.md for detailed instructions.

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

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.

• 🦠 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.

👋 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

• ⭐️ Thanks to DosX

• ⭐️ Thanks to PELock