How to using the hex inspector for malware file triage
- Step 1Drop the quarantined sample (no execution) — Drag the file into the inspector. It is read into an ArrayBuffer and sliced — never executed. The file must fit your plan's size limit (10 MB Free, 100 MB Pro, 500 MB Pro+Media, 2 GB Developer); for oversized droppers, carve the first chunk with a desktop tool first.
- Step 2Read offset 0 — what family is it? —
4D 5A(MZ) → Windows PE.7F 45 4C 46→ ELF.CF FA ED FE/FE ED FA CF→ Mach-O.23 21(#!) → script.50 4B 03 04(PK..) → archive/dropper container. The ASCII sidebar shows the text-like signatures plainly. - Step 3For a PE, follow e_lfanew at 0x3C — Locate offset
0x3C(row00000030, 13th byte). Read the 4 bytes there as a little-endian DWORD — that value is the file offset of the PE header. On Free's 256 B window you'll usually reach it; on Pro/Developer you can then read the PE signature it points to. - Step 4Verify the PE signature — Navigate (via the offset column) to the
e_lfanewtarget and confirm50 45 00 00(PE..). The two bytes after it are the machine type (4C 01= x86,64 86= x64, little-endian). If thee_lfanewoffset is past your tier window, note it and switch to a desktop tool to read the PE header itself. - Step 5Assess packing from the sidebar — Between the headers, normal binaries have readable runs (imports, section names like
.text,.rdata) and null padding. If you instead see a wall of.with no readable structure, suspect a packer or crypto. Don't conclude from the dump alone — quantify next. - Step 6Confirm with entropy and the type verdict — Run the same sample through entropy-analyzer; high-entropy chunks (>7.5 bits/byte) across the body corroborate packing. Run magic-byte-validator to catch extension lies (e.g. a
.jpgthat's really a PE). Only then hand off to a sandbox or disassembler.
First-row signatures you triage most
What the inspector shows at offset 0 for the file families that dominate malware triage. ASCII column is what the sidebar renders.
| Family | Magic bytes (hex) | ASCII sidebar | Triage note |
|---|---|---|---|
| Windows PE / EXE / DLL | 4D 5A | MZ | Follow e_lfanew at 0x3C to the PE header |
| ELF | 7F 45 4C 46 | .ELF | Byte 4: 01=32-bit, 02=64-bit; byte 5: endianness |
| Mach-O (64-bit) | CF FA ED FE | .... | Little-endian magic; FAT binaries start CA FE BA BE |
| Script (shebang) | 23 21 | #! | Read the sidebar for the interpreter path (/bin/sh) |
| ZIP / JAR / OOXML dropper | 50 4B 03 04 | PK.. | Could be a JAR, a macro-laden docx, or a staged payload |
| Disguised PE in image extension | 4D 5A (file named .jpg/.png) | MZ | Classic disguise — confirm with magic-byte-validator |
Reading the PE header in the dump
The offsets a PE walk touches, and where each sits in the inspector. e_lfanew is a little-endian DWORD — reverse the byte order to get the target offset.
| Field | Offset | How to read it in the dump |
|---|---|---|
| MZ signature | 0x00 | First two bytes: 4D 5A |
| e_lfanew (PE header pointer) | 0x3C | Row 00000030, byte 13; read 4 bytes little-endian (e.g. 80 00 00 00 → 0x80) |
| PE signature | value of e_lfanew | 50 45 00 00 (PE..) at the offset e_lfanew points to |
| Machine type | e_lfanew + 4 | 4C 01 = x86 (0x014C), 64 86 = x64 (0x8664), little-endian |
| Number of sections | e_lfanew + 6 | WORD, little-endian — unusually high counts can hint at oddly-built binaries |
What the inspector can and can't do for triage
Scope check so you don't over-trust a header read. The inspector is a first-pass signal, not a verdict engine.
| Triage question | Inspector answers it? | If not, use |
|---|---|---|
| What family / format is this? | Yes — read offset 0 | — |
| Does the extension lie? | Partially (you compare by eye) | magic-byte-validator |
| Is it packed / encrypted? | Hint only (wall of dots) | entropy-analyzer |
| What's the PE header past 8 KB? | No — window caps at 8 KB | CFF Explorer / radare2 / 010 Editor |
| What does the code do? | No — raw bytes only | Ghidra / IDA Pro disassembler |
| Has this sample changed vs a known copy? | No — single file, read-only | file-integrity-monitor |
Cookbook
Real triage moves on sanitised samples. Dumps show the inspector's on-screen layout (offset · hex · ASCII). No sample is ever executed.
PE walk: MZ → e_lfanew → PE signature
The canonical first move on a Windows sample. Confirm MZ, read the little-endian DWORD at 0x3C, then verify the PE.. signature it points to. This three-step walk weeds out fake or truncated PEs in seconds.
00000000 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 MZ.............. 00000030 ... 80 00 00 00 ............ 00000080 50 45 00 00 64 86 06 00 ... PE..d........... Read it: 4D 5A → MZ stub confirmed 0x3C: 80 00 00 00 → e_lfanew = 0x00000080 (little-endian) @0x80: 50 45 00 00 → 'PE..' signature confirmed next: 64 86 → machine 0x8664 = x64
Renamed PE hiding behind a .png extension
An email attachment named photo.png should open with the PNG signature. The inspector shows MZ at offset 0 instead — it's a Windows executable. The disguise is obvious in the sidebar.
File on disk: photo.png
00000000 4D 5A 90 00 03 00 00 00 04 00 00 00 ... MZ..........
Expected for PNG: 89 50 4E 47 0D 0A 1A 0A ('.PNG....')
Actual: 4D 5A ('MZ') → it's a PE, not a PNG
Confirm the lie with magic-byte-validator, then treat as
hostile: do not rename-and-open.Packed sample: the wall of dots
A UPX-or-similar packed binary still starts with MZ, but the body where strings and section names should be is almost entirely non-printable — a wall of . in the sidebar. That's the visual packing tell.
00000000 4D 5A 90 00 ... MZ......
...
00000200 3A 9F C4 1E 7B 02 D5 88 EE 41 BC 09 F7 2A 6D 13 :...{....A...*m.
00000210 C0 88 1F A4 5E D9 33 7C 0B E2 95 4A B6 18 F0 27 ....^.3|...J...'
Almost no readable runs in the sidebar across the body.
Next: entropy-analyzer → expect >7.5 bits/byte chunks,
confirming packing/encryption.Script payload: shebang in the sidebar
Not all malware is binary. A dropper script reveals its interpreter right in the ASCII sidebar — the #! shebang and path are readable text at offset 0.
00000000 23 21 2F 62 69 6E 2F 73 68 0A 65 78 70 6F 72 74 #!/bin/sh.export Read it: 23 21 → '#!' shebang /bin/sh → interpreter, plainly readable in the sidebar Verdict: shell script, not a compiled binary. Read further rows for the first commands; carve and analyse as text.
e_lfanew points past the window — know your limit
On a heavily-padded or oddly-built PE, e_lfanew can point beyond your tier's byte window. The inspector reads the pointer but can't show the target. Recognise this and switch tools rather than mis-reading.
Free tier, 256 B window: 0x3C: 00 04 00 00 → e_lfanew = 0x00000400 (1024) But the window only reaches 0x100 (256). The PE signature at 0x400 is NOT in view. Options: - Upgrade to Developer (8 KB) to reach 0x400 - Or open in CFF Explorer / radare2 for the full PE
Edge cases and what actually happens
e_lfanew points beyond your tier window
Out of windowIf the PE header offset stored at 0x3C is larger than your byte window (256 B Free / 1 KB Pro / 8 KB Developer), the inspector shows the pointer but not the PE signature it targets. Upgrade for a bigger window or read the full PE in CFF Explorer, radare2, or 010 Editor.
Dropper / installer larger than the size limit
RejectedThe inspector reads the whole file into memory and enforces the plan size limit (10 MB Free → 2 GB Developer). Large installers and self-extracting droppers may exceed it and get rejected. Carve the first chunk with dd/head on an analysis VM, then inspect the carved header.
Wall of dots is suggestive, not proof
InconclusiveA non-printable-heavy header is a packing hint, not a verdict — compressed media and legitimately encrypted files look the same in the sidebar. Always corroborate with entropy-analyzer; only high entropy across the body supports a packing conclusion.
Signature is mid-file (SFX / appended payload)
Out of viewSelf-extracting archives and appended payloads place the real signature far from offset 0. The inspector always reads from offset 0, so it shows the wrapper (often an MZ stub), not the embedded payload. Seek to the embedded offset in a desktop hex editor.
No execution, ever
By designThe inspector only reads bytes — it never executes the file and has no write path. This makes it safe to point at live, quarantined malware for a header read. It is not a sandbox, though: dynamic behaviour still requires a controlled detonation environment.
Anti-analysis: fake or padded MZ stub
CautionSome samples craft a misleading DOS stub or pad the header to push real structures past a quick reader's view. Read the e_lfanew pointer carefully (little-endian) and verify the PE.. signature actually exists at the target — don't assume a valid-looking MZ means a valid PE.
Compiler / Rich Header detail needs a parser
LimitedMSVC PE binaries carry a Rich Header between the DOS stub and the PE header; its bytes are visible in the dump but the inspector doesn't decode it. To extract Rich Header hashes for clustering, use a dedicated PE parser (pefile, CFF Explorer) — the inspector just shows you it's there.
Copy gives a flat hex string for your notes
ExpectedThe Copy button yields a continuous lowercase hex string (no offsets/ASCII), which is convenient for pasting into a case note or a hex-pattern search but is not xxd format. Re-space it if your detection tooling expects grouped bytes.
Frequently asked questions
Is it safe to drop live malware into the inspector?
For a header read, yes — the inspector only reads bytes into memory and renders them. It never executes the file and has no write path, so it can't run or alter the sample. It is not a substitute for a sandbox when you need dynamic behaviour.
How do I find the PE header offset?
Read the 4 bytes at offset 0x3C (row 00000030, 13th byte) as a little-endian DWORD — that's e_lfanew, the file offset of the PE signature. Use the inspector's offset column to navigate there and confirm 50 45 00 00 (PE..).
Can I read the whole PE header here?
Only the part that fits your window: 256 B (Free), 1 KB (Pro / Pro+Media), or 8 KB (Developer). If e_lfanew points beyond the window, switch to CFF Explorer, radare2, or 010 Editor to read the full optional header and section table.
How do I tell if a sample is packed?
Visually, a header body full of dots (non-printable bytes) with no readable section names or strings is a packing tell. Confirm quantitatively with entropy-analyzer: high-entropy chunks (>7.5 bits/byte) across the body indicate packing or encryption.
Does this replace a disassembler?
No. The inspector shows raw bytes and ASCII for triage. Decoding machine instructions and understanding behaviour is the job of Ghidra or IDA Pro. Use hex inspection to classify and prioritise; use a disassembler for deep analysis.
Can it detect a double-extension disguise like photo.jpg.exe?
You can see the real signature in the dump (e.g. MZ for a PE), which exposes the lie. For an automatic verdict that compares the claimed extension against the detected magic bytes, run magic-byte-validator, which is built to catch exactly this.
Why can't I open this big dropper?
The inspector loads the entire file into memory and enforces your plan's size limit (10 MB Free → 2 GB Developer). Oversized files are rejected. Carve the first kilobytes on an analysis VM (head -c 8192 sample > head.bin) and inspect the carved header instead.
Can I identify the compiler from the header?
Sometimes by eye — MSVC PEs carry a Rich Header between the DOS stub and the PE header, visible in the dump, while GCC/MinGW builds lack it. The inspector shows the bytes but doesn't decode the Rich Header; use a PE parser to extract clustering hashes.
Does inspecting the file send it to a server?
No. The on-page tool reads the file locally with FileReader and renders in your browser — important when handling samples you must not exfiltrate. Nothing about the sample is uploaded.
What's the full non-executing triage chain?
Hex Header Inspector (read the signature and PE walk) → magic-byte-validator (extension-vs-content) → entropy-analyzer (packing score). Optionally multi-hash-fingerprinter to compute hashes for IOC sharing. Only then detonate in a sandbox.
Can I bookmark or annotate offsets?
No — the inspector renders raw offset/hex/ASCII with no bookmarks, no field labels, and no tooltips. For annotated analysis (bookmarks, named fields, templates), use HxD bookmarks or 010 Editor templates on the desktop.
How do I compute a hash of the sample for sharing?
The inspector doesn't hash files — use multi-hash-fingerprinter to compute MD5, SHA-1, SHA-256, and SHA-512 digests in one pass for IOC reports and threat-intel sharing.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.