Hieronym (arXiv 2609.12457): LLM-based function renaming for stripped binaries

What happened on this date

On 2026-09-11 (UTC), Xiaoling Zhang and eight co-authors submitted v1 of Hieronym to arXiv. The paper targets function renaming in stripped binaries, where a function's meaning must be inferred from low-level code that varies with instruction set, architecture and optimization level, then expressed as a short readable name. The authors argue that existing methods either miss much of the semantics or generalize poorly to unseen binaries. Hieronym is a generative LLM framework using hierarchical, summarization-driven domain adaptation that combines global binary context, local calling context and the function's intrinsic semantics. The paper also introduces token-level and whole-name evaluation metrics. On x64, x86, ARM and MIPS binaries at O0 to O3, the authors report improvements of 50.12% in token-level precision, 41.75% in recall, 45.10% in F1 and 79.94% in name-level accuracy over state-of-the-art methods, plus experiments on real-world malware samples.

Why it matters for protecting app logic

Stripping symbols has long been treated as the most basic protection step. Work like this aims to infer the meaning that names carried, and the clues it relies on come from context: which library functions are called, who calls the function, and what constants and strings it handles. For developers, stripping is still worth doing because it removes the most direct answer, but it should not be described as hiding a function's intent. Mind the limits: the paper reports improvements relative to prior methods, the numbers come from the authors' own evaluation, and the abstract does not cover performance on obfuscated code, so it says nothing about hardened binaries.

Checks you can run

First, keep stripping symbols in release builds and confirm your pipeline actually performs that step. Second, review content that leaks context, such as log strings, error messages, assertion text and debug switches, removing them from release builds or replacing them with codes. Third, check whether the combination of imported system APIs and third-party libraries already reveals a module's purpose, and move sensitive processing to the server where needed. Fourth, inspect your release binary with your own analysis tools to see what readable clues remain after stripping. Treat names as one layer among several, not the main barrier.

Your checklist

• Confirm the release pipeline actually strips symbols
• Remove context-leaking strings such as logs and error messages
• Check whether imported API combinations reveal module purpose