Manalyze: a static analyzer that tells you what a PE executable looks like

Primary assessment, with the manual analysis deliberately left to you

Manalyze is a static analysis tool for PE files that you can use to conduct primary assessment on an executable or a set of executables. The way it describes its own scope is the most important thing to understand about it.

It collects weak signals that could indicate malicious behavior, and displays information that can help a subsequent manual analysis. That is the contract. The output is not a verdict, and the tool is not built to produce one. The value is in compressing a tedious first hour of a manual examination into a single run, and in making sure the analyst does not miss the boring checks while staring at the interesting ones.

The static nature of the analysis is the other half of the definition. Nothing is executed. That makes it safe to point at a sample of unknown provenance, and it means the tool sees only what is in the file, not what the file does. A packed or obfuscated sample defeats a great deal of it, which is why packing detection is one of the headline features.

The project is written in C++ for Windows and Linux and is released under the terms of the GPLv3 licence. The architecture is described as a robust parser for PE files with a flexible plugin architecture which allows users to statically analyze files in-depth, and the implementation language of the repository is listed as YARA, which is a clue about where the signature matching lives.

If you want to see what the reports look like before installing anything, the author runs a web service for the tool at manalyzer.org, and the documentation is hosted on Read the Docs.

Seven things it checks, and they are the right seven

The feature list is short and specific, and reading it tells you what an analyst actually wants to know about a PE file.

It identifies a PE's compiler. Which compiler and which version built a binary tells you a great deal about the toolchain used to produce it, and it is a cheap, high-value signal.

It detects packed executables. This is the one that matters most for a static analyzer, because a packed file is a file whose real contents are not visible, so every other check is running against the packer's stub rather than the program.

It applies ClamAV signatures, through Yara, and the implementation detail worth knowing is how the rules get there. Since ClamAV signatures are voluminous and updated regularly, it did not make sense to distribute them from GitHub or with the binary. Instead, you generate them by running the `update_clamav_signatures.py` script in `bin/yara_rules`, and you run it again whenever you want to refresh them. The compiled Yara caches are stored in `$XDG_CACHE_HOME/manalyze/yara_rules` or `~/.cache/manalyze/yara_rules`, and can be overridden with `MANALYZE_CACHE_DIR`.

It searches for suspicious strings, and it looks for malicious import combinations. The example given is `WriteProcessMemory` plus `CreateRemoteThread`, which is the textbook pattern for process injection, and a rule of that shape catches an entire family of techniques that no single-string search would find.

It detects cryptographic constants, just like IDA's findcrypt plugin.

It can submit hashes to VirusTotal, and it verifies authenticode signatures, on Windows only, since that is a platform facility.

Building it is cmake and make, and the offline path needs two manual checkouts

The build documentation opens with a sentiment worth quoting, that there are few things the author hates more than checking out an open-source project and spending two hours trying to build it, and that if the listed lines do not work then the build has failed at its job.

On Linux and BSD, tested on Debian Bullseye and FreeBSD 10.2:

apt-get install libboost-dev libboost-system-dev libssl-dev build-essential cmake git
git clone https://github.com/JusticeRage/Manalyze.git && cd Manalyze
cmake .
make -j5
cd bin && ./manalyze --version

The VirusTotal plugin is optional and requires the Boost.System library, which is worth noting because it is the one dependency that is not in the base package list on some distributions. If you want the tool on the PATH from every directory, `make install` from the root folder does that.

The macOS instructions are similar with a Homebrew line for `openssl boost` and a CMake flag for the OpenSSL location, and the Windows instructions involve Boost from boost.org, CMake, a `BOOST_ROOT` environment variable pointing at the boost folder, and Git, after which a Visual Studio project `manalyze.sln` appears in the folder.

The offline build is the one that will matter for a security team with an air-gapped analysis machine. You have to manually check out two projects, Yara and hash-library, from the author's forks, place them in the `external` folder as `external/yara` and `external/hash-library`, and then run `cmake . -DGitHub=OFF`. The `external/` directory at the top level of the repository is where those live, and the two dependencies are the same ones the top-level listing shows, which is a reminder that the primary language being listed as YARA reflects those vendored pieces rather than the analyser itself.

There is also a community Docker image, `docker pull evanowe/manalyze`, and prebuilt Windows, Linux and macOS archives on the releases page. Each archive includes the binary, the generated shared libraries, the built plugin libraries including the VirusTotal plugin, `manalyze.conf` and the `yara_rules/` directory, so the tool can run straight from the extracted directory with no install.

Paths, environment variables and a config file you can relocate

The path handling is the kind of detail that decides whether a tool is comfortable to run in a pipeline or awkward to run at all, and Manalyze has it covered.

The default install locations honour `CMAKE_INSTALL_PREFIX`. The config file goes to `${CMAKE_INSTALL_SYSCONFDIR}/manalyze/manalyze.conf`, commonly `/etc/manalyze/manalyze.conf` or `/usr/local/etc/manalyze/manalyze.conf`. The rules go to `${CMAKE_INSTALL_DATADIR}/manalyze/yara_rules`, commonly `/usr/share/manalyze/yara_rules` or `/usr/local/share/manalyze/yara_rules`. The plugins go to `${CMAKE_INSTALL_LIBDIR}/manalyze/plugins`.

Each of those can be overridden with an environment variable: `MANALYZE_CONFIG_DIR`, `MANALYZE_DATA_DIR`, `MANALYZE_PLUGIN_DIR` and `MANALYZE_CACHE_DIR`.

For a security team, that last one is the important detail. The compiled Yara signature cache in a shared location is a shared state, and in an environment where different analysts work on different samples, one person's refresh of the ClamAV rules changes what another person's next run sees. Being able to point the cache at a per-user or per-case directory removes that coupling.

The plugin directory override matters for a related reason. A plugin architecture means the set of checks is extensible, and the tool ships as a directory of plugin libraries rather than a single binary with everything linked in. The prebuilt archives include the built plugin libraries, including the VirusTotal plugin, so the standard install is complete, but a deployment that adds its own plugin needs to know where plugins are expected.

The command line is a dump interface, not a report generator

The usage output shows what kind of tool this is, because the options are all about extracting structure from the file.

The `--pe` option takes the PE to analyze and is also accepted as a positional argument, and multiple files may be specified. The `--recursive` flag scans all files in a directory, with subdirectories ignored. The `--output` option takes `raw`, which is the default, or `json`, which is the option that matters for automation.

The `--dump` option is the heart of it. It dumps PE information, and the available choices are any combination of `all`, `summary`, `dos` for the DOS header, `pe` for the PE header, `opt` for the optional header, `sections`, `imports`, `exports`, `resources`, `version`, `debug`, `tls`, `config`, `delay` and `rich`. Being able to ask for the import table alone, or the section table alone, is what makes it usable on a large corpus rather than only on one sample you are reading in full.

The `--hashes` option calculates various hashes of the file, with a note that it may slow down the analysis. The `--extract` option extracts the PE resource.

That command surface is a deliberate choice, and it says something about the tool's philosophy. There is no `verdict` flag and no score. The tool gives you the parsed structure and the signals, in a form you can pipe into something else, and the judgement stays with the analyst. For a team that wants to build its own rules on top, the `json` output and the plugin architecture are the two extension points that matter.

Where Manalyze is the wrong tool

The first case is a need for a verdict rather than a starting point. Manalyze is explicitly built for primary assessment, feeding a subsequent manual analysis. If your workflow needs a score, a classification or a pass and fail on a quarantine decision, this tool is not built for it, and nothing in the output shape suggests it will be.

The second case is a packed or heavily obfuscated sample. Static analysis of a packed executable analyses the packer. Manalyze detects that packing is present, which is the useful thing to do, but the rest of its checks then run against the stub. For a packed sample, a dynamic analysis sandbox tells you far more, and the tool's value in that case is telling you that the static route is closed.

The third case is non-PE malware. The tool is built around the Portable Executable format, and everything it does depends on parsing that structure. A Linux ELF sample, a macOS Mach-O sample or a script-based dropper needs a different tool entirely.

The licence is the practical consideration for a commercial deployment. The project is released under the GPLv3, which is a strong copyleft licence with obligations that matter if you intend to embed Manalyze in a product or to distribute it inside an organisation that treats tooling as part of a shipped product. The plugin architecture and the shared Yara cache also raise the question of how the tool is deployed across a team, and the environment variable overrides are the mechanism for answering that, but they do not answer the licence question.

On versions, the repository has a single release, v1.0.0 from 2026-07-21, and the last push was on 2026-08-29. The repository also carries a `.travis.yml` file, which dates the CI configuration to a time when that was the default choice.

Editorial conclusion

Manalyze fits a malware analyst or a security team that needs a fast first pass over an unknown executable before spending time in a disassembler, because it prints the structure and the weak signals in one run. It does not fit an automated pipeline that wants a verdict, since the tool is built to inform a subsequent manual analysis rather than to classify. Before you rely on it, note the licensing constraint it imposes, since the project is GPLv3 and the generated Yara rules and the compiled caches live in fixed locations on the machine, and check that your ClamAV signatures are refreshed with the bundled script before drawing conclusions from a clean result.

Frequently asked questions

Official sources

1. Issues
2. JusticeRage/Manalyze on GitHub
3. License: GPL-3.0
4. README
5. Releases