Executable File Inspector

## Read the container before you read the code Before disassembling anything, you usually want the boring facts: what format is this, what does it import, which hardening flags are set, is there a signature blob, and is there an overlay hiding past the last section. The Executable & Object Inspector answers those in the browser, with parsers that stop at explicit bounds rather than trusting the file. ## Format coverage **PE32 and PE32+** — COFF header and machine type, section table with raw and virtual sizes, data directories, import and export tables where present, resource and overlay indicators, mitigation flags including ASLR, DEP, CFG, high-entropy VA and SafeSEH, and the certificate table. **ELF32 and ELF64, both endiannesses** — program and section headers, the interpreter path, dynamic dependencies, symbol tables where they survive stripping, build ID, and common hardening flags such as RELRO, NX, PIE and stack canaries. **Mach-O, 32-bit and 64-bit, plus universal binaries** — every slice in a fat container, segments and sections, load commands, dylib dependencies, entry point, UUID, and the location of the code-signature blob. **Unix ar archives** — member listing with bounded extraction, so you can pull one object out of a static library and send it onward. ## What the signature report does and does not claim The inspector locates embedded signature containers and reports where they sit and how large they are. It deliberately stops there. It does not verify digests, walk certificate chains, check revocation, or tell you whether an operating system would accept the binary. That boundary is deliberate, because a half-verified signature is worse than an unverified one. Treat the output as "a signature blob is present at this offset, of this size" and verify trust with the platform tooling that owns that decision. ## Reading the output during triage A few patterns come up constantly: - **Imports that do not match the stated purpose.** A document converter reaching for `VirtualAlloc`, `WriteProcessMemory` and `CreateRemoteThread` is worth a second look. - **A tiny import table.** Packed binaries often import almost nothing, resolving APIs at runtime instead. Pair this with the Entropy Analyzer. - **A section whose virtual size dwarfs its raw size.** Classic unpacking stub shape. - **An overlay past the final section.** Sometimes an installer payload, sometimes appended data worth extracting. - **Missing mitigations on a recent build.** No ASLR or no NX on something compiled this decade is a finding in its own right. - **Section names that do not match the toolchain.** `UPX0` and `.themida` are self-explanatory; unusual names on an otherwise ordinary MSVC layout are not. ## Object files and static libraries Object files and `ar` archives get the same treatment as finished executables, which matters more often than it sounds. When a build produces a binary nobody expected, the question is usually which translation unit contributed a symbol, and that is answered by listing archive members and reading their symbol tables rather than by disassembling the linked result. Members extract with the same bounds as any other input, and each one becomes a derived artifact in the workspace, so a single object can go straight to the disassembler without ever touching disk. ## Hostile input handling Every count, offset, range, allocation and table size is checked before allocation or iteration. Malformed and deliberately adversarial files stop at a bound and return partial results plus diagnostics instead of crashing or hanging the tab. A truncated section table gives you the sections that parsed and a diagnostic for the rest, which is usually what you want, since malformed headers are themselves a signal. ## Handoffs Findings attach to the active Binary Lab session, so section offsets, import lists and signature locations travel with the artifact. From here the usual next moves are the Machine Code Disassembler for the entry point, the Hex Editor for a specific offset, the Entropy Analyzer for a suspicious section, or the YARA-X Rule Workbench to turn what you found into a detection. Everything runs locally, so an unreleased build or a customer sample never leaves the machine.