How I built a binary ELF/PE analyzer (Phase 2)

Angel Bandres — Thu, 02 Apr 2026 03:31:06 +0000

Introduction and Motivation

If you've read my previous post on Phase 1, you probably have already an idea of the evolution of this project. If you haven't let me explain briefly.

I've been wanting to learn about Cybersecurity, Reversing and Low-level development, and this is the very first step, the very tip of the iceberg if you will; to have some fun and hopefully land a job in this vast and fascinating area. I've named this project "Binalyzer" as a spiritual succesor to my first junior Full Stack project "Textalyzer" (completely vibecoded and barely knowing a thing or two about HTML).

This time around, I wanted to do things on my own, with little to no use of AI for the development of this project, so I can properly learn everything relevant to this project (namely, binary file structure and Python). I've decided to do this in Python since I didn't know much about the language and development speed is overall much faster in comparison with C/C++. Also, it's a surprisingly powerful and expressive language and there's always more to learn about it. Documentation is also interesting and relatively easy to digest too.

Now, what is Binalyzer?

As the name might imply, it's simply a CLI binary file analyzer. As of right now, you need Python to run it, and the command you need to use to run is

python main.py filepath_to_bin -a

What's with all these phases?

Each phase represents a new functionality of the script. Phase 1 involved basic detection of the file type (ELF or PE, for the time being). Now, phase 2 involves header parsing of these files, which I'm very proud about.

Now now, what are PE and ELF? Do ELF files have ears? Is PE the Pocket Edition of Minecraft?

Answering the last two questions, no, unfortunately. But, Binalyzer kinda "hears" the inner structure and, since you can run Python in your phone, it's technically "pocketable" ig.

Damn... what is ELF then?

According to the Linux manpages (which I read recommend to read for further information, but not exclusively), it is a:

format of Executable and Linking Format files

This structure is fairly straightfoward, defined almost entirely by unsigned integers (size depending on the architecture), and maybe a few arrays here and there.

Alright then, what about PE?

PE stands for Portable Executable. And that's all you need to know

Both files are dynamic in size (shocking!) and are structured in very different ways (what?!), but PE is more complicated (even more than I can think of).

How can you tell which one is which?

ELF

Check the first 4 bytes of the binary. It's a magic number. If it's "\0x7F E L F", then it's an ELF file.

PE

Check the first 2 bytes. If it's "MZ" then it's a DOS file. This is done to preserve compatibility with older DOS programs. Then, check bytes 61 to 64 (indices 60 to 63), that is the signature. If it's "P E \0 \0", then it's a valid PE file.

Thought: there are many other types of binaries and I assume that each and every one of them has a different way of being read. This may be important if I want to scale my detection capabilites for other types of binaries.

Alright. Now, tell me more about the structure of these "headers".

ELF Header

Made of

e_ident: a 16 byte (unsigned char) array that identifies how the file must be interpreted as.
e_type: Object file type
e_machine: Required architecture of an individual file
e_version: File version
e_entry: Point of entry. If you know a thing or two about operating systems and files, it's the address of the file where the system starts the process related to it.
e_phoff: Program Header table OFFset (address)
e_shoff: Section Header table OFFset
e_flags: processor-specific flags associated with the file
e_ehsize: ELF Header SIZE (in bytes)
e_phentsize: Program Header table ENTry SIZE
e_phnum: Program Header table's NUMber of entries
e_shentsize: Section Header table ENTry size
e_shnum: Section Header table's NUMber of entries
e_shstrndx: Section Header table's section name STRing table iNDeX. Basically, there's a table of strings in the section name, in the section header table, and that table contains an index.

PE header

This one is more complicated, as it contains multiple "sub-headers". Fortunately, the names of these fields within these sub-headers are clearer. Here are some of the sub-headers that I've managed to parse as of right now in phase 2:

File Header

Contains static information (metadata) on the moment the binary was compiled. These fields are:

Machine: The type of CPU the binary was made for.
NumberOfSections
TimeDateStamp
PointerToSymbolTable
NumberOfSymbols
SizeOfOptionalHeader
Characteristics: flags in hex that determine additional aspects of the binary

Optional Header

This header is not fixed in size per se, since it has the instructions on how the system should expand and run the binary in RAM. But, contains some standard fields which are the same in every PE file:

Standard Fields

Magic: The architecture of the binary, might be 32-bit (0x10b) or 64-bit (0x20b).
MajorLinkerVersion and MinorLinkerVersion
SizeOfCode (bytes)
SizeOfInitializedData
SizeOfUnitializedData
AddressOfEntryPoint
BaseOfCode (address): Start of the code section when the file is loaded into memory.
BaseOfData (address, 32-bit Magic only): Same for BaseOfCode, but for the data section.

These fields are based on custom integer types called WORDs (2 bytes) and DWORDs (4 bytes).

How did you do implement this in Python?

Now we're talking. I first took the file and read the header as a string of bytes. For both files, I used the struct module and its method struct.unpack(), using specific string formats depending on the architecture and endianness:

ELF Header Unpacking String Formats

32-bit, little endian: "<16BHHIIIIIHHHHHH"
32-bit, big endian: ">16BHHIIIIIHHHHHH"
64-bit, little endian: "<16BHHIQQQIHHHHHH"
64-bit, big endian: ">16BHHIQQQIHHHHHH"

Note: Since I treated the header as a string, I had some troubles with the indices when determining the architecture and endianness, so make sure you're using the right ones! Here are the ones

architecture = header[4] # fifth byte
endianness = header[5] # sixth byte

PE Header Unpacking String Formats

They are all little endian.

File Header: architecture-independent

"<HHIIIHH"

Optional Header: Magic-dependent

32-bit: "<HBBIIIIII"
64-bit: "<HBBIIIII"

32-bit uses an additional field for BaseOfData.

To whom may concern, this is the structure of the project, pretty self-explanatory tbh.

No pics no clicks! Where are the examples?

Here they are!

PE: Windows Notepad

ELF: ls (Linux)

Comparing to a standardized program: readelf -h, the resulting values are the same:

And now what?

I will be very soon starting development on phase 3, which will include a listing of the sections of the binary, so stay tuned for more!

If you want to check out the project, it's on GitHub

I am open to any questions, comments, suggestions and constructive criticism.

My first Low-Level project

Angel Bandres — Tue, 17 Mar 2026 14:11:58 +0000

As I'm getting into low-level and combining it with cybersecurity, yesterday I've started a project that analyzes binary files and their structure. Introducing:

Binalyzer: A simple binary file analyzer that shows information on their structure.

Currently, I've completed the first out of five phases of this project, which is the simple detection and validation of either PE or ELF files. I'm making this in Python so I can learn more of the language and its more simple syntax. Here are some use cases:

Check out and follow the project for future updates, here on GitHub

I am open to any feedback, thanks for reading :)

My First FullStack project

Angel Bandres — Tue, 17 Mar 2026 00:06:08 +0000

Coming from a background in C++ and Data Structures, I recently challenged myself to dive into the web ecosystem. The result? Textalyzer — a high-performance REST API and web client for real-time text analysis.
Throughout this project, I focused heavily on optimization and architecture. Here are the main technical hurdles I overcame:

Algorithmic Efficiency: Refactored the character frequency logic from a naive $O(N^2)$ approach to $O(N)$ by implementing custom Hash Maps, drastically improving processing time for large texts.
Data Persistence & Resilience: Integrated a serverless PostgreSQL database (Neon). When I encountered "Cold Start" connection drops on the cloud, I implemented Connection Pooling (pg.Pool) to ensure the server gracefully handles disconnections without crashing.
Clean Architecture: Applied Separation of Concerns by modularizing the Node.js backend logic, and separating the frontend into clean HTML, CSS, and Vanilla JavaScript files.

The Tech Stack:

Backend: Node.js, Express, PostgreSQLFrontend: HTML5, CSS3, Asynchronous JS (Fetch API)
DevOps: Git (SemVer), WSL2, Render (PaaS)

Check out the live project here

Dive into the code on Github, here

Excited for the next challenge! Always open to feedback from the community. 👇

DEV Community: Angel Bandres