Anchor Retrieval and LLM Reranking Target Source Recovery From Binaries
A new arXiv preprint proposes recovering source functions from stripped binaries by searching a source database rather than generating approximate pseudocode. The pipeline extracts strings, constants, external calls, and surviving function names with Ghidra, retrieves candidate files through an inverted index, narrows them to function snippets, and asks an LLM to rerank the candidates against binary context. The authors report 95.2% assembly instruction coverage on a controlled, high-fidelity database and 35.5% average coverage on a GitHub-based database. That gap makes retrieval quality the central operational risk. The results are author-run and have not been independently reproduced, so practitioners should separate retrieval recall from reranking accuracy before judging the method.
What happened
A new arXiv preprint describes a pipeline for recovering the likely original source function behind a stripped binary function. Instead of asking a model to invent plausible pseudocode, the method searches a database of available source code and tries to identify the real function that produced the binary.
The pipeline begins with evidence that tends to survive compilation: strings, constants, external calls, and any available function names. Ghidra extracts those anchors, an inverted index retrieves candidate files, and a narrowing stage identifies likely function snippets. An LLM then reranks those snippets using disassembly, decompiled output, and source metadata. Confident matches may become anchors for later recovery passes.
Technical context
The authors report 95.2% assembly instruction coverage on the controlled database and 35.5% average coverage on the GitHub-based database. The large difference is more informative than either headline result by itself. It suggests that candidate retrieval, not only model reasoning, determines whether the system can recover useful source. A strong reranker cannot select a correct function that never entered its candidate set.
| Pipeline layer | Primary question | Failure signal |
|---|---|---|
| Anchor extraction | Did compilation preserve discriminating evidence? | Common or missing anchors |
| Candidate retrieval | Did the correct source enter the candidate set? | Retrieval miss |
| Snippet narrowing | Was the relevant function isolated? | Wrong function boundary |
| LLM reranking | Did binary evidence support the selected candidate? | Confident false match |
| Recovery loop | Did earlier matches improve later passes safely? | Error propagation |
For practitioners
Evaluation should report retrieval recall before LLM reranking, precision at each confidence threshold, and the rate at which a confident mistake contaminates later passes. Tests should also vary compiler, optimization level, stripped metadata, library version, and database coverage. Without those controls, a high aggregate coverage number can conceal narrow conditions that do not transfer to an incident-response or malware-analysis workflow.
Editorial analysis
The practical contribution is the decision to treat binary recovery as evidence-guided retrieval rather than unconstrained code generation. That framing makes failures more observable: teams can inspect anchors, candidate sets, and ranking evidence instead of accepting fluent pseudocode. The limitation is equally clear: the preprint supplies author-run experiments, not independent validation.
What to watch
Watch for released code, reproducible datasets, independent testing, calibration of match confidence, and evaluations on binaries whose source corpus is incomplete or deliberately adversarial.
Key Points
- 1The pipeline retrieves likely source functions from anchor evidence, then uses an LLM to rerank candidates against binary context.
- 2The authors report 95.2% instruction coverage on the controlled database and 35.5% average coverage on the GitHub-based database.
- 3LDS recommends evaluating retrieval recall separately from reranking precision before treating source recovery as dependable in operational reverse engineering.
Scoring Rationale
An impact score of 6.5 reflects a useful evidence-guided recovery design and a revealing retrieval-quality result, tempered by preprint status and missing independent replication.
Sources
Primary source and supporting public references used for this report.
Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.
Try 250 free problems
