Idioms: A Simple and Effective Framework for Turbo-Charging Local Neural Decompilation with Well-Defined Types

Idioms: A Simple and Effective Framework for Turbo-Charging Local Neural Decompilation with Well-Defined Types

Speakers: Luke Dramko

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=6xgO2P2-LuY

Overview

This talk presents Idioms, a framework for improving neural decompilation -- using locally-hosted LLMs to recover readable, type-rich source code from compiled executables. The key insight is twofold: user-defined types (UDTs) like structs and unions are integral to code structure and must be predicted alongside the code, and interprocedural analysis is essential because type information often can only be inferred from how data is used across multiple functions. By including the bodies of related decompiled functions in the LLM's context and training it to predict both code and type definitions simultaneously, Idioms outperforms existing neural decompilers like LLM4Decompile on both correctness and code quality metrics.

The work also introduces RealType, a new benchmark dataset rich in user-defined types, and a novel dependency-graph-based correctness metric that avoids the limitations of unit-test-based evaluation. The entire approach runs on local 7B parameter models, making it suitable for classified or controlled environments where sending code to third-party APIs is prohibited.

Background

▶ Watch: The decompilation problem: compilation discards types, names, and structure (0:00)

Security practitioners regularly analyze executable programs where source code is unavailable. This is essential for malware analysis, vulnerability research, and patching legacy software. Reverse engineers rely on decompilers like Hex-Rays/IDA Pro, Ghidra, and Binary Ninja to convert executables back into higher-level languages like C. However, compilation is lossy: variable names, user-defined types, structured control flow, and comments are all discarded. Decompilers can recover structure but must make best guesses for the discarded information, resulting in generic placeholder names, size-based type substitutions, and desugared struct field accesses.

Neural decompilation uses LLMs to improve decompiled output by predicting what the original code looked like. Two approaches exist: direct translation from assembly to predicted source code, or treating the LLM as a refinement stage after a deterministic decompiler. The refinement approach is more effective for theoretical reasons: assembly is information-sparse (many instructions for few source characters), and translating between more similar languages (decompiled C to original C) is easier than between dissimilar ones (assembly to source C).

A critical constraint is that many stakeholders in government and industry adjacent to government are subject to information control policies that prohibit sending controlled or classified data to third-party cloud services. This motivates the use of local, fine-tuned LLMs rather than prompting commercial models like GPT-4.

Key Findings

▶ Watch: Insight 1: Types directly impact code structure, not just labels (4:00)

• Types directly impact code structure: User-defined types aren't just labels -- they determine the syntax of struct field accesses, pointer arithmetic patterns, and data flow. Without correct types, decompiled code is structurally misleading
• Interprocedural context is essential: A function's type usage often can only be resolved by examining how its parameters are used in other functions. Without this context, an LLM predicted the wrong collision resolution strategy for a hash table (separate chaining instead of linear probing), producing functionally incorrect code
• Joint prediction of code and types outperforms separate prediction because it ensures consistency between type definitions and their usage in code
• Idioms outperforms LLM4Decompile and other baselines on both correctness metrics (dependency graph isomorphism, unit tests) and quality metrics (variable name accuracy, type accuracy, UDT prediction)
• The RealType benchmark fills a gap in existing evaluation: prior benchmarks contain very few user-defined types, which are one of the central challenges of real reverse engineering
• The dependency-graph-based metric provides a more nuanced and theoretically grounded evaluation than unit tests alone, measuring whether the predicted code performs the same partially-ordered sequence of operations as the original
• All results achieved with a 7 billion parameter model running locally

Technical Deep Dive

▶ Watch: Ablation: wrong hash table algorithm predicted without cross-function context (8:00)

The Type Problem in Decompilation. Consider desugared struct field accesses in decompiled output: *(a1 + 8) instead of table->entries. Without knowing that a1 is a pointer to a HashTable struct with an entries field at offset 8, the decompiled code is opaque. Types aren't merely annotations -- they determine whether you see array indexing, pointer arithmetic, or struct field access, fundamentally changing how a reverse engineer interprets the code.

Interprocedural Analysis for Type Recovery. To determine the type of a field at offset a1+8, Idioms includes the bodies of other decompiled functions that use the same data. If a1+8 is passed to func_one as an argument, examining func_one reveals that the argument is typecast to a pointer and dereferenced (implying it points to non-pointer data), and that at offset 8 there's an array-style access pattern (implying a struct with at least two elements). This interprocedural information transforms an ambiguous offset into a concrete type inference.

Architecture. The final pipeline takes decompiled code plus related function bodies as input and predicts the original code alongside corresponding type definitions (struct and union declarations). The simultaneous prediction ensures that type names and field names in the definitions match their usage in the code body -- a consistency that cannot be guaranteed when using separate type prediction tools.

Evaluation Framework. The novel correctness metric treats functions as dependency graphs where nodes are operations and edges are data/control dependencies. Two functions are considered equivalent if their dependency graphs are isomorphic. The researchers developed a novel technique (published separately) that makes graph isomorphism tractable for dependency graphs specifically, avoiding the general problem's lack of known polynomial-time algorithms. Once operations are mapped between predicted and original code, variables can be matched, enabling evaluation of name accuracy, type accuracy, and UDT correctness. A softer metric variant ignores identifier names (which are notoriously difficult to predict exactly) and evaluates only structural type correctness.

RealType Benchmark. Existing benchmarks like ExeBench contain very few user-defined types. RealType was specifically designed to include complex structs and unions, filling a critical evaluation gap. Because meaningful unit tests for complex data structures with implicit invariants are extremely difficult to generate, the dependency-graph metric provides an alternative correctness measure.

Demo / Proof of Concept

▶ Watch: Dependency-graph-based correctness metric and RealType benchmark (10:00)

The motivating example traced through the entire talk showed a hash table implementation with linear probing. When given only the target function without interprocedural context, the LLM predicted a hash table with separate chaining (linked lists) -- a different and incorrect algorithm. With interprocedural context from related functions, the prediction correctly identified linear probing with an array-backed data store, matching the original implementation. This concrete example demonstrated that the difference between useful and misleading decompilation hinges on the availability of cross-function type information.

The presenter also highlighted a comparison with LLM4Decompile where poor variable names obscured the fact that the model had identified the first argument as a struct pointer and successfully resugared a field access, but without adequate type information, it was impossible to verify correctness.

Defensive Implications

▶ Watch: Q&A: cybersecurity applications and compiler-induced bug detection (16:00)

• Improved decompilation accelerates malware analysis: More readable and type-accurate decompiled code reduces the time reverse engineers need to understand malware behavior, improving incident response speed
• Local deployment enables classified work: Running on 7B parameter local models means this tool can be used in air-gapped or classified environments where cloud LLM access is prohibited, directly benefiting government malware analysis teams
• Verification remains critical: Neural decompilers can make arbitrary mistakes that deterministic decompilers cannot. The presenter's ongoing thesis work on a verification tool to double-check predictions against decompiled code addresses this risk
• Red team efficiency: Vulnerability researchers using decompilation for red teaming benefit from faster, more accurate type recovery, potentially enabling them to find bugs before adversaries
• Compiler-induced bugs: An audience member raised the intriguing possibility of using this technique to identify cases where compilers introduce bugs during optimization -- a novel defensive application the presenter acknowledged as promising future work

Key Takeaways

• User-defined types (structs, unions) are not just annotations -- they fundamentally determine code structure and must be predicted alongside the code for meaningful decompilation
• Interprocedural context is essential for type recovery: without cross-function information, neural decompilers produce functionally incorrect predictions
• Idioms outperforms existing neural decompilers by jointly predicting code and type definitions with interprocedural context, all on a local 7B parameter model
• The RealType benchmark and dependency-graph-based correctness metric address critical gaps in neural decompilation evaluation
• Local deployment makes this approach practical for government and classified environments where sending executables to cloud services is prohibited
• Neural decompilation is not a replacement for deterministic decompilers but a powerful refinement layer that makes reverse engineering significantly more efficient

About the Speaker(s)

Luke Dramko is a PhD student at Carnegie Mellon University (CMU) working on AI for code, program analysis, and security, with a focus on decompilation. He collaborates with reverse engineering teams at Microsoft who use decompilers daily to analyze malware and improve Windows Defender. His current thesis work includes developing verification tools for neural decompilation predictions. He mentioned being on the industry job market and expressed interest in positions at the intersection of AI, program analysis, and security.