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. That date matters: a signature file that has not moved since 2022 will not recognise packers and protectors that appeared afterwards, so a clean scan is weak evidence and a positive match is strong evidence. 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. A binary protected by a commercial packer will show you a small import table and an entry point in an unfamiliar section, and that is the end of what the structure can tell you; removing the layer is a separate discipline with separate 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 ships Linux and macOS builds and uses Qt for its interface, which is why search traffic around this project clusters on Linux installation. If your analysis environment is Linux, that alone decides the question.

The second difference is the stated tolerance for malformed files. CFF Explorer is a general-purpose PE editor built for legitimate binaries; PE-bear's README frames the whole project around malware analysts and around handling files that are deliberately broken. 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 last push to main was on 2026-09-20, three days before this writing, and the most recent release is v0.7.2 from 2026-06-05. The gap before that was longer: v0.7.1 landed on 2025-04-26 and v0.7.0.4 on 2025-04-13. So the pattern is bursts of release activity separated by roughly a year, with commits continuing in between. The repository is not archived. AppVeyor produces test builds on each commit to main, and the README warns those may be unstable, which gives you a way to try unreleased fixes without waiting for a tagged version. The SIG.txt file is a separate cadence entirely and has not been updated since 2022.

PE-bear is GPL-2.0. For an analyst running it locally, the licence is unremarkable. It becomes a real consideration if you intend to link bearparser into your own product or ship a modified PE-bear inside a commercial pipeline, because GPL-2.0 carries copyleft obligations that a permissive licence would not. That is a question for your own legal review, not something the README addresses. Upgrading between releases is a download and replace on Windows; on Linux it means rebuilding against whatever Qt you have, and the Qt4 path is explicitly the legacy one.

Editorial conclusion

PE-bear suits malware analysts and incident responders who need a quick structural read of an untrusted PE, including files that parsers reject. It is not a debugger, a disassembler or a packer-removal tool, so anyone expecting to step through code or unpack a protected binary should look elsewhere first. Before adopting it in a workflow, verify the release suffix matches your runtime: the vs17 and vs19 Windows builds need the Visual Studio 2015-2022 redistributable, the Linux build needs a matching Qt installed, and only the vs13 build ships with no external dependencies.

Frequently asked questions

Official sources

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