XPEViewer inspects and edits PE files on all three desktop platforms

A PE tool that does not need Windows

XPEViewer is described as a PE file viewer and editor for Windows, Linux and MacOS. The Portable Executable format is the container that Windows executables, DLLs and drivers use, and the tools that understand it have historically been Windows tools, so a cross platform one is the first thing that distinguishes this project.

The audience is a reverse engineer, a malware analyst, or a developer who needs to know what is inside a Windows binary while working on a different operating system. That includes the case of a Linux CI job that needs to inspect a PE, and the case of a developer who has both machines and does not want to switch. The project topics list the disassembler, the PE format, portable executable and reverse engineering, and the special thanks section credits PELock Software Protection and Reverse Engineering, which places the project in the protection analysis world rather than the developer tooling world.

The application is written with Qt, and the project is a long lived one. The releases are numbered 0.06 on 2025-12-22 and 0.05 on 2024-07-02, with a Beta tag from 2022-12-14 before them, and the last push was on 2026-10-15, with the repository not archived. So the source moves faster than the release tags, which is a fact worth keeping in mind when you read the version number.

The licence is MIT, the documentation is hosted in the repository itself under docs/, and the project has an associated homepage at ntinfo.biz. Translations are handled through a separate project, XTranslation, which is the same arrangement the author uses across the other tools in this family.

The directory names are the feature list

The repository root is a list of component directories, and for a tool like this the names are unusually informative because each one is a self-contained area of the application.

The analysis side is the largest group. XCapstone is the disassembler component, with XDisasmCore and XDisasmView next to it, so the decoding engine and its presentation are separate. XDecompiler is a decompiler component, XDemangle and XLLVMDemangler handle C++ and LLVM name demangling, and XCppfilt is the filter front end for it. XDynStructs with its engine and widget is the structure editing part, XStaticScan and XScanEngine are the static scanning side, and XYara is the Yara rule matching integration, which is how the tool checks a binary against signatures.

The inspection widgets cover the rest. XHexView and XHexEdit are the hex viewer and editor, XEntropyWidget is the entropy visualisation, XRegionsWidget is the region map, XSymbolsWidget handles symbols, XVisualizationWidget is the general visualisation, XMemoryMapWidget shows the memory map, and XFileInfo is the file properties view. XPDF exists for PDF handling, XPEID is the PEiD signature database support, XInfoDB is the signature and information database, and XExtractor and XArchive handle pulling content out of the file.

There is a Detect-It-Easy directory, and the presence of a .gitmodules file tells you that it is a git submodule rather than vendored source. That is a significant dependency to be aware of, because the components are not all maintained in one repository, and a clone without submodules gives you a directory that does not build.

The rest of the tree is the application shell: the XOptions and XStyles and XShortcuts configuration, XUpdate for the update mechanism, XOnlineTools, XGithub, XTranslation, XQwt for the Qt plotting widget, XAboutWidget, plus the shared Controls, Formats, FormatDialogs, FormatWidgets and SpecAbstract directories.

Two build systems, a qmake project file and a Debian script

Building this is a Qt project with two supported build paths, which is common for a codebase of this vintage.

The root holds a CMakeLists.txt and a build.pri, the qmake include file, along with a build_dpkg.sh script, a build_libs/ directory and a Dockerfile. The qmake project file is the older path, and the CMake file is the one that newer tooling expects.

The Dockerfile shows what the Linux build actually needs, and it is a short recipe. The base image is ubuntu:bionic by default, overridable through a build argument named image, and the source stage installs git and clones the repository with the recursive flag, which is what pulls the submodules. The builder stage then installs build-essential, qt5-default, qtbase5-dev and qttools5-dev-tools, checks that qmake is present by printing its version, and finally runs the packaging script from inside the cloned directory:

cd XPEViewer &&  bash -x build_dpkg.sh && bash -x install.sh

Two observations from that. The recursive clone is not optional, since the Detect-It-Easy component is a submodule. And the build is a Debian packaging script rather than a plain cmake invocation, which means the produce is a .deb, and the script is doing the work of a distribution package rather than a developer build.

The bionic base is worth noting too. Ubuntu 18.04 is an old baseline for a tool released at the end of 2025, and the image argument exists so you can point it at something newer, which is probably what you want if you are reproducing a build today.

Viewing and editing are different jobs, and only one of them is safe to guess at

The word editor in the description is the part with consequences, and it is worth separating what the tool shows from what it lets you change.

The viewing side is unambiguous and safe. A hex view, a disassembly view, entropy and region visualisations, symbol information, the memory map, a file properties panel and signature database lookups are all read only in effect, and they are the features a reverse engineer reaches for daily. A cross platform PE viewer with all of those in one window is the clear value proposition.

The editing side is different. The presence of a hex editor, a dynamic structures engine, a static unpacker and a decompiler means the application can write changes back into the file. That is a capability with real consequences, because a modified executable is a different artefact: its hash changes, its signature stops matching, and any check that expects a known build of that binary will behave differently. It is also, in the hands of someone testing a protection scheme, exactly the point.

What the project documentation does not appear to cover is workflow guidance. The README points to RUN.md for how to run the application, BUILD.md for how to build it and changelog.txt for the history, and none of those is described as a guide to safe editing practice, to backups before modification, or to how the editing features interact with a running sample. For a tool where the natural next question after inspecting a binary is changing it, that gap is worth filling by reading the code rather than by assuming.

The static unpacking component deserves a specific mention for the same reason. Unpacking a protected binary changes it, and the tool that does it is often the tool you want to run on evidence, so the operational habit of working on a copy is not optional advice here, it is the difference between a sample and a lost sample.

Releases at 0.06, a changelog file, and the wider tool family

The release history is the least conventional part of the project and the most useful to know in advance.

The tags are 0.06 on 2025-12-22, 0.05 on 2024-07-02 and a Beta tag from 2022-12-14. So there was a gap of about a year and a half between 0.05 and 0.06, and the version numbering is a decimal pair rather than a semantic version, which means there is no major version promise and no compatibility contract to lean on. Downloads are published as GitHub releases, with the release badge and a downloads badge in the README, and the changelog is a plain changelog.txt file at the repository root rather than a GitHub release note.

Against that, the last push was on 2026-10-15, roughly ten months after the last tag. That gap means the source tree is well ahead of what a user gets from the download button, and it is the sort of project where a bug fix in master is not yet in a release. Whether that matters to you depends on whether you want the newest behaviour or the newest stable artefact.

The project also sits inside a family of related tools by the same author, several of which appear as directories or submodule hooks here: Detect-It-Easy, XTranslation for the localisation workflow, XCapstone for the disassembly engine, and XPDF, XExtractor and XArchive for content handling. XPEViewer is the shell that ties several of them together into a GUI, which explains both the breadth of the directory list and the submodule dependency.

For a user, the practical checklist is short: download a release if you want a stable build, clone recursively if you want to build or to work on it, read the changelog to see how far master has moved past 0.06, and remember that the translation work happens in a separate repository.

Editorial conclusion

XPEViewer suits a reverse engineer who analyses Windows binaries on a Linux or macOS workstation, or a developer who needs to look at and adjust PE structure rather than only read it, and it suits someone who wants one tool for disassembly, hex editing, entropy, symbols and structure work. It is the wrong choice if you want a polished, frequently released product, because the version numbers are still at 0.06 and the release cadence is irregular, and a poor match if you need to ship a reproducible binary analysis environment, because the build depends on a Qt5 toolchain and a set of submodules. Before adopting, read docs/RUN.md and docs/BUILD.md, clone with submodules since the Detect-It-Easy component is a submodule, and check the changelog to see how far the current source has moved past the last tagged release.

Frequently asked questions

Official sources

1. horsicq/XPEViewer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases