PaperlayerView exact revision on arXiv

Source-linked AI summary

STILL: Recovering Lowered STL Semantics for LLM-assisted C++ Decompilation

Xiaohan Wang, Kevin Leach

arXiv:2608.26408v1cs.SE

TL;DR

Stripped C++ decompilation often loses STL container semantics, limiting executable recovery. STILL predicts function-level container semantics from stripped CFGs and injects compact hints into LLM refinement, improving results while revealing backbone-dependent interface requirements.

  • Problem

    Compilation, optimization, and stripping obscure STL container types and library structure, and decompilers often fail to recover these semantics in executable C++ output.

  • Method

    STILL predicts supported STL container semantics from stripped control-flow graphs and renders the predictions as compact hints alongside Ghidra decompilation for LLM refinement.

  • Results

    28.4% stripped HumanEval Rexec with predicted hints compares with 17.4% for no-hint refinement and 8.9% for raw Ghidra decompilation, while container prediction reaches 80.4% macro-F1 on held-out CodeContests and 89.0% on the stable HumanEval-C++ string/vector transfer slice.

  • Takeaways & Limitations

    Semantic hints can repair missing signature and container-facing information, but specialized decompilation backbones may require format-matched adaptation before benefiting.

  • Takeaways & Limitations

    STILL predicts function-level presence for only five containers and does not recover variable-level types, template arguments, nesting, iterator identities, or arbitrary library abstractions.

Abstract

from arXiv · show

LLM-assisted decompilation improves readability and re-executability, but still underperforms on stripped C++ functions that use the Standard Template Library (STL). Compilation, optimization, and symbol stripping remove or obscure source-level semantics such as container types and library-call structure, while traditional decompiler output often fails to recover them. We present STILL, a structured semantic interface that predicts function-level STL container semantics from stripped control-flow graphs and renders them as compact hints for LLM refinement. On StlBench, STILL predicts common container-level STL semantics, with the strongest cross-dataset results for stable string and vector slices. On stripped HumanEval decompilation, these hints enable DeepSeek-chat refinement to reach 28.4% executability, compared with 17.4% for no-hint refinement and 8.9% for raw Ghidra decompilation; hint utility is downstream-backbone-dependent, with decompilation-specialized models requiring lightweight adaptation to benefit from the same interface.

1 Introduction

Stripping and optimization erase C++ STL abstractions, creating a severe executability gap for STL-bearing functions. STILL recovers residual container semantics and exposes them as hints that improve LLM-assisted decompilation, although benefits depend on the downstream model.

  • Motivation: 51.9% executability on STL-free functions versus 6.2% on STL-bearing functions reveals an 8.4× gap.Compilation, optimization, and stripping remove signature information and container identity, hindering recovery even with LLM assistance.
  • Motivation: Residual binary evidence such as layout offsets, access widths, capacity branches, indexing, and library calls can indicate likely STL abstractions.These traces are incomplete and cannot guarantee reconstruction of exact source types.
  • Approach: STILL predicts function-level STL container semantics from stripped CFGs and renders them as compact hints before LLM refinement.The interface targets container identity rather than reconstructing a complete source program.
  • Results: 80.4% macro-F1 on held-out CodeContests and 89.0% macro-F1 on the stable HumanEval-C++ string/vector transfer slice demonstrate container-semantic prediction.The strongest cross-dataset performance is reported for stable string and vector slices.
  • Results: 28.4% stripped HumanEval Rexec with predicted hints exceeds 17.4% for no-hint refinement and 8.9% for raw Ghidra decompilation.Hint utility is backbone-dependent: specialized models may require adaptation to consume the interface.

2 STLBENCH: A Controlled Corpus for STL Semantic Extraction

STLBENCH is a controlled corpus designed to isolate how STL container information survives stripping and affects downstream LLM refinement. It aligns stripped functions, Ghidra output, and source-derived container labels under controlled sampling and leakage checks.

  • Corpus design: STLBENCH aligns stripped C++ functions, raw Ghidra output, and source-derived container labels for semantic-interface evaluation.The corpus addresses the lack of resources isolating STL information loss and downstream refinement.
  • Sampling: Target functions are self-contained CodeContests solutions selected with minimum-size and user-defined-call restrictions.At most one target function per problem reduces overlap between functions from the same task.
  • Corpus design: The corpus restricts supervision to map, queue, set, string, and vector, with per-class caps and explicit with-STL/no-STL quotas.It is roughly 60% with-STL and 40% no-STL, retaining no-STL functions as a control group.
  • Labels: Each source-derived label records function-level use of one or more supported containers rather than exact reconstructed C++ types.The labeling procedure is multi-label and counts top-level container occurrences.
  • Data hygiene: Train, validation, and test partitions are split by target function, with binary-embedding near-duplicate removal against HumanEval and decomp-eval.These checks prevent optimization variants or near-duplicates from crossing split boundaries.

3 Approach

STILL extracts typed CFG residue, predicts a binary STL gate and container labels, and renders them as compact hints alongside Ghidra output for LLM refinement. The design uses conservative residue evidence because string and vector leave more stable cues than ordered containers.

  • Semantic Interface: STILL maps a stripped function to a typed CFG G = (V, E, X, R) containing basic blocks, features, and six relation types.The graph supports semantic prediction from control-flow structure and block-local binary evidence.
  • Semantic Interface: The binary STL gate predicts whether any supported container is present, while the container vector predicts map, queue, set, string, and vector.The gate suppresses spurious hints for unsupported or no-STL functions.
  • LLM refinement: The interface renders predictions as a compact container list and supplies them with Ghidra decompilation to the LLM refiner.The hint restores container identity without requiring a reconstructed source program.
  • Residue recoverability: String and vector are usually recovered more accurately than map and set because their layout and access residue is more stable.Map and set can lower to similar traversal code, making their identities harder to distinguish.
  • Extractor Implementation: The extractor uses CONTRES and TREERES features from stripped assembly, followed by a relation-aware CFG encoder and separate interface heads.CONTRES captures contiguous-container cues, while TREERES captures ordered-container cues.
  • LLM refinement: For LLM4Decompile-Ref, hint-aware LoRA adaptation is evaluated to test whether the specialized backbone can consume the same interface.The adaptation is an evaluation condition rather than a separate contribution.

4 Evaluation

The evaluation tests whether STILL recovers STL semantics from stripped CFGs, improves decompilation quality, and transfers across datasets and downstream models. Results show strong semantic recoverability, improved executability and readability, and adaptation-dependent hint utility.

  • Experimental Setup: STILL is evaluated on held-out CodeContests and zero-shot HumanEval-C++ using function-level multi-label container prediction over five STL classes.The setup also measures compile and execution success, edit similarity, and paired LLM-judge readability.
  • RQ1: Recoverability of Missing STL Semantics: 80.4% macro-F1 and 95.4% gate F1 are achieved on held-out CodeContests, while the stable HumanEval string/vector slice reaches 89.0% macro-F1.Controls show substantially lower performance for majority-class, Ghidra-readout, and zero-shot LLM baselines.
  • RQ1: Recoverability of Missing STL Semantics: 42.0/53.0/56.0/55.1 per-opt macro-F1 after residue permutation shows that recovery depends on semantically aligned binary features rather than model capacity alone.The selected model explicitly represents layout/access and tree-region evidence; class reliability varies with which implementation traces survive stripping.
  • RQ2: Decompilation Quality: 28.4% overall Rexec versus 17.4% without hints demonstrates that compact recovered container hints improve DeepSeek-chat refinement on stripped HumanEval.HasSTL Rexec rises from 5.5% to 18.6%, while raw Ghidra reaches 0.0% on HasSTL functions and 49.1% on NoSTL functions.
  • RQ2: Decompilation Quality: +TYPE SEMANTIC wins 305 paired readability comparisons, ties 130, and loses 162, with mean RelRead +0.34.Across all pairs it adds +0.89 STL abstractions and removes 0.95 artifacts; among both-fail pairs, RelRead is +0.18.
  • RQ3: Downstream Hint Consumption: At fixed weights, oracle hints change specialized-backbone Rexec by only +0.2 pp, whereas LoRA adaptation raises it from 11.8% to 30.8% overall and from 1.1% to 26.9% on STL-bearing functions.GNN-recovered hints retain approximately 78% of the STL-slice oracle gain, showing that hint utility depends on downstream adaptation.

5 Related Work

STILL is positioned among adjacent decompilation, binary-analysis, and representation-learning work, while its evaluation includes diagnostics for hint use in specialized models.

  • Prior work spans LLM-based decompilation, binary type and data-structure recovery, and binary representation learning.
  • STILL targets STL container recovery as a semantic interface for downstream LLM refinement.
  • Table 4 diagnoses whether adapter training induces hint use using STL-slice Rexec.
  • The controlled ablation in Table 5 uses LLM4Decompile-Ref-6.7B-v2 on full stripped HumanEval-C++ with 584 samples.

6 Discussion

STILL identifies recoverability and hint consumption as distinct issues: implementation residue affects which containers are recoverable, while downstream models differ in how they use hints.

  • Containers with stable layout and access residue in stripped binaries are easier to recover than containers collapsing to shared low-level structures.
  • STL decompilation failures are separable, with restoring signatures and container-facing interfaces addressing only one repairable component.
  • DeepSeek-chat can use recovered hints directly in prompting, whereas LLM4Decompile-Ref needs format-matched adaptation.

7 Conclusion

The paper argues that stripped C++ decompilation loses STL semantics that remain partially recoverable from binary residue. STILL restores this channel before LLM refinement, improving executable recovery while revealing backbone-dependent hint use.

  • A major LLM-assisted C++ decompilation failure mode is missing source-level STL semantics after compilation, optimization, and stripping.
  • STL container abstractions remain partially recoverable through layout, access, and control-flow residue in binary CFGs.
  • STILL injects recovered semantic hints into LLM refinement, improving executable decompilation and repairing signature and container failures.
  • Hint utility depends on the downstream model: some refiners consume hints directly, while specialized models may require adaptation.

Limitations

STILL is a controlled, function-level study rather than complete C++ type recovery, and its evidence depends on the evaluated toolchain, downstream pipeline, and execution-based testing.

  • Scope of semantic recovery: STILL predicts only five function-level container labels, not variable-level types, template arguments, nesting, iterator identities, or arbitrary library abstractions.Evidence is strongest for string and vector; map and set estimates require greater caution because they are less frequent and similarly implemented.
  • Toolchain and pipeline dependence: Results were obtained with g++ on x86-64, libstdc++, angr CFGFast, and Ghidra, so learned residues may not transfer unchanged across toolchains, architectures, or optimization pipelines.
  • Toolchain and pipeline dependence: A correct function-level prediction does not guarantee useful refinement because CFG errors, aliases, empty Ghidra output, or interface mismatch can still prevent recovery.
  • Strength of downstream evidence: Rexec measures compilation and benchmark-test success, not semantic equivalence; finite tests can miss behavioral differences on uncovered paths or boundary conditions.Fuzzing increases confidence without proving equivalence, while symbolic methods face path explosion and incomplete C++ runtime and library modeling.
  • Potential risks and responsible use: STILL is intended for authorized reverse engineering, maintenance, security analysis, and research, with software licenses, terms of use, and applicable law respected.

B.1 STL Container Usage Survey

A conservative survey finds STL usage widespread among highly starred C++ repositories, with string and vector the most prevalent detected headers; residual external names rarely reveal container types directly.

  • Survey design: The survey used 10 source files per repository, so its header detection rates are lower bounds rather than complete repository prevalence estimates.
  • Survey results: 76 of 100 repositories (76.0%) contained at least one STL container header under conservative 10-file sampling.Manual verification found 17 additional confirmed STL users missed because of deep directories, wrapper headers, or Qt co-use.
  • Per-header breakdown: string (57.0%) and vector (56.0%) were the most prevalent headers in the sampled repositories.
  • Residual name cues: Remaining external-library call names directly indicating the true STL container type were rare overall and concentrated in string.
  • Evaluation boundary: The reported results are evidence within the controlled g++/x86-64/libstdc++ setting, not a claim of unchanged performance across other pipelines.

C.2 Contamination Control: Fresh Synthetic Evaluation

A fresh, held-out synthetic C++17 evaluation reduces concerns about benchmark contamination and shows that the frozen extractor and type-only hints retain strong performance.

  • Evaluation construction: The fresh evaluation contains 125 functions, including 100 STL-bearing functions and 25 no-STL hard negatives, compiled at O0–O3 into 500 stripped records.
  • Contamination controls: The set was excluded from training, prompt selection, threshold tuning, and model selection, with no exact normalized-source duplicates found against local HumanEval and CodeContests copies.
  • Extractor results: 81.0 macro-F1 and 97.2 gate F1 were achieved overall by the frozen semantic extractor on the fresh synthetic set.
  • Extractor results: For a retained O2 example, the extractor predicted exactly map, string, and vector for code using vector<string>, map<string,int>, and string-prefix operations.
  • Downstream refinement: 36.2% overall Rexec versus 22.8% and 26.2% STL-bearing Rexec versus 8.5% were obtained with type-only hints on the same held-out records.These controls provide stronger evidence on freshly generated data but cannot rule out every broader form of pretraining contamination.

D.2 Semantic Extractor Implementation Details

The semantic extractor represents stripped CFG evidence with block-local residue features for contiguous and ordered containers, without using source labels or decompiler text.

  • Input representation: The extractor computes residue features per basic block from stripped assembly parsed from the recovered CFG.
  • Input representation: It excludes source-level labels, debug metadata, Ghidra decompiler text, and residual symbol names from node features.
  • Residue features: CONTRES is a 33-dimensional vector capturing contiguous-container evidence through memory-layout, access-width, stride, indexing, and capacity/length cues.
  • Residue features: TREERES is a 68-dimensional vector capturing ordered-container evidence through pointer structure, tree-like offsets, comparisons, pointer chasing, and map/set payload cues.

E Artifact and Reproducibility

The artifact packages versioned experimental data with an end-to-end reproduction guide, documenting data preparation, environments, commands, formats, and evaluation procedures. It also records the headline semantic extractor’s architecture, training configuration, and reproducibility controls.

  • Artifact contents: The artifact includes versioned experiment data and a README covering CodeContests selection, preprocessing, label generation, deterministic splits, environments, construction commands, and evaluations.It also documents prompt and hint formats, evaluation scripts, expected metric files, and tables.
  • Extractor configuration: The headline semantic extractor uses a continuous+tree residue representation and a 3-layer RGCN with 128 hidden dimensions, residual connections, LayerNorm, and per-class attention pooling.
  • Reproducibility controls: Training is specified as 30 epochs of Adam with learning rate 10^-3 and seed 44, alongside recorded random seeds and exact package and compiler versions.The controlled environment includes g++ 11.4.0 and angr 9.2.193, with the Ghidra version pinned in the environment manifest.
Loading 2608.26408v1…