💻 computer science

Veritas: A Semantically Grounded Agentic Framework for Memory Corruption Vulnerability Detection in Binaries

Veritas is a semantically grounded, multi-agent framework that combines static analysis of lifted LLVM IR, dual-view LLM reasoning, and runtime validation to achieve high-recall, low-false-positive detection of memory corruption vulnerabilities in stripped binaries, successfully identifying a previously unknown Apple vulnerability.

Original authors: Xinran Zheng, Alfredo Pesoli, Marco Valleri, Suman Jana, Lorenzo Cavallaro

Published 2026-05-15

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Xinran Zheng, Alfredo Pesoli, Marco Valleri, Suman Jana, Lorenzo Cavallaro

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Problem: The "Lost Translation"

Imagine you have a complex machine (a computer program) that was built in a factory. The factory keeps the original blueprints (the source code), but the machine you actually receive is a stripped-down, black-box version (the binary) with all the labels, instructions, and diagrams removed.

Security experts need to find "memory corruption" bugs in these black boxes. These are like hidden cracks in the machine's foundation that allow a hacker to break in.

The problem is that without the blueprints, it's incredibly hard to see how a small part of the machine (like a button you press) connects to a dangerous part (like a pressure valve) miles away inside the box.

The Old Way: Guessing with AI

Recently, people started using powerful AI (Large Language Models) to look at these black boxes. The AI is smart; it can read the machine's "gibberish" code and try to guess where the cracks are.

However, the paper argues that the AI is like a detective who only has a blurry photo. The AI can see shapes, but it can't be sure if a line connects to a pipe or a wire. Because the "photo" (the binary code) is missing crucial details, the AI often:

Misses real cracks (False Negatives).
Thinks safe spots are cracks (False Positives).

The Solution: Veritas (The "Truth-Seeker")

The authors built a new system called Veritas. Instead of letting the AI guess freely, Veritas acts like a three-step investigation team that forces the AI to stick to the facts.

Think of Veritas as a team of three specialists working together:

Step 1: The Mapmaker (The Slicer)

Before the AI looks at anything, a specialized tool (the Slicer) scans the black box. It doesn't use AI; it uses strict math to draw a precise map.

The Analogy: Imagine the machine is a giant city. The Slicer ignores 99% of the city (the safe parts) and draws a single, thin line connecting the "Entrance" (where data comes in) to the "Danger Zone" (where data is used).
The Result: It gives the AI a tiny, focused path to investigate, rather than the whole messy city. This path is backed by "witnesses" (proof that the data actually travels this way).

Step 2: The Detective (The Dual-View Detector)

Now, the AI (the Detective) looks at the path the Mapmaker drew. But here is the trick: The AI looks at the path through two different pairs of glasses.

Glasses A (Decompiled Code): This looks like readable English sentences. It helps the AI understand the story of what's happening.
Glasses B (LLVM IR): This looks like raw, technical blueprints. It helps the AI see the exact math and memory addresses.
The Analogy: If the AI is confused about a specific street sign, it switches to the technical blueprints to see exactly where the road goes. This prevents the AI from making up stories that don't fit the math.

Step 3: The Forensic Tester (The Validator)

The AI might say, "I think there is a crack here!" But Veritas doesn't just take its word for it. A third agent (the Validator) goes out and physically tests the machine.

The Analogy: The AI is the witness in court saying, "I saw a crack." The Validator is the judge who says, "Show me." The Validator runs the machine with a special tool (a debugger) to see if the machine actually breaks when the AI says it should.
The Result: If the machine doesn't break, the "crack" is dismissed. If it does break, the bug is confirmed.

Why This Matters (The Results)

The authors tested Veritas on real-world software that had been stripped of its labels.

Success Rate: Veritas found 90% of the real bugs.
Accuracy: It had almost zero false alarms. When it said a bug existed, it was almost always true.
Real-World Win: In a separate test, Veritas found a brand-new, unknown bug (a "0-day") in Apple's software that no one knew about. They reported it, and Apple confirmed it and gave it a security ID (CVE).

The Bottom Line

The paper argues that you can't just rely on a smart AI to find bugs in complex, stripped-down software. The AI needs grounding.

Without Grounding: The AI is like a dreamer, imagining things that might not be there.
With Veritas: The AI is a scientist. It is given a specific path to check (by the Mapmaker), it checks the details with two different tools (the Detective), and it proves its findings with a physical test (the Validator).

By combining strict math, smart AI, and real-world testing, Veritas makes finding dangerous software bugs much more reliable and accurate.

Technical Summary: Veritas

Problem Statement

Detecting memory corruption vulnerabilities (MCVs) in stripped binaries presents a fundamental semantic reconstruction challenge. Unlike source code analysis, binary analysis must recover how memory objects are allocated, propagated, constrained, and accessed across functions from artifacts that have lost high-level structure, object boundaries, and explicit control flow due to compilation and stripping.

Recent Large Language Model (LLM)-based approaches have improved code understanding but struggle with binary MCV detection for three primary reasons:

Shared-State Tracking: Vulnerabilities often arise from inconsistent assumptions about shared memory regions across disjoint functions that lack direct call-chain edges. Standard call-graph expansion fails to capture these dependencies.
Semantic Loss: Recovered representations are fragmented. Lifted LLVM IR preserves low-level memory access patterns but is obscured by compiler artifacts (SSA variables, casts), while decompiled C provides high-level structure but collapses memory operations into generic offset expressions, erasing object identity.
Constraint Verification: Static analysis often cannot determine if a suspicious access is reachable under feasible path conditions. Without executable evidence, LLMs rely on syntactic proxies rather than proof of how attacker-controlled data propagates to memory-sensitive operations, leading to brittle reasoning and high false-positive rates.

Existing agentic frameworks designed for source code (relying on summarization or call-graph expansion) do not solve the semantic-recovery problem posed by stripped binaries, where the required semantic structure is partially absent by construction.

Methodology

Veritas is a hybrid, semantically grounded agentic framework designed to constrain LLM reasoning to verifiable program semantics and executable behavior. It organizes analysis into three stages aligned with two grounding layers: Static Grounding (recovered program facts) and Runtime Grounding (concrete execution evidence).

1. Semantic-driven Context Slicer (Static Grounding)

The Slicer operates without LLMs to extract compact, witness-backed source-to-sink flows from lifted LLVM IR.

Interprocedural Propagation Graph: It lifts the binary to LLVM IR using RetDec and constructs a typed interprocedural propagation graph ( $G_P$ ) encoding call, return, and global dependencies. This graph tracks how taint-relevant values (pointers, offsets, lengths) propagate across functions.
Witness-based Flow Extraction: Instead of treating all reachable source-sink pairs as meaningful, the Slicer verifies bounded interprocedural witnesses. It traces tainted tokens from input sources (e.g., fread) to memory-risk sinks (e.g., dangerous API arguments), validating propagation at each function boundary using def-use chains and metadata.
Flow Object Construction: Accepted witnesses are converted into compact flow objects containing ordered functions, taint-relevant tokens, and "anchor cues" (provenance classes and endpoint annotations). This replaces the full binary with a small, semantically complete context for downstream analysis.

2. Dual-view Vulnerability Detector (Controlled LLM Reasoning)

The Detector performs step-wise reasoning over the witness-backed flows, using a dual-view input representation to overcome semantic loss.

Dual-view Representation: For source and sink functions, the LLM receives both the decompiled C code (for control-flow reasoning) and the lifted LLVM IR (to disambiguate memory operations and sink semantics). For intermediate functions, it primarily uses decompiled code, guided by anchor cues.
Step-wise Reasoning: The LLM analyzes the flow one function at a time, maintaining an accumulated reasoning state (inventory of propagated values, aliases, and bounds). It updates this state based on assignments and control-flow decisions, avoiding the context limits of processing the entire flow at once.
Trie-based Memoization: To reduce redundancy, the system memoizes reasoning states for shared flow prefixes, invoking the LLM only on the unique suffix of a flow.
Consistency Checking: Before reporting a candidate, the Detector performs a final path-sensitive verification to ensure the tainted value remains vulnerability-relevant and that the sink access violates memory safety under feasible conditions.

3. Automatic Vulnerability Validator (Runtime Grounding)

The Validator translates detector hypotheses into executable checks to confirm or refute candidates.

Artifact Preparation: It maps detector hypotheses to executable coordinates (RVAs, symbols) using Radare2, bridging the gap between decompiler views and runtime debugging.
Multi-Agent Collaboration: Three agents orchestrate validation:
- Strategist: Plans the validation, selecting instrumentation targets, breakpoints, and triggering modalities (file, network, CLI).
- Verifier: Executes the plan, generating Proof-of-Concepts (PoCs) and running the binary under debuggers (Radare2) or memory checkers (Valgrind) to observe crashes or invalid accesses.
- Explorer: If initial evidence is insufficient, it probes alternative states or related functions to find supporting evidence.
Confirmation: A vulnerability is confirmed only when concrete runtime evidence (e.g., a segmentation fault, Valgrind error, or specific memory state) corroborates the reported sink, access pattern, and root cause.

Key Contributions

Veritas Framework: A semantically grounded agentic framework that unifies static program analysis and runtime validation to detect memory corruption in stripped binaries.
Three-Stage Architecture:
- A Slicer that extracts witness-backed flows from lifted IR without LLMs.
- A Dual-view Detector that reasons over flows using selective IR support to resolve semantic ambiguity.
- A Validator that confirms hypotheses using debugger-visible artifacts and concrete execution.
Fine-grained Benchmark: A curated dataset of 20 real-world binary memory-corruption cases with trace-level ground truth, constructed to evaluate grounded binary detection.
Performance: Evaluation shows Veritas achieves 90% recall on the benchmark, significantly outperforming static analyzers (0% recall), fuzzing (10% recall), and agentic baselines (25–35% recall). It produced zero false positives in an exhaustive validation of 623 candidates and only 2 false positives in a larger sampled audit.
Real-world Discovery: Veritas discovered a previously unknown zero-day out-of-bounds read in Apple's Universal Scene Description library (libusd_ms.dylib), which was confirmed and assigned a CVE.

Results and Significance

The paper argues that the effectiveness of LLM-based vulnerability discovery depends not on the model's intrinsic capability alone, but on the surrounding infrastructure's ability to recover the semantic structure required for reasoning.

Semantic Grounding as a Design Principle: The results support semantic grounding as an operational design principle. By constraining LLM reasoning to explicit memory-relevant facts (static grounding) and validating conclusions against executable behavior (runtime grounding), Veritas avoids the brittleness of unconstrained model speculation.
Superiority over Baselines: Traditional tools fail due to a lack of semantic grounding across functions. Agentic baselines fail because they lack explicit models of memory object lifecycles and rely on unguided exploration or syntactic patterns. Veritas bridges this gap by using deterministic analysis to pre-compute propagation and LLMs to interpret complex semantics, followed by rigorous runtime confirmation.
Cost-Accuracy Trade-off: While runtime validation is the primary cost bottleneck (requiring PoC generation and debugging), the framework demonstrates that high precision is achievable in stripped binary analysis only through executable evidence. The system prioritizes detection reliability over throughput, a necessary trade-off for security-critical binary analysis.

The paper concludes that for practical binary vulnerability detection, reasoning must be anchored in both recovered program semantics and executable evidence, a principle Veritas implements through its modular, hybrid architecture.