PE Analyzer & Disassembler — Inspect Windows Executables in Your Browser
This online PE analyzer parses Windows Portable Executable (PE / PE+) files — .exe, .dll, .sys, drivers, and packed samples — and disassembles executable sections into x86, x86-64, or ARM64 assembly. Use it as an EXE analyzer, DLL import table viewer, PE header parser, string extractor, hex viewer, and malware-triage scratchpad before opening a heavier reverse-engineering suite. Everything runs in your browser using a vendored copy of Capstone compiled to WebAssembly. Your binary is never uploaded to a server.
What is a PE file?
The Portable Executable format is Microsoft's container for code and data on Windows. It traces its lineage to COFF (Common Object File Format), and Microsoft documents the modern layout in the PE/COFF specification. A PE file starts with a legacy DOS MZ stub (so old MS-DOS systems can print "This program cannot be run in DOS mode."), followed by the modern PE signature, the COFF File Header, an Optional Header (mandatory despite the name), Data Directories, and a table of Sections holding the actual code and data.
PE header walkthrough
- DOS Header — 64-byte legacy block. The two-byte
e_magic field is "MZ" (Mark Zbikowski's initials). The e_lfanew field at offset 0x3C points to the NT Headers.
- NT Headers — Begins with the 4-byte
"PE\0\0" signature.
- File Header (IMAGE_FILE_HEADER) — Machine type (0x8664 = AMD64, 0x14C = i386, 0xAA64 = ARM64), number of sections, timestamp, characteristics flags.
- Optional Header — Linker version, entry-point RVA, image base, section alignment, subsystem (GUI / CUI / native), DLL characteristics (DEP, ASLR, CFG), and the Data Directories array.
- Data Directories — 16 (RVA, Size) pairs pointing into the file: Export, Import, Resource, Exception, Certificate, Base Relocation, Debug, TLS, Load Config, IAT, Delay Import, COM Descriptor (.NET), etc.
- Section Table — One IMAGE_SECTION_HEADER per section: name (
.text, .rdata, .data, etc.), virtual address, virtual size, raw offset, raw size, characteristics (execute / read / write).
- Sections — The actual bytes.
.text is typically the only executable section; .rdata holds constants and the Import Address Table; .data holds initialised globals; .rsrc holds resources.
RVA (Relative Virtual Address) is an offset from the image base when loaded in memory. Converting RVA → file offset requires walking the section table to find which section's virtual range contains the RVA, then translating relative to that section's raw data pointer.
Typical first-pass questions are: is this PE32 or PE32+? Which machine type is declared? Does the entry point land in .text or a suspicious custom section? Are imports resolved by name or ordinal? Do the DLL characteristics advertise ASLR, DEP, high-entropy VA, or Control Flow Guard? Are any sections both writable and executable, unusually high entropy, or much larger virtually than on disk?
Example triage workflow
- Load the sample and confirm the file signature, machine type, subsystem, image base, entry point RVA, section count, and compile timestamp.
- Inspect sections for names such as
.text, .rdata, .data, .rsrc, UPX0, or random-looking labels, then compare raw size, virtual size, execute/write flags, and entropy.
- Review imports to spot API families such as networking, process injection, registry access, crypto, service control, persistence, or anti-debugging calls.
- Read strings and hex for URLs, mutex names, file paths, command lines, embedded scripts, resource markers, and magic bytes.
- Disassemble code sections and jump to the entry point to follow prologues, thunks, import calls, conditional branches, and obvious unpacking stubs.
Concrete examples
- Malware triage: a packed EXE may have a tiny
.text section, a large executable UPX1 section, high entropy, and imports limited to LoadLibraryA and GetProcAddress.
- DLL review: a plugin DLL can be checked for exported function names, ordinal-only exports, forwarded exports, and the subsystem/architecture expected by the host process.
- Exploit-lab learning: a small compiled C program lets you compare an entry point, function prologue, stack setup, and call instructions against the original source.
- Build hardening: release artifacts can be inspected for NX compatibility, dynamic base, high-entropy VA, and guard flags before shipping.
What is disassembly?
Disassembly converts raw machine bytes into a human-readable representation of the corresponding CPU instructions (mnemonic + operands). It is not decompilation: there is no recovery of variable names, types, control structures, or source comments. The output is a flat instruction listing — branches and calls show their target addresses but the structure remains linear.
Modern decompilers (Ghidra, IDA, Binary Ninja) reconstruct higher-level pseudocode by performing control-flow analysis, type inference, and pattern matching. These workflows require substantial heap memory and are not currently practical to run in a browser tab. This tool covers the disassembly half — the same first-pass view you would get from objdump -d or llvm-objdump.
Architecture cheat sheets
x86-64 (AMD64) registers
x86-64 general-purpose register naming across 64/32/16/8-bit widths with conventional uses.
| 64-bit | 32-bit | 16-bit | 8-bit | Conventional use |
|---|
| RAX | EAX | AX | AL | Return value / accumulator |
| RCX | ECX | CX | CL | 4th arg (Win64) / 1st arg (Linux) |
| RDX | EDX | DX | DL | 3rd arg / I/O |
| RBX | EBX | BX | BL | Callee-saved base |
| RSP | ESP | SP | SPL | Stack pointer |
| RBP | EBP | BP | BPL | Frame pointer (often omitted) |
| RSI / RDI | ESI / EDI | SI / DI | SIL / DIL | 2nd/1st arg (Linux) / source / destination |
| R8–R15 | R8D–R15D | R8W–R15W | R8B–R15B | Extra args + scratch |
The Windows x64 calling convention passes the first four integer arguments in RCX, RDX, R8, R9 and reserves 32 bytes of shadow space on the stack. System V (Linux / macOS) uses RDI, RSI, RDX, RCX, R8, R9 and no shadow space.
ARM64 (AArch64) registers
X0–X30 are 64-bit general-purpose; W0–W30 their 32-bit aliases. X0–X7 carry function arguments (X0 = first arg, also return value). X29 is the frame pointer, X30 the link register, SP the stack pointer. There is no separate program counter exposed to user code; PC-relative addressing handles it implicitly.
Use cases
- Malware triage — Quickly assess what APIs a sample imports, look for high-entropy packed sections, surface suspicious flags (TLS callbacks, executable-and-writable sections).
- CTF reverse-engineering challenges — Skim the disassembly of crackmes and keygenmes before reaching for a heavyweight tool.
- Binary diffing — Compare disassembly listings of two builds to spot regressions or backports.
- Learning assembly — Compile a small C program with MSVC or MinGW and walk through the resulting code with this tool open alongside the source.
- Crash dump analysis — Cross-reference a faulting instruction pointer from a Windows minidump against your release binary's disassembly.
- Build verification — Confirm that DEP, ASLR, and Control Flow Guard are enabled (DLL Characteristics) before shipping.
Security limits and ethics
Only analyse binaries you are authorised to inspect. Loading a malicious binary into this tool is designed to be low risk because the file is read as data and never executed, but extracted strings, resources, URLs, and copied commands may still be harmful. For active malware analysis, use an isolated VM and dedicated tooling — this is a static triage aid, not an antivirus engine, EDR, sandbox, emulator, YARA scanner, or exploit detector.
Static disassembly has limits: packed or encrypted samples may hide their real code until runtime, anti-disassembly tricks can confuse linear instruction streams, jump tables and mixed code/data can make branch targets ambiguous, and stripped binaries rarely preserve symbol names. Browser memory also matters; very large executables or debug-heavy binaries can be slow even though the UI accepts files up to 200 MB.
Standards & references
- Microsoft PE/COFF Format specification — authoritative reference for DOS headers, COFF headers, optional headers, data directories, section tables, imports, exports, base relocations, resources, debug data, TLS, load config, and certificates.
- Microsoft DUMPBIN reference — command-line PE inspection reference useful for comparing this browser output with local Visual Studio tooling.
- LLVM objdump documentation — reference for the common offline disassembly workflow this tool approximates in the browser.
- Intel® 64 and IA-32 Architectures Software Developer's Manual — full x86 / x86-64 instruction set.
- Arm Architecture Reference Manual — ARM64 (AArch64) instruction encoding.
- Capstone Engine — the multi-architecture disassembly library powering this tool (BSD-3).
- pe-library — MIT-licensed pure-JS PE parser used for the header walkthrough.