ALIBI (arXiv 2609.19722): false narratives inside binaries can mislead LLM analyzers

What happened on 2026-09-17

At 05:27 UTC on 2026-09-17, Hyeongjun Choi and co-authors submitted v1 of 'ALIBI' (arXiv 2609.19722), filed under cs.CR and cs.LG. The paper looks at large language models that have been added to malware triage workflows. The authors append a small, read-only, never-executed section to a compiled binary. It holds a plausible but false narrative describing the file as a security product, while the imports and the actual runtime behavior stay the same. Rather than giving the model instructions, the section recasts the suspicious evidence as normal behavior for a benign endpoint tool. According to the abstract, Gemini 2.5 Pro flipped 30 of 35 baseline-malicious PE samples to benign, out of a set of 50. GPT-5.5 Pro and Claude Opus 4.7 mostly kept their labels but lowered severity and confidence substantially. On ELF binaries, Gemini flipped 16 of 40. A verification-oriented defense prompt roughly halved the benign verdicts, yet 42.9% of malicious samples were still judged benign.

What it means for a developer's threat model

The paper is about malware triage, not app cloning, but it carries two direct lessons for developers. First, more teams now use LLMs to help review third-party SDKs, dependencies and even their own release artifacts. ALIBI shows that descriptive text inside a binary is input an adversary can shape, and that a model may treat what a file claims about itself as evidence. Second, some developers may be tempted to reverse the idea and embed misleading narratives in their own apps to confuse AI-assisted analysis. We would not recommend it. The paper does not evaluate that use. The technique resembles what the paper's malicious samples do, so it could get your app flagged by security products. And it gives no reliable protection against an analyst who reads imports and behavioral evidence. The authors conclude that analyzers need provenance checks that separate verified facts from claims supplied by the sample.

Checks you can put in place

If you use an LLM to help review third-party components or your own builds, three habits help. First, require every conclusion to point to a verifiable fact, such as a signature, a hash, an imported symbol or observed network behavior, rather than to descriptive text inside the binary. Second, keep a non-LLM baseline running alongside it, including signature verification, SBOM comparison and known-vulnerability scanning, and treat model output as a lead to follow up, not a verdict. Third, mark in each report which judgments came from tool output and which came from model reasoning, so they can be traced later. For your own release artifacts, inventory the strings and resources they contain on a regular basis, and confirm they do not carry internal notes, debug text or descriptions that were never meant to be public.

Your checklist

• Require LLM review conclusions to cite verifiable facts like signatures, hashes and imports
• Keep non-LLM baselines such as signature checks, SBOM diffs and vulnerability scans
• Regularly inventory strings and resources in release artifacts and remove internal notes