Glaurung 0.1.0

formats, processors, and commands

RISC-V, MIPS, and PowerPC stop after disassembly. There is no GUI.

Input

file formats

format triage disassembly decompiler notes
ELF yesyesyesDWARF ingestion; symbols, relocations, sections
PE / COFF yesyesyesPDB support; .pdata parsing on x64
Mach-O yesyesyessymbols, segments, load commands
Java class yesseparate`classfile`, `java`, `java-recovery-report`
Lua bytecode yesseparate`luac`

Processors

RISC-V stops after disassembly

MIPS and PowerPC stop there too. x86, x86-64, ARM, and ARM64 also lift to the intermediate representation used by the decompiler.

architecture disassembles lifts to IR notes
x86 yesyes32-bit; measured cross-arch as i386
x86-64 yesyesthe primary lane
ARM (A32 / Thumb) yesyesboth encodings measured separately
ARM64 / AArch64 yesyesstrongest structuring rate of any lane
RISC-V yesnodisassembly only — the decompiler does not lift it
MIPS, PowerPC yesnodisassembly engines selectable; not lifted

Analysis

passes you can run

  • Function discovery, control-flow graphs, call graphs, cross-references
  • Stack-frame analysis and stack-variable recovery
  • Type propagation and struct recovery
  • DWARF ingestion; PE/PDB ingestion and naming
  • FLIRT signature matching for library functions
  • Symbol demangling — Itanium, Rust, MSVC
  • String extraction with encoding classification and cross-references
  • Entropy analysis and packer detection (UPX, Themida, VMProtect, and others)
  • Binary similarity and function-level diffing between two binaries
  • An LLIR → SSA → AST pipeline producing C-like pseudocode
  • Persistent .glaurung SQLite projects with undo and redo
  • Names, comments, labels, types, prototypes, bookmarks and journal entries, each with provenance
  • Windows driver analysis: windows-risk, IOCTL dispatch recovery, buffered-input taint
  • Optional PydanticAI agents for question answering, naming, vulnerability review and source recovery
  • Byte patching at a virtual address, and a recompile-and-verify path

Interfaces

one Rust engine

PyO3 exposes the engine to Python. The command line calls the same bindings.

rust456 files · 283,732 lines
src/lib.rs — the module list
pub mod core;        pub mod triage;      pub mod symbols;
pub mod demangle;    pub mod similarity;  pub mod strings;
pub mod entropy;     pub mod analysis;    pub mod debug;
pub mod flirt;       pub mod disasm;      pub mod ir;
pub mod decompile;   pub mod formats;     pub mod winmd;
pub mod program;     pub mod unpack;      pub mod target;
pub mod error;       pub mod logging;     pub mod timeout;

#[cfg(feature = "exec")]     pub mod exec;
#[cfg(feature = "symbolic")] pub mod symbolic;
#[cfg(feature = "python-ext")] pub mod python_bindings;
python87 exported names · PyO3
Python PyO3
import glaurung as g

# Triage: format, architecture, hardening, strings, entropy.
art = g.triage.analyze_path("/bin/ls")
v = art.verdicts[0]
print(v.format, v.arch, v.bits, v.confidence)

# The analysis types are the same objects the Rust core builds.
# Binary, Function, ControlFlowGraph, BasicBlock, Instruction,
# DataType, Reference, Section, Segment, StringLiteral, Symbol, ...
print(len([n for n in dir(g) if not n.startswith("_")]), "exported names")
cli40 subcommands
glaurung --help 2026-08-31
triage            strings           symbols           disasm
cfg               decompile         explain           name-func
ask               repl              graph             detect-packer
diff              kickoff           patch             verify-recovery
export            undo              redo              xrefs
frame             strings-xrefs     view              find
bookmark          rename            comment           label
proto             journal           classfile         java
java-recovery-report                luac              pe
windows-risk      types             windows           locks
group