rea-reverse

Native binary overview: ELF, PE and Mach-O

Open an ELF, PE or Mach-O file to see its architecture and headers, its sections and segments with entropy, the libraries and symbols it imports and exports, its hardening flags and its printable strings. Nothing is executed or disassembled.

Your binary never leaves your browser. The file is parsed locally in a Web Worker that has no network access. Nothing is uploaded. How to verify this yourself

Drop an ELF, PE or Mach-O file here

or

Executables, shared libraries (.so, .dll, .dylib), drivers, object files and universal (fat) Mach-O binaries. Up to 512 MiB.

What this tool does not do

  • Static parsing only: nothing is run, disassembled or decompiled. To read the code, open the file in Ghidra or another disassembler.
  • Security features are read from headers, flags and imported names. They describe how the file was built, not whether it is safe, and signatures are detected, never verified.

Before you load a native binary into Ghidra or IDA, it helps to know what it is: which CPU it targets, whether it is a library or an executable, what it links against, how it was hardened and whether part of it looks packed. That first look usually means running file, readelf, otool, nm, strings and a checksec script one after another, on whatever operating system you happen to be on.

This tool gives you that overview for ELF (Linux, Android, BSD, firmware), PE (Windows EXE, DLL and drivers) and Mach-O (macOS and iOS, including universal binaries) in one page. It parses the headers and tables in your browser. Nothing is executed, disassembled or uploaded.

What it does

Input. Drop or choose one file of up to 512 MiB. The format is detected from its first bytes, not from its name:

  • ELF: 32-bit and 64-bit, little-endian and big-endian (ET_EXEC, ET_DYN, ET_REL, ET_CORE).
  • PE: PE32 and PE32+ (EXE, DLL, SYS drivers, EFI images). A file with a CLI header is labelled as a .NET assembly, with a link to the .NET metadata and IL viewer for its types and IL.
  • Mach-O: 32-bit and 64-bit, either byte order (executables, dylibs, bundles, object files, kernel extensions). A universal (fat) binary lists every slice with its architecture, offset and size; pick a slice and the report switches to it.

Report.

  • Identity: format, architecture, bitness, byte order, file type and role, entry point, file size and SHA-256. Per format:
    • ELF: OS/ABI, the interpreter from PT_INTERP (for example /lib64/ld-linux-x86-64.so.2 or /system/bin/linker64), DT_SONAME and the GNU build-id note.
    • PE: subsystem, the COFF timestamp, linker and OS versions, image base and the imphash.
    • Mach-O: platform, minimum OS and SDK from LC_BUILD_VERSION or LC_VERSION_MIN_*, LC_UUID, the dylib install name and the signing identifier and team ID from the code signature.
  • Segments and sections: name, address, file offset, file and memory size, permissions (r-x, rw-), type, and the Shannon entropy of each region’s bytes. Regions above 7.2 bits per byte (and at least 1 KiB) are tagged high entropy: compressed or encrypted data such as packed code, embedded archives or images. That is common and legitimate; it only tells you where a disassembler will see no code.
  • Linked libraries: ELF DT_NEEDED; PE import and delay-load DLLs; Mach-O LC_LOAD_DYLIB, weak, re-exported, lazy and upward dylibs.
  • Imports and exports: ELF dynamic symbols (.dynsym, or .symtab for objects and static executables) with their type; PE imports per DLL, including ordinal-only imports and delay-load imports, and the export table with ordinals and forwarders; Mach-O external symbols from the symbol table, with the dylib each import binds to. The table can be filtered by name or library and by direction, and renders 500 rows at a time.
  • Security features: a checklist read from headers, flags and imported names:
    • ELF: NX stack (PT_GNU_STACK), PIE, RELRO (partial, or full with BIND_NOW), stack canary and FORTIFY hints (imports of __stack_chk_fail and __*_chk), stripped symbol table.
    • PE: ASLR (DYNAMIC_BASE), high-entropy ASLR, DEP (NX_COMPAT), Control Flow Guard, SafeSEH or NO_SEH on 32-bit images, Authenticode signature present, FORCE_INTEGRITY, .NET.
    • Mach-O: PIE, NX stack, stack canary hint, code signature present (CodeDirectory version and flags, ad hoc or with a CMS signature), hardened runtime, LC_ENCRYPTION_INFO cryptid, __RESTRICT segment.
  • Strings: printable ASCII and UTF-16LE runs of at least 6 characters (you can set 2 to 64), with the section each one sits in. The first 20,000 by offset are listed and filterable; Download all as .txt writes every string (up to 2,000,000) as offset, encoding, section, text.
  • Export: the whole report as JSON.

How it works

The page reads the file with Blob.slice, so headers, section tables, symbol tables and names are fetched from the file on demand. For ELF it reads the ELF header and program headers, then the section headers and their name table, PT_INTERP, the notes, the dynamic section (strings through DT_STRTAB, mapped to a file offset via the PT_LOAD segments) and the symbol table. For PE it reads the DOS and COFF headers, the optional header and its data directories, the section table, and then follows RVAs into the import, delay-import, export and load-config tables. For Mach-O it walks the load commands, the nlist symbol table and the code signature SuperBlob.

Every read is bounds-checked, and every count the file declares is capped before it is used: 4,096 sections, segments, load commands and libraries, 100,000 symbols, 64 MiB for any single table. When a table is damaged or cut off, that part is skipped and listed under Notes; the rest of the report is still shown. A worker that runs for more than two minutes is stopped.

The SHA-256 is computed with WebCrypto. WebCrypto has no streaming hash, so the file is read into memory once for it; the same bytes feed the entropy and strings scans. The PE imphash follows the algorithm of pefile (get_imphash): standard imports in table order, DLL names lowercased without .dll, .ocx or .sys, joined as dll.function, then MD5. Values were checked against pefile, llvm-readelf, llvm-readobj, otool, nm, codesign and llvm-strings on test binaries built for this tool.

How your files stay private

Your file is not uploaded:

  • Parsing, hashing, entropy and the strings scan all run in a Web Worker on your device.
  • Section, symbol, library and string values are shown as plain text; nothing from the file is interpreted as HTML or run.
  • Analytics events are coarse: success or an error code, the format (elf, pe, macho or fat), a coarse architecture such as x86-64 or arm64, a size bucket and a duration bucket. They never contain the file name, hashes, symbol names, strings or any other content. The full list is on the privacy page.
  • The tool page shows no ads.

How to verify this yourself

  1. Open your browser’s developer tools and switch to the Network tab before you choose a file. Analyze a binary, switch a slice and download the strings. The only requests are page assets and the worker script /_astro/binary-worker-*.js; none carries your file.
  2. Or load the page, go offline (turn off Wi-Fi, or tick Offline in the Network tab) and analyze a file. It still works.
  3. The worker runs under the Content Security Policy default-src 'none'; script-src 'self'; connect-src 'none', so the browser does not let it make any network request.

Limitations

  • No code analysis. There is no disassembly, decompilation, control flow or emulation. Use REA with Ghidra for that.
  • Security features are hints, not a verdict. Canary and FORTIFY detection only looks for imported helper functions, so a statically linked binary can show “no” even when it was built with them. A missing PT_GNU_STACK is reported as unknown, because the default depends on the platform.
  • Signatures are detected, not verified. Authenticode and Mach-O code signatures are reported as present with their basic fields; certificates, hashes and notarization are not checked.
  • imphash. It is not computed when the import table is incomplete, or when it has ordinal-only imports from ws2_32.dll, wsock32.dll or oleaut32.dll, because pefile resolves those through built-in name tables that this tool does not ship. Delay-load imports are not part of the imphash, as in pefile.
  • Mach-O exports come from the symbol table. The export trie (LC_DYLD_INFO, LC_DYLD_EXPORTS_TRIE) and chained fixups are not decoded, so a binary stripped of external symbols shows fewer exports than dyld_info would. The entry point is shown for LC_MAIN; LC_UNIXTHREAD is named but its register state is not decoded.
  • ELF symbol versions (@GLIBC_2.2.5) are not shown, and a dynamic symbol table without section headers (only DT_SYMTAB) is not read. Program headers must sit in the first 64 KiB, and 64-bit offsets above 2^53 (kernel images) are rejected.
  • Strings are printable ASCII (0x20–0x7e) only, in single bytes or UTF-16LE code units. Other encodings, compressed data and strings built at run time are not found.
  • Other formats (COFF objects without an MZ header, static libraries, Java class files, WebAssembly) are not parsed. For .wasm use the WASM analyzer.

FAQ

Why is the entropy of a section close to 8?

Data that is compressed or encrypted looks random, and random bytes approach 8 bits per byte. Packers such as UPX, embedded .zip or image resources, and encrypted payloads all do this. Code and text usually sit between 4.5 and 6.5.

Why are the offsets of a fat binary small?

Mach-O offsets inside a universal binary are relative to the start of each slice, as otool prints them. The slice list shows where each slice starts in the file.

The timestamp of my DLL is in the future.

Builds made with deterministic or reproducible settings (for example MSVC /Brepro) store a hash in the COFF timestamp instead of a date.

Does “PIE: n/a” on a shared library mean something is wrong?

No. Shared libraries are position-independent by design, so the PIE question only applies to executables. In the same way, NX, PIE and RELRO do not apply to object files, which are never loaded on their own.

How is this different from checksec?

The checks are the same kind (headers and imports), but this works the same way for ELF, PE and Mach-O and needs no install. The wording is neutral on purpose: a missing feature is a fact about the build, not proof of a vulnerability.

Compliance

Analyze binaries you built yourself, open-source software, CTF challenges or files you are authorized to assess. Respect the licenses of the software you inspect, including any terms that restrict reverse engineering, and the laws that apply to you. See the disclaimer.