A CMake packaging of Ghidra's SLEIGH processor-semantics library that lets reverse engineers embed disassembly and p-code lifting into standalone tooling for authorized analysis.

SLEIGH is the language Ghidra uses to describe the semantics of instruction sets for general-purpose microprocessors, with enough precision to support serious reverse engineering of compiled software. It underpins two of Ghidra's most important engines: the disassembler and the decompiler. What lifting-bits/sleigh does is take that NSA-maintained C++ implementation and wrap it in a CMake build project so it can be compiled, installed, and consumed as a standalone library by tools that are not Ghidra at all. That is a genuinely useful unlock for anyone building custom binary-analysis pipelines who does not want to reimplement instruction semantics or shell out to a full IDE.

The repo metadata tells you the audience before you read a line of the README: topics include binary-analysis, decompiler, disassembler, reverse-engineering, and sleigh, with the primary language listed as CMake itself — a strong hint that this is infrastructure rather than an end-user application. It is licensed Apache-2.0, sits at a modest 191 stars on the master branch, and supports all three major platforms: Linux, macOS, and Windows. Cross-platform parity matters here because a lifting library that only builds on one OS dramatically limits its usefulness in heterogeneous analysis environments.

One architectural detail deserves immediate attention: the Ghidra source code is not vendored into this repository. During CMake configuration, the build system pulls a stable version of the upstream source from the internet automatically. The src/README.md documents how to customize which commit is used, including pointing the build at a local copy of the Ghidra tree. From a supply-chain perspective this is the single most important thing to verify: if you are building analysis tooling for sensitive work, pin the fetched commit or supply your own audited source tree rather than accepting whatever the default resolution grabs.

Dependencies are deliberately minimal. Required components are zlib for HEAD builds, Git, and CMake 3.18 or newer. Optional packages — Doxygen and GraphViz — exist only for building documentation. That lean dependency surface is part of the point of the project: you get the SLEIGH engine without the considerable weight of the full Ghidra distribution. The build flow is the standard modern CMake incantation: cmake -B build -S . to configure, cmake --build build --parallel 8 to compile, and cmake --install build --prefix ./install to deploy. Packaging is supported directly via cmake --build build --target package, which makes it practical to distribute the library across a lab environment.

The README includes a demonstration program called sleigh-lift that doubles as the clearest documentation of the library's API. It accepts a hexadecimal byte string and either disassembles it or lifts it to p-code, Ghidra's architecture-neutral intermediate representation. The invocation pattern is sleigh-lift [action] [sla_file] [bytes] [-a address] [-p root_sla_dir] [-s pspec_file], where the action is either disassemble or pcode and the sla_file is a compiled processor specification. Feeding it x86-64.sla with the bytes 4881ecc00f0000, for example, yields SUB RSP,0xfc0 — a stack-pointer adjustment recognizable to anyone who has read compiler prologues.

The p-code output is where the real analytical value shows itself. Instead of a mnemonic, you get a sequence of IR operations: INT_SUB, INT_LESS, INT_SBORROW, POPCOUNT, and flag computations against register and unique varnodes with explicit sizes and addresses. Because p-code normalizes every architecture into the same semantic vocabulary, tooling built on top of this library can reason about x86-64, ARM, or PowerPC code through one uniform interface. That is precisely why decompilers and emulators built on p-code can be architecture-agnostic, and it is the property that makes this library attractive as a foundation for custom static analysis.

If you do not want the demonstration binary, the sleigh_BUILD_EXTRATOOLS CMake option can be set to OFF during configuration to skip building sleigh-lift entirely. This kind of toggle reflects the project's orientation toward being embedded rather than used directly — consumers typically want the library and the spec-compilation machinery, not the example front end.

A small but thoughtful convenience lives in the support directory: a helper that is not part of upstream SLEIGH or Ghidra. The sleigh::FindSpecFile function takes a file_name and a vector of search_paths, returning a std::optional to the located specification file. Its default search path, sleigh::gDefaultSearchPaths, includes the install and build directories generated during CMake configuration plus a set of common installation locations. This solves the annoying practical problem of knowing where compiled .sla files actually landed on a given system. As with the tools, sleigh_BUILD_SUPPORT set to OFF removes the helpers from the build.

Integration as a dependency is clearly a first-class concern rather than an afterthought. An installed SLEIGH exposes a CMake interface consumable with find_package, demonstrated in the tests/find_package/CMakeLists.txt example. The project also ships a sleigh_compile helper function in cmake/modules/sleighCompile.cmake for compiling your own .slaspec files, with a fuller worked example in the example directory that uses upstream Ghidra example sources. The sleigh_INSTALL_SPECDIR CMake variable gives you the absolute path to the root directory of compiled sleigh files, and the README candidly advises you to inspect it manually to know what to expect — sensible advice given how spec layouts vary across versions.

In an authorized workflow, where this fits is the space between "I'll just open it in Ghidra" and "I need a repeatable, scriptable analysis pipeline." Threat researchers triaging firmware across many architectures, engineers building automated triage for submitted binaries, and tool authors adding disassembly or decompilation-grade semantics to their products all benefit from a buildable, linkable SLEIGH. Because the output is deterministic analysis of bytes you already possess, it is a purely passive instrument — there is nothing here that touches a target system, making it equally at home in defensive malware research and internal toolchain work.

Things to watch for: the internet-fetching configuration step means build reproducibility depends on pinning the Ghidra source commit, and consumers should track upstream Ghidra releases to pick up new processor specifications and semantic fixes. The README is honest that this is an unofficial packaging, so alignment with upstream API changes is a maintenance consideration for anything you build on it. Still, as a piece of infrastructure that liberates one of the best open-source semantics engines from its IDE harness, lifting-bits/sleigh earns its place in a serious analyst's toolchain.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Inside MiniVisorPkg: a UEFI hypervisor that boots your OS under observation


• revng for lifting binaries into an analyzable LLVM intermediate representation


• TitanHide for stealthy debugger concealment during authorized reverse engineering