ThreatRay Pairs Code Matching With AI to Slash Malware Analysis Time

Josh Stroschein

Large language models cannot reliably reverse compiled malware unless binary similarity engines first filter out benign runtime libraries, setting the stage for an adversarial shift toward anti-LLM code obfuscation.

AI-assisted summary of EP29 Binary Similarity in the LLM Era with Jonas Wagner and Endre Bangerter of ThreatRay — original source. Check the original for full context.

Source published: 2026-09-16

Key ideas

Academic algorithms for binary code similarity often fail to become viable production tools because effective attribution depends on massive data engineering, sandbox detonation, and labeled reference datasets rather than the comparison algorithm alone. (6:00)
Binary code similarity delivers immense value to AI reverse-engineering pipelines by pruning thousands of benign and library functions, preventing context exhaustion and hallucinations in LLMs by isolating only the unique malicious code. (25:00)
ThreatRay has automated OSINT indexing by crawling threat intelligence blogs, pulling referenced binary hashes, and indexing their code to allow frontline responders to match novel, obfuscated payloads directly back to public threat actor reporting. (37:47)
Internal trials at ThreatRay demonstrated that equipping agentic AI models with precise binary similarity and reverse-engineering APIs compressed complex, multi-binary APT attribution workflows from eight hours down to just twenty minutes. (46:17)
Security researchers project that increased AI automation in reverse engineering will trigger dedicated anti-LLM obfuscations engineered specifically to induce hallucinations and derail model tokenization logic. (52:45)

Detailed notes

## Background Published by Josh Stroschein on September 16, 2026, on the Behind the Binary podcast feed, this episode features ThreatRay co-founders Jonas Wagner and Endre Bangerter. According to the show description, the discussion explores the practical state of binary similarity in the LLM era, dispelling AI hype by detailing why raw LLMs struggle with unguided binary analysis and how combining code similarity with AI accelerates malware investigation.

## TL;DR Jonas Wagner and Endre Bangerter trace the evolution of binary similarity from traditional heuristics like BinDiff and SSDEEP to modern function embeddings and agentic workflows. They explain how the practical bottleneck in malware classification lies in data curation, sandbox detonation, and stripping runtime noise from statically linked languages like Go and Rust rather than in academic algorithm design. While adversaries could theoretically use generative AI or advanced obfuscation to defeat code-matching models, the reality is that threat actors rarely invest beyond standard packing. Ultimately, the guests showcase how combining pre-indexed code similarity with autonomous AI agents dramatically accelerates triage, goodware pruning, and retrospective threat hunting without succumbing to LLM hallucinations.

## Atmosphere & style The conversation carries an analytical, pragmatic, and refreshingly grounded tone that cuts through contemporary AI marketing hype. Josh Stroschein engages as a technically seasoned peer and sounding board, trading candid insights with the guests about the real-world operational frictions of reverse engineering. The exchange feels like a masterclass in low-level engineering realism, balancing enthusiasm for emerging agentic workflows with a clear-eyed understanding of persistent obstacles like indirect control flow and adversarial anti-LLM obfuscation.

## Bulletin - `06:00` Academic algorithms for binary code similarity often fail to become viable production tools because effective attribution depends on massive data engineering, sandbox detonation, and labeled reference datasets rather than the comparison algorithm alone. - `25:00` Binary code similarity delivers immense value to AI reverse-engineering pipelines by pruning thousands of benign and library functions, preventing context exhaustion and hallucinations in LLMs by isolating only the unique malicious code. - `37:47` ThreatRay has automated OSINT indexing by crawling threat intelligence blogs, pulling referenced binary hashes, and indexing their code to allow frontline responders to match novel, obfuscated payloads directly back to public threat actor reporting. - `46:17` Internal trials at ThreatRay demonstrated that equipping agentic AI models with precise binary similarity and reverse-engineering APIs compressed complex, multi-binary APT attribution workflows from eight hours down to just twenty minutes. - `52:45` Security researchers project that increased AI automation in reverse engineering will trigger dedicated anti-LLM obfuscations engineered specifically to induce hallucinations and derail model tokenization logic.

## Key takeaways - `00:00` Binary similarity aims to determine whether two compiled machine-code binaries originate from the same source code without having access to the original source. - `03:00` The compilation process strips critical semantic context such as variable and function names while introducing synthetic structural variation across optimization flags and CPU architectures. - `06:00` The binary similarity field has evolved from expert-crafted graph isomorphisms (like BinDiff) toward modern vector embeddings and MinHash indexing architectures (such as Ghidra's BSim and MCRIT). - `10:00` Real-world binary classification breaks down on packed malware unless samples are first detonated inside automated sandboxes to extract unmapped memory blocks. - `15:00` Syntactic instruction matching is computationally fast but highly fragile, breaking easily under simple compiler optimization flags or architectural shifts. - `20:00` Semantic similarity represents the ultimate goal of code matching, but its reliance on computationally expensive formal methods like symbolic execution forces practical systems to rely on structural graph matching as a proxy. - `20:00` Malware authors in the wild rarely deploy extreme obfuscation like control flow flattening, relying instead on traditional packing and making structural graph matching highly effective in production. - `30:00` Statically compiled languages like Go and Rust bloat binaries with thousands of runtime and library functions, necessitating function-level similarity filtering before analysis. - `25:00` Pairing binary similarity with LLMs allows defenders to filter out 90% or more of benign runtime code, directing scarce model context and reversing capacity only to novel, suspicious functions. - `31:37` Extracting semantics once via an LLM and using binary similarity engines to propagate those semantic labels across thousands of corpus binaries provides massive analytical leverage. - `43:24` Indexing compiled code into a searchable repository enables instant historical retro-hunting without the processing overhead and syntax constraints of scanning with YARA. - `50:00` Frontline SOC analysts can leverage autonomous agents coordinating disassemblers, similarity engines, and sandboxes to perform rapid binary triage without deep personal reverse-engineering expertise. - `52:45` Obfuscation techniques such as indirect jumps and fractured control flow graphs disrupt LLM reasoning just as severely as they do traditional static disassemblers like IDA Pro. - `55:00` The expansion of AI-assisted malware analysis will lead threat actors to evolve from basic evasion toward code-level structural mutations designed specifically to break LLM tokenization and inference.

## Detailed walkthrough ### `00:00` Defining Binary Similarity and the Threat Landscape

Josh Stroschein opens the episode by framing the paradox of artificial intelligence in cybersecurity: while defenders gain dramatic efficiency, attackers gain an engine for sheer scale. Jonas Wagner introduces the ultimate consequence of this dynamic, noting that code-based detection could face an existential crisis if generative tools reach full autonomy.

> “If the LLMs take over and they get even more efficient, then I mean, the attacker could craft a new malware family for every attack, right? In the extreme case. Then, to be honest, then all code-based approaches become less useful, right?” — Jonas Wagner

Josh introduces Endre Bangerter and Jonas Wagner, co-founders of ThreatRay, to discuss binary similarity (commonly abbreviated as "bin-sim"). While bin-sim can theoretically touch various intermediate languages, the primary focus of the discussion is native machine code executed directly by the CPU—the most challenging domain in reverse engineering.

Jonas defines the foundational goal of bin-sim: determining whether two compiled binary snippets originated from the same underlying source code without having access to that source code. Solving this reliably and at scale unlocks critical workflows across malware analysis, incident response, and software provenance.

```mermaid flowchart LR accTitle: Binary Similarity Process accDescr: High-level overview of comparing compiled binaries to infer shared source code heritage. subgraph Compilation["Compilation Process"] SC1["Source Code A"] -->|"Compiler & Flags"| B1["Binary Code A"] SC2["Source Code B"] -->|"Compiler & Flags"| B2["Binary Code B"] end subgraph Matching["Bin-Sim Engine"] B1 --> Engine["Similarity Analysis Engine"] B2 --> Engine Engine --> Output{"Shared Source Code?"} end ```

`03:00` The Compilation Barrier and Traditional Handcrafted Heuristics

The core hurdle of binary similarity is that the compilation process actively strips out semantic context while injecting synthetic diversity. Compilers discard developer-friendly metadata like function and variable names, and depending on optimization flags, compiler versions, or target CPU architectures, the resulting assembly instructions for the exact same source code can look radically different. Consequently, bin-sim tools are forced to reconstruct intent from whatever residual artifacts survive compilation.

Over the past two decades, practitioners relied heavily on handcrafted domain heuristics. Jonas cites BinDiff as the historical gold standard: - **BinDiff**: Acts as the "godfather" of binary code similarity by parsing function control-flow graphs (CFGs) to identify shared versus unique functions between two files. While highly precise, it relies on pairwise comparisons that do not easily scale to massive corpuses. - **SSDEEP (Context Triggered Piecewise Hashing)**: Very fast and lightweight for whole-file comparisons, but brittle and shallow because small shifts in bytes or layout break the match. - **Signature & Heuristic Matching (YARA, AV, IDA FLIRT)**: Effective for static byte patterns and library signature detection, but prone to evasion under code reordering, register renaming, or compiler variation.

Around a decade ago, research reached a turning point. Instead of building purely deterministic, expert-crafted rules, the field shifted toward data-driven machine learning models to combine the deep precision of tools like BinDiff with the speed and scale required to search across massive datasets.

`06:00` Academic Evolution, Modern Open-Source Tooling, and the Data Bottleneck

Josh questions whether the public tooling landscape has grown stagnant, noting that traditional staples like SSDEEP and IDA FLIRT still dominate everyday analyst workflows. Jonas clarifies that while practitioner mindshare may seem static, academic research has advanced rapidly through distinct eras:

Jonas highlights two notable modern tools that have emerged in the public/open-source space: - **Ghidra's BSim**: Implements modern function-level vector embeddings, enabling fast nearest-neighbor similarity searches across large codebases—scaling far beyond the limits of one-to-one BinDiff comparisons. - **MCRIT (MinHash-based Code Relationship Identification Tool)**: An open-source framework developed by Daniel Plohmann that provides a scalable architecture to index and query binary code similarity from scratch.

Endre Bangerter intervenes to explain why powerful academic algorithms rarely become ubiquitous standalone products. While thousands of similarity algorithms exist on GitHub and in academic papers, an algorithm is essentially useless without an indexed, high-quality corpus of binary data and rich metadata. In real-world enterprise environments, the limiting factor is rarely the algorithm itself; it is the infrastructure required to ingest, normalize, and contextualize ground-truth binaries so that similarity matches provide actionable threat intelligence.

`10:00` The Reality of Data Curation and Sandbox Detonation

The conversation opens with a discussion on the gap between academic algorithm design and usable tooling: making output easily digestible for an end user is often more difficult than crafting the core similarity algorithms themselves. While the algorithms are mathematically fascinating, they are practically useless without a meticulously curated, accurately tagged reference database. Josh Stroschein points out the parallel when writing individual YARA rules: an analyst must obtain an authentic sample, assign it to a family, verify that the sample set is statistically representative, and run it across massive corpuses to validate true positives and rule out false positives. Sourcing reliable data remains a major bottleneck—whether pulling from open platforms like abuse.ch or navigating commercial datasets like VirusTotal, knowing how well a sample pool reflects the real-world malware landscape is inherently difficult.

Endre Bangerter clarifies that the operational friction goes far beyond mere data collection, using malware classification as the primary example. The theoretical model assumes that an analyst collects reference binaries across various malware families, compares an unknown binary against them, measures code overlap, and assigns the label of the closest match. In the field, this straightforward strategy collapses immediately because the vast majority of modern malware is packed, while the true family characteristics reside inside the unpacked payloads.

```mermaid flowchart TD accTitle: Pipeline for Memory-Dumped Payload Classification accDescr: Flow showing how samples pass through sandboxing to memory dumps and filtering before matching. subgraph INGEST["1. Ingestion & Detonation"] A["Packed Unknown Sample"] --> S["ThreatRay Sandbox Execution"] R["Reference Family Binaries"] --> S end

subgraph MEMORY["2. Memory Extraction"] S --> D["10–30 Memory Dumps & Files"] D --> F{"De-noising & Filtering"} end

subgraph CLASSIFY["3. Attribution"] F -->|"Strip Loaders & Statically Linked Libs"| P["True Payload Code"] P --> M["Per-Function Similarity Matching"] M --> L["Reliable Family Attribution"] end ```

To counter packing, ThreatRay detonates both reference sets and incoming unknown binaries inside an automated sandbox that monitors memory, unpacks layers, executes runtime web downloads, and dumps all unmapped or altered code blocks directly from memory. This execution step radically transforms the geometry of the problem: instead of performing a simple one-to-one binary comparison, analysts must match an incoming set of 10 to 30 extracted memory chunks against an entire database consisting of dozens of sets of binary components per reference family.

- Unpacking and detonation uncover dynamic loaders, dependencies, and OS libraries in memory, all of which will produce noisy false matches if naively compared against reference sets. - Family labels cannot be propagated directly from file hashes; labels must attach specifically to the genuine, recovered payload inside memory. - As Endre Bangerter summarizes: “And once you have them labeled, then you can reliably do this classification. But also labeling is not so easy, by the way.”

---

`15:00` De-Noising, Compilers, and the Brittleness of Syntactic Matching

Even after dumping code from memory, deep noise persists. Payloads frequently incorporate statically linked third-party libraries, intertwining distinct payload logic with generic runtime components. ThreatRay addresses this by conducting similarity matching at the individual function level rather than over entire files. This introduces algorithmic nuances: similarity engines fail on very small functions due to lack of unique entropy, and they occasionally correlate unrelated large functions that share standard patterns. Building production-grade similarity requires an entire supporting pipeline of workflows and heuristics designed to strip runtime noise, detect actual functional boundaries, and correctly label true malicious code.

Josh highlights the intensifying architectural hurdles facing binary similarity: modern languages like Go and Rust generate massive executables loaded with static runtimes and standard libraries. Simultaneously, compiler optimization levels act destructively on original source logic, while advanced obfuscation engines mutate control flows, inject opaque predicates, weave mixed Boolean arithmetic, and obliterate function boundaries. These structural modifications raise the question of whether binary similarity can endure against such extreme distortions.

Jonas Wagner structures the challenge into two broad layers: "implicit variation" arising naturally from compilers, different instruction set architectures, optimization flags, and language runtimes, alongside "explicit obfuscation" applied deliberately by threat actors to break reverse-engineering tooling. Resolving this requires choosing binary features that survive these mutations. Jonas describes the spectrum of analytical methods, beginning with direct syntactic similarity:

Jonas explains that while comparing instruction sequences yields fast detections for nearly identical builds, its operational utility degrades instantly under minor environmental changes. As Jonas Wagner observes regarding basic instruction comparison: “So it's good, it's super fast, but very brittle. It's very easy to kind of get around that, even if you just add a compiler optimization flag.”

`20:00` Structural vs. Semantic Similarity and the Real-World Habits of Malware Authors

Moving up the abstraction ladder from raw bytes, the discussion turns to structural similarity—the technique utilized by tools like BinDiff and standard disassemblers. When analyzing a binary, analysts often inspect a function's control flow graph (CFG) and visually compare it against another. The underlying assumption is intuitive: if two control flow graphs share a similar structure, the control flow is likely identical, meaning the functions themselves perform similar work. While structural similarity holds up well against minor compiler variations or light obfuscation, aggressive techniques like control flow flattening intentionally shatter this structural layer.

Beyond structure lies the semantic layer: determining whether two pieces of binary code achieve the exact same operational outcome. Jonas Wagner and Endre Bangerter characterize semantic matching as the genuine "holy grail of code similarity," as it strips away all implicitly or explicitly introduced superficial variations. However, trying to formally extract semantics—such as using symbolic execution to mathematically prove code equivalence—is computationally expensive and fails to scale in high-throughput environments. Consequently, practical industrial and academic systems rely on structural graph similarity as a viable, lightweight proxy for semantic equivalence.

Despite theoretical vulnerabilities to techniques like control flow graph flattening or minor compiler optimization tricks, Endre Bangerter points out that real-world adversaries rarely employ such sophisticated transformations:

> “And the reality is they don't do that much in most cases. I could put it like this. which is good for us, which is good for all the people who write Yara rules.”

Malware authors predominantly rely on simple packing rather than exotic in-binary obfuscation. ThreatRay's capability to track malware families across thousands of samples via CFG similarity confirms this: if malware authors routinely deployed advanced obfuscators, ThreatRay's graph signatures would break down. The reality in the wild reveals a striking delta between academic worst-case scenarios and common practice. Much like Yara rules—which are theoretically trivial to evade yet remain remarkably effective in production across the security community—graph-based code similarity continues to function reliably because the majority of attackers stick to low-friction evasion methods.

- **Similarity Approaches**: - *Structural Similarity*: Analyzes control flow graphs (e.g., BinDiff); effective against common compiler variations, but breaks under control flow flattening. - *Semantic Similarity*: Measures actual program intent and behavior; highly robust against syntactic changes, but relies on computationally prohibitive methods like symbolic execution. - **Empirical Reality**: ThreatRay tracks malware families primarily through CFG code similarity; authors rarely use deep obfuscation beyond traditional packing layers.

```mermaid flowchart TD accTitle: Binary Code Similarity Comparison Hierarchy accDescr: Hierarchy comparing syntactic byte matching, structural graph matching, and semantic matching.

subgraph Layers ["Analysis Layers"] L1["Syntactic / Byte Level (Hashes, Yara rules)"] L2["Structural Level (Control Flow Graphs, BinDiff)"] L3["Semantic Level (Symbolic execution, behavioral intent)"] end

subgraph Tradeoffs ["Operational Tradeoffs"] T1["High speed / Fragile against compiler changes"] T2["Scalable proxy / Vulnerable to CFG flattening"] T3["Robust 'Holy Grail' / Computationally prohibitive to scale"] end

L1 -.-> T1 L2 -.-> T2 L3 -.-> T3 ```

---

`25:00` The LLM Shift and Pruning Goodware to Focus AI Analysis

Josh Stroschein observes that malware ecosystem dynamics often skew perceived sophistication. Commodity infostealers typically generate raw payloads and offload obfuscation to customers via packers, artificially inflating the volume of simplistic samples. In contrast, well-resourced nation-state adversaries build bespoke compiler toolchains that weave complex obfuscation directly into the binary layout, distorting the CFG without necessarily altering core instructions. Furthermore, modern generative AI dramatically lowers the barrier to building complex tooling: Josh recounts using an LLM to port the legacy Obfuscator-LLVM (OLLVM) project to modern build toolchains in just a single evening, warning that capable offensive actors can readily achieve similar pipeline automation.

If attackers leverage LLMs to generate bespoke, structurally unique malware families for every intrusion campaign, traditional pattern-matching and graph-based similarity models will lose their diagnostic efficacy. In that extreme scenario, defenders must shift toward semantic abstractions—identifying the fundamental operational reality of attacks (such as keylogging or code injection routines, which inevitably invoke recognizable API patterns) regardless of how the binary is structured.

Yet Endre Bangerter highlights a crucial, resilient application of code similarity that actually gains value in the LLM era: goodware and library identification. Malicious binaries are routinely bloated with statically linked open-source libraries, runtime boilerplate, and benign framework code. ThreatRay indexes known goodware to filter this noise out of their detection signatures. By combining goodware indexing with decompilation fed into LLMs, ThreatRay solves a core limitation of modern AI-driven reversing:

> “So LLM is much faster because only 50 functions instead of 1000 needs to be analyzed. There's less hallucination.”

In a binary containing 1,000 functions, graph similarity can rapidly classify 950 as standard third-party libraries. Instead of flooding an LLM with the entire binary—which triggers context exhaustion, severe hallucinations, and prohibitive latency—the similarity engine weeds out the legitimate baseline and isolates the remaining 50 unknown functions for targeted LLM inspection. Even in a future where adversaries use AI to synthesize distinct malicious logic for every engagement, that newly minted code will immediately stick out against enterprise goodware baselines and internal EDR prevalence telemetry.

- **Commodity vs. Advanced Threats**: Commodity malware authors rely on external crypters/packers, whereas advanced nation-state groups integrate custom obfuscation passes directly into compiler pipelines. - **Lowering Developer Barriers**: Josh demonstrated the practical power of LLMs by porting the entire legacy OLLVM toolchain to a modern compiler environment in one evening. - **Goodware Filtering**: ThreatRay applies binary similarity symmetrically to index known goodware and common libraries, filtering boilerplate out of signatures. - **Targeted AI Decompilation Pipeline**: - *Input*: 1,000-function binary. - *Similarity Stage*: Matches and discards 950 benign/library functions. - *LLM Reversing Stage*: Feeds only the remaining 50 unknown functions to the model, drastically reducing inference cost, analysis turnaround time, and hallucination rates. - **Detection via Prevalence**: Even if fully unique code is generated per target, the complete absence of benign code matching or historical fleet prevalence flags it inside enterprise EDR systems.

`30:00` Filtering Noise in Statically Compiled Binaries and the Limits of LLM Reversing

Endre Bangerter begins by noting that while cybersecurity remains an endless cat-and-mouse game, attackers churning out brand-new binaries for every single intrusion encounter their own operational bottlenecks around uniqueness. The natural defense strategy is to isolate unique novel logic from repeated standard code so that the truly malicious additions stand out. Once isolated, that residual code can be handed off to reverse engineers or fed into AI models for deeper inspection.

```mermaid flowchart TD accTitle: Filtering and Reversing Pipeline accDescr: A binary is separated into known code and unique code before AI analysis.

subgraph Ingestion["Binary Ingestion"] A["Statically Compiled Binary (Go / Rust: 10,000+ Functions)"] end

subgraph Filtering["Code Filtering"] B["Code Similarity Engine"] C["Known Good Code (Runtimes & Libraries)"] D["Unique Unknown Code (~500 Functions)"] end

subgraph Analysis["Targeted Analysis"] E["LLM / AI Reversing"] F["Human Analyst Review"] end

A --> B B --> C B --> D D --> E D --> F ```

Jonas Wagner emphasizes that code similarity provides immense leverage when confronting modern malware written in statically compiled languages like Go and Rust. In these environments, runtime routines, dependencies, and third-party libraries are baked directly into the executable, forcing an analyst to navigate thousands of functions upon opening a sample. Jonas argues:

> “There it becomes extremely handy if you can cleanly separate out what is known good code, either from the runtime or from any third-party libraries, and as a human or as a machine, only focus on what's left beyond that.”

Josh Stroschein concurs with the necessity of reducing that surface area before turning to automation, remarking:

> “I mean, if you give me 10,000 functions or 500, I'm going to hallucinate more on the 10,000 myself. So it would make sense that our LLMs are just going to do the same thing, at least right now.”

- Statically compiled binaries (Go, Rust) routinely introduce thousands of runtime and library functions into a single file. - Filtering out established dependencies leaves only the core logic for automated LLM reversing or human review. - Reducing function volume directly prevents human cognitive overload and curbs model hallucinations.

---

`31:37` Enriching Code Matching: Dynamic Telemetry and Semantic Propagation

Josh raises the question of whether binary similarity (BIN-SIM) models can incorporate broader external and runtime clues—such as dynamic sandbox executions, outbound IP connections, WHOIS lookups, and historical telemetry—to produce better matches and automated labels. Jonas explains that ThreatRay has deliberately adhered to a pure static analysis paradigm. A purely static framework avoids the overhead, evasion risks, and unreliability of forcing suspicious code to execute. Nonetheless, Jonas acknowledges that granular dynamic execution traces could theoretically help characterize behavior much more sharply within a machine learning pipeline.

Endre agrees with Josh's line of thought, asserting that raw code matching without context is fundamentally limited. Moving forward, attributing samples to accurate malware families must be augmented by rich contextual signals, whether through observed API calls or network infrastructure. Furthermore, Endre proposes an architectural hybrid between LLMs and binary similarity: because LLM-driven reverse engineering is computationally expensive and slow, an AI agent could thoroughly reverse a single instance of a routine, extract its functional semantics, and then propagate those semantic annotations across every related binary in the database using similarity indexing. Endre asserts:

> “I personally think the more context you can add to a piece of code, the more useful this similarity will become.”

- ThreatRay currently relies on purely static binary analysis to avoid the operational bottlenecks of sandboxing and dynamic execution. - Endre points out that dynamic behavior (such as sequential API invocations) is simply another layer of program semantics. - Reversing a function once via an LLM and using code similarity to propagate those semantic labels across matching functions across the corpus can yield massive speedups.

---

`35:00` The Intermediate Representation (IR) Debate: Lifting vs. Learning

Josh pivots the conversation to semantic extraction techniques, specifically lifting native machine instructions into an Intermediate Representation (IR) to strip away syntactic differences across CPU architectures. He notes that while projects have explored this space, writing generalized rules (like YARA signatures) at an IR level seems fraught with practical hurdles, and he asks for their take on the trade-offs.

Jonas outlines two fundamental schools of thought in binary code similarity:

1. **The IR/Lifting Approach:** Machine instructions are lifted to an intermediate language to eliminate variations generated by varying compiler optimization levels and target CPU architectures. While this produces cleaner code representation, it introduces a fragile and computationally heavy compilation/decompilation step. Jonas recalls that when ThreatRay initially investigated lifting, the underlying tooling was notoriously brittle. 2. **The Machine Learning Approach:** The similarity system bypasses lifting entirely. Instead, statistical or deep learning models are trained directly on raw binaries, learning to remain invariant to compiler variations and architectural shifts on their own without needing an intermediate abstraction layer.

Jonas observes that if IR and lifter ecosystems have matured into robust, stable toolchains in recent years, an IR-centric approach represents an exceptionally clean foundation for code representation.

---

`37:47` Real-World Scale: Connecting Unknown Samples to Threat Intelligence

Josh steers the discussion back to practical operations, highlighting that only a small circle of specialized reverse engineers analyze malware function by function. He asks how binary similarity delivers practical value at scale to frontline incident responders who recover an obfuscated, unfamiliar payload during an active breach.

Endre explains that responders primarily need immediate answers: identifying the malware family or discovering relevant contextual threat intelligence. To bridge this gap, ThreatRay automated an intelligence-gathering pipeline that indexes public threat data:

```mermaid flowchart LR accTitle: ThreatRay OSINT Ingestion Pipeline accDescr: ThreatRay crawls public blog posts, extracts hashes, fetches binaries, indexes their code, and links them to incident response queries.

subgraph Ingestion["OSINT Harvesting"] A["Threat Intelligence Blogs (e.g., Mandiant, Vendors)"] --> B["Extract Hashes & Indicators"] B --> C["Acquire Binary Samples"] end

subgraph Indexing["Code Processing"] C --> D["ThreatRay Code Similarity Index"] end

subgraph Application["Incident Response"] E["Unknown Incident Payload"] --> F["Similarity Query"] F --> D D --> G["Matched Blog Posts, Actor Context & Attribution"] end ```

ThreatRay actively crawls open-source threat intelligence (OSINT)—such as technical research blogs published by Mandiant and other cybersecurity vendors—to extract reported cryptographic hashes. They retrieve the underlying binaries and index their code down to the functional level. Consequently, when an incident responder encounters a novel, heavily obfuscated sample that yields no direct hash matches or obvious family attribution, ThreatRay's engine can match small fragments of code back to historical binaries detailed in specific research publications, immediately supplying the responder with adversary context and investigation leads.

- ThreatRay regularly harvests hashes from public threat intelligence publications, pulls the corresponding binaries, and indexes their internal code. - Even if a captured file shares no direct file hash with known threats, functional similarity can associate it with past campaign analyses and adversary reporting.

`40:00` Triage, Incident Response, and the Ambiguity of Detections

Even when code reuse is minimal or binaries are partially obfuscated, matching just a few functions can be sufficient to point an incident responder toward a relevant public blog post or analysis, unlocking the rest of an investigation. While the analyst must still read the report and perform follow-up research, having that anchor is radically better than confronting an unknown binary blindly. By filtering out standard library code beforehand, AI systems can also reliably infer and output the core capabilities of an unknown sample. As Endre Bangerter emphasizes regarding front-line triage:

> “I mean, these people in the end basically either care about the family or capability for a quick triage and I think these are problems you will be able to solve with AI.”

Josh Stroschein notes that this filtering and confident identification addresses a chronic pain point across the industry. When submitting a file hash to public and private multi-engine platforms, practitioners frequently receive a mixed bag of conflicting classifications. It is often impossible to know whether a tag is derived from genuine binary code similarity, an opportunistic IDS signature, or generic network heuristics. When responding to an incident where an infection might have been active for weeks or months, identifying a specific threat like RedLine Stealer helps shape persistence checks, but responders often have to assume a worst-case scenario regardless. Stroschein ponders the split between earlier prevention and post-breach detection, questioning how much post-infection classification actually alters response workflows versus preventing the compromise altogether.

```mermaid flowchart TD accTitle: Binary Filtering and Triage Flow accDescr: Processing unknown malware through library stripping to derive classification and capabilities.

subgraph Input ["Ingestion"] Raw["Unknown Binary Sample"] end

subgraph Processing ["ThreatRay Analysis"] Strip["Strip Library Code / Dependencies"] Match["Binary Similarity & AI Evaluation"] end

subgraph Output ["Incident Response Value"] Cap["Extract Malware Capabilities"] Fam["Identify Malware Family"] Report["Link to OSINT / Public Reports"] end

Raw --> Strip Strip --> Match Match --> Cap Match --> Fam Match --> Report ```

- When querying multi-scanner platforms, detection labels often bubble up from unrelated network signals or IDS alerts rather than verified code similarities. - Understanding whether an incident involves ransomware, an information stealer, or an APT fundamentally alters the incident response playbook.

---

`43:24` Retrospective Hunting and Searchable Binary Code

Jonas Wagner clarifies that ThreatRay positions itself at the far end of the operational lifecycle, focusing on deep post-incident investigation and authoritative classification. A core capability of their architecture is treating binary code as an indexable, searchable entity over millions of samples spanning more than a decade of data. Whenever a new threat signature or malware family is extracted from open-source intelligence (OSINT), the platform can reclassify its entire historical repository. This allows analysts to immediately uncover unrecorded historical variants or discover that an APT had deployed tools years before public disclosures.

> “So we see quite a lot of overlaps between kind of older variants or tools or families that were reported years later, and that's ultimately only possible because we treat binary code as a searchable entity.”

Unlike conventional retro-hunting workflows—which require analysts to craft targeted YARA rules and wait through long, computationally heavy retroactive scans—a pre-indexed code database surfaces past variants instantly. Endre adds that while classification and capability mapping dominate mainstream incident response, binary similarity delivers massive utility to intelligence analysts who must cluster unclassified samples, identify previously unknown families, and establish code lineage for actor attribution.

- Historical code indexing eliminates the latency and syntax burdens associated with manual retro-hunting via YARA. - Code clustering enables analysts to prioritize either densely populated clusters (widespread campaigns) or completely isolated samples (stealthy bespoke tooling). - Code lineage tracking exposes structural relationships across different malware generations and rival or allied threat actor groups.

---

`46:17` Verifiability and the Rise of Agentic AI

Trust in binary similarity requires rigorous transparency. Threat analysts and reverse engineers will not accept opaque, black-box declarations that two binaries are related; they need clear provenance. ThreatRay addresses this by exposing verification trails across both the algorithmic and intelligence layers. When a match is reported, the system shows the exact reference sample, the corresponding OSINT report, and the specific functions or assembly blocks that triggered the hit.

Looking forward, Endre highlights agentic AI as the breakthrough mechanism to democratize these niche, time-intensive intelligence workflows. While reversing and attributing an APT family across hundreds of related binaries typically requires an elite analyst to dedicate six to eight hours of uninterrupted effort, ThreatRay’s early internal trials demonstrated that pairing an AI agent with binary similarity APIs compressed that exact task to 20 minutes with equivalent conclusions:

> “Binary similarity and the data behind it, etc., will become a very important tool for agents, which delivers a very unique signal and the signal is precise.”

While raw LLMs are prone to hallucinations and non-deterministic speculation, feeding them verified binary similarity data gives them an objective, highly specialized ground truth on which they can build reliable automated investigations.

`50:00` The Agentic Future: Bringing Binary Analysis to the Front Lines

Endre Bangerter sketches out his vision of where binary analysis is inevitably heading: a paradigm shift toward autonomous agents that orchestrate a suite of classical analysis technologies rather than attempting to replace them. In this emerging ecosystem, decompilers, disassemblers, sandboxes, binary similarity engines, and PE file viewers are transformed into discrete lower-level tools invoked and intelligently combined by agents. Endre emphasizes that this development will finally make binary analysis mainstream. Currently, frontline Security Operations Center (SOC) personnel face massive hurdles when handling unknown binaries; constrained by time and lacking deep reverse engineering expertise, they typically submit a file to a sandbox and either get a useful behavioral report or hit a dead end, leaving them unable to perform deeper triage. By utilizing AI agents equipped with grounded, precise binary tools, the industry can democratize low-level analysis, allowing defenders to identify and stop threats much earlier in the attack lifecycle.

```mermaid flowchart TD accTitle: Agentic Binary Analysis Workflow accDescr: Diagram illustrating how an agent coordinates lower-level binary analysis tools to triage malware for SOC analysts and reverse engineers.

subgraph Agents ["Autonomous Agent Layer"] LLM["AI Orchestration Agent"] end

subgraph Tools ["Grounded Classical Tooling"] DIS["Disassemblers & Decompilers"] SIM["Code Similarity Engines"] SBX["Sandboxes & Dynamic Traces"] PEV["PE File Viewers & Parsers"] end

subgraph Defense ["Security Outcomes"] SOC["SOC Frontline: Rapid Triage"] RE["Senior RE: Deep Investigation"] end

Josh Stroschein responds enthusiastically, noting that he has long advocated for technical security practitioners to build foundational reverse engineering skills. Without understanding how a binary interacts with the operating system at a granular level, triaging an unknown sample effectively remains nearly impossible. However, the steep learning curve and time commitment of reversing have historically kept it out of reach for most defenders. Bringing contextual analysis and code pattern similarity right to the front lines would represent a profound leap forward. Jonas Wagner seconds this optimism, sharing that his own hands-on work combining agents with ThreatRay's platform and traditional tools has proven extraordinarily empowering. He points out that this architecture allows someone with only moderate reversing ability to perform meaningful binary triage, while elite reverse engineers like Josh will be liberated from tedious boilerplate tasks. As Endre puts it: “And making binary analysis mainstream through agents which use precise tools on a lower level, that will make binary analysis accessible to much more people, and that's eventually very good because you need that capability early on in the defense process, right?”

- The shift toward agentic workflows relies on agents orchestrating traditional, grounded tooling (disassemblers, decompilers, PE viewers, sandboxes, and similarity platforms) rather than relying on pure LLM inference. - Democratizing binary analysis addresses the acute bottleneck in SOC environments where analysts lack the time and specialization to conduct deep manual reverse engineering. - Freeing senior reverse engineers from routine plumbing enables them to dedicate their focus to novel techniques and truly complex malware threats.

---

`52:45` The Persistent Hurdle of Obfuscation and the Rise of Anti-LLM Techniques

Despite the promise of agentic analysis, Josh expresses lingering skepticism when it comes to heavily obfuscated malware. He walks through the concrete structural challenges of binaries with scattered control flow, opaque predicates, and indirect control flow jumps. Standard static tools like IDA Pro fail to construct a clean control flow graph because they cannot resolve indirect execution branches without dynamic execution traces, binary patching, and laborious manual restitching. Josh questions whether LLMs can genuinely overcome these fundamental roadblocks, noting that while an answer may exist somewhere within the instructions, opaque layering makes program flow profoundly difficult to trace algorithmically.

```mermaid flowchart LR accTitle: Obfuscation Roadblock to LLM Analysis accDescr: Illustrating how indirect control flow disrupts both static disassemblers and LLMs until manual or dynamic reconstruction occurs.

A["Obfuscated Binary"] --> B["Indirect Control Flow & Splattered CFG"] B --> C["Disassembler Fails (IDA Pro)"] B --> D["LLM Loses Context & Reasoning"] C & D --> E["Requires Dynamic Execution & Manual Patching"] ```

Endre acknowledges that Josh’s reservations are entirely justified, clarifying that LLMs possess no magic bullet for deobfuscation. In fact, he argues that the widespread introduction of LLMs into automated malware reversing will inevitably trigger the next chapter in the cat-and-mouse game: the emergence of dedicated anti-LLM obfuscations engineered deliberately to induce LLM hallucination and failure. Jonas and Endre reject the idea that AI will wrap up reverse engineering challenges within a couple of years. In Endre's words: “The more we are throwing LLMs into malware reversing and automating this, I'm sure we will see also malware surfacing, which has anti-LLM obfuscation in there. Right. I mean, they will make the LLMs fail. And it's for sure not the end of the story, right? It's not like LLMs will solve everything and in two years we're done.”

- Indirect control flow and scattered execution graphs disrupt static disassembly tools and prevent LLMs from following code logic without external execution or patching. - Adversaries are expected to pivot toward anti-LLM obfuscation techniques designed specifically to cause AI reasoning agents to break or produce bogus output. - Automated deobfuscation remains an iterative, adversarial cycle rather than a solved problem.

---

`55:00` Adversarial Adaptation, the Fast-Moving AI Hype Cycle, and Closing Thoughts

Expanding on Endre's remarks, Josh outlines his thesis regarding the evolution of evasion. Most malware obfuscations encountered in the wild today were designed solely to slow down human analysts and bypass rudimentary static signature scanners. However, as automated AI-driven analysis expands, sophisticated threat actors will inevitably adapt. These adversaries will not simply resort to basic prompt injections; they will deploy structural, pattern-breaking code mutations engineered to undermine the mathematical models and tokenization logic of LLMs. Because LLMs fundamentally face the exact same structural challenges as humans—struggling equally when a control flow graph is fractured into indirect jumps—they will hit the same walls, requiring external tools to reconstruct execution traces and patch binaries.

Jonas reflects on the broader AI landscape, acknowledging that the past few years of intense AI hype have made it difficult to separate substantive technical utility from marketing noise. The field is developing at an overwhelming pace, where model capabilities and techniques learned just three months earlier are rapidly eclipsed by newer architectures. Jonas anticipates that this volatility will stabilize over the next couple of years, yielding a far clearer picture of how both attackers and defenders utilize these technologies in production.

Wrapping up the episode, Josh thanks both Jonas Wagner and Endre Bangerter for sharing their perspectives on binary similarity and the pragmatic integration of machine learning into malware analysis. Jonas thanks Josh for hosting the conversation, and Josh closes the show by reminding listeners to subscribe, leave a review, stay curious, and keep exploring.

- Traditional obfuscation was built to defeat static signatures and human analysts; future evasion will target AI tokenization and control flow parsing directly. - Anti-LLM evasion will move beyond textual prompt injections into code-level structural mutations that obscure intent from machine learning models. - The AI hype cycle is expected to settle over the next few years into realistic defensive and offensive operational baselines.

## Notable quotes > `52:45` The more we are throwing LLMs into malware reversing and automating this, I'm sure we will see also malware surfacing, which has anti-LLM obfuscation in there. — Endre Bangerter

> `46:17` Binary similarity and the data behind it, etc., will become a very important tool for agents, which delivers a very unique signal and the signal is precise. — Endre Bangerter

## Mentioned ThreatRay, Josh Stroschein, Jonas Wagner, Endre Bangerter, BinDiff, SSDEEP, YARA, IDA FLIRT, Ghidra BSim, MCRIT, Daniel Plohmann, abuse.ch, VirusTotal, Go, Rust, Obfuscator-LLVM, Mandiant, RedLine Stealer, IDA Pro

## Video description "Throwing more LLM prompts at a packed binary won’t make your analysis faster. But combining code similarity with AI will." In Episode 29 of Behind the Binary, Jonas Wagner and Endre Bangerter of ThreatRay join the podcast to lay out the real-world state of binary similarity in the LLM era. They demystify the current AI hype cycle, explaining why large language models are structurally unsuited for raw, unguided binary analysis, and how traditional binary similarity techniques are finding a ma...

[Source](https://www.buzzsprout.com/2414128/episodes/19802488-ep29-binary-similarity-in-the-llm-era-with-jonas-wagner-and-endre-bangerter-of-threatray.mp3)

中文简报

ThreatRay结合代码匹配与AI技术大幅缩短恶意软件分析耗时大语言模型若没有二进制相似度引擎先行过滤良性运行时库，便无法可靠逆向编译后的恶意软件，这为对抗转向针对LLM的代码混淆奠定了基础。 Jonas Wagner与Endre Bangerter梳理了二进制相似度分析从BinDiff和SSDEEP等传统启发式算法，到现代函数嵌入和智能体工作流的演变过程。他们解释道，恶意软件分类的实际瓶颈在于数据治理、沙箱引爆以及剔除Go和Rust等静态链接语言中的运行时噪声，而非学术层面的算法设计。尽管攻击者理论上可以利用生成式AI或高级混淆手段来瓦解代码匹配模型，但现实情况是威胁行为者很少在标准加壳之外投入更多成本。最后，两位嘉宾展示了将预先索引的代码相似度与自主AI智能体相结合，如何在不陷入大语言模型幻觉的情况下，大幅加速分类排查、良性代码剔除以及追溯性威胁狩猎。用于二进制代码相似度的学术算法往往难以转化为可行的生产工具，因为有效的归因取决于海量数据工程、沙箱引爆以及带标签的参考数据集，而不仅仅是比较算法本身。 (6:00) 二进制代码相似度通过剔除数千个良性和库函数，为AI逆向工程管线提供了巨大价值，它通过仅隔离出独特的恶意代码，防止了大语言模型出现上下文耗尽和幻觉。 (25:00) ThreatRay通过抓取威胁情报博客、提取引用的二进制哈希并为其代码建立索引，实现了开源情报索引的自动化，使一线应急响应人员能够将新颖、混淆的有效载荷直接关联回公开的威胁组织报告。 (37:47) ThreatRay的内部测试表明，为智能体AI模型配备高精度的二进制相似度与逆向工程API，可将复杂的多二进制APT归因工作流从八小时压缩至仅二十分钟。 (46:17) 安全研究人员预测，逆向工程中AI自动化程度的提升将引发专门的反LLM混淆手段，这些手段专门设计用来诱发幻觉并破坏模型的分词逻辑。 (52:45)

Detailed notes — zh

## Background 本期播客由 Josh Stroschein 主持并发布于 RSS/网络平台的《Behind the Binary》栏目（第 29 期），上线于 2026 年 9 月 16 日。节目邀请了 ThreatRay 联合创始人 Jonas Wagner 与 Endre Bangerter 共同做客，围绕“大语言模型（LLM）时代的二进制相似度”展开深入探讨，揭示了为何单纯向加壳二进制文件堆砌 LLM 提示词无法加速分析，以及代码相似度技术如何与现代 AI 结合实现高效逆向。 ## TL;DR 节目系统梳理了二进制代码相似性（Bin-Sim）的核心挑战，剖析了编译器如何抹除符号元信息并引入代码形变，以及技术范式从手写规则（如 BinDiff）、图结构匹配向向量嵌入（如 Ghidra BSim）的演进。嘉宾指出，现实恶意软件大多仅采用简单加壳，而海量静态编译语言（如 Go、Rust）带来的第三方库噪声成为分析的主要瓶颈。通过利用代码相似度建立良性库白名单进行去噪预过滤，可将成千上万个函数精炼为几十个核心函数投喂给 LLM，从根本上遏制模型幻觉并大幅提速。最后，对谈展望了由 AI 智能体（Agent）整合反汇编、动态沙箱与高精度代码相似度信号的未来防御格局，并探讨了未来可能出现的专门针对 LLM 的对抗性混淆机制。 ## Atmosphere & style 整场对话洋溢着资深逆向工程师之间务实、理性且极具洞察力的专业技术氛围。面对当前狂热的 AI 炒作周期，嘉宾们没有盲目跟风，而是以严谨的技术视角拆解大模型处理底层机器指令时的致命短板，既有对现实黑产“反直觉低水平”的生动调侃，也有对攻防对抗演进的前瞻性思考。主持人的层层追问与两位创始人的技术深潜形成顺畅呼应，让听众在冷静、去伪存真的技术思辨中感受到二进制底层分析与前沿人工智能碰撞带来的深刻震撼。 ## Bulletin - `27:00` 大语言模型（LLM）若直接处理整个被加壳的二进制文件极易产生严重幻觉，而通过预先进行良性库代码去噪过滤，可将成千上万个函数浓缩至数十个核心恶意函数再交由 LLM 分析，实现秒级高精度逆向。 - `47:15` 在针对复杂 APT 恶意家族的对比基准测试中，结合底层函数级代码相似度与关联引擎的 AI 智能体仅耗时 20 分钟便完成了资深逆向专家需 8 小时才能得出的人工研判结论。 - `42:45` 现代恶意代码相似度分析正将底层机器码作为可检索实体进行索引，使得防御者在开源威胁情报（OSINT）更新后能够秒级完成跨越十余年的全量历史样本回溯，彻底摆脱传统离线 YARA 慢速扫描的局限。 - `20:00` 真实攻防中恶意软件作者绝大多数仅采用基础加壳而非破坏控制流图的高级编译期混淆，使得以控制流图为核心的结构相似性技术在当前依然具备极高的工业落地有效性。 ## Key takeaways - `00:00` 二进制相似度分析的核心目标是判断两段原生机器指令是否源自相同源码，而编译器抹除元数据及不同优化级别带来的巨大代码形变是逆向推断的主要瓶颈。 - `05:00` 二进制相似度算法本身在开源社区屡见不鲜，但真正构成工业级落地技术壁垒的是高质量、经过精准清洗和打标的已知代码与恶意软件语料库。 - `10:00` 绝大多数恶意代码均带有外壳，沙箱内存转储往往输出数十个碎片，使传统一对一的样本比对演变成包含加载器与动态库的高维‘多对多’代码集合比对。 - `15:00` 二进制相似度存在从‘语法字节层’到‘结构控制流图层’再到‘语义层’的技术光谱；符号执行等纯语义方案开销极大，因此结构相似度仍是当前工业界最具性价比的近似代理。 - `25:00` 若未来攻击者借助 LLM 能够为单次攻击动态生成全新恶意家族，传统基于静态特征与控制流图的检测将彻底失效，防御技术必须向基于底层行为语义（如击键记录、代码注入等 API 序列）的匹配迁移。 - `30:00` 针对 Go、Rust 等静态编译语言引入的海量运行时库噪声，代码相似度引擎能够快速剔除已知良性代码，大幅降低人类分析师与大语言模型的认知负载与幻觉风险。 - `35:00` 将底层机器码抽象为中间表示（IR）在理论上能消除架构差异，但由于 Lifting 工具链过于脆弱且拖慢性能，现代工程实践更倾向于利用机器学习模型在原生指令级别直接学习抗变异特征。 - `40:00` 将安全厂商公开情报（OSINT）博客样本与底层代码进行全局索引，使应急响应人员在现场捕获未知混淆样本时，仅凭几个相似函数即可穿透表象反查到关联的攻击活动。 - `45:00` 自动化代码相似度引擎必须保持‘可验证性’，向分析人员提供基准样本报告溯源与底层汇编指令对比白盒细节，以满足逆向专家的审慎研判需求。 - `50:00` AI 智能体将反汇编、沙箱与代码相似度等底层经典工具打通并自主调度，有望大幅降低二进制分析的专业门槛，将前置分流与深度防御能力普及至一线 SOC 人员。 - `53:15` 面对间接控制流等深度混淆，LLM 同样会陷入迷失，未来攻防对抗必将催生出专门破坏代码特征模式、干扰 LLM 语义理解的对抗性 Anti-LLM 混淆技术。 ## Detailed walkthrough ### `00:00` 二进制相似度（Bin-Sim）的核心定义与编译挑战本期节目探讨了在大语言模型（LLM）时代背景下二进制代码相似性（Binary Code Similarity，简称 Bin-Sim）的演进历程与现实挑战。对话开篇指出了一个极端的攻防悖论：如果 LLM 的自动化生成效率持续攀升，攻击者甚至可以做到在每一次攻击中都使用全新生成的恶意软件家族，届时纯粹依赖代码层面的检测和分析手段其实用性将大打折扣。正如嘉宾在开场所强调的：“If the LLMs take over and they get even more efficient, then I mean, the attacker could craft a new malware family for every attack, right? In the extreme case. Then, to be honest, then all code-based approaches become less useful, right?” 虽然 AI 为防御者带来了前所未有的分析速度，但它同样赋予了攻击者近乎无限的规模化生产能力。主持人 Josh Strohschein 随后介绍了来自 ThreatRay 的两位联合创始人 Endre Bangerter 与 Jonas Wagner，并抛出首要议题：究竟什么是二进制相似度？Jonas 解释称，这个概念的目标直截了当——即观察两段二进制机器代码，判断它们是否由相同的源代码编译而来。能够在规模化场景下高可靠地完成这种判断，将在众多安全领域解锁极具价值的应用。Josh 指出，虽然概念可以泛化，但在安全领域最核心也是最艰难的场景，正是针对那些由 CPU 直接执行的原生机器指令（Native Code）。谈及这一问题为何长期难以攻克，Jonas 指出，最根本的瓶颈在于逆向工程师无法接触到原始源代码，只能完全依赖编译后残留的机器码。在此过程中，编译器扮演了双重破坏者的角色： - **销毁关键元信息**：编译过程抹去了原始代码中的函数名、局部变量名等对逆向分析极其重要的语义数据。 - **引入巨大的代码形变（Variance）**：相同的源代码在不同的编译器品牌、不同的优化标志级别（如 `-O0` 到 `-O3`）或不同的目标架构（如 x86、x64、ARM）下，最终生成的机器码在形态上往往天差地别。所有二进制相似度工具的本质，都是在逆向工程中寻找编译后残存的数据或结构特征，以此为线索回溯推断它们源于同构代码。 ```mermaid flowchart TD accTitle: Compilation variance in binary similarity accDescr: Shows how source code information is lost and varied during compilation, leaving limited binary artifacts for analysis. subgraph SRC["原始输入 (Source Context)"] A["高级语言源代码 (C/C++)"] B["高价值元信息 (函数名 / 变量名 / 类型)"] end subgraph COMP["编译器转换过程 (Compiler Effects)"] C["信息抹除 (符号与结构擦除)"] D["代码形变 (架构/优化标志/编译器差异)"] end subgraph BIN["底层产物 (Machine Code Output)"] E["各异的原生二进制指令流"] F["相似度算法回溯匹配 (Bin-Sim Matching)"] end A --> C B -.->|"被销毁"| C A --> D C --> E D --> E E --> F ``` --- ### `05:00` 从领域规则匹配到机器学习与学术工具的演进回顾二进制代码相似性过去二十年的发展历程，其演变清晰地分为几个世代。早期生态基本由资深安全研究员手工设计的领域规则（Handcrafted Domain Knowledge）主导，其中最具代表性的奠基之作是 BinDiff。Jonas 将其称为代码相似性领域的“教父”工具：它通过比较两个二进制文件，精确识别其中哪些函数是共享的、哪些是独有的，启发了后续无数研究。然而，传统的工具生态面临着显著的两极分化：BinDiff 具备极高的函数匹配精度，但在海量样本比对时速度较慢，难以应对横向扩展；而像 SSDeep 这类基于分文字下文触发哈希（CTPH）的模糊哈希（Fuzzy Hashing）工具虽然检索极快，匹配粒度却过于浅显，对抗编译器的代码变异时极其脆弱。大约十年前，学术界与工业界开启了一次重要的范式转移。研究者们不再局限于手工编写启发式对比逻辑，而是尝试引入机器学习（ML）、深度学习，乃至当下以 Transformer 架构和大语言模型为核心的向量化方案。ThreatRay 早期切入该领域的初衷，也是试图借助数据驱动的方法破局：探讨机器学习模型能否在海量数据下不仅兼具 BinDiff 的高精度，同时还能像哈希匹配那样兼顾扩展性与面对编译器混淆的鲁棒性。针对 Josh 提出的“近年来开源领域或公共工具似乎略显停滞”的疑问，Jonas 指出了两个代表性的现代化公开项目： - **Ghidra 的 BSim（vSim）**：采用了非常前沿的机制，把函数直接编码并投影到高维向量空间生成嵌入（Vector Embeddings）。依托向量相似度检索，它能够在超大规模数据集上执行极速匹配，解决了传统图遍历匹配无法扩容的问题。 - **Daniel Plohmann 开发的 MCRIT**：这是一个开源的二进制代码相似性平台，从底层完整构建了代码相似度索引与搜索管道，配备了工业级系统所需的整套机制。 Endre Bangerter 对此进行了关键补充，解释了为何学术界论文和 GitHub 项目层出不穷，但真正能落地的工业级工具却极为罕见。他指出，实现某种相似度算法本身并不难，甚至在 GitHub 上可以找到无数复现论文的算法代码；但想要让其在现实业务中产生价值，算法仅仅是冰山一角，最核心的壁垒在于是否掌握高质量的参考数据集和精准的元数据关联。没有庞大且规整的已知库与恶意软件数据支撑，再优秀的算法面对未知样本也无法输出有意义的结论。 - **算法与数据割裂**：开源社区往往能提供算法实现，但工业级落地受制于高质量恶意代码语料库与库函数指纹库的匮乏。 - **匹配技术范式演进**：手工启发式匹配（如 BinDiff、IDA FLIRT、SSDeep） $\rightarrow$ 深度学习与图神经网络 $\rightarrow$ 基于 Transformer 与向量嵌入的特征匹配（如 BSim）。 ### `10:00` 样本获取的瓶颈与天真相似度比对的现实困境对终端用户而言，如何让分析结果变得“易于理解和消费”，往往比核心算法本身更难。核心算法虽然极其吸引人，但如果没有经过精细清洗、打好标签的数据库作为支撑，其本身在实际场景中并没有太大用处。Josh Stroschein 提出了现实中分析师面临的困境：如果要编写一条 YARA 规则来标记某个恶意软件家族，首先必须拿到能够代表该家族的样本集，并对其进行置信度验证，还要在更大的已知家族语料库中交叉测试。数据源的代表性也是个巨大疑难，无论是完全开放的 Abuse.ch，还是处于付费墙后的 VirusTotal，分析师都很难判断这些样本是否能真正代表野外生态的全貌。针对这种困惑，Endre Bangerter 阐释了代码相似度在恶意软件分类中的核心逻辑与真实挑战。理论上，天真的设想极其直观：从尽可能多的家族中收集确认无误的参考样本，当遇到未知二进制文件时，比对代码重合度最高的参考样本，并将该家族标签传递给未知样本即可。然而真实世界的复杂性迅速打破了这种美好假象。当下绝大多数恶意软件都会加壳（Packed），而家族特征通常只存在于脱壳后的有效载荷（Payload）中。为了解决这一问题，ThreatRay 的做法是将所有参考样本以及待分析的未知样本全部送入沙箱中引爆（Detonate）。其沙箱系统在监控内存、执行脱壳并下载网络载荷后，会将内存中所有未知的可执行代码全部转储出来。但这直接导致比较维度发生剧烈爆炸：分析师不再是拿两个明确的样本进行一对一比对，而是面对一个样本在沙箱中解出 10 个、20 个甚至 30 个内存转储片段，最终演变成“多对多”的二进制代码集合比对。正如 Endre Bangerter 所总结的那样：“And suddenly you have a much more difficult problem. You're comparing sets of binaries to many sets of binaries, right? And no longer two clearly attributed samples from family and an unknown sample, basically, right?” ```mermaid flowchart TD accTitle: Sandbox Detonation and Data Curation Workflow accDescr: 样本通过沙箱引爆后产生多段内存转储，经过去噪与细粒度函数级标注，以实现准确的二进制相似度比对。 subgraph S1["样本引爆阶段"] A["加壳恶意样本"] -->|"沙箱动态引爆 / 内存监控"| B["内存转储代码段 (10-30 个碎片)"] end subgraph S2["噪声混淆困境"] B --> C["加载器 (Loaders)"] B --> D["第三方依赖库 (Libraries)"] B --> E["真实核心载荷 (True Payload)"] end subgraph S3["数据治理与比对"] E -->|"自动化去噪与打标"| F["函数级精准特征提取"] F -->|"规避短函数与通用代码"| G["家族分类与代码相似度比对"] end ``` ### `15:00` 载荷治理与现代混淆编译下的相似度光谱当样本在沙箱中引爆后，加载器（Loaders）和系统动态库等大量噪音代码随之涌现。如果直接进行天真的相似度比对，未知样本往往会错误地匹配到通用加载器或静态链接库上，导致家族分类完全失效。因此，数据的清洗与治理（Data Curation）成为了最耗时、最关键的护城河。即使成功定位了核心载荷，静态链接库的混入依然屡见不鲜；此外，算法在不同大小的函数上表现差异极大，过小的函数极易引发误报，某些大型函数同样可能产生混淆。ThreatRay 将比对粒度细化到“函数级别（Per-function Level）”，并投入大量精力构建自动化工作流与工具，以剔除库代码噪声并精准标注载荷。 Josh 进一步提出了更加严峻的现实挑战：现代编程语言（如 Go、Rust）自带庞大的运行时环境和静态链接库，编译器优化（如不同的优化等级）能产生极具破坏性的指令变动，而主动的控制流平坦化、混淆手段（注入不透明谓词、混合布尔算术 MBA、打散函数边界）更让二进制的最终形态面目全非。面对这些足以摧毁特征签名的变化，二进制相似度分析究竟该如何立足？ Jonas Wagner 解释称，面对编译器优化带来的“隐式变异（Implicit Variation）”与对抗性的“显式混淆（Explicit Obfuscation）”，关键在于从编译产物中提取能够跨越这些变异的特征。这在技术上存在一个从浅入深的光谱： - **语法相似度（Syntactic Similarity）**：光谱的最左侧类似于模糊哈希（SSDEEP）的思路，直接比对两段指令序列的语法对齐情况。 - **局限性**：这种方法运行极快，但在现代逆向场景中极其脆弱。只要编译器更换了优化标记、调整了指令生成顺序，或者引入了哪怕极其轻微的代码变换，语法比对便会彻底失效。正如 Jonas Wagner 所断言：“So it's good, it's super fast, but very brittle. It's very easy to kind of get around that, even if you just add a compiler optimization flag.” ### `20:00` 结构相似性、语义层分析与现实恶意软件的“反直觉低水平” Jonas Wagner 解释了二进制代码相似性比对的更高层级——**结构相似性（Structural Similarity）**。例如反编译工具或 BinDiff 这类工具所做的，就是分析函数的控制流图（Control Flow Graph, CFG）。最直观的假设是：如果两个函数的控制流图结构相似，那么其控制流就相似，大概率这两个函数本身也是相似的。BinDiff 正是通过精妙的图算法来比对这种结构。这种方法对编译器生成的微小变异或简单的混淆具有一定的容忍度；但一旦攻击者引入像“控制流平坦化”（Control Flow Graph Flattening）这样的对抗技术，结构层面的特征就会被彻底破坏。在结构之上，相似性分析的“终极圣杯”是**语义层（Semantic Layer）**——即判断两段二进制代码在本质上是否执行相同的功能。语义提取能抹平绝大部分显式或隐式引入的代码变异。学术界常尝试使用符号执行（Symbolic Execution）来从数学上证明两段代码功能等价，但由于其计算开销巨大、极难横向扩展，因此在工程实践中，绝大多数商业工具和主流学术方法仍然停留在结构相似性层面，将其作为逼近语义相似性的低成本代用品。 Endre Bangerter 随后提出一个令人吃惊的行业反常现象：虽然学术界和防御者整天研究对抗控制流平坦化或各种混淆技巧，但现实世界中的恶意软件作者实际上“懒得出奇”。他们大部分情况下只使用简单的加壳（Packing），很少采用真正破坏 CFG 的高级混淆器： > “And the reality is they don't do that much in most cases. I could put it like this. which is good for us, which is good for all the people who write yard rules.” —— Endre Bangerter Endre Bangerter 指出，正如 YARA 规则理论上极易被绕过，但现实中全球安全行业依然依靠 YARA 运作得极好一样，ThreatRay 通过代码相似性追踪恶意软件家族的效果出奇稳定。现实中的攻击手法与理论上“可能达到的混淆上限”之间存在巨大的鸿沟。 ```mermaid flowchart TD accTitle: 三层二进制相似性分析模型及其实际应用 accDescr: 展示语法字节层、结构控制流图层与语义层三个分析层级，并指出工业界目前停留在结构层的原因。 subgraph Layers["代码相似性分析层级"] L1["语法/字节层 (哈希、YARA规则)"] L2["结构相似性层 (CFG控制流图、BinDiff)"] L3["语义层 (圣杯) (符号执行、功能证明)"] L1 --> L2 L2 --> L3 end subgraph IndustryReality["工业落地现实"] P1["L3 开销极高，难以横向扩展"] P2["L2 是语义的最佳工程近似代理"] P3["绝大多数黑客仅加壳，极少做深度混淆"] end L3 -.-> P1 L2 ==> P2 P2 --> P3 ``` - **三层分析模型**：字节/语法层（易失效）、结构层（CFG 匹配，工业主力）、语义层（符号执行，理想但极其昂贵）。 - **现实混淆水平**：黑客极度依赖套壳（Packing），极少数高级样本会采用彻底破坏 CFG 的编译期混淆。 - **YARA 类比**：虽然特征极易通过重编译扰乱，但在实际攻防流水线中，简单的特征和结构图匹配依然高效得令人难以置信。 --- ### `25:00` 攻击者分层、LLM 驱动混淆与“语义攻击技术”的未来 Josh Stroschein 针对攻击者的技术分层进行了剖析。在黑产经济中，常见的商品化信息窃取木马（Commodity Info Stealer）通常是由基础设施平台生成原始二进制文件，而把免杀混淆交由下游客户自行解决，因此下游买家往往只套一层现成的加壳工具，这在宏观样本数据上造成了“低端加壳泛滥”的假象。然而，对于具备国家背景（APT）或高水平的攻击者，他们拥有定制的编译期混淆流水线（如定制化的 LLVM 混淆），能把混淆逻辑直接熔铸进二进制文件本身，彻底扭曲控制流。 Josh 分享了一个自身经历：他仅凭大语言模型的辅助，就在一个晚上将原版已废弃的 OLLVM（Obfuscator-LLVM）项目完整移植到了现代编译工具链上，且代码完全一对一兼容。连防御者都能在一个晚上借助 LLM 完成这种工具链适配，专注于进攻性操作的黑客组织更是能借助 LLM 实现指数级的混淆进化。面对 Josh 的顾虑，Endre Bangerter 承认，如果未来 LLM 让自动化攻击成本降到极低，甚至能为“每一次攻击活动动态生成一个全新的恶意软件家族”，那么所有基于静态代码特征的方法（无论是 YARA 规则还是 CFG 结构相似性）都将彻底失效。届时，安全行业必须全面转向**语义匹配（Semantic Matching）**： > “Let's say if you do, I don't know. Key Login, Code Injection, no matter how you write your code, there will be some semantic similarity between these attack techniques. And I think that's where the whole thing will be moving in the future, for sure.” —— Endre Bangerter 无论恶意代码表面如何变形，其底层的恶意操作（如击键记录、代码注入、特定 Windows API 调用序列）在语义逻辑上依然具备不可磨灭的共性。 --- ### `27:00` 白名单去噪：代码相似性在 LLM 时代的全新价值针对 LLM 时代传统相似性工具该如何生存的问题，Endre Bangerter 指出了一个此前常被忽视、但极具生命力的核心场景：**合法良性库代码（Goodware Identification）的识别与剔除**。恶意载荷通常是自研攻击逻辑与大量第三方开源库或系统运行库混合编译而成的。ThreatRay 在系统构建初期，为了提高恶意特征签名的纯净度，建立了一套庞大的合法软件与开源库索引库。即使未来恶意攻击代码每次都被 LLM 重新生成，其引用的公共库代码往往依然保持相对稳定。利用代码相似性技术迅速“剔除”已知的良性函数，剩下的未知部分就是核心攻击载荷。 ThreatRay 将这一理念应用于其最新的 AI 逆向功能中。许多安全厂商直接将反编译后的全部伪代码无脑投喂给 LLM，往往导致严重的上下文溢出与大模型幻觉。ThreatRay 采取了预过滤架构： ```mermaid flowchart LR accTitle: 结合相似性索引与LLM的高效逆向分析工作流 accDescr: 展示从千级函数载荷中通过白名单代码过滤，将分析范围缩减至50个核心函数并投喂给LLM的流程。 A["待分析恶意载荷 (例如 1000 个函数)"] --> B["良性库代码相似性过滤引擎 (Goodware Code Index)"] B -->|"识别出 950 个通用库函数"| C["剔除良性代码 (去噪)"] B -->|"剥离出 50 个未知函数"| D["核心恶意逻辑 (仅占 5%)"] D --> E["LLM / AI 逆向引擎 (定向深度反编译与分析)"] E --> F["高准确度报告 (零幻觉、秒级完成)"] ``` Endre 举例说明了这种混合方案的巨大收益： - **降本增效与遏制幻觉**：如果一个样本包含 1000 个函数，ThreatRay 的相似性引擎能立刻识别出其中的 950 个属于标准第三方库，逆向模块只需把剩下的 50 个未知函数发送给大模型。“LLM 处理 50 个函数不仅速度飞快，而且几乎不产生幻觉；如果一口气喂给它 1000 个函数，按现阶段 LLM 的水平必然会满嘴胡话。” - **反制 AI 动态生成的样本**：即便攻击者利用 LLM 针对每次行动重新生成独一无二的全新代码，这种“处处全新”的特征在企业端点（EDR）的基础设施流行度（Prevalence）检测中反而会极其显眼，直接暴露其异常性。 ### `30:00` 猫鼠游戏、静态编译语言的噪声过滤与上下文富集在二进制攻防的演变中，攻击者如果为每次攻击都生成全新的二进制文件，就会面临“独特性（Uniqueness）”带来的新问题。Endre Bangerter 指出，网络安全本质上是一场猫鼠游戏，攻击者与防御技术都在持续进化。分析师的核心诉求是将独一无二的新代码与通用代码剥离出来，一旦新代码凸显出来，就可以交给 AI 进行逆向分析。未来的代码相似度模型必然会引入更多语义理解（Semantics）。Jonas Wagner 进一步补充，现代恶意软件广泛采用 Go 或 Rust 等静态编译语言，分析师每次在反汇编器中打开二进制文件，都会面对数千甚至上万个函数。此时，代码相似度检测最具价值的落地场景，就是干净利落地剔除掉来自运行库（Runtime）或第三方开源库的“已知良性代码（Known Good Code）”，无论对于人类分析师还是自动化机器管线，都能将精力精确聚焦在剩余的恶意业务逻辑上。Josh Stroschein 打趣道，如果要看 10,000 个函数，自己产生的幻觉肯定比看 500 个函数要多得多，现在的 LLM 自然也是同理。随后 Josh 提出了一个启发性的问题：在二进制相似度（Bin-Sim）问题中，除了静态特征，是否还能引入沙箱运行时的动态信息（如连接过的 IP、Whois 数据、网络活动日志等上下文线索）来丰富特征匹配与标签标注？Jonas 回应称，ThreatRay 目前严格专注于纯静态方法，这种设计的最大优势在于无需依赖代码的实际执行（避免了动态沙箱对抗或未触发执行的问题）；但他承认，细粒度的动态执行轨迹（Fine-grained Execution Traces）如果能输入到分析管线中，必然能更好地刻画代码行为并提升结果。Endre 对此极为赞同，他强调单纯的代码匹配价值有限，必须依托上下文信息；而动态执行中记录的 API 调用本身就是一种代码语义。 ```mermaid flowchart TD accTitle: 静态编译二进制代码过滤与语义传播管线 accDescr: 展示从 Go/Rust 庞大二进制中过滤良性库代码、提炼核心恶意逻辑并通过相似度网络传播语义的流程。 subgraph Filter["1. 噪声过滤阶段"] A["Go / Rust 静态编译二进制 (10,000+ 函数)"] --> B["代码相似度引擎比对"] B --> C["剥离运行时与第三方库代码 (Known Good Code)"] B --> D["提取未知独特性代码 (Core Logic)"] end subgraph LLM_Rev["2. 语义抽取阶段"] D --> E["LLM / AI 针对性深度逆向"] E --> F["输出高价值语义注解 (API 行为 / 语义描述)"] end subgraph Propagate["3. 规模化传播阶段"] F --> G["相似度网络检索匹配"] G --> H["跨样本函数批量传播标注 (极速丰富知识库)"] end ``` - 静态编译的 Go 和 Rust 样本会引入大量运行时环境代码，导致反编译代码量暴增，阻碍分析效率。 - 剥离已知良性代码能够成倍降低人类逆向工程师与大型语言模型的“幻觉（Hallucination）”和认知负载。 - 动态分析数据（如 API 调用序列、外部 IP 通信）本质上是静态代码的动态语义表达，是未来相似度匹配的重要演进方向。 Endre Bangerter 在探讨结合代码相似度与人工智能逆向时强调： > “So, I mean, to simply propagate the semantics to all the functions which are sufficiently similar, that would be a huge speed up.” --- ### `35:00` 中间表示（IR）的权衡与事件响应者的实战赋能随着对话深入到代码语义层，Josh 提出了利用中间表示（Intermediate Representation, IR）进行提升（Lifting）的技术路径——通过将底层机器码抽象为结构更规范、语义更丰富的 IR，从而消除不同 CPU 架构和编译器优化带来的语法差异。Jonas 总结指出，学术界与工业界在处理二进制代码相似度时通常存在两个阵营：第一种阵营正是依靠 Lifting 转换到 IR，剥离编译器和架构变化以获得更干净的代码表征；但它的代价是引入了极其脆弱的工具链，并且会拖慢整个管线的吞吐性能。第二种阵营则是借助机器学习直接跨越架构和编译器的噪声，让模型学会忽略这些变化，从而完全避开中间表示层。Jonas 回忆 ThreatRay 早期调研该技术时，IR Lifting 工具链过于脆弱（Brittle），因而未被采纳；不过他也认可若现代 IR 技术变得稳定可靠，它依然是非常优秀的代码表示方案。对话随后收拢回真实的工业界应急响应（Incident Response, IR）场景。Josh 提问：对于广大不需要逐个函数扣代码的事件响应人员，二进制相似度技术如何真正赋能？Endre 坦言，事件响应人员拿到一个被混淆的未知样本时，首要目标通常不是逆向细节，而是弄清楚它到底是什么家族。为此，ThreatRay 建立了一套结合开源威胁情报（OSINT）的机制：自动化抓取如 Mandiant 等安全厂商技术博客中披露的恶意样本哈希，下载二进制文件并对其全部代码进行特征索引，将博客的威胁情报上下文与底层代码紧密绑定。即使现场捕获的代码是全新的变种或尚未被行业统一定名，相似度引擎也能直接穿透表象，将其与历史分析报告关联起来，迅速为现场排查人员还原出威胁背景。 - **IR Lifting 路线的权衡**：理论上能抹平指令集架构（ISA）和编译器优化差异，但 Lifting 过程非常脆弱，且会为大规模处理管线增加性能瓶颈与噪声。 - **机器学习路线的权衡**：跳过 IR 提升步骤，利用算法直接在原生指令级别训练模型鲁棒性，具备更强工程稳定性与处理速度。 - **情报与代码关联体系**：通过将安全厂商公开披露的技术博客样本进行全局代码索引，可使未知混淆样本在几秒内通过代码重合度反查到具体的攻击活动和威胁实体。 Endre Bangerter 在总结用户对相似度分析系统的期望时指出： > “I personally think the more context you can add to a piece of code, the more useful this similarity will become.” ### `40:00` 应急响应中的精准分类与能力识别在应急响应（Incident Response, IR）场景中，即便恶意代码经过了部分混淆，只要攻击者复用了部分代码，哪怕仅匹配到几个关键函数，往往就足以将分析人员直接指引到某篇公开发布的技术分析博客。这种关联能为调查打开突破口，分析师虽然仍需阅读报告并做进一步研判，但相比面对一个毫无头绪的未知二进制文件，工作效率会有质的提升。对于快速排查而言，分析人员最关心的无非是恶意软件家族归属或具体能力。结合 AI 预过滤技术，在剔除通用库代码后，系统能够相当可靠地提炼出样本的行为能力。 ```mermaid flowchart LR accTitle: 应急响应中的样本分流与分析流程 accDescr: 展示未知样本经过去噪和二进制相似度匹配后，支撑应急响应调查的过程。 subgraph Pre["样本预处理"] A["未知二进制样本"] --> B["剔除通用库代码\n(去噪处理)"] end subgraph Match["相似度检索"] B --> C["函数级代码\n相似度匹配"] C --> D["关联技术博客与\n历史已知报告"] end subgraph Triage["响应决策"] D --> E["明确恶意软件家族\n或功能特性"] E --> F["调整应急响应策略\n(勒索软件 vs APT)"] end ``` Josh Stroschein 指出，当前分析人员面临的一大痛点在于分类结果的杂乱与不可信。把一个样本的哈希值扔到各大公开或私有情报平台，得到的结果往往参差不齐。很多时候用户根本无法获知分类的依据究竟是底层的代码相似度，还是仅仅因为触发了某条 IDS 网络签名规则。此外，Josh 也提出了一个现实疑问：当分析师在响应现场确认入侵样本是 RedLine Stealer 这一类窃密木马时，攻击往往已经在内网潜伏了数天、数周甚至数月，知晓具体的家族到底在多大程度上能改变最终的处置策略？除了勒索软件这类必须立即阻断的极端场景外，通常都只能按最坏情况来应对。Jonas Wagner 对此回应称，ThreatRay 的定位更偏向调查后端的精准分类工具，明确攻击者用的是 Cobalt Strike、勒索软件还是复杂的 APT 专属工具，确实会直接改变事件响应的处置级别与应对重心。 * “I mean, these people in the end basically either care about the family or capability for a quick triage and I think these are problems you will be able to solve with AI.” —— Jonas Wagner 强调了 AI 与代码相似度结合解决快速分流的核心诉求。 * “A lot of times you don't know where the classification is coming from.” —— Josh Stroschein 点出当前威胁分类缺乏透明度与可信依据的普遍痛点。 --- ### `42:45` 历史回溯搜索：将二进制代码作为可检索实体除了单次分类，将海量二进制代码构建成可检索数据库并结合专家审核，在威胁情报回溯分析中展现出巨大的威力。ThreatRay 从多方数据源持续索引了数以百万计的二进制文件。每当安全社区发布开源情报（OSINT）报告、团队提取出新家族的特征签名时，系统便会自动对整个历史数据集进行全量重新分类。这一机制使得团队能够立刻发现：某些最新曝光的恶意软件家族或变种，其实早在数年前就已存在于历史样本池中，只是当时未被识别或报道。 Jonas Wagner 解释说，这种能力的底层逻辑在于“把二进制代码当成可被直接搜索的实体”。在传统的安全运营中，如果要回溯历史数据（Retro-hunting），分析人员必须先编写专门的 YARA 规则，再在大规模样本库中发起漫长且耗时的全盘扫描。而依托预先索引的函数级代码相似度，分析人员只需轻点鼠标，就能在跨越十余年的海量数据中瞬间完成回溯比对。 * “So we see quite a lot of overlaps between kind of older variants or tools or families that were reported years later and that's ultimately only possible because we treat binary code as a searchable entity.” —— Jonas Wagner 说明了代码可检索化带来的历史穿透力。 * 该架构摆脱了依赖编写复杂 YARA 规则进行离线慢速匹配的局限，让分析师能够像搜索文本一样自由检索底层机器码的同构演变。 --- ### `45:00` 威胁情报中的聚类分析与可验证性（Verifiability）对于逆向工程专家和威胁情报（CTI）分析师而言，代码相似度的价值不仅体现在主流的“打标签”上，更体现在高阶的聚类与关系发现中。面对每天涌入的海量未知恶意软件，分析人员面临“到底哪一个样本更值得花时间深入逆向”的选择困境。通过代码相似度算法，系统可以对海量未知代码进行自动化聚类（Clustering）： 1. 迅速形成密集聚类的簇群通常代表当前正在大规模传播的活跃家族变种； 2. 处于离散、孤立状态的奇异样本，往往意味着新型专属工具或高度定制化的 APT 攻击，同样具备极高的分析优先级。这种分析不仅有助于绘制恶意家族的演进谱系，甚至能够为攻击归因（Attribution）提供强有力的证据链。然而，逆向人员天生具有怀疑精神，当一个自动化系统声称两个函数或代码块属于同源时，分析师最先提出的问题一定是：“你是怎么得出这个结论的？你的置信度有多高？” Endre Bangerter 与 Jonas Wagner 指出，ThreatRay 从早期研发时就确立了“可验证性（Verifiability）”的设计原则。系统在给出匹配结论的同时，会直接公开证据链： * **情报层面证明**：明确展示当前结论命中了哪一个基准样本，并附带该样本最初来源的原始 OSINT 报告链接； * **算法层面证明**：允许分析人员直接下钻检查两个函数汇编指令的具体比对细节，让匹配过程完全透明白盒化。 * “So if we say it's a match, you can kind of inspect that match. That's something that people basically always want once they dig into the details.” —— Jonas Wagner 解释高级安全分析师为何绝不接受黑盒式的匹配判断。 --- ### `47:15` 智能体（Agentic AI）与高精度代码相似度信号的结合针对未来的技术演进，Endre Bangerter 认为，高阶威胁情报分析目前仍然局限于少数拥有深厚专业技能与充足时间的专家群体，是一个典型的“小众垂直领域（Niche Application）”。而当前智能体 AI（Agentic AI）的迅猛发展，正是将这项高门槛技术推向广泛应用的历史性机遇。 ThreatRay 近期进行了一次前沿实验：他们构建了一个分析智能体，并将平台沉淀的核心能力——从自动化分类到跨数百个二进制文件的函数级代码匹配接口——全量接入该智能体。为了测试效果，团队选取了一个复杂的 APT 恶意软件家族进行基准对照： * **资深逆向专家**：耗费了整整 8 个小时的人工逆向与研判，才彻底理清该家族的功能结构、历史攻击活动关联并完成威胁归因； * **AI 智能体**：在调用底层代码相似度与关联引擎的情况下，仅仅耗时 20 分钟就输出了近乎一致的完整分析结论。 Endre 总结道，纯粹的大语言模型（LLM）虽然具备强大的逻辑推演和归纳能力，但经常会产生幻觉或输出模棱两可的模糊判断。而二进制代码相似度所输出的底层数据，则是一个绝对精准、独一无二且确定性极强的真实信号（Ground Truth）。两者的深度结合，让 AI 智能体拥有了穿透机器码底层的“眼睛”，有望彻底重塑未来恶意代码分析与情报研判的生产力格局。 * “And what they'll be doing in the Malware report, right? And the agent pretty much got the same thing in 20 minutes.” —— Endre Bangerter 分享了智能体将原本需要 8 小时的人工高级分析缩短至 20 分钟的对比实验。 * “Binary similarity and the data behind it, etc., will become a very important tool for agents, which delivers a very unique signal and the signal is precise.” —— Endre Bangerter 强调了精准代码信号作为智能体底层基础设施的关键定位。 ### `50:00` AI Agent驱动的二进制分析与SOC防御赋能 Endre Bangerter阐述了二进制分析领域的未来图景：未来的核心不再是孤立的工具，而是由AI智能体（Agents）将经典底层技术有机整合起来。无论是反编译、反汇编、沙箱（Sandboxes）还是PE文件查看器，都将成为Agent根据上下文智能调用的工具套件。这种范式转变将使原本门槛极高的二进制分析走向主流化。Endre指出，当下的安全运营中心（SOC）面临巨大挑战，分析人员收到未知二进制样本时，往往只能扔进沙箱跑一下，跑得出结果就看，跑不出就束手无策，根本没有时间和能力进行深度逆向。“Making binary analysis mainstream through agents which use precise tools on a lower level, that will make binary analysis accessible to much more people, and that's eventually very good because you need that capability early on in the defense process,” Endre强调，尽早构建起前置防御能力至关重要。 Josh Stroschein对此表示强烈赞同。他长期以来一直提倡从事安全技术工作的人都应掌握逆向技能，因为如果不懂操作系统底层运作机制，就根本无法真正理解如何对二进制样本进行分级分类（Triage）。然而，逆向工程学习曲线陡峭且极其耗时。如果能将上下文分析、代码相似度比对以及代码模式识别结合起来推向前线，将带来深远改变。Jonas Wagner也分享了自己的实际体验，他坚信Agent的未来：“I highly believe in an agentic future. I've been working with agents in combination with different tools as well as our platform, and it's truly, truly empowering for someone with mediocre reversing skills to also dip a bit further into these fields.” Jonas认为，把Agent与扎实可靠的基础分析工具相结合，将使初级人员能够胜任更复杂的逆向任务，而资深逆向工程师则能从繁琐重复的基础劳动中解放出来，将精力集中在真正有趣、有挑战性的工作上。 ```mermaid flowchart TD accTitle: AI Agent整合底层分析工具工作流 accDescr: 展示未知二进制样本如何通过AI Agent协调底层经典分析工具并在前线防御中输出结果 subgraph DefenseFrontline ["前线与SOC防御"] A["未知二进制样本 (Unknown Binary)"] G["SOC分析人员 / 逆向工程师"] end subgraph AgentSystem ["AI Agent系统架构"] B["AI Agent 调度中心"] end subgraph ClassicalTools ["底层经典工具集"] C["反编译 / 反汇编 (IDA / Ghidra)"] D["沙箱动态分析 (Sandbox)"] E["代码相似度比对 (ThreatRay)"] F["PE文件与格式解析器"] end A --> B B <--> C B <--> D B <--> E B <--> F B --> G ``` ### `53:15` 代码混淆、间接控制流与Anti-LLM对抗的猫鼠游戏 Josh提出了一个令他深感困惑的现实阻碍——代码混淆（Obfuscation）。以具有间接控制流（Indirect Control Flow）的离散程序流为例，IDA Pro这类反汇编器无法直接跟踪间接跳转，必须依赖内存执行或手动打补丁（Patching）把控制流缝合回去。他怀疑LLM是否真能解决这种高度不透明的代码追踪难题。Endre回应道，虽然自己并非利用LLM进行反混淆的专家，但混淆问题必然会持续存在，甚至会催生针对AI的防御：“The more we are throwing LLMs into malware reversing and automating this, I'm sure we will see also malware surfacing, which has anti-LLM obfuscation in there. It's for sure not the end of the story, right? It's not like LLMs will solve everything and in two years we're done. I think cat-and-mouse game, you keep going on.” Josh进一步分享了他的理论：当前的大多数混淆技术主要用于干扰人类分析师或绕过传统的静态特征检测，并不是针对LLM设计的。然而，随着防守方开始引入LLM与机器学习，高水平的攻击者必然会开发专门的Anti-LLM技术。这些技术可能不仅仅是提示词注入（Prompt Injection），更会包含破坏代码特征模式的变异手法，使LLM在处理代码语义时彻底失效。归根结底，LLM分析代码的底层逻辑与人类并无本质区别，只是速度更快、效率更高；当面临混乱的间接控制流图时，LLM同样会迷失，分析人员依然必须配合其他工具打补丁、重建控制流图。 - 传统的混淆手段（如控制流平坦化、间接跳转）能让IDA等静态工具失效，迫使分析人员依赖动态执行或手动修复控制流。 - 攻击者与防御者的攻防对抗将延伸至AI领域，恶意软件未来将内置专门针对LLM的对抗性混淆机制。 - LLM并不能奇迹般地消除逆向工程中的逆向壁垒，底层的猫鼠游戏仍将以全新形式长期持续。 ### `56:05` AI狂热周期与节目尾声 Jonas指出，过去几年整个技术领域都处于对AI的高度炒作周期（Hype Cycle）之中，普通人很难透过迷雾看清真相。更为棘手的是其迭代速度之快：“What you learned three months ago is already superseded again with a new generation of models.” Jonas预计，在接下来的几年里，随着攻防双方在实战中摸索出各自利用这些技术的真实边界，狂热情绪会逐渐平息，整个行业对AI的实际价值与局限性将形成更加客观、成熟的认知。在节目最后，Josh向嘉宾Jonas Wagner和Endre Bangerter致谢，感谢他们来到《Behind the Binary》深入剖析LLM时代下的二进制相似度分析技术。Jonas表达了参与节目的谢意，称赞这是一场非常有趣的深度对话。Josh向听众致辞告别，呼吁大家订阅播客并留下评价，以让更多安全从业者了解这些前沿探索，并以经典的“保持好奇，持续探索”为本期节目画上句号。 ## Notable quotes > `47:15` Binary similarity and the data behind it, etc., will become a very important tool for agents, which delivers a very unique signal and the signal is precise. — Endre Bangerter > `50:00` Making binary analysis mainstream through agents which use precise tools on a lower level, that will make binary analysis accessible to much more people, and that's eventually very good because you need that capability early on in the defense process, — Endre Bangerter > `35:00` I personally think the more context you can add to a piece of code, the more useful this similarity will become. — Endre Bangerter > `00:00` If the LLMs take over and they get even more efficient, then I mean, the attacker could craft a new malware family for every attack, right? In the extreme case. Then, to be honest, then all code-based approaches become less useful, right? — Endre Bangerter > `50:00` I highly believe in an agentic future. I've been working with agents in combination with different tools as well as our platform, and it's truly, truly empowering for someone with mediocre reversing skills to also dip a bit further into these fields. — Jonas Wagner > `42:45` So we see quite a lot of overlaps between kind of older variants or tools or families that were reported years later and that's ultimately only possible because we treat binary code as a searchable entity. — Jonas Wagner > `15:00` So it's good, it's super fast, but very brittle. It's very easy to kind of get around that, even if you just add a compiler optimization flag. — Jonas Wagner > `20:00` And the reality is they don't do that much in most cases. I could put it like this. which is good for us, which is good for all the people who write yard rules. — Endre Bangerter ## Mentioned Josh Stroschein, Jonas Wagner, Endre Bangerter, ThreatRay, BinDiff, SSDeep, Ghidra, BSim, Daniel Plohmann, MCRIT, Abuse.ch, VirusTotal, YARA, OLLVM, Mandiant, Cobalt Strike, RedLine Stealer, IDA Pro ## Video description "Throwing more LLM prompts at a packed binary won’t make your analysis faster. But combining code similarity with AI will." In Episode 29 of Behind the Binary, Jonas Wagner and Endre Bangerter of ThreatRay join the podcast to lay out the real-world state of binary similarity in the LLM era. They demystify the current AI hype cycle, explaining why large language models are structurally unsuited for raw, unguided binary analysis, and how traditional binary similarity techniques are finding a ma... [Source](https://www.buzzsprout.com/2414128/episodes/19802488-ep29-binary-similarity-in-the-llm-era-with-jonas-wagner-and-endre-bangerter-of-threatray.mp3)

Source quotes

[47:15] Endre Bangerter: Binary similarity and the data behind it, etc., will become a very important tool for agents, which delivers a very unique signal and the signal is precise. [50:00] Endre Bangerter: Making binary analysis mainstream through agents which use precise tools on a lower level, that will make binary analysis accessible to much more people, and that's eventually very good because you need that capability early on in the defense process, [35:00] Endre Bangerter: I personally think the more context you can add to a piece of code, the more useful this similarity will become. [0:00] Endre Bangerter: If the LLMs take over and they get even more efficient, then I mean, the attacker could craft a new malware family for every attack, right? In the extreme case. Then, to be honest, then all code-based approaches become less useful, right? [50:00] Jonas Wagner: I highly believe in an agentic future. I've been working with agents in combination with different tools as well as our platform, and it's truly, truly empowering for someone with mediocre reversing skills to also dip a bit further into these fields. [42:45] Jonas Wagner: So we see quite a lot of overlaps between kind of older variants or tools or families that were reported years later and that's ultimately only possible because we treat binary code as a searchable entity. [15:00] Jonas Wagner: So it's good, it's super fast, but very brittle. It's very easy to kind of get around that, even if you just add a compiler optimization flag. [20:00] Endre Bangerter: And the reality is they don't do that much in most cases. I could put it like this. which is good for us, which is good for all the people who write yard rules.

Source quotes

[52:45] Endre Bangerter: The more we are throwing LLMs into malware reversing and automating this, I'm sure we will see also malware surfacing, which has anti-LLM obfuscation in there. [46:17] Endre Bangerter: Binary similarity and the data behind it, etc., will become a very important tool for agents, which delivers a very unique signal and the signal is precise.

Original transcript

[0:00] If the LLMs take over and they get even more efficient, then I mean, the attacker could craft a new malware family for every attack, right? In the extreme case. Then, to be honest, then all code-based approaches become less useful, right? While AI gives defenders a massive boost in speed, it gives attackers an equally powerful engine for scale. Welcome back to Behind the Binary. I'm your host, Josh Strohschein. Joining me today are Andre Bangeter. and Jonas Faulkner, the co-founders of ThreatRay, We explore the evolution of binary similarity, moving from handcrafted domain rules like SSD to modern ML vector embeddings, how to deal with the overwhelming noise of statically linked libraries, and what happens to code matching in an AI-driven agentic future. Let's jump into the conversation. So welcome Andre, or Andre. I'll probably inadvertently go back and forth between the two during the podcast today, and Jonas. Both of you are from ThreatRay. Today we're talking about everybody's favorite topic, binary similarity or BIN-SIM. And I think we're going to have a really interesting conversation because this is a problem that I think is still... Very much unsolved and well, maybe. And I'm curious to see, you know, perspective backgrounds, current kind of state of the art and where you think we're heading. So why don't we just start for the audience by defining what we mean by binary similarity for our conversation today? Yeah, sure. So thanks a lot for having us here. It's a pleasure being here talking about the topic we've been at for a long time. 10 years or more even. And yeah, I mean, what is the idea or the goal of binary similarity or binary code similarity? So the goal is pretty simple, right? You look at two pieces of binary code, and then you simply want to decide if both of them were created from the same source code essentially. and doing so reliably and ideally at scale then enables Quite a lot of interesting applications in many different spaces. So from our side, we're mostly in the Melder Space, that's our our fascination and where it all started, but you also have a lot of applications outside of that kind of a malware space. Okay, so we're talking, and I tend to think machine code, native code, we've got bytes that are going to be executed directly by a CPU. Certainly the concept applies to a broader space, but I think that's really what we're focused on here and probably where the the most challenging part of Bensim lies. There's a number of different ways to perform similarity matching, signatures, AV, Yara, fuzzy matching. Can you maybe run us through a little bit of the techniques that are commonly employed and if you have any opinions or perspectives on how effective they are and where they're best employed? Yeah, sure. So there's actually quite a range and also a history. of the techniques or the approaches, the ideas behind it. And it kind of boils down to the fundamental challenge that, of course, you don't have access to the source code. to decide if two pieces of binary code are produced by the same source code or not. So you need to rely on what's there in binary code of the compilation. And the primary challenge is that the compiler destroys a lot of valuable information, which would have helped you prior to that. like function names or variable names. And on top of that, the compiler also adds a lot of variants. to the compiled code. So you can take the same piece of source code and depending on the compiler or the compiler flags or what architecture you're targeting can look vastly different. in machine code at the end. So what all of these tools essentially try to do is to work with what is left of the compilation and to find some piece of data or information to kind of work backwards and then decide or show that it was created by the same source code. And it's also a field that is quite well researched and also plenty of tools that came out of that, as you just mentioned beforehand. and it also evolved quite a lot over the last maybe 20 years or so, I'm sure pretty much everyone knows Bindif, which is kind of the godfather of binary code similarity. You take two binaries, it will tell you which functions are unique or shared between the two bilaries, that was also [5:00] kind of an inspiration for many of the following approaches back then. So maybe also a little bit of backstory from our side, how we got into that field ultimately is 10-ish years or so, where there was quite an interesting transition period between tools and algorithms. So back then you had a lot of the tools like Bindif or SSD and so on, which were created by essentially experts who knew how to evaluate binary similarity and used a lot of handcrafted domain knowledge. And that then slowly transitioned into more of a machine learning-based field or these last 10 years where you essentially try to throw a lot of data at the problem and essentially trying to answer the question whether or not a machine learning approach could be better than kind of handcrafted things like BINDIF That was also kind of our starting point back then Can we take these more recent or modern machine learning approaches and create kind of a system for binary code similarity that would also scale and be highly resilient to any variations or changes introduced by compilers over a large amount of data? So kind of combine the best of different worlds, Bindif being very precise on finding code similarities, whereas other tools like SSD were very fast but also kind of shallow and not very robust on finding these similarities. So I think all of the tools you mentioned beforehand, they have their applicability and their use cases and we kind of also the research around it kind of try to combine the the best of both worlds, having highly reliable binary code similarity at scale. And a lot of the tools have been around now for a while, at least the staples, the SSDeeps, and you've got things like Flirt and Ida. And maybe we get to this more towards the end of the session as we kind of look to the future But what else is out there Has there been any significant tooling at least in the public space kind of the open source tool maybe academic work that really changed significantly how we approach this problem in the last 10 or 15 years Because it feels a bit stagnant to me. It certainly has yielded some interesting tools during those years. Funnily enough, the academic world has moved quite a lot over the last 10 years from, say, the handcrafted approaches to machine learning to deep learning and now more and more also to the transformer architectures around large language models. And tooling-wise, what is probably most interesting that came out recently is GITRAS vSIM, where they essentially use quite a modern approach of calculating embeddings of functions into a vector space. And then based on that, you can find similarities amongst a larger data set, which scales, of course much much better than what you could do with BINDIF And there was also a tool or platform almost you could say from Daniel Ploman a few years back called mcrit where he basically built a code similarity system open source from scratch, which with all the bells and whistles, where you can freely index search through basically binary code similarities based on approach you developed. I think these were probably the most interesting tools, at least publicly speaking, that came out recently. So, basically, I mean, the question is also a bit, right, why don't we see more of these tools in the open source, in the real world? I guess we'll come to that later, but I think one thing is the algorithms, right, implementing them, et cetera. You can find tons of them on GitHub, from research papers. But to actually make them useful, you also need to have the right data, right? I mean, after all, cold similarities, you have some unknown binary and you want to find some similar binaries. And I think our current thinking here, ThreatRay, is that having the right data and having the right meta information and kind of make this data [10:00] Huh? Easily to consume for end user. That's almost a harder part than the core algorithms, right? And core algorithms for themselves are super interesting. but not useful per se without curated database, tagged it. Yeah, that's a problem. I don't know. I'm interested to hear a little bit more about that because if you take a very individualistic approach to say I want to create a Yara rule to represent a malware family, I have to have a sample to begin with and first be able to associate that sample with a family or define a family. I have a sample set that's representative enough, that's significant enough that I can be confident in that signature and then test against additional larger corpuses of maybe other known families. And so this process seems to be difficult, particularly as you're trying to identify particular families of things. The data as well, I'm curious, because when you look at sources, where you get the data, if you go to abuse CH, which is just, I pick it because it's all open, it's open community. Of course, virus total is a large corpus, but it's behind a paywall. How do you know how representative those are of the broader ecosystem of any particular family or even just what's floating around on the planet right now? So yeah, I guess I don't know where the question lies within that, but just the idea of getting the samples and building a corpus of data has to be a big part of the challenge. Yeah, it goes beyond that, right? I mean, maybe We can explain that a bit on, I mean, one core use case of code similarity is malware classification, right? And the basic idea is, as you said, I get from as many families as possible. I get and reference samples, right, confirmed samples from that family, And the idea is on a high level, well, I have an unknown binary. Let's see. which sample matches most, has the most covalent, code overlap with the unknown binary and that's where I get the family right. and kind of propagate the label of that matching sample. I'm the family label. And... That's naively, that's the way to do it, but if you tend to do that in the real world, it's complicated, right? So there are lots of lots of problems. So one problem is, for instance, packing. So most followers pack these days. So, um, And families are typically about unpacked payloads. So, what you start to do and what we start to do when building ThreadTrade is you run all your reference samples, so you confirm samples from families through a sandbox. And we have a sandbox. We use a sandbox in ThreadTray. which is very good in detonating samples, unpacking them, downloading stuff from the Internet, and then It's monitoring the memory and dumps out all the unknown code from memory. So that means If you run a sample through through our sandbox, in the end you end up with 10, 20, 30, pieces of code, right? Dumped from memory or files, whatever. And You do that for all your reference samples from different families. You do it from the unknown sample you're looking at, right? and suddenly you have a much more difficult problem. You're comparing sets of binaries to many sets of binaries, right? and no longer two clearly attributed samples from family and an unknown sample, basically, right? That gets you lots of problems, right? When you detonate samples, you have Suddenly you have loaded components, It'd show up. and their libraries showing up, etc. and if you naively match your... unknown sample, the detonated unknown sample against your detonated reference set you get matches on on these loaders, on those libraries, etc., and you no longer know to which family does this thing belong, right? That's... That makes things really difficult. So, just naively getting samples and labels on the samples is not enough, right? So, What we do, I mean, to solve this problem is you really need to detonate samples in the sandbox and you need to find the payloads and you need to properly label the payloads. And I mean, this kind of data curation, right, that turns out to be kind of a hard problem also, which is pretty time consuming. [15:00] I have to detonate all those samples and get the payloads, label them. And once you have them labeled, then you can reliably do this classification. But also labeling is not so easy, by the way. I mean, Even if you have found the payload from memory, it may contain statically linked libraries again. So you mix up the actual payload code with library code, So these are problems then These similarity matching algorithms, they don't work equally well on all functions. We do it on, by the way, on a per function level. So on the per function granularity, So for smaller functions, typically these similarity matching algorithms don't work very well. Then they also mix up some bigger functions, so you have to know which functions they work well. So you have to really carefully label your payloads. to get precise results and precise classification. That's where we have spent lots of time. So, I mean, the algorithms and getting the raw data, that's relatively easy. Maybe I've spent lots of time is to come up with workflows, toolings, algorithms, whatever. to reliably, let's say, identify payloads, label it correctly, remove the noise, and all these things. That's what I meant before with curating data, right? You have to really find the right data, properly label it, otherwise the matches you get are kind of meaningless or pretty noisy. There's a couple things that still are kind of the forefront of my mind here. You mentioned obfuscation and packing. I think that's a big one and an obvious one. problem that we have to discuss because you have compilers and we have modern languages. So we have all these things that are conflating the issue. Go and Rust, add in massive libraries, statically linked, runtimes. Compilers themselves can be different levels of optimizations can be very destructive. We have obfuscations that can be very additive. that mutates control flow or injects opaque predicates and mixed Boolean and you know, it adds to the flow of the program, but, you know, scatters the logic around. So now the function boundaries have been completely obliterated until it's reconstructed itself. Where do you think binary similarity stands against these different layers of optimizations and obfuscations? I kind of see them as the same thing right now. They're mutating the final state of a binary. thus impacting our ability to ID it and to create signatures or heuristics or anything to perform similarity matching. Yeah, right. So that's fundamentally the problem that you need to deal with. There's, you could say, kind of implicit variation that you get from the different compilers, the different architectures, compiler optimizations. You have different languages, of course. It's a bit different on Go. It's a bit different on Rust, how they work. And then you have more explicit obfuscation, I guess, which you could introduce on top of that, which certainly happens. And maybe to look at it from the other side, how do you deal with that? How do you actually make sure that you're picking the kind of information or data from the compiled form that ideally survives through all of these variations from compiler obfuscation layers. And there's kind of a spectrum of... of approaches that you can look at. Um, The first in the spectrum is more kind of syntactic similarity that you're trying to do, which is close to what an SSD would be doing, right? So you take two... sequences of instructions, say left and right for two functions, and then it kind of look like whether or not these sequences of instructions align or are similar. And that works if you use the same compiler, the same optimization level, the same architecture, and there's nothing in between, which would add additional obfuscation, then you could easily match whether or not to Binary code sequences are essentially the same, but that's very brittle. It's very easy to kind of get around that, even if you just add a compiler optimization flag. So it's good, it's super fast, but very brittle. [20:00] And then the kind of a higher level that you try to look at this, the structural similarity. So this is, for example, what Bindiff does. The same if you look at the output of a disassembler, you can look at the control flow graph of a function, for example. You could compare them, basically eyeball it between two functions. And the naive assumption is if the two graphs look similar, then the control floor is similar, and likely the functions are similar as well. which is exactly what Bindif tries to do with a couple of clever algorithms. So this is more structural similarity. So if you have a variance from the compiler or an obfuscation layer, to control flow graphs. can still look very similar or equal. Of course, if you have things like control holograph flattening, you kind of destroy that structural layer as well. And then kind of the third way of looking at it is the semantic layer. do two pieces of binary code essentially do the same. So this is a bit of the holy grail of code similarity if you can do that. and That then removes a lot of the introduced, either implicitly or explicitly. I'm introduced to variants that you have. And you can try to extract semantics from a piece of code. There's, again, many approaches, for example, symbolic execution, where you try to essentially prove that two different pieces of code, they do the same. But that's very expensive to do. It doesn't scale very well. So practically speaking, most of the approaches work on this structural similarity layer. as Bindiff does, as a lot of the academic approaches do, because it kind of approximates semantic similarity. It's a good proxy for it, but without all the kind of heavy lifting. But as you said, for all of these approaches, counter examples with things like control flow graph flattening or very simple optimization tricks that kind of attack these approaches and some of them are seen more often in practice, some of them a bit less. But what you always have to deal with is the variants that are introduced by different compilers and architectures. And the question is also what do attackers or malware-writers actually really do, right? and I must say, you're kind of astonished that they don't do that much, right? I mean, they mostly do packing. But I mean, We didn't do a scientific study, but I mean, as I said, we track mother families through cold similarity. That works very well. I mean, if they would do any of these things, right, our signatures of tracking capability will break down and be very rare to see that. Of course, there are samples that go to obfuscators and Um, then I mean, They totally destroy the way we detect code similarity through these control flow graphs. but astonishingly we Really? see it pretty rarely. and I think that is also, I mean, maybe I have a different view from your job, from your work. But I think there is kind of a gap in what could be done, can be done, or may be done in rare cases, and what actually most malware writers are doing. right and I'm And the reality is they don't do that much in most cases. I could put it like this. which is good for us, which is good for all the people who write yard rules. You have the same problem for Yara, right? It's so easy to bypass Yara. Still, you have tons of resources producing Yarrables, very good ones, by the way, and it works amazingly well. I mean, for me, that's kind of the Pretty astonishing. how these technologies work in the real world, although it will be pretty easy to bypass. I am really curious about that. the sophistication level, and I guess maybe, kind of to one of my points earlier, if you look at a commodity, Info Stealer and part of their infrastructure is they produce a binary, but the customer has to provide the the obfuscation, so probably a layer of packing would be the easiest way to wrap that up and distribute it. You're going to have a higher proportion of those. It's going to kind of distort what's happening. You look at maybe a more sophisticated adversary. I would just say, generally lump that into the nation state and they develop maybe a, you know, a [25:00] through obfuscating pipeline where it's in the compiler or it's a real custom binary writing thing. and they can mold the obfuscation into the binary itself. You don't lose the original instructions. Certainly you lose the semantics, but you can really... adversely affect the flow. That's difficult, though. But even in the age of now with LLMs, I'm wondering if that's going to change and... And not only maybe, you know, kind of beyond talking about similarity, but even just disrupting the ability of LLMs to analyze and recognize the patterns. I was able to port the original OLLVM project in like an evening using LLMs. It's the same code that it was when it was originally written, but it was a one for one port working with modern build chains. So like if I can do that in an evening, I can't imagine what somebody who's really focused on. offensive operations, criminal or otherwise, can do. Yeah, that seems to be the thing. Of course. If the LLMs take over and get even more efficient. Then I mean attacker could craft a new malware family for every attack, right, in the extreme case. And then, to be honest, then all code based approaches, be it pattern matching, Yara, our approach with binary similarity control programs, they become less useful, right? Then we need to move on to different things. I mean, I think that we need to go in direction of semantic matching, or I think the semantics will be the same. Let's say if you do, I don't know. Key Login, Code Injection, no matter how you write your code, there will be some semantic similarity between these attack techniques. And I think that's where the whole thing will be moving in the future, for sure. I mean, that can be, you can lift your models from purely syntactical graph graph-based models, you can start adding semantics like API calls, whatever, to rather move in that direction. That's one thing, right? The other thing we haven't talked about, and which is Thank you. Maybe it's an application of code similarity which will survive LLMs. is good with identification, right? So identifying legitimate libraries, etc. So, We built that into the system actually to clean out the signatures that we talked about before, right? You get often payloads. which are mixed with library code and whatever code, and to make our signatures better we started to Pretty much the same way as we do with malware code, we start to index goodware code. and I would assume that in the future the library code will stay still more how to say, more stable than in this hypothetical attack tools which change with maybe with every attack, right? Yes. So the ability to find those libraries and then to, how say, to kind of wield out, is that the right word in English? Or identify? The unique unknown code, that could become an interesting application of code similarities. So you focus maybe on the known good stuff, right? And you will be able to quickly identify the unknown thing. That's already an application we'll be doing with What we did is we have recently added a AI reverses to the platform, which is basically what everyone else is doing. So we decompile the code and then we feed it to one of the NLM's, so no big innovation there, but what we found is pretty interesting is we're combining it with our bootware code detection. So let's say we see lots of payloads. Um... which are, let's say, 1000 functions big, and we are able to identify 950 functions as library code. and we only need to direct the LLM for reversing to these 50 remaining functions. That has to be proven to be That has to be proven to be very helpful, right? I mean... So LLM is much faster because only 50 functions instead of 1000 needs to be analyzed. There's less hallucination. If you give 1000 functions to an LLM, it will hallucinate at the current state, maybe not in the future. And I could imagine that In the extreme case, where LLMs and AIs will write the new malware for every campaign, On the one hand, the ability to identify library code, legitimate code they become more important. to isolate the new code, right? And by the way, if you generate new code for every attack, that sticks out as well. Maybe more trivially, but let's say EDRs, you have this prevalence, right? You have this prevalence on your infrastructure. How often have you seen it back? [30:00] And it... I mean, if you produce a new binary for every attack, you run into different problems because of uniqueness, right? And I could imagine it's going there, right? So you want to separate the unique from the non-code and And then the The new code will stick out. You can throw it also with AIs for reversing, etc. So it's a wild guess. That's my feeling that it's important, right? And after all, cybersecurity is a cat and mouse game, as you all know. and um The attackers will evolve and defense will also evolve. And certainly also these code similarity models will evolve and they will add semantics to it. I think that's where this will be heading. I think also to add to the point of The value of having good detection is what you mentioned beforehand with newer families, Go and Rust. where basically everything is statically compiled in, and you need to basically look at thousands of functions every time you open a binary. like that. There it becomes extremely handy if you can cleanly separate out what is known good code, either from the runtime or from any third-party libraries, and as a human or as a machine, only focus on what's left beyond that. That's also a super good use case that we found. It makes, yeah, it makes a lot of sense to me. I mean, if you give me 10,000 functions or 500, I'm going to hallucinate more on the 10,000 myself. So it would make sense that our LLMs are just going to do the same thing, at least right now. I've had this, I don't know, this thought, it's not well grounded, but is there... other contextual clues or information we can add to the BIN-SIM problem to help? I mean, you talk about labeling and classification and... Is it always just strictly, you're executing in the sandbox, so now you have static and runtime information, you have the ability to take While this... code not only connected to an IP, but now we have the information from the IP that it connected to and who is information and maybe record of activity through other data sources. Does that can that feed into our... or been some approaches to better enrich the matching as well as the labeling that then gets applied to those Certainly, I would say so. It's not something we strictly follow at the moment with our approach. very focused on the static approach. So that also makes us not needing to rely on the execution of code. which is a very neat property. Bob having very fine-grained execution traces could certainly feed into Let's say that better characterizing, what this piece of code is doing. and then feeding that through an algorithm or pipeline or model. which I would imagine make the results better as well. um, trying to think if there's any actual research around combining these two approaches. I'm sure there is. I can't think of anything on top of my head. the I believe it would certainly be in addition to current approaches. So I think, to be honest, Jonas, that's the way to go, what Josh said, right? I mean, as you said in the beginning, I mean, just matching code is It's nice, but it's pretty useless unless you have contextual information. And the obvious thing we are doing is adding These mother family labels, which we just have described, It's already kind of big effort to do that properly, precisely. But doing the stuff Josh said is absolutely, that will be central in the future. Right. You want to add also I mean, you said you want to use execution information. In the end of the day, that's also some kind of semantics. You see what APIs were called, whatever. and That's something that will happen for sure. Makes code much more useful. And also what is interesting, I mean also with AI, right? So they are relatively slow with reversing a piece of code. But what you could do is You could have one piece of code reversed to get the semantics out of it with an AI. and then through similarity you can propagate it, right? So, I mean, to simply propagate the semantics to all the functions which are sufficiently similar, that would be a huge speed up. I mean, that would be kind of a hybrid approach combining LLMs, AI reversing, we've called similarity and, um, That seems something that will happen and that's also something we thought about here at Vechway. [35:00] Um... Yeah. Simply, it makes the matches more useful. That's the thing, right? I mean, Ideally, if you have a match with some piece of code, the last thing you want to do as a normal user is to reverse that code, because it takes time, you don't have the skills, So ideally the system comes up with all the information, right? Annotations about APIs, about semantics, About IP addresses, it did connect to whatever. So... I personally think the more context you can add to a piece of code, the more useful this similarity will become. We've talked a little bit about the semantic approach understanding of a piece of code I think it came up a little bit earlier, you know, this idea of lifting the machine code, the native instructions into something that's maybe a little bit more semantically rich. and maybe less syntactically rich because we're abstracting it away from the underlying architecture. This would be an IR. You mentioned that, Jonas, there's a lot of projects out there that do this. What is your perspective on that? What are the pros and the cons of using... or trying to use that as a foundation for similarity or even just like signatures. I haven't seen an implementation of it you know, like Yara, but at an IR level. I mean, it seems like it's certainly wrought with a lot of problems and challenges. So I'm curious to get your... Both of your thoughts on that. Yes, sir. I think two camps of thinking, especially applied to binary code similarity. One of them is let's use IR or lifting to basically get rid of some of the variations that are introduced by different compilers or architectures. So you have kind of cleaner binary code at the end. and you can pick more from that bind record that would be stable across these variances. That's certainly one way of doing things. Thank you. You, however, also add an additional layer on top of your pipeline. which has to perform very well and not introduce more issues or noise along the way. I remember back then when we were looking at the topic, The tooling around lifting was quite brittle. I don't know if that changed over the last couple of years, but back then it was an additional we didn't care so much about due to the gratefulness and then kind of the a camp of thinking is we just learn by machine learning to not care too much about these variations that are introduced by different architectures or compilers. And we just work around that so we don't need to care about any intermediate. representations or any lifting on top of that. I think both of them are super valid. If IR has moved a lot over the last couple of years, I would probably pick that as a clean representation of code. Um, Yeah, I think that's a good way to summarize it. I guess maybe taking the conversation to a practical or back to a practical approach is that there's only a handful of people that are – really digging into binary code and really needing to understand any given executable at a per function level How does this scale then to, let's say, an incident responder? You've got a sample in... you've recovered, you don't know what it is, it's not obvious that it was ransomware or something, it's got enough obfuscation. What does binary similarity... Help. at the largest scale maybe for our community or for the world. honest answer, right? I mean, let's say if you look at incident responders, they will know what it is, right? So either you were able to classify it through code similarity, Um, So you assign it to a malware family. That's what everyone wants in the first step. Or maybe you can find some contextual information about it. So that's what we're doing in Threadway. We started a couple of years ago to Um... index samples which are referenced in open source intelligence, let's say in blogs by Mandiant or whoever, right? We crawl these blogs, we get the hashes, then we get the binaries, we index the code of the binaries, so We have a big number of binaries which are associated with the blog post, basically, right? And how you could help an incident responder is basically, okay, that's a piece of unknown code. We don't know the family. but in some cases we'll find relations to samples and blog posts through code similarity. They can be Sometimes it's really on the small number [40:00] Functions, right? If the code hasn't been entirely obfuscated or some code has been reused, sometimes a few functions are good enough. to point an instant to respond to to a blog post which can be super helpful to unlock the investigation. He or she will still have to go through the blog post and do some research, but It's fundamentally more useful than having a binary where you have no idea what it is. Mm-hmm. And I think in the future, I mean, Now already, the other very useful feature obviously is if you run it through AI Diverser, As you described before, you remove the library code to increase the quality, and then at least you can in many cases pretty reliably output the capabilities of this LNOT sample. I mean, these people in the end basically either care about the family or capability I'm for a quick triage and I think these are problems you will be able to solve with AI. So AI will be That was super important for the field for sure, right? Bye. That's the real value is, like you said, filtering out. to help isolate and then just getting confident identification to be able to take an unknown sample and have something that I can trust and validate or verify that yes, the classification that I'm getting from this is accurate because that's hard. You know, you could take a, a hash of a sample. You can go to all these different platforms, public and private, and, um, you can just get such a mixed bag of, of results. And, A lot of times you don't know where the classification is coming from. Is it actually binary similarity or like a code family that's driving it? Is it based entirely off of a network signal, like an IDS signature that then gets bubbled up and provided as the classification? It's really hard. And then from there, like, what do you do with that? Okay. I'm on an incident response. I know I've got red line stealer. Okay. Well, at least I have some idea of the capabilities. I can research that further and figure out what kind of persistence does it quickly steal. It's all after the fact though. I mean, I don't know how much it actually changes the response. I've always wondered like, how much does it actually change the response? I'm the the malware has already been in my environment for days, weeks, months. Knowing what kind of malware it is helps, I suppose, to a degree, but I think you have to... ultimately treat it like a worst case scenario Unless there's something obvious that happens like ransomware, then you're obviously dealing with. But then there's like, how do you detect it in the first place? I think that's probably the biggest thing. closing that that gap. I mean, what's in, what's the best approach here? Are we closing the gap from the time a breach occurs to the time somebody realized organization realizes it, or do we, do we try to prevent it in the first place? And those are two, I suppose, very different approaches. But it seems like this is a big part of the solution is being able to identify these things sooner and sooner based off of the code. Yeah, I think on our end, we're more the tool at the far end, which is used for kind of investigation. or proper classification. which then, as you mentioned, it also alters your type of response, if it's Cobalt Strike versus Ransomware versus some APT family. you will alter your response a bit. Um... That's for sure. That's also something that our users use us for. ultimately. I think maybe one point that we could also try to cover a bit, just came to mind, is is the combination of having a search system. on top of a lot of that. and the curation aspect that Ender mentioned. makes this very interesting for intelligence applications going back in time So we index millions of binaries from vast a pool of data from different sources. and basically every time we create new signatures for a new family, let's say from an ausent report, We basically reclassify our entire data set and then we can immediately spot whether or not back in time there were some variants of this malware family that weren't seen or weren't reported beforehand. So we see quite a lot of overlaps between kind of older variants or tools or families that were reported years later. and that's ultimately only possible because we treat binary code as a searchable entity. and you can basically, with the click of a button, search back in time, over a decade or so of data to surface [45:00] older variants. That's kind of a very nice property that we found over the years for intelligence. research or investigations that you can freely go back in time and look at code again without having to write a specific Yardad rule. and then doing retro-haunting, which takes quite a while usually. So I think... I mean, the main, mainstream application of code similarities classification, right? I mean... That's also for instant response, I think. classification capabilities. And as Jonas just mentioned, I mean, that are Lots of exciting, less mainstream, maybe more niche capabilities which come in intelligence analysis. just the ability to link some unknown codes to millions of samples, huge database. allows you to do all kinds of things. discovered a previous versions of a malware, you find relationships between families, What some of our users are doing I mean, They see lots of unknown malware. and They need to decide. which one is more interesting than the other, right? So what they do, for instance, is they start to cluster the code, which is right, right? Based on code similarity, we can create clusters. And then you find the more interesting cases, right? I mean, those that cluster or the isolated ones can be also very interesting. That gives you lots of information for tracking mauler families, finding new mauler families, Um, So a lot of the value, I would say, of code similarities is in intelligence, tracking families. even attributing to actives in some cases, as you know, that will work. That's a big use case, and I think that's... That's the niche one it's more for. people like you probably write reverse engineers for threat intelligence analysts. Um, And there's lots of value of code similarities for those people. I think what's also important to note is that talking to these people is you always need to kind of have a verifiability. So if a system says these two blocks of code or these two functions, they're the same, then people want to know how did you get there? How sure are you? So what we early on decided on is that we want to have this kind of variability. So if we're saying, you know, this matches this particular malware family, we also indicate By the way, this is the sample that we used for our code signature. And the sample was found in this particular OSINT report, for example. so that you can kind of track how we got to the conclusion. On one hand, on the intelligence side, And on the other hand, also on the, let's say, algorithmic side. So if we say it's a match, you can kind of inspect that match. That's something that people basically always want once they dig into the details. You know, how did you get there and, you know, how can I verify this? We've talked about future state. Is there anything there that you think is worth mentioning or revisiting? So, yeah, what we think and we're experimenting with that, of course, is, I mean, as you just mentioned, right? It's rather a niche, I mean, especially intelligence analysis, that's a niche application for pretty advanced people, I have also time, skills and time you need, right? There, the whole development of this agentic AI stuff, right? That's a huge opportunity to take this out of the niche. We made some early experiments recently and we We came up with an agent and we gave all the stuff we have to the agents, from classification to function-level matching across hundreds of binaries. all these things which takes a lot of time and energy to figure out what it means eventually. It's really preliminary results, but they're pretty amazing. So yeah, we did some, I don't remember, some APT family analysis. where we had one of our most skilled analysts work on it for eight hours to... to figure out everything about that malware family, to attribute it. in relation to prior attacks, And what they'll be doing in the Malware report, right? And the agent pretty much got the same thing in 20 minutes. And, um... Bye. I think so, looking forward. Thank you. Thank you. Binary similarity and the data behind it, etc., will become a very important tool for agents. which delivers a very unique signal and the signal is precise. I mean, unlike LLMs, which, as you know, are powerful, but sometimes they say this and that. It's a very precise signal. and unique and I think that will... That's [50:00] the future of the field, right? It will be used by those agents with other classical technology like decompilation, disassembly, all these tools will become tools used by agents who smartly combine them. Also sandboxes, I guess, everything you have, whatever, P file viewers. whatever and that's where this is going and And I think the whole field will become much more mainstream. whole binary analysis which is good, right, because It's a very important problem if you look at the SOC, right? Bye. They really struggle these days. They get some unknown binaries. What shall they do? They run it through a sandbox, maybe. Either they get result or not. They don't have the time to go deep. and making binary analysis mainstream through agents which use precise tools on a lower level. that will make Bye. finding analysis accessible to much more people, And that's eventually very good because You need that capability early on in the defense process, right? You talked before about you want to... detect or protect as big as possible and that will be the effect of that. So I think that's... Bye. That's the way we have agents using these classical tools. That's very powerful. I think so. I mean, it just seems like a... I've long been an advocate of anyone dealing on the technical side of security having reversing skills. You just, how do you... How do you know how to even approach the triaging of a binary, just continue to focus on that, if you don't really understand at a lower level how they operate, what is actually occurring in the operating system and all of the inner details there. And I know that's harder because it's a learning curve and then it becomes very time consuming. And so being able to combine all that contextual analysis as well as the similarity and the code patterns and put it there closer to the front lines, I think is going to be quite amazing and profound. Did you want to follow up on with that? I highly believe in a genetic future. I've been working with agents in combination with different tools as well as our platform. and it's truly, truly empowering. for someone with mediocre reversing skills to also dip a bit further into these fields, I think. There will be a bright future ahead. combining these authentic approaches with really good, solid, grounded tools. And as you said in the beginning, George, I mean, also you as, I guess, a lead reversal, right? I mean, you will be able to focus more on the really interesting stuff. and I think jobs will become hopefully more interesting, right? It'll be a hopefully net positive effect, right? shifting of work to a different focus of what you do and you can focus on more interesting things as a human, right? That's my big hope, right? Still, I'm just hung up on... the obfuscation layer and that it seems like we have a vision of a future that But if obfuscations are still there, they can so sufficiently... I mean, just take... you know, a scattered flow of a program with indirect control flow. I mean, you can't disassemble that cleanly because Ida can't follow the indirect flow. You have to then rely on other mechanisms of execution. Maybe it's Well, I mean, even in memory, yeah, it's going to execute. You maybe get some other semantic understanding from it, but you still can't follow the code until you patch it. that flow back and stitch it back together. Am I just looking at this wrong or is LLM is going to be able to help us solve this? I mean, I'm thinking, okay, yeah, you have an indirect flow and you can maybe, well the answer's in there somewhere, right? But the more opaque you make that, the more difficult it becomes to trace. And I don't know, this is an area I'm still finding it hard to see a clear path that the future is going to solve. Just my opinion, I'm not an expert in using LLMs for deobfuscation, but Yes, that will be a problem. The more we are throwing LLMs into malware reversing and automating this, I'm sure we will see also malware surfacing, which has anti-LLM obfuscation in there. Right. I mean, they will make the LLMs fail. And it's for sure not the end of the story, right? It's not like LLM's will solve everything and in two years we've done. I think cat-and-mouse game, you keep going on. Yeah, I have a theory that we're [55:00] And again, I don't know how well grounded this is yet, but it seems like, you know, let's just say most obfuscations that we deal with today are, still designed to... disrupt the human and to maybe avoid basic static signature type systems. They're not really designed to handle the future with LLMs. And I don't even know, to extend that, I know you talked about your approach with machine learning, but eventually, at least the sophisticated adversaries, when the need arises, they'll there'll be a class of anti-LLM techniques. And it'll be probably a lot of the old stuff, and not just prompt injection, but, you know, like actual... pattern breaking mutations and stuff that just make it hard for the LLMs to process. And I don't know how those really change, I guess, at the end of the day. Maybe they don't, because... LLMs are still in a way just doing the same things we're doing. They're just doing them quicker and more efficiently. So all the same techniques apply. You scatter the flow of a program and it's all indirect. Well, LLMs will have... trouble following that. A human will have trouble following that and you'll have to pivot to different tools and patch things up and figure out the flow and reconstruct the graph. And I don't know. It's just... It's interesting. I'm really curious to see where all of this heads. The hype cycle with AI has been real for the last couple of years. It's hard to see through. It's also moving so fast. What you learned three months ago is already superseded again with a new generation of models. I think it's a highly evolving field at the moment and I would assume it will settle over the next couple of years. I have a better impression of Oh-ho. attackers and defenders are using these technologies. Okay, well then I will do this. I will say thank you both Jonas and Andre for joining me today and talking binary similarity, a topic that hopefully everybody in the podcast audience is interested in hearing and learning more about. Again, thank you for your time. Last words to both of you. I just say thanks for having us, Josh. It was a really interesting conversation. Thank you. And that's all for this episode of Behind the Binary. Thanks so much for tuning in. If you enjoyed the show, please consider subscribing and leaving a review. It really helps us to reach new listeners. Until then, stay curious and keep exploring.