HELIOS: Hierarchical Graph Abstraction for Structure-Aware LLM Decompilation

This skill enables Claude to perform high-quality binary decompilation by treating it as a structured reasoning task rather than plain text translation. Instead of feeding raw decompiler output directly to the LLM, HELIOS encodes the program's control-flow graph (CFG) and function-call graph (FCG) into a hierarchical text representation with three abstraction levels -- function-level metadata, block-level control flow, and instruction-level semantics -- then combines this with the raw pseudo-C output and optional compiler error feedback. This approach raises compilability from ~45-71% to 85-94%+ and improves functional correctness by up to 5.6 percentage points across x86, ARM, and MIPS architectures, all without model fine-tuning.

When to Use

• When the user provides a binary, object file, or disassembly and asks you to produce compilable C source code
• When decompiler output (from Ghidra, IDA, Binary Ninja) contains broken control flow, missing branches, or won't compile
• When reverse engineering an optimized binary where the decompiler's pseudo-C is syntactically fragile or logically inconsistent
• When the user needs to decompile across architectures (x86_64, ARM, MIPS) and wants consistent results
• When analyzing malware or firmware and the user needs recompilable, semantically faithful C code for further analysis
• When the user has Ghidra P-Code or CFG data and wants to use it to improve decompilation quality

Key Technique

The core insight: LLMs treat decompiled code as flat text and ignore the graph structures that govern program control flow. This causes them to hallucinate branches, invent variables, and produce code that doesn't compile. HELIOS fixes this by extracting the control-flow graph from a binary analysis tool (Ghidra), encoding it as structured text at three hierarchical levels, and supplying it alongside the raw decompiler output as a structured prompt.

The three-level hierarchy: Level 1 (FUNCTION_CONTEXT) provides a compact summary -- function name, signature, target architecture, number of basic blocks, and loop count. Level 2 (CFG_OVERVIEW) encodes the CFG as an adjacency list, showing each basic block's successors and structural role (loop header, branch target, exit block). Level 3 (BLOCK_DETAILS) contains distilled P-Code instructions for each basic block, giving the LLM ground-truth semantic operations to reason against. This hierarchy lets the LLM check its own output: every branch in the generated C must correspond to an edge in the CFG, and no new global variables should appear unless grounded in the block details or raw decompilation.