Pharos puts a Prolog reasoning layer on top of ROSE disassembly

ROSE underneath, reasoning on top

Pharos does not implement its own disassembler. The README states that it uses the ROSE compiler infrastructure developed by Lawrence Livermore National Laboratory for disassembly, control flow analysis, instruction semantics, and more. What CMU SEI added is a layer above that, and the layer is what makes the tools different from a general purpose reverse engineering suite.

The visible pieces are a library, libpharos/, a set of tools/ directories each containing a .pod file, share/ holding the rule data, scripts/ holding build helpers, and tests/ with a gtest/ directory. CMakeLists.txt drives the build, and there is a Dockerfile, a .devcontainer/ directory and azure-pipelines.yml.

The most distinctive component is the Prolog rules. OOAnalyzer was rewritten from an earlier implementation called Objdigger using Prolog rules to recover object attributes, and the README links a CCS 2018 paper describing that work. share/prolog/oorules/ carries the rules, with separate notes on running the tool against very large executables. A rule base you can read and edit is the reason to choose this framework over a binary whose internals are opaque.

The last push was on 2026-09-16, and there are no GitHub releases, so there is no tagged version to pin.

Only OOAnalyzer states what it accepts

The README is uneven about input support, and the unevenness is the most useful thing to know before you plan a pipeline.

OOAnalyzer, the tool for analysis and recovery of object oriented constructs, identifies object members and methods by tracking object pointers between functions. Its supported input is stated plainly: only 32-bit x86 executables compiled by Microsoft Visual C++. A previous implementation was named Objdigger and was renamed to reflect the Prolog rewrite.

The other tools say nothing about architecture, compiler or format. APIAnalyzer finds sequences of API calls with specified data and control relationships, intended for paradigms such as opening a file, writing to it and closing it. CallAnalyzer reports static parameters to API calls and doubles as a demonstration of the calling convention, parameter analysis and type detection work. FN2Yara generates YARA signatures for matching functions. FN2Hash produces hashes and other descriptive properties for functions, usable for similarity analysis or as features for machine learning.

If your corpus is ARM, or Rust, or Go output, the README gives you no basis for expecting results from any of them. Treat OOAnalyzer's stated restriction as a warning about the whole distribution rather than an isolated fact.

DumpMASM is the exception the README warns about directly. It dumps disassembly listings in the same style as the other tools, but it has not been actively maintained and the recommendation is to use ROSE's standard recursiveDisassemble instead.

Building it is the hard part, and the Dockerfile shows the way

The repository ships an INSTALL.md for build details, and the Dockerfile is the most concrete record of what a working build actually needs. The dev stage is based on ubuntu:noble and installs a long apt list: build-essential, flex, ghostscript, bison, automake, libtool, python3 with setuptools, sqlite3 and libsqlite3-dev, zlib1g-dev, cmake, ninja-build, libyaml-cpp-dev, a large set of libboost packages covering chrono, filesystem, iostreams, program options, random, regex, system, wave, thread and timer, plus libxml2-dev and libcapstone-dev.

It then runs a prerequisite script before the project source is copied in, so that ROSE, SWI-Prolog and z3 are built once and not rebuilt on every source change.

mkdir -p /root/pharos/scripts/
/root/pharos/scripts/build_prereqs.bash

The source is added, the build runs from /root/pharos/build, and afterwards static archives are stripped from /usr/local/lib and /usr/local/bin.

/root/pharos/scripts/build.bash

A test stage exists as well and runs the unit tests through ctest.

ctest --output-on-failure -j $NCPU

The dev stage accepts an NCPU build argument and sets CXXFLAGS to --param ggc-min-expand=5 --param ggc-min-heapsize=32768, which the comment describes as reducing memory use by default. A reclaimed stage deletes the build directory and the swipl-devel, z3 and rose trees for a smaller runtime image.

Read that dependency list as the cost of entry. SWI-Prolog, z3 and ROSE are built from source here.

The README asks you to expect rough edges

The project's own framing is unusually candid. The README calls Pharos a research project whose code is under active development, provides no warranties of fitness for any purpose, and says that while the release provides build instructions, unit tests and some documentation, much work remains to be done.

The specific admission is about portability: a few select build configurations have been tested, but the portability of the source code has not been actively tested. For anyone planning to run this across a fleet, that sentence is the whole risk assessment.

The stated reason for releasing at all is transparency into the research and to stimulate conversation with other binary static analysis researchers. The README names a contact, Ed Schwartz, and is candid that a timely response may not happen. There is no support commitment, no versioned release, and no changelog to diff against. Changelog discipline is something this project does not have; the tool descriptions and the paper are the documentation.

The licence is BSD, as stated in the README and carried in LICENSE.md.

The Ghidra integration moved out to Kaiju

One integration path in this repository is gone, and the replacement is named. The Pharos distribution used to include a plugin that imported OO information exported by OOAnalyzer into Ghidra. To get that functionality now, the README directs you to Kaiju, the CERT CC Ghidra plugin, which includes what the old OOAnalyzer plugin provided.

That is the right shape for an alternative comparison rather than naming a competitor and describing nothing. The two approaches differ in where the reasoning happens. In Pharos proper, the analysis runs as separate command line processes over the ROSE intermediate representation, with the results in files, which suits batch work over a corpus and suits anyone who wants to change the Prolog rules.

The trade is environment against programmability. Ghidra gives you a decompiler and manual annotation alongside the recovered OO structures; Pharos gives you a rule base you can fork. FN2Yara and FN2Hash sit on the Pharos side of that line, since both are about producing artifacts to feed elsewhere rather than about reading code in a UI.

Editorial conclusion

Pharos fits research groups and reverse engineers who want to read OOAnalyzer's Prolog rules and adapt them, or who need function level YARA generation from a ROSE disassembly rather than from disassembly alone. It does not fit production pipelines that need predictable cross platform results, since the README states portability is untested and only one tool states its supported input at all. Before adopting it, build it through scripts/build.bash as the Dockerfile does, run the ctest suite the test stage runs, and confirm against your own executables that OOAnalyzer gives answers on your compiler output rather than assuming the Visual C++ result carries over.

Frequently asked questions

Official sources

1. cmu-sei/pharos on GitHub
2. Issues
3. README