Detect It Easy for static file identification and malware triage

Detect It Easy is a cross-platform static-analysis tool that identifies file types, packers, protectors, and obfuscation across PE, ELF, and Mach-O formats for malware analysts and reverse engineers.

Tool	horsicq/Detect-It-Easy — cross-platform file identification and static inspection tool for Windows, Linux, and MacOS
Category	static binary analysis / file triage
Primary Use	Identifying packers, protectors, compilers, and anomalies in PE, ELF, and Mach-O samples during malware analysis, reverse engineering, and digital forensics
Safe Use	Intended for authorized malware analysis, forensic examination of samples in controlled labs, and defensive research; the tool never executes the files it inspects
Telemetry Note	DiE is a read-only, passive analyst tool — it leaves no footprint on targets; from a defense perspective, it is the instrument used to detect packing, anti-analysis tricks, and masquerading in samples

Detect It Easy, or DiE, from horsicq/Detect-It-Easy positions itself as a cross-platform tool for file identification and static inspection, aimed squarely at malware analysts, cybersecurity experts, and reverse engineers. With over 11,500 stars on GitHub and an MIT license, it has become a fixture in the triage stage of sample analysis. What separates it from a simple file-command replacement is its layered architecture: native format parsers doing the heavy lifting of structural parsing, combined with an extensible DiE-JS analysis layer that supports both compact signatures and multi-stage, stateful algorithms. The project runs on Windows, Linux, and MacOS, which matters for teams that triage PE, ELF, and Mach-O samples from a single workstation.

The README is unusually detailed about the internal design. The native DiE core supplies format parsing, bounded reads, address translation, searching, and disassembly primitives, while the DiE-JS layer builds detection logic on top of those primitives. This split is worth emphasizing: the JavaScript modules are not thin wrappers around native detector calls. They select candidates, maintain state, traverse bounded control flow, validate relationships across structures, reject benign explanations, correlate independent evidence, and reconcile results. That design keeps detection policy reviewable in the database rather than buried in compiled code — a meaningful property for analysts who need to audit or extend detections themselves.

The flagship capability documented in the README is the PE heuristic engine, implemented as __GenericHeuristicAnalysis_By_DosX.7.sg under the db/PE/ directory and maintained by DosX. The README is explicit that this engine is not merely a fallback when signatures fail. When enabled, it runs as a separate higher-level analysis engine that can corroborate, qualify, or reject earlier database results, with every heuristic conclusion visibly marked as such. This separation between signature-derived facts and heuristic findings is good hygiene in a triage tool, because it lets the analyst weigh evidence rather than receiving a single opaque verdict.

A critical safety property appears repeatedly in the documentation: the file is never launched. The engine works exclusively 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, which the README correctly identifies as a common blind spot when protected or suspicious behavior begins inside a library rather than an application. For analysts working in authorized lab environments, this static-only posture reduces the risk profile of triage compared to sandboxed detonation.

The native-code analysis combines cached linear disassembly with bounded traversal of reachable startup code and purpose-built state machines. The README is careful about scope: the engine tracks register, flag, stack, address-provenance, and instruction-boundary facts without pretending to be a sandbox or full CPU emulator. Within those bounds, it claims 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 the irregular control flow typical of polymorphic packers and protectors — and to remain effective across register substitution, neutral padding, equivalent arithmetic forms, and bounded reordering produced by commercial generators and private cryptors.

Managed code gets its own treatment. Rather than treating a .NET assembly as little more than metadata and strings, the engine uses an internal MSIL opcode model to build operand-aware bytecode patterns for indirect calls, function pointers, control-flow transformations, arithmetic mutations, and invalid instruction sequences. It is explicitly not a CLR emulator, but the README's framing suggests it can reason about executable IL patterns, which covers .NET obfuscation techniques like encrypted strings, anti-tamper checks, fake metadata, watermarks, and virtualization-like code.

Much of the engine's value comes from joining evidence across layers, and this is where the documentation is strongest. The engine can relate version-resource identity to Authenticode state, Rich build metadata, runtime model, and detected protection; cross-check file-system extensions; interpret mangled import and export symbols from MSVC, GNU/MinGW, Borland, and Swift; and recognize fingerprints left by dumpers, unpackers, and PE reconstructors. The README stresses that a single scan produces findings from separate analysis paths — no single backend predicate produces the complete report. For an analyst, that means the output reads as a set of independently derived observations that can be individually trusted or discounted.

The catalog of detection passes is extensive. Anti-analysis coverage includes static signs of anti-debugging and anti-dumping aimed at tools like dnSpy, ILSpy, SandBoxie, Cuckoo, Wine, and VMs, plus native checks for direct PEB and debug-register access, Trap Flag tricks, privileged instructions, direct syscalls, and manual hash-based API resolution that leaves no ordinary import trail. Packers, cryptors, SFX archives, RunPE-like behavior, high entropy, embedded PE files, and artifacts left by dumpers such as Scylla, ImpRec, and OllyDump are all covered by a curated database of positional import hashes, section names, and resource signatures. The README frames this correctly: it gives the analyst fair warning when debugging, decompilation, or dumping may be deliberately obstructed.

Triage-oriented passes round out the picture. Format integrity checking examines headers, alignment, relocations, IAT/EAT, CLR metadata, Authenticode placement, AMD64 unwind records, Guard CF metadata, and chained WIN_CERTIFICATE entries, then classifies damage as Uncritical, Degraded, or Critical — a distinction that helps an analyst decide whether a sample is original, damaged, dumped from memory, or partially reconstructed. Debug-leftover detection surfaces build paths and project names from PDB records and Costura.Fody artifacts. Filename handling is PE-aware rather than paranoid: .bpl is named as a Borland Package, .xll as a Microsoft Excel Add-In, and .wcx as a Total Commander Packer Plug-In, avoiding false alarms on legitimate ecosystems.

Provenance and licensing context are treated as analytical signal rather than noise. Compiler, linker, and language inference draws on mangled symbols, Rich records, runtime libraries, section layout, and source-file residue, and can recover build provenance even when no exact compiler signature survives. Licensing and DRM detection — .NET licensing APIs, license managers, SteamStub, and Denuvo markers — is presented with an important caveat: this context can explain why a commercial application is packed or unusually structured without presenting license enforcement itself as malicious behavior. That kind of calibrated judgment is what separates a useful triage assistant from a false-positive generator.

Two operational notes deserve attention. First, the README carries a warning that detectiteasy.com is not affiliated with the project and should not be trusted as a download source — releases come only from the DIE-engine releases page on GitHub, and analysts should heed that given the frequency of typosquatted tool sites. Second, there is a developer API library, die_library, for teams that want to embed DiE's detection capabilities into automated pipelines, and a community translation effort through XTranslation. Both signal an active, maintained project rather than a dormant signature database.

In an authorized workflow, DiE sits at the very front of the analysis chain: it answers what a sample is, what wrapped it, what built it, and what it will try to do to your tooling — before you ever commit to deeper disassembly or controlled detonation. For defenders, its conservative heuristics, explicit evidence reporting, and static-only posture make it a reliable first-pass instrument; for red-team operators, it is equally useful for verifying that a deliverable's packer or compiler fingerprint matches expectations during authorized engagement preparation. Few triage tools document their false-positive controls — independent evidence, architecture gates, bounded scans, and explicit antipatterns — this candidly, and that documentation alone is a good reason to keep DiE in the toolkit.

Official project repository for horsicq/Detect-It-Easy.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.