PE Inspector: Windows EXE and DLL Viewer

How to use

1. Drop the file on the box. An .exe, .dll, .sys driver, .ocx control or .efi binary all parse the same way — the extension is not what decides.
2. Read the header tiles for the architecture, PE32 versus PE32+, EXE versus DLL and the subsystem. A console and a GUI build of the same program differ only here.
3. Check the hardening chips. ASLR, DEP and CFG are what a current Windows toolchain sets by default, so an amber chip on a recent binary is worth explaining before you ship it.
4. Scan the imports for the capability you care about: WS2_32 means sockets, WININET or WINHTTP means it talks to the web, ADVAPI32 means registry or service work, CRYPT32 means certificates.
5. Look at the section table for anything writable and executable, and at the data directories for a certificate, a debug entry or a CLR runtime header that changes how the rest should be read.

Frequently asked questions

The file has a signature chip. Does that mean it is safe?

No, and the distinction matters. The chip only says the certificate data directory is non-empty, which means an Authenticode blob is appended after the last section of the file. It does not say that the blob matches the bytes in front of it, that the signing certificate chains to a root Windows trusts, that the certificate was valid at signing time, or that the signer is who the file claims. Any of those can be false while the directory is still populated — a file can be re-signed with a self-issued certificate, or the payload can be modified after signing so the hash no longer matches. Verifying it properly needs the full chain, revocation data and usually a trusted countersignature timestamp, which is a network operation and deliberately out of scope for a browser tool that promises never to upload your file.

What does high-entropy ASLR add over plain ASLR?

Plain ASLR moves an image to a random base at load time, but on 32-bit Windows only about eight bits of the address are actually random, which is few enough to brute-force in a loop. HIGH_ENTROPY_VA tells the loader that the image is safe to place anywhere in the full 64-bit address space, which raises the randomised bits into the high teens and makes guessing impractical. It only means anything on a PE32+ image that also has DYNAMIC_BASE set, and it further requires that the program never truncates a pointer to 32 bits — which is why linkers gate it behind /HIGHENTROPYVA and why a 64-bit binary built from careless 32-bit-era source may deliberately leave it off.

Why do some imported functions show as #12 instead of a name?

Because the file imported them by ordinal. Each entry in a thunk array is a machine word whose top bit is a flag: when it is set, the low 16 bits are the ordinal to look up in the exporting DLL's address table, and no name is stored anywhere in the importing file. When it is clear, the rest of the word is an RVA pointing at a hint/name pair and the name is right there. Importing by ordinal is slightly faster to resolve and was common in older code; it is also what you see when someone wants to obscure which API is being called. This tool shows the raw ordinal rather than guessing, because the mapping from ordinal to name lives in the exporting DLL and depends on which version of it is installed.

The section table shows a section that is writable and executable. How bad is that?

It is unusual enough to be worth a look, but it is not proof of anything on its own. A normal compiler and linker emit .text as read plus execute and .data as read plus write, and never both at once, because DEP exists precisely to make that combination fault. Sections carrying IMAGE_SCN_MEM_WRITE and IMAGE_SCN_MEM_EXECUTE together usually come from a runtime packer that decompresses code into its own section before jumping into it — UPX names its section UPX1 — or from an old installer, a self-modifying protection scheme, or a JIT that allocates in the image rather than at runtime. If you did not expect any of those, the binary is doing something worth understanding before you run it.

The link timestamp says 1970, or a date in the future. Is the file corrupt?

Almost certainly not. TimeDateStamp is a 32-bit seconds-since-1970 field that the linker fills in, and modern toolchains stopped treating it as a date. A reproducible build sets it to zero or to a fixed constant so that the same source always yields byte-identical output, and MSVC with /Brepro writes a hash of the inputs there instead, which lands at an arbitrary and often far-future point on the calendar. Rich header data and the debug directory are usually better evidence of the toolchain than this field is, and none of it is evidence of when a file was actually shipped. Treat it as metadata that happens to be shaped like a date.

This is a .NET assembly. Why do the imports and the entry point look almost empty?

Because for a managed assembly the PE part is a shell. When the CLR runtime data directory (index 14, the COM descriptor) is non-empty, the real program is IL stored inside .NET metadata, and the native headers exist mainly to satisfy the Windows loader. A classic C# executable has exactly one import, _CorExeMain from mscoree.dll, an entry point that is a two-instruction jump to it, and a .text section that is mostly metadata rather than machine code. So the architecture field may say Intel 386 for a program that will happily run 64-bit, and the section sizes tell you nothing about how big the program is. Reading it properly needs an IL disassembler such as ildasm or ILSpy.

Related tools