Large language models can now pick apart a malware sample faster than any human analyst, but the notes they leave behind are not always worth trusting. That is the finding of a new study from SentinelLABS researchers Gabriel Bernadett-Shapiro and Aleksandar Milenkoski, who tested how frontier models annotate disassembled code and then built an open-source harness, VerifiedIDA, to keep that work checkable.
The stakes are practical. Defenders can use LLMs to analyse far more malware in less time, while, as the researchers note, attackers can use the same capability to speed up vulnerability research and exploit development. If an AI's reverse engineering output feeds incident response, detection rules or threat hunting, an analyst has to be able to see why the model concluded what it did. The team lays this out in SentinelLABS' original report.
A Turla backdoor as the test bench
The researchers had models from Anthropic, OpenAI and open-source projects reverse engineer malicious and legitimate binaries through a deliberately simple harness: basic tools for reading code, following cross-references and writing labels, types and comments into an IDA Pro database, with no human or automated feedback. Most of the testing shown used GPT-5.6 Sol. Their two detailed case studies use a sample of ComRAT (SHA-1 0139818441431c72a1935e7f740a1cc458a63452), a backdoor attributed to the Russian group Turla, which IntelFusions last covered when it hit Ukraine with a new backdoor.
The models did several things well. They worked methodically, largely avoided fabrication by falling back to generic labels such as "unknown" when the code did not support a conclusion, and made good use of documented Windows API behaviour. But four problems kept recurring:
- Accuracy of labels: some names given to functions and variables did not describe what they actually do, and nothing in the database reveals that a label is weak.
- Capture of findings: models established facts during analysis and never wrote them into the database, so the work was lost.
- Continuity of work: planned steps were dropped as the analysis went on, which the researchers suspect is mainly due to context compaction.
- Completeness of analysis: models labelled a function before exploring all the code it calls, missing capabilities hidden in those callees.
Let the model judge, make the system keep receipts
The proposed standard splits the job. The model makes the analytical calls; the system around it must keep the evidence behind every annotation, verify that each change actually landed in the database, store project state outside the model's context, and allow an independent reviewer to challenge annotations and flag unfinished work.
VerifiedIDA implements that for IDA Pro. It applies every edit to a candidate copy of the database, reads the result back and rejects edits that cite stale evidence or change things the model did not intend. It keeps a SQLite ledger of inspections and operations plus a project notebook of what the model knows and plans next, and hands the finished database to reviewer models with read-only access.
One experiment shows the payoff. In six earlier GPT-5.6 Sol runs on a ComRAT function, none opened a helper routine that resolves forwarded exports, and the four runs that annotated the parent function all missed that behaviour. With VerifiedIDA's experimental call-flow mode, which listed the function's 20 direct callees and held the claim open until each had an outcome, the model found the helper and documented it. The researchers are candid about limits: applied across a whole project, the mode generated 265 required nodes for eight edits, so they reserve it for selected claims.
Get VerifiedIDA from GitHub and test it
The harness, the standard's specification and a user guide are on SentinelLABS' GitHub. The authors invite adapters for Ghidra and Binary Ninja, and stress that the standard is a floor: it does not make a model's analysis correct, it makes its mistakes findable. For teams already piping LLM output into detections, that distinction is the whole point. A wrong label that can be traced back to the code it came from is an error; one that cannot is a liability.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.