# readpe analyses Windows PE binaries from the command line > readpe is a C implementation of the toolkit formerly known as pev, a multiplatform command line suite for inspecting and analysing Portable Executable files, with libpe folded back into the same tree. It is GPL-2.0 licensed with an LGPL exception for the library, and it builds with make on Linux, macOS and Cygwin. **mentebinaria/readpe** — The PE file analysis toolkit - Repository: https://github.com/mentebinaria/readpe - Stars: 792 · Forks: 138 - Language: C - License: GPL-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/mentebinaria-readpe ## A PE analysis toolkit that outgrew the name pev readpe is an open source, full-featured, multiplatform command line toolkit to work with and analyse PE, Portable Executable, binaries. The name and the history are explained in the FAQ, which is worth reading before anything else because it tells you where to look for older material. This repository used to be pev and was moved from a user account to an organisation account, and it was renamed because the original name stood for PE Version and no longer reflected the current state of the application. The maintainers felt readpe was a good name since it is the most prominent tool in the set. There is also an online manual linked from the README, hosted on sourceforge. The second FAQ entry matters for anyone building the project. libpe has been absorbed into this repository, because the two repositories were tightly coupled and version controlling them together made the most logical sense. So the current shape is one repository with two things in it: a library, lib/libpe, that does the PE parsing, and a set of command line tools in src that use it. The repository listing shows the whole structure: the lib directory, the src directory, an include directory for public headers, a completion directory for shell completions, a doc directory, a tests directory, a Makefile, a pev.conf configuration file, a pev.spec packaging spec, and two licence files, LICENSE and LICENSE.OpenSSL. The audience is reverse engineers and malware analysts who work in a terminal, and the topics confirm it: binary-analysis, malware-analysis, malware-research, pe-file, portable-executable and reverse-engineering. ## Building on Linux takes make, and installing takes the library path The build is a plain make invocation, and the README's Linux instructions are short enough to quote in full. ``` git clone https://github.com/mentebinaria/readpe.git cd readpe make ``` The note that follows is the one that catches people out: you may need to install OpenSSL using your package manager, with the examples given as apt install libssl-dev and yum install openssl-devel. The FAQ repeats it for the case where the build fails with a fatal error about openssl/evp.h not being found, and adds that on macOS both the CFLAGS and LDFLAGS environment variables have to be set. Installing on Linux is where the project shows its age, and where the shared library matters: ``` cd readpe sudo make install echo "/usr/local/lib" | sudo tee /etc/ld.so.conf.d/libpe.conf sudo ldconfig ``` The three steps are one operation, not three. The install puts libpe into /usr/local/lib, and because it is a shared object the dynamic linker has to be told to look there and then told to reload its cache. Skipping the second and third steps produces the error the FAQ documents, an error while loading shared libraries about libpe.so.1 not being found, and the FAQ's answer is simply to follow the Linux installation steps above. That is an old-fashioned install, and it is the direct consequence of the tool being a set of C programs linked against a shared C library rather than a self-contained binary. ## macOS needs flags pointed at Homebrew, Windows needs Cygwin The other two platforms are handled with their own quirks. On macOS the build passes the OpenSSL include and library paths explicitly: ``` cd readpe CFLAGS="-I/usr/local/opt/openssl/include/" LDFLAGS="-L/usr/local/opt/openssl/lib/" make ``` The note says you may need to install OpenSSL and PCRE via Homebrew, with the two commands given as brew update and brew install openssl. On Windows the build goes through Cygwin: ``` cd readpe make make zip ``` The Cygwin install needs a specific set of packages, and the README lists them in a table. The Archive category needs zip, and the Devel category needs binutils, gcc-core, git and make, and the Net category needs libssl-devel. The zip target then assembles a Windows distribution, which is where the Makefile details are most revealing. The zip target is marked Cygwin only, and it builds the Windows-specific part of the tools, creates a directory named readpe with the version in it, copies the plugin DLLs from src/build/plugins into a plugins subdirectory, writes a pev.conf file containing a single plugins_dir=plugins line, copies the userdb.txt file and libpe.dll, and then copies four Cygwin runtime DLLs into the package: cygwin1.dll, cygcrypto-3.dll and cygz.dll, plus the OpenSSL library. It finishes by zipping the tree and removing the staging directory. Those runtime DLLs are the giveaway that this is a self-contained bundle: a user on Windows gets a zip that runs without installing Cygwin, with the crypto library, the plugins and the configuration already in place. ## One Makefile driving two sub-trees The top-level Makefile is a thin dispatcher, and reading it tells you how the project is organised. ``` LIBPE_DIR = lib/libpe PEV_DIR = src VERSION = 0.85 ``` Every target is delegated twice, once into the library and once into the tools: ``` all: %: cd $(LIBPE_DIR) && $(MAKE) $@ cd $(PEV_DIR) && $(MAKE) $@ ``` That catch-all pattern rule is why make, make zip and the other targets work from the top of the tree without the top-level file needing to know what each sub-tree builds. The library and the tools have their own Makefiles, and the top-level one only decides the order and the variables. The version variable, 0.85, is also used to name the Windows zip archive, readpe with the version and a win suffix, and the zip target sets the archive name to that directory with a .zip extension. The release tags tell a similar story: v0.85 on 2025-08-08 and v0.85.1 on 2025-08-29, whose release note is a version fix. For packaging on Linux distributions there is a pev.spec file, which is the RPM spec, and pev.conf, the configuration file that the Windows bundle generates with its plugins_dir setting. The presence of both, plus a completion directory for shell completions and a tests directory, suggests a project with a real distribution story rather than a single script. ## GPL-2.0 for the tools, LGPL-3.0 for the library The licence section is short and it is not a single licence, which matters if you intend to link against libpe. This project is licensed under the GNU General Public License version 2, with the exception of the contents of lib/libpe which are licensed under the GNU Lesser General Public License version 3. Copies of these licences can be found respectively in the project root and in lib/libpe. So the split is deliberate. The command line tools are GPL-2.0, and the library that other programs can link against is LGPL-3.0, which is the permissive end of the copyleft family for a library: linking against it does not by itself oblige you to release your own program under the GPL. The repository also carries a LICENSE.OpenSSL file, which sits alongside the OpenSSL dependency the build instructions keep insisting on. The practical reading is that a security team can embed libpe in an internal tool under LGPL terms, while shipping the readpe tools themselves as GPL-2.0 software. A commercial product that wanted to redistribute the tools themselves would have to consider the GPL-2.0 obligations, and a company whose legal process has no template for either licence should read the two files rather than rely on the summary above. ## Where readpe is the wrong tool The boundaries are clear and they are the boundaries of the format. First, this is a PE toolkit. Portable Executable is the Windows family, and the library parses that format. If your targets are Linux ELF binaries or macOS Mach-O files, none of this applies, and the online manual linked from the README is the reference for what the format support actually covers. Second, it is a command line tool and it is a C program. There is no library-style scripting interface described in the README, no Python bindings, and no API section. Automation means either writing a shell script around the binaries or linking libpe, which is the LGPL half of the project and the only part of it that is meant to be embedded. Third, the build is a prerequisite. A C toolchain, OpenSSL development headers, PCRE on macOS, a Cygwin environment with a specific package list on Windows, and on Linux the shared library path and ldconfig dance. That is a fair amount of setup for a tool that solves one problem well, and it is the main reason the project has not replaced the many simpler one-off PE inspection scripts that exist. Fourth, the release line has slowed. The repository is not archived and the last push was on 2026-08-25, so the source is being worked on, but the newest tagged release is v0.85.1 from 2025-08-29 and there is no newer tag. Anyone who needs a specific, auditable build should pin to that tag rather than track the branch, and should expect to compile it themselves rather than download a binary. ## Conclusion Reverse engineers and malware analysts who live in a terminal should use readpe, because it gives a full PE inspection and analysis workflow on Linux, macOS and Windows without a graphical interface, and it keeps the libpe library in the same tree as the tools. It is the wrong tool if you need to analyse ELF or Mach-O binaries, because the format support stops at the PE family, and it is the wrong choice if you want a maintained release cadence, since the newest tag is v0.85.1 from 2025-08-29 while the last push was on 2026-08-25. Before building, install OpenSSL development headers, and read the licence section, because lib/libpe is LGPL version 3 while the rest of the toolkit is GPL version 2. ## FAQ ### What is readpe and what was it called before? It is a multiplatform command line toolkit to work with and analyse PE binaries. The repository used to be pev and was renamed because the original name stood for PE Version and no longer reflected the state of the application, with libpe absorbed into the same repository. ### How do I build readpe on Linux? Clone the repository, cd into it and run make. You may need OpenSSL development headers first, with apt install libssl-dev or yum install openssl-devel, and the FAQ also covers a fatal error about openssl/evp.h not being found. ### Why do I get an error about libpe.so.1 not being found? The install puts the shared library in /usr/local/lib, which the dynamic linker has to be told about. The Linux install steps add /usr/local/lib to /etc/ld.so.conf.d/libpe.conf and then run ldconfig, and the FAQ says to follow those steps. ### What licence applies to readpe and to libpe? The project is licensed under the GNU General Public License version 2, with the exception of the contents of lib/libpe, which are licensed under the GNU Lesser General Public License version 3. Copies are in the project root and in lib/libpe. ## Sources - [Issues](https://github.com/mentebinaria/readpe/issues) - [License: GPL-2.0](https://github.com/mentebinaria/readpe/blob/master/LICENSE) - [mentebinaria/readpe on GitHub](https://github.com/mentebinaria/readpe) - [README](https://github.com/mentebinaria/readpe/blob/master/README.md) - [Releases](https://github.com/mentebinaria/readpe/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mentebinaria-readpe