PE-bear: a GUI reversing tool for malformed PE files

What PE-bear is for, and who actually needs it

A Portable Executable is the container Windows uses for .exe and .dll files: a DOS stub, a PE header, a section table, an import table, a resource directory, and whatever the author decided to put after that. When an analyst receives a suspicious sample, the first questions are structural rather than behavioural. Which sections exist, what are their raw and virtual sizes, which APIs are imported, is there a TLS directory, does the entry point land inside a section that should not contain code. PE-bear exists to answer those questions quickly through a GUI, and the README states the objective plainly: a fast and flexible first view for malware analysts, stable enough to handle malformed PE files.

That last clause is the differentiator. Malware authors deliberately corrupt headers, overlap sections, and set size fields to values that make strict parsers throw. A tool that refuses to open such a file is useless at exactly the moment you need it. PE-bear is written in C++ against bearparser, its own parsing library, with capstone for disassembly and sig_finder for signature matching. The audience is narrow and technical: reverse engineers, incident responders, and anyone triaging Windows binaries on a machine that is not necessarily Windows.

How the parser, the disassembler and the signature scanner fit together

The repository layout makes the architecture visible. bearparser, capstone and sig_finder are git submodules, pulled in by a recursive clone. bearparser does the structural work: it reads the headers and directories and exposes them as objects the GUI can render as a tree. capstone supplies the disassembly engine, so the code view is generated locally rather than by shelling out to an external disassembler. sig_finder handles signature matching against the bundled SIG.txt, which the README describes as signatures from PEid's UserDB converted by a script. The GUI itself lives in the pe-bear directory, with translations in Language/ and desktop integration files in xdg/.

The consequence of this split is that PE-bear is a viewer and a light editor over a parsing library, not a monolithic application. The parser is the part that has to survive hostile input, and it is the part the project treats as its own product. Everything else, the tree view, the hex view, the disassembly pane, is presentation over that model. If you want to script PE parsing without a GUI, that is a different job: bearparser is the library, and the README does not present PE-bear itself as having a scripting or batch interface.

Installing PE-bear on Windows and Linux

The README points first at the releases page for downloads. On Windows there are three package-manager routes, and the WinGet command is given verbatim in the README:

winget install pe-bear

Chocolatey and Scoop are listed as alternative channels for the same Windows build. Which binary you pick matters. Builds with the vs13 suffix carry no external dependencies. Builds with vs17 or vs19 require the Visual Studio 2015-2022 redistributable. The vs10 build uses Qt4 and exists for backward compatibility with old Windows versions such as XP, and the README warns it may lack features. Linux users should expect to install a suitable Qt version themselves, since the README states the Linux build requires the appropriate Qt to be installed.

If no packaged build fits, the project builds from source. A recursive clone is required because the dependencies are submodules:

git clone --recursive https://github.com/hasherezade/pe-bear.git

On Linux and macOS the repository ships shell scripts rather than a documented CMake invocation. build.sh uses the latest Qt; build_qt6.sh, build_qt5.sh and build_qt4.sh pin specific major versions. On macOS, macos_wrap.sh generates the .app bundle. On Windows the README says to use CMake to generate a Visual Studio project, open it, and build. The wiki page on building from sources is where the README sends you for anything beyond that, and the README itself does not document the CMake flags.

A first real pass over a suspicious binary

The workflow the tool is designed around is loading a file and reading its structure before doing anything else. Open the sample in the GUI and the header fields, section table and directories are laid out for inspection; the README directs users to the wiki for tips and tricks rather than documenting the panes in the repository text. From there the practical checks are the ones any PE triage starts with: whether section names look like a known packer, whether raw sizes and virtual sizes disagree in a way that suggests appended data, whether the entry point falls in an executable section, and what the import table actually references.

The signature scanner is the other entry point. SIG.txt ships in the repository root and the README dates its last update to Oct 17, 2022, noting that it contains signatures converted from PEid's UserDB. The README dates that signature list to 2022. Both missed and coincidental matches are possible, so investigate a positive match and do not treat an absence of matches as proof that a file is clean. Treat the scanner as a shortcut, not as a verdict. The hex view and the disassembly view are there for the cases where no signature fires and you have to read the bytes yourself.

Where PE-bear stops being the right tool

PE-bear is a static inspection tool. It does not execute the sample, does not set breakpoints, and does not observe runtime behaviour. If your question is what the binary does when it runs, you need a debugger or a sandbox, and PE-bear will not answer it. It also does not unpack. Packed binaries can obscure imports and code, though their structure varies. Unpacking is a separate task and may require other tools.

The editing capability deserves a caution of its own. The project describes itself as a reversing tool and the topic list includes pe-editor, so modification of fields is part of the design. Editing a PE and then running it is a good way to produce a file that crashes for reasons unrelated to the original malware, and the README does not document any validation pass or rollback for edits. Work on a copy. There is also no documented command-line mode or batch interface, so anything involving hundreds of samples is outside the tool's scope as described; the README presents it as a GUI application throughout.

PE-bear versus CFF Explorer and other PE viewers

The obvious comparison is CFF Explorer, the long-standing Windows PE editor bundled with Explorer Suite, which is what a generation of analysts learned on. The difference in approach is portability and parsing posture. CFF Explorer is a Windows application; PE-bear is a Qt-based multiplatform project, with Linux builds and macOS source-build instructions. Check current distribution availability and test the tools on representative files.

The second difference is the stated tolerance for malformed files. PE-bear’s README frames the project around malware analysts and handling malformed files. That framing is a design priority, not a guarantee, and the README offers no test corpus or comparison to back it up. A reasonable approach is to keep both: when one parser rejects a sample, the other may still render it, and the disagreement itself is informative. The bundled SIG.txt also inherits from PEid, so analysts who already maintain PEid signature sets will find the format familiar rather than novel.

Maintenance cadence, licence and the cost of staying current

The project publishes releases and also describes AppVeyor test builds for commits to the main branch, warning that those builds may be unstable. Check the release page for current versions and platform-specific requirements. The README dates its bundled signature list to October 2022; verify its current contents before relying on it.

The repository is GPL-2.0 licensed. If distributing modified software or combining it with other code, review the applicable licenses, including those of dependencies. On Linux, the project notes that its build requires an appropriate Qt version; verify the requirements for the specific package you install.

Editorial conclusion

PE-bear gives analysts a graphical first look at PE structures and includes a disassembly view. It is not a debugger or a substitute for dynamic analysis. Check the current release and its platform dependencies, use an isolated analysis environment for untrusted samples, and corroborate findings with other tools.

Frequently asked questions

Official sources

1. hasherezade/pe-bear on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases