Reverse Engineering Is Becoming a Trust Boundary Problem

I usually think about reverse engineering as a process of removing uncertainty from an artifact. A binary, firmware image, hardware configuration, or undocumented subsystem contains structure that is not immediately visible, and the analyst works backward until enough of that structure becomes understandable.

Two papers released within a month of each other made me think about a different part of that process.

The first, When Binaries Talk Back: Representation-Confusion Attacks on LLM-Assisted Reverse Engineering, was submitted in July 2026. It studies what happens when an LLM-assisted reverse-engineering pipeline correctly extracts information from a hostile binary but then gives that information more authority than it deserves. A string can become an instruction. Several views of the same underlying bytes can become false corroboration. A tentative note can later return as trusted analysis state. (1)

The second, SLAC: Access-Driven CPU-to-GPU Side-channel Attacks via System-Level Cache on Apple Silicon, was submitted in August 2026. Its authors first reverse engineer the Apple M1 system-level cache set-indexing functions, then use the recovered mapping to construct fine-grained CPU-to-GPU Prime+Probe side channels. Those channels are used to recover graph structure from GNN workloads and information from LLM inputs and outputs. (5)

These are very different papers. One concerns the semantic role assigned to reverse-engineering observations. The other concerns an undocumented microarchitectural mapping. I think they connect through the same underlying question: what happens when a hidden representation crosses a trust boundary?

In the first case, attacker-controlled binary content crosses into an AI analyst’s reasoning process. In the second, GPU memory activity crosses into a CPU-observable shared cache. In both cases, the important work begins by understanding a representation that the system was not designed to expose as a high-level interface. (1) (5)

Reverse engineering is no longer entirely passive

Traditional static analysis already assumes that the program being analyzed is hostile. Strings can lie. Dead code can distract. Packing and obfuscation can distort what tools recover. Anti-debugging and anti-analysis techniques attempt to make the analyst’s observations less useful. What changes with an LLM-assisted workflow is that the recovered observations may be interpreted by a system that can also propose actions, call tools, write analysis state, and produce conclusions. (1)

That changes the meaning of untrusted input.

A decompiler can faithfully recover a string from .rodata. The extraction can be completely correct. The security failure can occur later if an LLM interprets that string as analyst intent, system policy, evidence of program behavior, or a reason to modify persistent analysis state. When Binaries Talk Back calls this broader class Representation-Confusion Attacks in Reverse Engineering, or RARE. (1)

The distinction matters because filtering for obvious prompt injection is not enough to solve the larger problem. The paper explicitly includes non-imperative failures. Three records can all be accurate representations of the same underlying location and still create false corroboration if the pipeline counts them as three independent sources. A stored hypothesis can also become a false fact if its uncertainty is lost when it is written and later retrieved. (1)

Before RARE, binaries were already being used to manipulate RE agents

This problem did not appear for the first time in July.

In May 2026, Crawford, Phillips, and McClure demonstrated a technique for attacking an LLM-powered reverse-engineering system connected to Ghidra through GhidraMCP. Their proof of concept used extraneous string assignments that survived compilation and decompilation, allowing adversarial instructions to enter the model context without changing the executable’s intended runtime behavior. Their attack-generation process adapted ideas from AutoDAN to search for prompt strings that caused the analysis agent to describe the wrong target behavior. (2)

Follow-up work by Crawford and McClure examined detection of these strings and then deliberately obfuscated them. The paper reports that neural classification can help detect the tested attacks, but its effectiveness declines when the injected content is transformed to evade detection. The authors frame this as a reason to continue developing defenses outside the model rather than assuming the model can reliably identify every hostile instruction embedded in analysis content. (3)

There is also evidence that the idea has moved beyond controlled academic examples. In June 2026, SentinelLABS reported a macOS Rust implant called Gaslight that contained a roughly 3.5 KB payload made of 38 fabricated system-style messages intended to influence LLM-assisted malware triage. The malware itself still required ordinary technical analysis, but the embedded content was constructed specifically for an AI consumer of that analysis. (4)

What I find important is not simply that malware can contain prompt injection text. The more general problem is that reverse-engineering output has become executable input for another reasoning system. That creates a new security boundary between observation and authority. (1) (2)

Three ways a correct observation becomes a wrong conclusion

The RARE paper separates three failure modes: authority confusion, evidence confusion, and tainted-state promotion. (1)

Three different ways correctly extracted binary-derived content can be assigned an invalid role. Source: Santos-Grueiro, Figure 2.

Authority confusion is the most recognizable. Binary-derived content is treated as if it came from the analyst, developer, system policy, or another trusted instruction source. The content does not have to alter the decompiler. The decompiler can produce exactly the expected output. The failure happens because a later component grants the payload instruction privilege. (1)

Evidence confusion is more subtle. Reverse-engineering systems often produce several representations of the same artifact. A string extractor may expose one value, a decompiler may render the same constant, and a workflow may place it into a structured field. Those are three observations, but they may still have one provenance root. Counting them as independent confirmation can validate a claim that the underlying evidence does not establish. (1)

Tainted-state promotion is temporal. A hypothesis may be safely stored as uncertain, but if the state system later returns only the content and drops the status, provenance, or support requirements, the same hypothesis can re-enter the workflow as an established fact. The error is not necessarily created during the first analysis step. It can be introduced by storage and retrieval. (1)

I find it useful to express the common structure as a role transition:

$$o \xrightarrow{\pi} r,$$

where $o$ is an observation and $r$ is the role assigned to it. The destination role might be

$$r\in \{ \text{data}, \text{instruction}, \text{evidence}, \text{trusted state} \}.$$

This notation is my abstraction of the paper’s promotion concept, not an equation defined by the authors. The important question is not only whether $o$ was extracted correctly. The system also needs to know whether $o$ has enough authority or support to occupy role $r$. That is the boundary the paper is trying to preserve. (1)

More tools can create less trustworthy evidence

One result in the paper changed how I think about multi-tool AI analysis.

The authors instrument Ghidra, r2pipe, and angr and preserve stable handles plus provenance metadata outside the model. In a selected eight-program single-tool subset, no individual tool view reached the Support Gate threshold for the tested false claim. When observations were fused across tools, however, the support-only policy validated the false shared-provenance claim in all 32 evaluated model-program cells. Once the Provenance Gate grouped records that shared an exact root or recorded common ancestor, it validated none of those 32 false claims while retaining all 32 positive controls. (1)

That is important because agreement between tools is only meaningful when the evidence is sufficiently independent.

If Ghidra, r2pipe, and angr each expose different transformations of one attacker-controlled string, a model can observe three pieces of text without receiving three independent reasons to believe a behavioral claim. The number of observations increased, but the number of independent provenance units did not. (1)

The controlled holdout makes the same point with a different setup. Under the support-only gate, 23 of 40 false shared-root claims were validated. The provenance-aware gate validated 0 of 40, while both policies validated all 40 supported positive-control claims. The result is not that provenance proves independence. The paper explicitly warns against that interpretation. It shows that known dependence should be preserved instead of being erased by the presentation layer. (1)

The defense I find more convincing is architectural

The RARE-Guard design separates untrusted binary-derived observations from the control plane. The model sees typed records and stable handles. A trusted sidecar retains origin, support, reachability, roots, ancestors, and taint. Tool authorization, support validation, provenance grouping, and state validation happen outside the model. (1)

RARE-Guard keeps authority and provenance decisions outside the model. Source: Santos-Grueiro, Figure 4.

This design is more convincing to me than relying primarily on a stronger system prompt.

A model can still read hostile content. It can still use that content to decide what should be investigated next. The important difference is that reading data does not automatically grant the data permission to invoke a tool, validate a strong claim, or become trusted state. (1)

The paper’s controlled holdout illustrates this distinction. Without runtime controls, the evaluated models proposed the planted unsafe action in 35 of 40 adversarial cases and none of the 40 clean cases. Rendering the binary-derived content as data reduced the unsafe proposals to 15, but it did not eliminate them. A separate Tool Authorization layer denied all 15 remaining unsafe proposals and authorized all 40 matched analyst requests. (1)

My conclusion from this part of the work is that the model should be allowed to propose, but the runtime should decide what a proposal is allowed to become.

That is a useful design rule beyond reverse engineering.

A completely different paper starts with another hidden representation

The SLAC paper begins at a much lower level.

Apple M-series systems use a unified memory architecture in which the CPU and integrated GPU share physical memory, and the M1 includes a system-level cache shared across CPU clusters and the GPU. Prior work had already shown that this SLC could leak coarse occupancy information. The 2025 EXAM paper reverse engineered several SLC properties and used aggregate occupancy to perform website fingerprinting, pixel-stealing, and screen-capture attacks. It did not recover the explicit Apple M1 SLC set-indexing hash functions needed for fine-grained access-driven Prime+Probe targeting. (5) (6)

Earlier work on integrated CPU-GPU systems had also shown that shared resources can support cross-component covert channels. Leaky Buddies demonstrated GPU-to-CPU channels on Intel integrated platforms using the shared LLC and ring-bus contention. SLAC studies the opposite direction on Apple Silicon: an attacker on the CPU observing a victim GPU workload. (7) (5)

The reverse-engineering problem is that the Apple M1 does not expose a simple documented mapping from physical addresses to SLC sets. The paper reports 4,096 SLC sets, which requires a 12-bit set index, and finds that all 12 index bits are generated through hash functions over multiple physical-address bits. (5)

Recovering the Apple M1 cache-set mapping

The authors first construct eviction sets using what they call collision-profile clustering.

They fill the SLC from the GPU with a large filler region, access one test cache line from the GPU, then probe the filler lines from the CPU to observe which lines were displaced. Repeating this process creates an eviction profile for each test line. Test lines that map to the same SLC set disturb similar filler lines, so the researchers cluster addresses by profile similarity. Each cluster becomes an empirical eviction set. (5)

The clustering produced 4,096 groups. On the tested 8 GB M1, the lower 33 bits form the effective physical byte address. Since the cache line is 128 bytes, the lowest seven bits are line offsets. That leaves 26 candidate address bits that can contribute to the 12-bit SLC index. (5)

The paper models each index bit as an XOR of a subset of those address bits. A compact way to write one recovered index bit is

$$s_j = \bigoplus_{k\in S_j} a_k,$$

where $a_k$ is physical-address bit $k$, $S_j$ is the subset used by index bit $j$, and $\oplus$ is XOR. With 26 candidate bits, there are

$$2^{26}$$

possible XOR subset functions for one index bit before filtering. The researchers eliminate functions that are inconsistent within a cluster or fail to partition the 4,096 clusters evenly, leaving 4,095 valid functions, then choose 12 linearly independent functions that jointly assign distinct 12-bit indices to all 4,096 clusters. (5)

One functionally equivalent set of 12 recovered SLC index functions. Source: Xu et al., Figure 4.

There is a detail here that I think is important for reverse engineering in general. The authors do not claim that their numerical set labels are Apple’s internal labels. They recover a functionally equivalent partition of physical addresses into the 4,096 cache sets. For the attack, equivalence is enough. The objective is not to recover Apple’s source code or internal naming. The objective is to recover the relationship needed to target congruent cache addresses. (5)

That is a useful definition of success in reverse engineering: recover the hidden structure required for the next technical question.

Reverse engineering is the prerequisite, not the final result

Once the set-indexing functions and replacement behavior are understood, the paper uses them to construct eviction sets for arbitrary SLC sets and build two variants of a CPU-to-GPU Prime+Probe channel. (5)

The CPU-only version is called CPrime+CProbe. Because the Apple M1 SLC is exclusive relative to the CPU’s private caches, the attacker cannot simply load selected lines and assume they now occupy the SLC. CPrime uses a two-stage procedure that first manipulates lines associated with the SLC and then loads additional L2 eviction data so surviving lines are forced into the SLC. The probe phase runs on the CPU. (5)

The faster GPrime+CProbe variant performs priming from the GPU and probing from the CPU. The paper reports a covert-channel throughput of 62.5 Kbps for CPrime+CProbe and 400 Kbps for GPrime+CProbe, a 6.4 times increase. The faster method is cleaner but requires the adversary to execute GPU kernels through Apple’s Metal API, while the primary CPrime+CProbe attacks can run from an unprivileged CPU process without GPU access. (5)

The important transition is

$$\text{undocumented mapping} \rightarrow \text{recovered cache sets} \rightarrow \text{targeted eviction sets} \rightarrow \text{side-channel trace}.$$

The reverse engineering produces a measurement primitive.

From cache activity to model secrets

A cache trace by itself is not a prompt, a token, or a graph edge.

SLAC therefore adds a profiling and inference layer. The general workflow constructs an Access Mapping Matrix

$$M\in\mathbb{Z}^{N\times S},$$

or a binary form depending on the noise-reduction method. Each row describes the cache-set footprint of one target item. During victim execution, the attacker observes a vector

$$\mathbf{v}\in\mathbb{Z}^{S}$$

representing SLC activity. Secret recovery compares the observed vector against the profiled rows of $M$ to infer which items the victim accessed. (5)

The same cache observation primitive is applied to two different GPU workloads. Source: Xu et al., Figure 9.

For the GNN attack, each node’s feature vector becomes a profiled item. The victim’s neighborhood aggregation reads feature vectors for neighboring nodes, so the observed SLC footprint contains information about which nodes were accessed. Across five evaluated graph datasets, the paper reports full-graph recall above 90% for the CPU-only CPrime+CProbe attack, with precision above 86% on all five after full-graph consistency recovery. The GPU-primed variant produces still higher precision and recall, including precision above 99% on Cora, Citeseer, and Pubmed. (5)

The LLM attack is even more interesting because the side channel does not directly identify every token uniquely.

For input recovery, the researchers profile a domain-specific dictionary of keywords and monitor embedding-layer accesses during prefill. In their MedQuad and FinancialQA evaluations, CPrime+CProbe recovers the target keyword with 76.3% to 81.2% accuracy depending on model and dataset. GPrime+CProbe increases that range to 91.5% to 94.8%. The evaluated models are TinyLlama and GPT-2 Medium. (5)

For output recovery, the attack observes embedding lookups during autoregressive decoding. Because one observed cache superset can correspond to several candidate tokens, the authors use a local copy of the same language model to resolve ambiguity. For the initial three tokens, candidate triples are scored as

$$\operatorname{Score}(x_1,x_2,x_3) = P_{\mathrm{LLM}}(x_1\mid\varnothing) P_{\mathrm{LLM}}(x_2\mid x_1) P_{\mathrm{LLM}}(x_3\mid x_1,x_2).$$

After fixing the first three tokens, each later token is selected from its side-channel-derived candidate set $C_t$ using

$$\hat{x}_t = \underset{x\in C_t}{\arg\max} \; P_{\mathrm{LLM}} \left( x\mid \hat{x}_1,\ldots,\hat{x}_{t-1} \right).$$

In the reported experiments, CPrime+CProbe recovers 70.5% to 85.3% of output tokens across the two models and two datasets, while GPrime+CProbe reaches 75.7% to 88.9%. The authors note that early token errors affect later predictions because the reconstruction itself is autoregressive. (5)

This combination is what I find most interesting. Reverse engineering recovers the cache mapping. Microarchitectural measurement narrows the possible memory accesses. A language model prior then narrows candidate tokens further.

No one layer provides the complete secret.

The attack works by combining representations.

The two papers are about opposite directions of trust

The RARE paper asks what happens when information from a hostile artifact moves upward into a reasoning system.

SLAC asks what happens when information from a supposedly internal hardware mechanism moves sideways across CPU and GPU execution domains.

I think both papers can be reduced to a similar pattern:

Paper	Hidden or untrusted representation	Reverse-engineering question	Security failure
RARE	Strings, decompiler views, records, provenance	What role is this observation actually allowed to have?	Data becomes authority, false evidence, or trusted state
SLAC	Physical addresses and undocumented SLC set mapping	Which memory addresses share the same cache sets?	GPU memory activity becomes observable from another execution domain

The first paper shows that semantic provenance matters. The second shows that microarchitectural mapping matters.

In both cases, a system is vulnerable when an internal representation is treated as if its boundary were stronger than it really is. (1) (5)

What I learned from these together

The first thing I took from them is that reverse engineering is increasingly about preserving or recovering relationships, not simply recovering content.

In RARE, the individual string may be extracted perfectly. What matters is where it came from, how other records were derived from it, what it can support, and whether it has authority. In SLAC, an individual physical address is not enough. What matters is the relation between address bits and SLC sets. (1) (5)

The second is that more information does not automatically mean better evidence.

RARE shows this directly when several tool views of one provenance unit create apparent corroboration. SLAC reaches a different version of the same issue: raw cache observations are noisy and ambiguous, so they need structured profiling, differential tracing, aggregation, and probabilistic disambiguation before they support a useful secret-recovery claim. (1) (5)

The third is that reverse engineering can be only the first stage of a larger system.

Recovering Apple’s SLC hash functions is a substantial result, but the paper’s security impact comes from what those functions enable afterward. The mapping becomes a means for targeted observation. In the AI-agent paper, reverse-engineering output is also intermediate state. It becomes input to another reasoning and action system. (1) (5)

That changes how I think about evaluating an RE result. The useful question may not be only, “How much of the original structure did we recover?” It may also be, “What new operation becomes possible because this structure is now known?”

What I would not conclude

I would not read the RARE results as proof that every LLM reverse-engineering agent is easily compromised. The paper evaluates bounded workflows, two models in its controlled holdout, and specific authority, evidence, and state tasks. It explicitly states that unrestricted tools, autonomous open-ended planning, long-running memory, and general deployed RE agents are outside the measured scope. (1)

I also would not read SLAC as a general remote attack against arbitrary modern GPU inference. The experiments target Apple M1 systems with a co-resident attacker, and the LLM privacy demonstrations use TinyLlama and GPT-2 Medium under the paper’s specific deployment and profiling assumptions. The authors discuss extending the attack family to later Apple M-series systems as future work, not as an already demonstrated result. (5)

Those limitations do not make either result less interesting. They define the boundary of what has actually been shown.

Where I think reverse engineering is heading

For AI-assisted software analysis, I expect provenance to become part of the architecture rather than metadata added after the model has already consumed a flattened prompt.

A reverse-engineering agent should know the difference between:

$$\text{what the binary says},$$ $$\text{what a tool observed},$$ $$\text{what the analyst requested},$$

and

$$\text{what the system has actually verified}.$$

Those categories should not exist only as prose instructions inside the model context. RARE’s results suggest that authorization, evidence requirements, provenance, and state status are stronger when they remain enforceable outside the model. (1)

For hardware reverse engineering, I expect heterogeneous systems to keep producing security questions at boundaries that were designed primarily for performance. Unified memory, shared caches, accelerators, and increasingly specialized compute blocks create more situations in which different execution domains interact through hardware state. EXAM and SLAC show a progression from coarse SLC occupancy to fine-grained set-level observation on Apple Silicon. Leaky Buddies established earlier that cross-component channels are possible on integrated CPU-GPU systems. (6) (5) (7)

The broader direction I see is that reverse engineering is becoming less separable from the system that consumes its result.

An AI analyst changes the threat model of software RE because extracted content becomes model input.

A shared CPU-GPU cache changes the threat model of hardware RE because a recovered mapping becomes an observation channel.

The artifact is still being reverse engineered, but the most important question may now be what the recovered representation is allowed to influence.

Papers and research connected in this piece

1. Igor Santos-Grueiro, When Binaries Talk Back: Representation-Confusion Attacks on LLM-Assisted Reverse Engineering, 2026. arXiv
2. Brian Crawford, Justin Phillips, and Patrick McClure, Automatically Attacking Software Reverse Engineering AI Agents, 2026. arXiv
3. Brian Crawford and Patrick McClure, Investigating Detection and Obfuscation of Prompt Injection Attacks Against Software Reverse Engineering AI Agents, 2026. arXiv
4. Phil Stokes, macOS.Gaslight | Rust Backdoor Turns Prompt Injection on the Analyst, Not the Sandbox, SentinelLABS, 2026. SentinelLABS
5. Tianhong Xu, Saion K. Roy, Ruyi Ding, Aidong Adam Ding, and Yunsi Fei, SLAC: Access-Driven CPU-to-GPU Side-channel Attacks via System-Level Cache on Apple Silicon, 2026. arXiv
6. Tianhong Xu, Aidong Adam Ding, and Yunsi Fei, EXAM: Exploiting Exclusive System-Level Cache in Apple M-Series SoCs for Enhanced Cache Occupancy Attacks, 2025. arXiv
7. Sankha Baran Dutta, Hoda Naghibijouybari, Nael Abu-Ghazaleh, Andres Marquez, and Kevin Barker, Leaky Buddies: Cross-Component Covert Channels on Integrated CPU-GPU Systems, 2021. arXiv