Drop a binary below — .exe, .dll, .sys, .so, .o, .elf, .dylib, .bin or any unrecognized blob — and this page will hash it, fingerprint the format and the compiler, dump its headers and sections, list its imports, parse the Authenticode chain, detect packers and anomalies, and scan it with a built-in ClamAV-style rule set.
It's a single static page running pefile, pyelftools, asn1crypto and ppdeep via Pyodide (CPython on WebAssembly). First load is ~10 MB; after that, analysis is local and fast.
your file never leaves this browser tab
This page performs deep static triage of arbitrary binary files entirely
inside your browser. It identifies the file format (Windows PE, Linux
ELF, Apple Mach-O, Java class, WebAssembly, etc.), computes cryptographic
and fuzzy hashes (MD5, SHA-1, SHA-256, SHA-512, ssdeep, plus PE-specific
imphash and authentihash), dumps the headers,
enumerates sections and imports and exports and resources, fingerprints
the compiler that produced the binary, flags known packers and structural
anomalies, parses Authenticode digital signatures and certificate chains,
and runs a built-in ClamAV-style rule engine over the raw bytes to
surface known malware families, suspicious imports, URLs, IPs,
anti-analysis strings, embedded executables and LOLBin usage.
Uploading a sample to a third-party service can mean handing your
incident-response evidence — or your customer's internal binary — to
an unknown operator. This page ships a full CPython runtime
(Pyodide),
pefile, pyelftools and asn1crypto into your tab on first load — every
byte of the analysis then happens locally. There is no upload
endpoint. Your binary is read with FileReader,
handed to the WASM Python interpreter, and never sent across the wire.
Windows PE (.exe, .dll, .sys, .ocx, .cpl, .efi) — both PE32 and PE32+ across x86, x64, ARM, ARM64 and IA64; Linux ELF (.so, .o, .elf, core dumps) across x86, x64, ARM, AArch64, MIPS, PowerPC and RISC-V; Apple Mach-O 32/64-bit and fat universal binaries; Java class files; WebAssembly modules; plus generic identification for ZIP/JAR/APK, gzip, bzip2, xz and other common containers. If the file doesn't match a known format, you still get hashes, entropy and a full signature scan.
Is the binary uploaded anywhere? No. The page is static HTML, JavaScript and WebAssembly. There is no backend. After the Pyodide runtime and Python packages are cached, you can disconnect from the network and the tool still works.
What compilers can it detect?
For PE files, the Rich header is parsed and matched against a table of
Microsoft compiler product IDs covering Visual Studio 6.0 through
Visual Studio 2022, including MASM, the linker, the resource compiler
and CVTRES. For ELF files, the .comment section is read
for GCC and Clang version strings. Go is detected via
.go.buildinfo and embedded version markers. Rust is
detected via panic strings and rustc markers. .NET
binaries are detected via the CLR header in the PE optional header
data directories. Delphi binaries are flagged from Borland/Embarcadero
resource strings.
What does imphash mean?
It's the MD5 of a normalised list of the binary's imported DLL/function
pairs — the classic Mandiant fingerprint. Two PE files with the same
imphash were typically built from the same source with the same
toolchain and same import table layout, which makes it useful for
clustering malware samples. It does not identify the file's
contents — only its import surface.
What does authentihash mean?
It's the hash Microsoft uses for Authenticode — a SHA-256 (or SHA-1)
over the PE bytes excluding the checksum field, the security
data directory entry, and the certificate table itself. Two PE files
with the same authentihash are byte-for-byte identical except for
their signatures. Removing the signature does not change the
authentihash.
What packers and protectors does it find? Section-name fingerprints for UPX, ASPack, FSG, MPRESS, PECompact, Petite, NsPack, Themida, VMProtect, Enigma, Y0da Protector, MEW, PEBundle, kkrunchy, Crinkler, Neolite and others; plus entropy analysis to flag custom/unknown packers; plus detection of writable-and- executable sections, TLS callbacks (often used by anti-debug stubs), large overlay data, and suspicious section names that often indicate runtime unpacking or shellcode storage.
How is the digital signature verified? The Authenticode security directory is extracted from the PE, the embedded PKCS#7 SignedData blob is parsed with asn1crypto, and the certificate chain — subject, issuer, serial, validity window, signature and public-key algorithms — is presented. Counter-signatures and timestamps are extracted when present. Note that cryptographic verification of the signature against the file's authentihash is not performed in the browser; presence, parseability and chain structure of the signature are reported, not validity.
What does the signature scanner check?
A built-in rule set in the ClamAV naming style
(Win.Tool.Mimikatz, Win.Loader.CobaltStrike-Beacon,
Win.Coinminer.XMRig, …) plus generic rules for embedded
PEs, anti-VM/anti-debug markers, crypto constants, suspicious API
imports, Windows LOLBin invocations (powershell, mshta, certutil,
bitsadmin, regsvr32, schtasks, vssadmin, wbadmin), embedded URLs and
IPs, and registry persistence keys. Each rule emits a finding with a
severity (info / low / medium / high / critical), family tag, and
human description.
Why not just run YARA? YARA's official Python binding is a C extension wrapping libyara — it doesn't run cleanly under Pyodide. Rather than ship a partial port, this tool implements a focused built-in rule engine in pure Python. If you need full YARA, run it locally against the file once you've triaged it here.