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 | yes | yes | yes | DWARF ingestion; symbols, relocations, sections |
| PE / COFF | yes | yes | yes | PDB support; .pdata parsing on x64 |
| Mach-O | yes | yes | yes | symbols, segments, load commands |
| Java class | yes | — | separate | `classfile`, `java`, `java-recovery-report` |
| Lua bytecode | yes | — | separate | `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 | yes | yes | 32-bit; measured cross-arch as i386 |
| x86-64 | yes | yes | the primary lane |
| ARM (A32 / Thumb) | yes | yes | both encodings measured separately |
| ARM64 / AArch64 | yes | yes | strongest structuring rate of any lane |
| RISC-V | yes | no | disassembly only — the decompiler does not lift it |
| MIPS, PowerPC | yes | no | disassembly 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
.glaurungSQLite 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.
rust
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; python
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") cli
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