Log date · Wed
STILL paper: recovering STL semantics from stripped C++ for LLM decompilation
STILL predicts STL container semantics from stripped control-flow graphs to guide LLM decompilation, showing stripping does not hide library structure.
What happened on 2026-08-26
On 2026-08-26 at 21:20 UTC, Xiaohan Wang and Kevin Leach submitted v1 of 'STILL: Recovering Lowered STL Semantics for LLM-assisted C++ Decompilation' to arXiv. The abstract notes that LLM-assisted decompilation improves readability and re-executability but still performs poorly on stripped C++ functions that use the Standard Template Library, because compilation, optimization and stripping obscure container types and library-call structure. STILL predicts function-level STL container semantics from stripped control-flow graphs and turns them into compact hints for LLM refinement. On stripped HumanEval decompilation, DeepSeek-chat refinement reached 28.4% executability with hints, versus 17.4% for no-hint refinement and 8.9% for raw Ghidra output. The abstract adds that the benefit depends on the downstream model.
What it means for protecting app logic
Many iOS, Android and desktop apps put core algorithms into native C++ libraries on the assumption that stripping symbols makes them unreadable. This paper shows that even without names, how a library is used leaves recognizable traces in control-flow structure, and those traces can be learned and used to improve LLM decompilation. The numbers should be read accurately: 28.4% executability means most functions were still not recovered as runnable code, and the evaluation uses small functions such as HumanEval tasks, which says nothing about automatically reconstructing an entire native library. It indicates a trend and a direction, not a ready-made capability.
Checks you can run
Downgrade 'symbols are stripped' from a protection to a hygiene measure on your checklist. Inventory the functions in your native libraries that carry real core value and assess whether they must run on the client at all. Open your own release native libraries in a common decompiler to see how recognizable structures such as containers and string handling are in the output, and keep that as an internal baseline. Do not rely on native code being hard to read to protect keys or license decisions. Repeat this self-check periodically as tools improve.
Your checklist
- Treat symbol stripping as hygiene, not protection
- Inventory high-value functions in native libraries
- Decompile your own native libraries as a recurring baseline
Primary sources
- arXiv: STILL: Recovering Lowered STL Semantics for LLM-assisted C++ Decompilation · Source date 2026-08-26 · Checked 2026-10-12