Paper deep dive

Detokenization Leaks: Reconstructing Local LLM Outputs From Cache Traces

Roy Weiss, Benyamin Konstantinov, Eitam Sheetrit, Tomer Simon, Yisroel Mirsky

Year: 2026Venue: arXiv preprintArea: cs.CRType: PreprintEmbeddings: 114

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%

Last extracted: 9/12/2026, 2:57:31 AM

Summary

This paper introduces 'Detokenization Leaks,' a novel side-channel attack that reconstructs text generated by locally hosted Large Language Models (LLMs) by monitoring CPU cache activity during the detokenization phase. Unlike previous attacks requiring specific deployment configurations like shared memory or Mixture-of-Experts architectures, this method targets the universal detokenizer component. The attack utilizes Flush+Reload on shared tokenizer code to precisely time Prime+Probe measurements, isolating token-dependent cache signals. A clustering and language model pipeline then recovers the original text from noisy cache observations. The authors demonstrate the attack's effectiveness across various hardware, frameworks, and model families, including real-world deployments like OpenClaw.

Entities (11)

CPU Cache · hardware-component · 99%Large Language Models · technology · 99%Detokenization Leaks · attack-method · 98%Side-Channel Attacks · security-concept · 98%Flush+Reload · side-channel-technique · 97%Prime+Probe · side-channel-technique · 97%Detokenizer · software-component · 95%OpenClaw · software-system · 92%HuggingFace Transformers · software-library · 90%llama.cpp · software-library · 90%Ollama · software-system · 88%

Relation Signals (8)

Detokenization Leaks → exploits → CPU Cache

confidence 98% · reconstructs the text generated by locally hosted LLMs by observing CPU cache activity

Detokenization Leaks → uses → Flush+Reload

confidence 97% · we use Flush+Reload on shared tokenizer code to detect when decoding occurs

Detokenization Leaks → uses → Prime+Probe

confidence 97% · perform Prime+Probe at the right moment and isolate token-dependent cache activity

Flush+Reload → monitors → Shared Tokenizer Code

confidence 95% · we use Flush+Reload on shared tokenizer code to detect when decoding occurs

Detokenization Leaks → targets → Detokenizer

confidence 95% · our approach targets the detokenizer, a component used in default LLM inference pipelines.

Detokenization Leaks → demonstratedon → OpenClaw

confidence 92% · including systems such as OpenClaw (which we demonstrate)

llama.cpp → isvulnerableto → Detokenization Leaks

confidence 90% · tokenizer implementations (e.g., in Llama.cpp) are loaded as shared libraries... susceptible to the attack

HuggingFace Transformers → isvulnerableto → Detokenization Leaks

confidence 90% · HuggingFace Transformers... are reused across a wide range of applications... susceptible to the attack

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:We present a new attack that reconstructs the text generated by locally hosted LLMs by observing CPU cache activity during detokenization. Unlike prior attacks that rely on deployment-specific assumptions, such as shared data memory, CPU offloading, or Mixture-of-Experts architectures, our approach targets the detokenizer, a component used in default LLM inference pipelines. To obtain clean signals, we use Flush+Reload on shared tokenizer code to detect when decoding occurs, which lets us perform Prime+Probe at the right moment and isolate token-dependent cache activity. We then apply a clustering-and-language-model pipeline to recover text from noisy cache observations. We evaluate the attack across multiple datasets, hardware platforms, inference frameworks, and model families, and show that it can recover semantically accurate outputs from real-world local LLM deployments, including agentic systems. This vulnerability is particularly significant because the most widely used tokenizer implementations are susceptible to the attack and are embedded in many popular local LLM products and agent frameworks, including systems such as OpenClaw (which we demonstrate), substantially broadening the practical attack surface.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

110,570 characters extracted from source content.

Expand or collapse full text

Detokenization Leaks: Reconstructing Local LLM Outputs From Cache Traces DOI: X.XXXXXXXConference: Make sure to enter the correct conference title from your rights confirmation email; June 03–05, 2018; Woodstock, NYISBN: 978-1-4503-X-X/2026/08CCS: Security and privacy Roy Weiss Affiliation: Ben Gurion University, Israel , Benyamin Konstantinov Affiliation: Ben Gurion University, Israel , Eitam Sheetrit Affiliation: Microsoft Security, Israel , Tomer Simon Affiliation: Microsoft Security, Israel and Yisroel Mirsky Note: Corresponding author Affiliation: Ben Gurion University, Israel 2026 Abstract. We present a new attack that reconstructs the text generated by locally hosted LLMs by observing CPU cache activity during detokenization. Unlike prior attacks that rely on deployment-specific assumptions, such as shared data memory, CPU offloading, or Mixture-of-Experts architectures, our approach targets the detokenizer, a component used in default LLM inference pipelines. To obtain clean signals, we use Flush+Reload on shared tokenizer code to detect when decoding occurs, which lets us perform Prime+Probe at the right moment and isolate token-dependent cache activity. We then apply a clustering-and-language-model pipeline to recover text from noisy cache observations. We evaluate the attack across multiple datasets, hardware platforms, inference frameworks, and model families, and show that it can recover semantically accurate outputs from real-world local LLM deployments, including agentic systems. This vulnerability is particularly significant because the most widely used tokenizer implementations are susceptible to the attack and are embedded in many popular local LLM products and agent frameworks, including systems such as OpenClaw (which we demonstrate), substantially broadening the practical attack surface. Keywords: Large Language Models, Side-Channel Attacks 1. Introduction Large Language Models (LLMs) have rapidly transformed sectors such as healthcare, finance, education, and entertainment. Models such as ChatGPT and Llama provide high-quality natural language generation, summarization, and decision support across diverse applications. Increasingly, users rely on LLMs for sensitive tasks, including preliminary medical advice, drafting confidential communications, and financial planning (Raiaan et al., 2024). Beyond standalone usage, LLMs are now embedded in autonomous or semi-autonomous agent systems that orchestrate multi-step workflows, interact with external tools, and manage user data over extended sessions. Frameworks such as OpenClaw and Claude-Code enable agents to perform tasks including file management, coding, and personal assistance, often operating on sensitive inputs such as local files, credentials, and private communications (Wang et al., 2024; Deng et al., 2025). A Shift to Local Hosting. As LLM adoption grows, there is a clear trend toward local deployment, driven by privacy, latency, and reduced reliance on external services. Advances in quantization, pruning, and optimized runtimes have made local execution feasible on consumer hardware (Ma et al., 2023; Kwon et al., 2023; Dettmers and Zettlemoyer, 2023). Tools such as Llama.cpp (Gerganov, 2023), GPT4All (Anand et al., 2023), and Ollama (Team, 2026) allow users to run models including Llama (Grattafiori et al., 2024), Mistral (Jiang et al., 2023), and Phi (Abdin et al., 2024) on desktops and laptops with minimal setup. This paradigm extends to agent-based systems, where users deploy LLM-powered agents locally to retain control over data and execution (OpenClaw Foundation, ). These agents typically run as long-lived processes with persistent access to local resources (e.g., files, APIs, and credentials), and therefore process sensitive information continuously over extended interactions. Side-Channel Attacks on Local LLMs. While local deployment improves privacy by keeping data on-device, it also shifts the threat model toward the underlying hardware. In particular, co-resident processes on the same machine may observe low-level microarchitectural side effects of LLM inference. One important class of such leakage arises from the CPU cache: because programs access memory through shared cache structures, an adversarial process can monitor cache contention to infer which memory locations another process is accessing. Since these memory access patterns depend on the data being processed, they can inadvertently reveal sensitive information. This creates an opportunity for adversaries to extract information directly from local LLM executions. A Lack of Universality in the Threat Model. Recent works have demonstrated cache-based side-channel attacks that exploit this effect to infer text generated by LLMs. However, these attacks rely on strong, deployment-specific assumptions. They require particular system or model features, such as unified CPU/GPU memory (Adiletta and Sunar, 2025), CPU layer offloading (Gao et al., 2025), or the use of a Mixture-of-Experts (MoE) model architecture (Ding et al., 2025). Although these conditions can arise, some are rare, and none are universally present across LLM deployments. For example, memory sharing of internal model data depends on specific system configurations, and many deployments use standard (non-MoE) architectures. Proposed Approach. In this paper, we propose a more broadly applicable cache-based side-channel attack, one that makes far fewer assumptions about the victim’s LLM libraries and configuration. Our attack is stronger because it targets a component that is universal to all LLM pipeline deployments in their default configuration: the detokenizer. LLMs read and generate tokens, which are akin to words or word chunks. When a token is generated by the model, it is represented as an integer ID. To read the text, each ID must be mapped back to its corresponding word chunk. This occurs on the CPU via a lookup table, such as a hash map (Brown et al., 2020; Chowdhery et al., 2023). Therefore, each time a token is generated, we expect to see a unique pattern in the cache that can be traced back to each token. Improved Universality. To avoid relying on strong assumptions such as shared data memory, we instead employ a Prime+Probe attack to observe memory access patterns in the CPU cache. However, Prime+Probe is inherently noisy and is typically effective only when memory access patterns either repeat frequently or involve large memory regions that produce strong, distinguishable signals. In our setting, neither condition holds: each token’s decode operation touches only a small portion of the cache, resulting in weak and highly ambiguous signals that are difficult to isolate and interpret. To address these challenges, we rely on two key insights that enable the effective use of Prime+Probe in this setting: Insight 1.: Precise timing enables cleaner signals. If we can align Prime+Probe measurements tightly around the detokenization step, we can significantly reduce noise and isolate the cache activity of interest. We achieve this using an auxiliary side channel: specifically, we apply Flush+Reload to the tokenizer library. In common deployments, tokenizer implementations (e.g., in Llama.cpp) are loaded as shared libraries by the operating system.11 1 In contrast to (Adiletta and Sunar, 2025; Gao et al., 2025), which assume shared data structures (often unavailable or disabled in standard deployments), we rely only on shared instruction pages (shared libraries), shared by default across processes in modern operating systems (Yarom and Falkner, 2014). When the tokenizer code is invoked, it triggers a detectable signal, allowing us to precisely time our Prime+Probe measurements around each token decode operation. Insight 2.: Cache collisions are inevitable but structured. Even with improved timing, cache signals remain noisy, and different tokens may map to overlapping cache sets, making them difficult to distinguish directly. To address this, we group tokens based on similarity in their observed cache access patterns and assign each group a discrete symbol. This produces a reduced symbolic representation of the trace sequence. Because these symbols preserve the order of generated tokens, we then train a downstream language model to map these symbol sequences to text, leveraging linguistic context to resolve ambiguities and reconstruct the original output. A Widespread Vulnerability. Focusing on the tokenizer exposes a broad and practical attack surface. In current LLM ecosystems, a small number of tokenizer implementations (primarily Llama.cpp (Gerganov, 2023) and HuggingFace Transformers (Wolf et al., 2020)) are reused across a wide range of applications. As illustrated in Fig. 1, these libraries underpin numerous locally hosted systems, including LLM servers and agent frameworks, all of which rely on them as backend components. Since these local instances run long-term, an adversary with minimal privileges can use this attack to (1) profile a target instance, (2) learn the mapping between cache traces and tokens using our method, and (3) subsequently reconstruct future outputs from that instance. This enables the extraction of sensitive user information across a diverse set of real-world deployments. Figure 1. Tokenizers such as Llama.cpp and HuggingFace Tokenizers are vulnerable to our attack. Because these libraries are widely deployed in local LLM servers, the vulnerability extends to a large ecosystem of downstream applications, tools, and IDE plugins that depend on them (as of August 2026). In our evaluation, we show that the attack can decipher content from a wide range of LLM tasks, from conversational LLMs to instruct LLMs to code LLMs, using three datasets (UltraChat (Ding et al., 2023), ChatDoctor (Li et al., 2023), and Code-Alpaca (Chaudhary, 2023)). We also evaluate our attack across two hardware platforms (laptop and desktop), two inference frameworks, and two target models, covering diverse tokenizer implementations and application domains. We also evaluate an end-to-end attack on the popular locally hosted agent OpenClaw (OpenClaw Foundation, ). Contributions. In summary, this paper makes the following contributions: • A More Universal Cache-Based Side-Channel Attack. We present a detokenization-based side-channel attack that operates under default system configurations, avoiding the strong assumptions required by prior work (e.g., shared data structures, specific model architectures, or specialized CPU/GPU memory configurations). This significantly broadens the applicability of cache-based attacks on local LLM deployments. • Precise Prime+Probe via Auxiliary Synchronization. We show how to obtain fine-grained temporal alignment for Prime+Probe by leveraging Flush+Reload on shared tokenizer code. This enables targeted measurement of detokenization events and substantially improves signal quality despite the inherent noise of Prime+Probe. • Robust Trace-to-Text Reconstruction from Noisy Signals. We introduce a novel pipeline for mapping noisy, collision-prone cache traces to natural language. Our approach clusters continuous timing data into symbolic sequences and uses language models to reconstruct text, leveraging context to resolve ambiguity. • Comprehensive Evaluation on Real-World Systems. We evaluate our attack across diverse LLM tasks, hardware platforms, tokenizer frameworks, and model families, and demonstrate end-to-end attacks on real-world deployments, including a popular locally hosted agent system (OpenClaw). 2. Background In this section, we review the LLM inference pipeline and the cache side-channel primitives relevant to our setting, focusing on decode-time behavior and shared CPU resources. These components together define the attack surface exploited in our setting. 2.1. LLM Inference and Tokenization LLMs operate on discrete units of text known as tokens, which typically correspond to words, subwords, or characters. During inference, the model consumes a user-provided input prompt and generates a sequence of output tokens in an autoregressive manner. This process involves two distinct stages: the encode phase and the decode phase. In the encode phase, the input prompt string p∈Σ∗p∈ ^* is tokenized on the CPU into a sequence of token IDs (p1,p2,…,pn)∈Vn(p_1,p_2,…,p_n)∈ V^n, using a deterministic vocabulary (V) defined by the tokenizer. These IDs are then passed to the model as the initial inference context. The decode phase maps each token ID to its corresponding string. At each step, the model predicts the next token ID rir_i based on the previously generated context. To present the output in human-readable form, these integer token IDs are converted to UTF-8 strings using the decode table (D), which resides on the CPU, in contrast to the model parameters that typically remain on the GPU. To provide real-time feedback, inference frameworks invoke the decode operation immediately after each token is generated, making this mapping process inherently autoregressive. 2.2. Local LLM Deployments Advances in quantization, pruning, and optimized inference runtimes have enabled LLMs to run directly on commodity personal devices (Ma et al., 2023; Kwon et al., 2023; Dettmers and Zettlemoyer, 2023). Motivated by latency and privacy, local deployments are increasingly used in developer tools, document processing systems, and personal assistants (Xu et al., 2025; Yuan et al., 2024; Zhang et al., 2024a). Most local deployments follow a client-server architecture in which an inference backend exposes a localhost API to desktop interfaces, IDE plugins, or automation tools. Clients submit prompts and receive responses, typically streamed token by token as they are generated and decoded. To avoid repeatedly loading model weights, the backend remains active and serves multiple requests over time. Systems such as Ollama and LM Studio follow this design (Team, 2026). 2.3. Cache Side-Channel Attacks Modern CPUs employ caches to reduce memory access latency. These caches are organized into multiple levels, typically L1, L2, and the Last-Level Cache (LLC). L1 and L2 caches are private to individual cores, while the LLC is shared across cores. On each memory access, the CPU first checks the cache hierarchy: a cache hit returns data quickly, while a miss fetches it from main memory and stores it in the cache. This shared caching behavior creates observable contention between processes, enabling an attacker to infer a victim’s memory access patterns from a separate process. Flush-based Attacks. Flush-based side-channel techniques, such as Flush+Reload (Yarom and Falkner, 2014) and Flush+Flush (Gruss et al., 2016), exploit scenarios where memory pages are shared between an attacker and a victim. In Flush+Reload, the attacker evicts a shared cache line using clflush and measures the time to reload it; a fast access indicates that the victim accessed the same line. This enables high-resolution monitoring of specific cache lines corresponding to code or data. In practice, shared memory arises from shared libraries (e.g., dynamically linked code). Extending this to arbitrary data structures requires additional conditions, such as explicit shared mappings, page deduplication, or unified memory. As these are not consistently present, the applicability of Flush+Reload-style attacks on data is limited. Prime+Probe Attacks. Prime+Probe is a contention-based side-channel technique that does not require any shared memory between attacker and victim. Instead, it exploits the fact that multiple addresses may map to the same cache set, creating measurable interference. The attacker first fills selected cache sets with their own data (prime phase), allows the victim to execute, and then measures access times to the same addresses (probe phase). Increased access latency indicates that the victim has evicted some of the attacker’s cache lines, revealing information about the victim’s memory accesses. L1 Prime+Probe. In our setting, we focus on the L1 data cache, which is private to a physical core but shared between simultaneous multithreading (SMT) siblings. This enables an attacker co-scheduled on the same physical core to monitor L1 cache activity with high temporal fidelity and low measurement latency, making it well-suited for short per-token decode operations in autoregressive LLM inference. On common x86 systems, L1 set selection is determined by the virtual address bits within the page offset, so accesses to different entries may contend on the same set even without shared memory. At the same time, L1 Prime+Probe is challenging: the cache is small, the hit-miss timing gap is narrow, and the number of sets is limited. As a result, measurements are noisy and multiple memory locations may alias to the same observed cache set, reducing spatial resolution (Rauscher et al., 2025). 2.4. Decode Tables in Practice The decode table D is a data structure that maps token identifiers to their corresponding UTF-8 byte sequences. In mainstream implementations, it is stored as an array-like structure indexed by token ID. For example, in Llama.cpp, which underlies frameworks such as Ollama and GPT4All, it is implemented as a std::vector. Other libraries use equivalent containers. In HuggingFace’s Tokenizers library, for example, the decode table is implemented using Rust’s default HashMap. Although its randomized hash seed may cause the memory layout to differ across process invocations, the layout remains fixed once initialized. Thus, within a long-lived process, decoding the same token consistently accesses the same memory locations, producing stable and repeatable cache access patterns. 3. Attack Overview 3.1. Threat Model Victim Setup. We consider a user running an LLM locally on a personal device, either as a standalone server or as the backend of a local application or agent framework. Such deployments are increasingly used for sensitive tasks, including summarizing emails, drafting confidential communications, providing personal advice, and managing files and services. This setting appears in several common forms: (i) local model servers used by developer tools, (i) desktop assistants that optionally expose a localhost API, and (i) workstation inference services shared by multiple local clients. In practice, these deployments typically run a long-lived backend process that exposes an API accessible over localhost. For example, Ollama binds to 127.0.0.1:11434 by default and exposes an HTTP API such as POST /api/generate, through which any local process can submit prompts and receive responses. Higher-level applications and agent frameworks connect to such local endpoints. For example, OpenClaw supports local model providers including Ollama and other local inference backends. Persistence and execution. We assume that inference runs locally on the host CPU and/or GPU and that the LLM instance is long-lived, serving multiple requests over time. This ensures that tokenizer data structures remain stable during execution, as described in Section 2.4. Platform assumptions. We assume the victim system employs simultaneous multithreading (SMT), such as Intel Hyper-Threading, exposing multiple logical processors per physical core. This is a practical assumption, as SMT is commonly enabled by default on consumer systems (Intel Corporation, n.d), including across a broad range of modern CPUs summarized in Appendix Table 7. Moreover, disabling SMT can reduce performance by 25%–35% (Walton, 2019), providing a practical incentive to leave it enabled. Under SMT, the adversary can identify the processor executing the victim and place its own thread on the corresponding sibling processor using standard unprivileged affinity mechanisms, as commonly assumed in SMT-based side-channel attacks (Bhattacharyya et al., 2019; Gast et al., 2023). Finally, we assume that the tokenizer implementation includes executable code pages that are shared across processes, as is standard for dynamically linked shared libraries and native extension modules in modern operating systems. We verified this property for the popular libraries we evaluated, including HuggingFace’s Transformers library and Llama.cpp as shown in Figure 1. Our attack does not assume that tokenizer data structures are shared; it relies only on shared code pages, which are enabled by default. Adversary Model. The adversary’s objective is to reconstruct the plaintext output generated by the hosted LLM instance, or more generally, to infer sensitive information from that output. To achieve this objective, we consider an unprivileged adversarial process co-located on the same machine as the victim and scheduled on the corresponding SMT sibling. The adversary runs as a benign user-space application (e.g., a desktop app or IDE plugin) and does not require elevated privileges or modifications to the operating system or LLM framework. Capabilities. The adversary can (1) execute standard user-space instructions, including cache line flush (clflush) and high-resolution timing (rdtsc), (2) access shared code pages of dynamically linked libraries used by the victim, and (3) interact with the local LLM service by issuing prompts and observing outputs through its exposed local interface. None of these capabilities requires special privileges. As is standard in profiling-based side-channel attacks, the adversary can use this access to collect labeled traces and learn a mapping between cache observations and generated text before applying the attack to unknown executions (Ding et al., 2025; Zhang et al., 2024b; Yuan et al., 2022; Yuan et al., 2021). Knowledge. Our attack is agnostic to the victim’s model family, model version, quantization, vocabulary size, inference framework, and application configuration. The only implementation-specific information required is the tokenizer library used by the victim, since its shared decode routine provides the Flush+Reload trigger. This library need not be known a priori: as described in Section 4, the attacker can identify the active tokenizer implementation by monitoring candidate decode routines while inducing generation. These assumptions are consistent with prior cache side-channel threat models (Yarom and Falkner, 2014; Liu et al., 2015). Exclusions. The adversary does not require access to shared data structures, internal model states, or GPU memory. Unlike prior work (Adiletta and Sunar, 2025; Gao et al., 2025), we do not assume any shared data memory between attacker and victim. The attack relies only on shared instruction pages from dynamically linked libraries, which are read-only and shared by default in modern operating systems. 3.2. Vulnerability Breakdown Key insight. The core vulnerability is that LLM detokenization relies on a deterministic decode table whose memory access pattern depends on the generated token. During inference, each output token rir_i is represented internally as an integer ID, and the tokenizer’s decode function maps that ID to its corresponding UTF-8 string by reading the decode table D. Because different tokens correspond to different entries in D, decoding different tokens causes accesses to different memory locations. As discussed in Section 2.4, this mapping remains fixed for the lifetime of the process. As a result, the same token repeatedly induces the same cache activity, creating a stable leakage source that can be profiled and later exploited. Why this matters. This leakage arises from a component that is fundamental to LLM inference: every generated token must eventually be converted back into text. Unlike prior attacks that depend on deployment-specific features such as shared data memory or particular model architectures, our leakage source comes from the decode-table lookup itself, making the attack applicable across a broad range of local LLM deployments. Technical formulation. As discussed in Section 2.1, LLMs operate over a fixed vocabulary of token identifiers. During generation, each predicted token rir_i must be decoded into a human-readable string by querying the decode table D. Since different token strings reside at different memory locations, the memory access pattern of the decode operation depends on rir_i. Although one process cannot directly observe another process’s memory accesses, each lookup of rir_i induces activity in an L1 cache set cjc_j that can be detected via Prime+Probe. The mapping from a token identifier rir_i to its cache set is given by cj=(((ri⋅E)modP)≫log2⁡B)&(N−1),c_j= ( ((r_i· E) P ) _2B )\,\&\,(N-1), where E is the size of an entry in the decode table D, P is the page size, B is the cache line size, and N is the number of L1 cache sets. On typical x86 systems (B=64B=64, N=64N=64), this simplifies to cj=((ri⋅EmodP)≫6)& 63.c_j= ((r_i· E P) 6 )\,\&\,63. As detailed in Section 2.4, the decode-table layout remains fixed after initialization, so the mapping from a token identifier rir_i to its corresponding cache set cjc_j remains stable during execution. This enables a profiling-style attack: the adversary collects a limited set of labeled traces from the same long-lived victim by issuing benign queries and observing the corresponding outputs, producing trace–token pairs that capture decode-table accesses. These pairs are then used to learn a mapping from cache traces to tokens and reconstruct outputs generated for other applications or users of the same server. Let ti∈ℕNt_i ^N denote the cache trace collected during the decode step of token rir_i, where each component records the access latency of one L1 cache set. The trace tit_i exhibits a token-dependent signature, with its dominant signal at index cjc_j. Observing the sequence (t1,t2,…)(t_1,t_2,…) therefore reveals information about the ordered token sequence (r1,r2,…)(r_1,r_2,…), enabling reconstruction of future outputs from traces alone. Insight. Detokenization exposes an output-aligned side channel. Each generated token is decoded in output order, so the resulting cache observations form a noisy representation of the generated token sequence itself. However, exploiting this leakage is non-trivial due to several inherent challenges associated with Prime+Probe: Challenge 1 (C1): Cache Collisions. The L1 cache of a consumer CPU has only about 64 cache sets that an attacker can monitor with Prime+Probe. Yet each set may correspond to an enormous number of memory addresses. For example, on a system with 8GB of RAM, over 100 million addresses can map to the same set. This massive collision space makes it extremely difficult to isolate and reliably monitor a single address. As a result, naively applying Prime+Probe to monitor D is impractical. Challenge 2 (C2): Low signal-to-noise ratio. In the L1 cache, the timing difference between a hit and a miss can be only a few cycles, making measurements highly sensitive to noise. OS activity and scheduling interference further reduce signal clarity. Since our attacker operates in a single-shot setting (the generated token keeps changing), averaging across repeated measurements (as done in other works) is not possible. Challenge 3 (C3): Coarse spatial resolution. The number of L1 cache sets N is small relative to the vocabulary size |V||V|. Because Prime+Probe observes activity only at cache-set granularity, the mapping from tokens to sets is many-to-one. Multiple tokens may therefore map to the same cache set, creating aliasing and ambiguity in reconstruction. To make Prime+Probe effective despite these limitations, we address C1 by performing Prime+Probe at the moment a token is about to be decoded. By narrowing the probe window, we eliminate a significant number of collisions that occur due to other processes. We accomplish this with an auxiliary side channel based on Flush+Reload, which is used to detect when the victim invokes the decode function, upon which the spy process triggers a Prime+Probe measurement to capture the resulting cache activity (§4.2). To address C2, we characterize the timing behavior of the decode routine and use it to choose when probing begins and the delays between Prime+Probe steps. This improves overlap with the victim’s token-dependent accesses and yields more stable measurements (§4.3). Finally, to mitigate the ambiguity introduced by C3, we employ a language model-based reconstruction method that translates noisy cache traces into semantically meaningful token sequences (§4.4). 3.3. Attack Workflow At a high level, the attack has four steps: (1) wait for the LLM to be prompted, (2) detect when the next generated token is about to be decoded using Flush+Reload (Section 4.2), (3) collect cache traces for the current token using Prime+Probe (section 4.3, repeat steps 2-3 for the entire response, (4) translate traces into text using a predictive model (Section 4.4). To realize this attack, the adversary must first obtain the predictive model used for reconstruction. We therefore divide the attack into two phases, illustrated in Figure 2: a profiling phase, in which the adversary learns the mapping from cache traces to text for a specific long-lived server instance, and an exploitation phase, in which the learned model is used to reconstruct future outputs from the same instance. Phase I: Profiling. The adversary first interacts with the local LLM service through its exposed API and issues its own prompts, causing the model to generate tokens whose ground-truth text is known to the adversary. In parallel, the adversary monitors decode activity using Flush+Reload and collects a cache trace using Prime+Probe for each generated token. This produces a labeled dataset that maps generated tokens to their corresponding cache traces. The adversary then trains a reconstruction model on this dataset. As shown in Section 5.4, profiling can be performed rapidly using only 250 targeted queries, or using approximately 7,650 ordinary conversational queries to obtain an equivalent profile when less distinctive interactions are desired. Phase I: Exploitation. After profiling, the adversary passively monitors the same server instance while it serves other users or applications. The adversary again uses Flush+Reload to detect decode invocations and, on each detection, performs a Prime+Probe measurement to capture token-level cache activity. Repeating this over the full response yields a sequence of cache traces, which is then fed to the trained reconstruction model to recover the generated text. Figure 2. Attack workflow illustrating the profiling and exploitation phases and their 4 steps. During profiling, the adversary induces generation to collect traces covering common tokens and trains a predictive model; during exploitation, it uses this model to reconstruct future conversations. In the next section, we will carefully detail how we designed and implemented Steps 2–4. 4. Attack Implementation 4.1. LLM Prompting (step 1) During exploitation (Phase I), the attacker simply proceeds to Step 2 and waits for a user or application to prompt the target LLM server. During profiling (Phase I), the attacker instead actively queries the server to obtain traces paired with ground-truth response tokens. We consider two profiling approaches. In targeted profiling, the attacker asks the model to repeat selected token sequences, providing controlled token coverage and multiple traces per token with few queries. For example, we use queries of the form “repeat the following sequence 5 times: ⟨ of 10 tokens⟩ ”. Alternatively, in benign profiling, the attacker issues ordinary conversational queries and collects traces from the tokens that naturally occur in the responses. As shown in Section 5.4, targeted profiling achieves strong reconstruction with only 250 queries, while benign profiling reaches comparable performance using a larger number of ordinary interactions. 4.2. Detecting an Imminent Token (step 2) In this step, we determine when a token is about to be decoded using D in order to probe the cache at the right moment. We do so by detecting when the decode routine is executed. Building on prior work (Yarom and Falkner, 2014), we use an auxiliary side channel based on the Flush+Reload technique over shared libraries. Since tokenizer implementations are loaded as shared libraries, their instruction pages are shared across processes, enabling reliable detection of decode execution across all evaluated frameworks (Figure 1). To set up this ‘trigger’ side channel, the adversary first identifies the tokenizer library used by the victim and the address of its decode routine. This does not require knowledge of the victim’s model or inference configuration. Common tokenizer implementations are typically open-source or publicly distributed and loaded through shared executable pages, as is standard on modern operating systems. The adversary can therefore monitor candidate decode routines while issuing prompts to the local service; the routine whose Flush+Reload activity correlates with generated output reveals the active tokenizer implementation. Once identified, the routine can be analyzed offline using standard tools such as gdb or readelf. For example, in Llama.cpp, the adversary may locate the symbol llama_detokenize at a fixed offset within the shared object file.22 2 This holds for version 0.3.16 of the Llama.cpp Python binding library, available at https://github.com/abetlen/llama-cpp-python The adversary then maps the shared library into its own address space (e.g., via mmap or dlopen) to obtain the base virtual address, computes the target address, and monitors it using Flush+Reload. Concretely, the attacker repeatedly flushes the target cache line using clflush and measures its reload time; when the victim executes the decode function, the line is brought back into the cache, resulting in a significantly lower access latency that serves as a trigger signal. This process is unaffected by ASLR since the relevant code remains physically shared across processes. We implement the detection phase using a widely adopted side-channel toolkit (Yarom, 2016). The target address is monitored in a tight loop with minimal pauses to ensure high temporal resolution. Since Flush+Reload operates at cache-line granularity, the signal remains localized, improving the signal-to-noise ratio (Yarom and Falkner, 2014; Rauscher et al., 2025). Experiment. To evaluate the detection performance, we simulate decode invocations at random intervals of 10–30 ms, reflecting typical token-generation delays. Over 1.2 million invocations, an attacker process continuously monitors the decode function and achieves a 97.66% true positive rate with zero false positives, demonstrating high reliability. 4.3. Capturing a Token’s Cache Trace (step 3) If a decode event is detected from step 2, a token is about to be decoded. At this point, the attacker captures a trace of the decode-table lookup in the cache. Since the decode table itself is not shared between processes, Flush+Reload cannot be used to monitor its token-dependent accesses. We therefore use Prime+Probe. When the decode of token rir_i is detected, we use Prime+Probe to monitor all N=64N=64 sets of the L1 cache, obtaining one trace (ti∈ℕ64t_i ^64) of access latencies. Although the attacker can reliably detect the invocation of the decode function, the precise timing of the table lookup within D remains unobservable. Therefore, through an offline analysis, the adversary optimizes the Prime+Probe measurement using high-resolution rdtsc timing. In our desktop Llama.cpp setup, for example, we found that the ideal time window is to probe from 88 μ after the trigger event for a total of 1515 μ . This delay remains stable across models within the same framework, such as Phi and Llama-3. We also experimented with applying Prime+Probe to the LLC, but found it impractical for this leakage source. Unlike the 64-set L1 cache, the LLC is orders of magnitude larger and substantially slower to probe (Liu et al., 2015; Rauscher et al., 2025). Moreover, the decode table spans a large memory region whose entries are distributed broadly across the LLC, requiring the attacker to monitor a large number of cache sets. Covering this set space within the short decode window was therefore not feasible. Figure 3 shows representative single probe traces for two tokens, illustrating how different decode operations induce distinct cache-set traces. We briefly note several implementation details that are important for obtaining stable measurements. We construct eviction sets covering all L1 cache sets using virtual addresses that map to distinct indices, with each set represented by a small group of congruent addresses. L1 Prime+Probe measurements are inherently noisy due to hardware prefetching, limited cache capacity, and self-interference. We found that existing toolkits such as Mastik (Yarom, 2016) do not provide sufficiently stable measurements in this regime. Instead, we use a modified version of CacheSC (Haller, 2020), which offers finer control over memory access patterns. In this implementation, eviction sets are traversed as randomized linked lists to avoid predictable access patterns and reduce both hardware prefetching effects and self-evictions, significantly improving signal quality. Overall, this procedure yields one trace tit_i per decoded token, forming the trace sequence (t1,t2,…)(t_1,t_2,…) for the entire generated response. Figure 3. Example cache traces collected during the decode operation of two tokens. Each bar shows the average access latency of a cache set over 10 repetitions. Figure 4. The trace-to-text reconstruction pipeline. Each trace in the sequence is first encoded into an embedding and assigned to a cluster learned during the profiling phase. The trace is then replaced with the symbol corresponding to that cluster, producing a sequence of symbols. Finally, this symbol sequence is passed to a language model trained to reconstruct the original tokens. Following prior work, we use separate models for the first segment (LLMA) and subsequent segments (LLMB). 4.4. Text Inference via Predictive Model (step 4) After collecting traces (t1,t2,…)(t_1,t_2,…), the adversary’s final step is to reconstruct the original response tokens (r1,r2,…)(r_1,r_2,…). This is challenging because thousands of tokens are compressed into just 64 observable cache sets, leading to severe collisions that make direct trace-to-token recovery infeasible (C3). The problem is further compounded by timing noise and limited measurement resolution (C1, C2). Crucially, however, these collisions are not random: they are stable and structured. Using clustering, we map groups of tokens with similar trace patterns to shared symbols. This converts the sequence of numerical traces into a symbolic sequence that serves as a coarse representation of (r1,r2,…)(r_1,r_2,…). Although lossy, this symbolic sequence preserves substantial linguistic structure, which is sufficient for us to train a language model to reconstruct the original text. An overview of our reconstruction pipeline is shown in Figure 4. Insight. Although individual Prime+Probe traces are ambiguous because of heavy collisions, this ambiguity is reduced when traces are viewed as a sequence and constrained by the fact that they must correspond to coherent language. We now describe how this pipeline is instantiated in practice, focusing on (i) mapping traces to symbolic tokens, and (i) reconstructing text from the resulting symbol sequences. 4.4.1. Trace Symbolization As a preliminary step, we evaluate whether individual traces can be mapped directly to tokens. We train a multilayer perceptron (MLP) classifier to predict token identifiers from raw latency vectors. The classifier achieves very low accuracy (e.g., below 1% top-1), indicating that individual traces provide weak token-level information due to cache-set aliasing and measurement noise. This motivates the use of an intermediate representation that groups traces with a similar structure. Each trace tit_i is represented as a 64-dimensional latency vector, one value per monitored L1 cache set. We normalize these vectors and map them to a normalized embedding space using a lightweight MLP encoder trained with a supervised-contrastive objective (Khosla et al., 2020), where traces of the same token are treated as positives. We then compute one centroid per token by averaging its profiling-trace embeddings and cluster the token centroids into K groups using K-means with cosine similarity (Lloyd, 1982). We learn an embedding before clustering rather than applying K-means directly to raw traces, which are noisy and overlap substantially in the original latency space. Using token-level supervision available during profiling, the encoder learns to group traces of the same token and separate those of different tokens, improving cluster separation and downstream symbolization. Each cluster defines a symbolic token sℓ∈Ss_ ∈ S, where S=s1,…,sKS=\s_1,…,s_K\. During symbolization, each trace is assigned to its nearest cluster center and replaced by the corresponding symbol, producing a symbolic sequence that captures the coarse structure of the underlying token sequence. We use K=64K=64, which balances clustering fidelity and symbol diversity (Appendix F). To integrate these symbols into the reconstruction model, we extend the tokenizer vocabulary with K synthetic entries of the form ⟨SYMk⟩ _k , one per cluster, following prior work (Weiss et al., 2024). Each is assigned a unique token ID appended to the base vocabulary, allowing symbolic sequences to be processed through the model’s standard embedding layer. 4.4.2. Semantic Reconstruction Given a symbolized trace sequence (s1,s2,…)(s_1,s_2,…), we reconstruct the corresponding response tokens (r1,r2,…)∈V∗(r_1,r_2,…)∈ V^* by treating the task as sequence-to-sequence translation from symbolic tokens to natural language using Flan-T5-XL (Chung et al., 2024). We follow Weiss et al. (Weiss et al., 2024), who observe that the first sentence of LLM responses often reveals the main topic and facilitates reconstruction of subsequent content. Accordingly, they employ two separate models for staged reconstruction, a design we adopt. Our contribution instead lies in extracting informative discrete symbol sequences from noisy microarchitectural traces. We split each response into 32-token segments R=(R0,R1,…)R=(R_0,R_1,…). LLMALLM_A reconstructs the first segment R0R_0 from its symbol sequence alone. For j>0j>0, LLMBLLM_B reconstructs segment RjR_j conditioned on the symbol sequence and the previous segment text. During training, this context is the ground-truth previous segment Rj−1R_j-1; during inference, it is the model prediction R^j−1 R_j-1. LLMALLM_A is prompted with the symbol sequence alone, while LLMBLLM_B is prompted with both the previous segment text and the current symbol sequence. Both models are trained with teacher-forced cross-entropy loss. Although symbolization is many-to-one, reconstruction remains effective because the model exploits sequential structure and contextual conditioning to resolve locally ambiguous symbols (Loshchilov and Hutter, 2017). Additional training details are provided in Appendix E. 5. Evaluation In this section, we outline the evaluation setup. Then we will explore the fidelity of the reconstruction attack along three primary dimensions: generality, robustness, and cost-effectiveness. 5.1. Experiment Setup Environment Hardware. To evaluate generality, we conduct experiments on two systems: a laptop and a desktop, both running Ubuntu 22.04 LTS. The laptop uses an Intel® Core i7-8650U CPU @ 1.90 GHz with a 32 KB L1 cache (8-way), 256 KB L2 cache (4-way), and 8 MB L3 cache (16-way). The desktop uses an 11th Gen Intel® Core™ i7-11700K CPU @ 3.60 GHz with a 48 KB L1 data cache (12-way), 32 KB L1 instruction cache (8-way), 512 KB L2 cache (8-way), and 16 MB L3 cache (16-way), and is additionally equipped with NVIDIA RTX 3090 and RTX 3080 GPUs (CUDA 12.2). Datasets & Training. We use three publicly available LLM-generated datasets: Code-Alpaca (Chaudhary, 2023), UltraChat (Ding et al., 2023), and ChatDoctor (Li et al., 2023), covering programming, medical queries, financial advice, and general knowledge. For multi-turn datasets, we retain only the first LLM response. Each dataset is randomly split into training, validation, and test sets using an 80%/10%/10% ratio, with standard deduplication (Lee et al., 2021; Brown et al., 2020; Chowdhery et al., 2023). Further preprocessing details are provided in Appendix C. Our evaluation additionally uses cache traces collected with the Prime+Probe procedure described in §4.3. For each token, we collect 50 traces from repeated executions of the decode routine, split into 30 profiling traces for training and 20 held-out traces for evaluation. Thus, reconstruction is evaluated only on traces unseen during profiling. For reconstruction, we fine-tune Flan-T5-XL for 5 epochs to obtain LLMALLM_A and LLMBLLM_B across multiple settings. Training is performed on an NVIDIA RTX 6000 Pro GPU and takes up to 6 hours for LLMALLM_A and 4 days for LLMBLLM_B. Metrics. We evaluate natural-language and code outputs separately, as reconstruction quality is captured differently for each. For UltraChat and ChatDoctor, we report normalized character-level Edit Distance (ED), where lower is better, ROUGE-1 F1 (Lin, 2004) for unigram overlap, and cosine similarity ϕφ between Sentence-Transformers all-MiniLM-L6-v2 embeddings (Reimers and Gurevych, 2019), where ϕ∈[−1,1]φ∈[-1,1] and higher values indicate stronger semantic similarity. We also use GPT-4.1-mini as an LLM-based judge and report Attack Success Rate (ASR) as the fraction of samples judged semantically equivalent, following prior work on LLM-based evaluation (Gu et al., 2024; Zheng et al., 2023). For Code-Alpaca, lexical and embedding-based metrics do not reliably capture functional correctness. We therefore use the same judge to assess whether reconstructed and reference snippets implement the same functionality, allowing benign differences such as variable renaming, formatting, or alternative correct implementations (Tong and Zhang, 2024; Crupi et al., 2025). Judge prompts are provided in Appendix Figure 8. Experiments. We evaluate the full reconstruction pipeline across multiple configurations, varying the target model between Phi-3-mini (Abdin et al., 2024), which uses a 32k-token vocabulary, and Llama-3 (Grattafiori et al., 2024), which uses a 128k-token vocabulary. We further vary the tokenization framework (Llama.cpp and HuggingFace Transformers), hardware platform (laptop and desktop), and dataset (UltraChat, Code-Alpaca, and ChatDoctor). For each configuration, each of the reconstruction models is trained on a disjoint training split and evaluated on unseen traces and responses, reporting results for both first-segment and full-response reconstruction. 5.2. Attack Generality Table 1. Reconstruction performance for textual datasets, frameworks, hardware platforms, and target models. All metrics are reported as mean ± standard deviation. Higher is better for all metrics except ED (↓ ). Dataset Framework Hardware Target First Segments Full Paragraphs ASR Φ R1-F1 ED ↓ ASR Φ R1-F1 ED ↓ UltraChat Llama.cpp Laptop Phi-3-mini 57.51% 69.24% ± 31.59% 77.25% ± 21.80% 77.97% ± 20.63% 85.15% 86.68% ± 14.19% 82.70% ± 9.69% 82.96% ± 9.68% Llama-3 39.71% 54.53% ± 33.54% 63.99% ± 23.96% 65.72% ± 22.18% 72.03% 81.22% ± 15.67% 72.56% ± 10.28% 72.08% ± 10.37% Desktop Phi-3-mini 61.55% 71.62% ± 30.98% 78.72% ± 21.51% 79.35% ± 20.32% 87.42% 87.52% ± 13.80% 83.02% ± 9.54% 83.31% ± 9.56% Llama-3 44.52% 59.41% ± 33.28% 69.32% ± 23.60% 70.18% ± 22.10% 74.78% 83.19% ± 15.12% 76.52% ± 10.21% 76.09% ± 10.40% HuggingFace Laptop Phi-3-mini 58.77% 69.43% ± 31.18% 75.65% ± 22.18% 77.05% ± 20.66% 86.11% 86.38% ± 14.04% 80.23% ± 9.69% 80.89% ± 9.59% Llama-3 25.50% 40.08% ± 33.26% 51.18% ± 25.92% 54.21% ± 22.90% 56.68% 76.51% ± 16.99% 64.78% ± 11.48% 62.89% ± 11.60% Desktop Phi-3-mini 55.22% 66.58% ± 32.70% 74.21% ± 23.59% 75.40% ± 21.86% 84.04% 85.81% ± 14.51% 80.82% ± 10.17% 81.11% ± 10.14% Llama-3 43.02% 57.70% ± 33.45% 67.67% ± 23.76% 68.87% ± 22.23% 73.26% 82.55% ± 15.22% 75.17% ± 10.18% 74.84% ± 10.38% ChatDoctor Llama.cpp Laptop Phi-3-mini 84.67% 84.38% ± 23.27% 85.17% ± 19.52% 86.74% ± 17.67% 90.08% 75.25% ± 15.17% 63.89% ± 12.62% 66.28% ± 12.68% Llama-3 48.67% 56.40% ± 27.75% 62.29% ± 22.67% 65.56% ± 20.50% 78.60% 67.97% ± 17.40% 66.37% ± 14.09% 67.05% ± 14.16% Desktop Phi-3-mini 63.89% 64.00% ± 29.22% 62.02% ± 25.86% 62.71% ± 22.43% 91.27% 74.24% ± 17.35% 70.55% ± 14.22% 71.01% ± 13.69% Llama-3 51.58% 59.14% ± 28.41% 65.53% ± 23.52% 68.27% ± 21.19% 81.24% 69.74% ± 17.76% 69.08% ± 14.62% 69.60% ± 14.57% HuggingFace Laptop Phi-3-mini 66.98% 67.62% ± 26.56% 69.12% ± 22.10% 72.44% ± 19.73% 92.85% 75.97% ± 16.54% 73.76% ± 13.10% 75.56% ± 12.65% Llama-3 34.23% 47.50% ± 27.93% 52.21% ± 25.55% 57.06% ± 22.33% 59.76% 61.02% ± 17.72% 56.10% ± 16.06% 56.30% ± 16.20% Desktop Phi-3-mini 67.26% 68.80% ± 26.76% 72.26% ± 22.14% 74.70% ± 19.80% 92.80% 76.62% ± 16.67% 75.40% ± 13.60% 76.56% ± 13.20% Llama-3 51.85% 59.59% ± 27.97% 65.95% ± 22.38% 68.38% ± 20.49% 80.61% 69.73% ± 17.61% 69.11% ± 14.26% 69.72% ± 14.30% Table 2. Code-Alpaca reconstruction performance (ASR) for first-segment and full-output reconstruction. Framework Hardware Target First Full Llama.cpp Laptop Phi-3-mini 90.17% 95.87% Llama-3 50.13% 49.43% Desktop Phi-3-mini 87.65% 90.56% Llama-3 81.55% 86.86% HuggingFace Laptop Phi-3-mini 85.19% 88.44% Llama-3 64.69% 71.35% Desktop Phi-3-mini 84.92% 89.71% Llama-3 79.19% 84.72% In this section, we evaluate the attack’s performance in reconstructing both the initial segment and full paragraphs across all configurations. We distinguish between first-segment and full-response reconstruction, as the initial portion often reveals the core confidential topic. Attack Examples - Ultrachat Judge: Success ϕ:1.00φ:1.00 R1: 1.001.00 ED: 0.000.00 Ref: Yes, incorporating daily exercise into your routine can improve your mental health in several ways. Exercise can help reduce symptoms of depression and anxiety Pred: Yes, incorporating daily exercise into your routine can improve your mental health in several ways. Exercise can help reduce symptoms of depression and anxiety Judge: Success ϕ:0.835φ:0.835 R1: 0.700.70 ED: 0.2960.296 Ref: There are several types of therapy that are effective for treating anxiety and depression: 1. Cognitive Behavioral Therapy (CB Pred: There are several types of therapy that are effective for treating anxiety and depression disorders (ADHD) by combining counseling and therapy Judge: Success ϕ:0.699φ:0.699 R1: 0.8370.837 ED: 0.1530.153 Ref: Both cardio and strength training can be effective in weight loss strategies. Cardio exercises such as running, cycling, and swimming can help Pred: Cross-training and strength training can be effective in weight loss surgery. Cardio exercises such as running, cycling, and swimming often help Judge: Success ϕ:0.451φ:0.451 R1: 0.6250.625 ED: 0.3360.336 Ref: Fibromyalgia and Chronic Fatigue Syndrome (CFS) share some common symptoms, such as fatigue, sleep problems, Pred: Cyanobacteria and fungi do not always and everywhere share some common symptoms, such as fatigue, sleep problems, Judge: Failure ϕ:0.532φ:0.532 R1: 0.6520.652 ED: 0.2870.287 Ref: Studies have shown that drinking beer in moderation may have some cardiovascular health benefits, particularly for those at risk of heart disease. Pred: Studies have shown that athletes eating disorders often may have some cardiovascular health benefits, particularly at the intermediate levels of heart disease. Figure 5. Examples of successful and unsuccessful attacks on R0R_0 in UltraChat. The full results are presented in Table 1 for textual datasets and in Table 2 for code datasets, with real reconstruction examples in Figure 5. Across all settings, reconstruction achieves high semantic fidelity despite ambiguous token-level signals. For full paragraphs, UltraChat reaches ASR of ∼ 56–87% with semantic similarity ϕφ of ∼ 76–87%, while ChatDoctor achieves substantially higher ASR of ∼ 78–93% with ϕφ of ∼ 61–76%. Despite weak per-token signals, reconstructions often preserve subtopics and local structure even when individual words are incorrect. This semantic robustness stems from sequence-level modeling: although individual symbols are noisy and ambiguous, the model leverages context across the sequence to resolve uncertainty, enabling accurate semantic reconstruction even when lexical similarity degrades. To further characterize reconstruction fidelity beyond broad semantic recovery, we examine the fraction of outputs achieving very high semantic similarity (ϕ≥0.9φ≥ 0.9). For first-segment reconstruction, this rate reaches up to 62.92%62.92\% on ChatDoctor and 44.62%44.62\% on UltraChat. Even for full responses, up to 58.48%58.48\% of UltraChat reconstructions achieve ϕ≥0.9φ≥ 0.9. These results show that the attack can recover outputs with high fidelity, rather than merely identifying their broad topic. Appendix G provides the full breakdown. Insight. Semantic recovery makes the attack effective even without exact token inference, while the high-fidelity results show that the leakage can extend well beyond topic-level information to closely reconstructed outputs. Performance is consistent across hardware platforms and inference frameworks, indicating that the attack does not depend on specific microarchitectural properties. Instead, it relies on stable decode-table access patterns within a given deployment, together with effective profiling to learn the corresponding mappings. Performance differences are primarily driven by the target model and dataset. Llama consistently underperforms Phi, which we attribute to its larger vocabulary (×4× 4) and the resulting increase in cache-set collisions. Additionally, more structured datasets such as ChatDoctor and Code-Alpaca yield higher performance than more diverse datasets like UltraChat, suggesting that constrained token distributions reduce reconstruction ambiguity. 5.3. Attack Robustness All experiments so far use real cache traces and therefore already include natural measurement noise. To further study robustness, we inject additional synthetic noise, with probability p, into the symbolic token sequences produced by the clustering stage. Specifically, we introduce deletions, insertions, and substitutions in the clustering output. In our reconstruction pipeline, deletions correspond to false negatives in the auxiliary detection side channel, where a decode event is missed and no trace is collected. Insertions correspond to false positives, where a spurious cache hit is detected despite no true decode event. Substitutions represent clustering misclassifications, where a collected cache trace is assigned the wrong symbolic token. This form of synthetic corruption is commonly used in prior side-channel reconstruction work to evaluate robustness to measurement errors (Gao et al., 2025; Yuan et al., 2022; Zhang et al., 2024b). For each value of p, we evaluate our base reconstruction model LLMALLM_A, trained on standard UltraChat traces collected on the laptop using Llama.cpp with Phi-3 as the target model. The model is trained only on the original, uncorrupted traces. During evaluation, each token in the clustering output is independently corrupted with probability p, with the corruption type chosen uniformly among deletion, insertion, and substitution. This allows us to systematically measure how reconstruction quality degrades as noise increases. Figure 6. Robustness to additional noise injected into the reconstruction pipeline. We report, for each p, the base ASR and the rate of high-fidelity predictions with ϕ≥0.9φ≥ 0.9 for both hardware settings. As shown in Figure 6, performance gradually degrades as p increases. Even at p=0.15p=0.15, LLMALLM_A still attains an ASR of ∼30% 30\%, with roughly 10%10\% of reconstructions achieving high semantic fidelity (ϕ>0.9φ>0.9). These results show that reconstruction remains robust under substantial injected noise. 5.4. Query Performance Tradeoff The profiling phase is critical to the reconstruction attack, as it establishes the mapping between cache activity and output tokens. In practice, profiling presents a tradeoff between the number of queries and how distinctive they are. We therefore evaluate two approaches: targeted profiling, which deliberately elicits selected tokens with few queries, and benign profiling, which uses only ordinary conversational queries at the cost of a larger budget. We evaluate this tradeoff using the laptop, UltraChat, Llama.cpp, and Phi-3 setting. In targeted profiling, the attacker issues queries of the form “repeat the following sequence 5 times: ⟨ of 10 tokens⟩ ”, obtaining five traces per selected token. Tokens are chosen by frequency in the UltraChat training split. For each targeted-query budget (QtQ_t), we construct an equivalent profile using ordinary UltraChat-style queries until they provide the same profiled token set and trace coverage. Figure 7 reports the resulting ASR, with the corresponding benign-query budget (QbQ_b) shown on the upper axis. Figure 7. ASR as a function of targeted and equivalent benign profiling query budgets on Phi-3-mini. Targeted profiling is highly query-efficient: with only Qt=250Q_t=250 queries, the attack exceeds 55% ASR and completes within roughly 6 minutes of standard inference on the tested hardware. Distinctive repetition queries, however, are not required. An equivalent profile can be obtained with approximately Qb=7,650Q_b=7,650 ordinary conversational queries, requiring roughly 3 hours and achieving about 53% ASR. With Qb=10,950Q_b=10,950 benign queries, ASR reaches approximately 56%, close to the unlimited-profile baseline of 57.51%. Further increases provide little additional benefit, with performance remaining around 53–56%. These results show that profiling can be adapted to the attacker’s constraints: targeted queries enable rapid profiling, while ordinary conversational queries retain near-baseline reconstruction performance with a larger budget. 5.5. Hardware Evaluation To evaluate the attack on recent hardware, we repeat the first-segment evaluation on a 13th Gen Intel Core i9-13950HX using Llama.cpp with Phi-3-mini and Llama-3 on UltraChat. Modern processors employ hardware prefetchers that can introduce additional cache accesses, interfering with cache-based side-channel measurements (Van Bulck et al., 2018; Wang et al., 2019). As shown in Table 3, performance degrades relative to our earlier results (Table 1), but the attack remains effective, demonstrating that the leakage persists on modern Intel hardware despite these effects. Table 3. Reconstruction performance (first-segments) on a 13th Gen Intel CPU. Target ASR ϕ>0.5 φ>0.5 R1-F1 ED ↓ Phi-3-mini 38.40% 52.12% 56.97% 61.07% Llama-3 31.97% 46.86% 53.87% 57.97% 5.6. End-to-End Attack on OpenClaw So far, our evaluation relied on dataset-aligned traces, where cache measurements were collected and matched to pre-existing text corpora. While this isolates the reconstruction pipeline, it does not capture a fully realistic deployment. We now evaluate the attack end-to-end on a live system by performing profiling, training, and reconstruction directly on an OpenClaw agent (OpenClaw Foundation, ) running a local Phi-3-mini model (Abdin et al., 2024), without any synthetic alignment. OpenClaw is a general-purpose open-source LLM agent framework for local deployment, enabling persistent assistants that manage personal workflows and interact with local resources, and is among the most popular such systems by GitHub stars (Figure 1). We use a subset of UltraChat prompts (n=25,000)(n=25,000) as inputs to the agent, issuing them and collecting traces during real execution. We evaluate reconstruction on the first response segments only, as these are sufficient to recover the main topic of the output, as discussed in Section 5.2. This reflects a practical deployment in which an LLM-based agent processes user queries over time. We report reconstruction performance using ASR and mean semantic similarity ϕφ. Since OpenClaw relies on Llama.cpp for local inference (Figure 1), we compare against the corresponding controlled setting (Llama.cpp, Phi, Desktop, UltraChat), which achieves 61.55% ASR and 71.62% ϕφ (± 30.98%). On OpenClaw, the attack achieves 30.12% ASR with a mean ϕφ of 42.23%±20.28%42.23\%± 20.28\%. Performance degrades due to additional end-to-end noise, including timing variability and imperfect alignment. Nevertheless, the attack remains effective, showing that reconstruction transfers to a real-world deployment. 6. Mitigation Strategies In this section, we discuss potential mitigations and their practical limitations in the context of our threat model. Decode Table Randomization. As described in Section 3.1, our attack relies on a stable mapping between token identifiers and their memory footprint during the lifetime of the victim process. A natural mitigation is therefore to randomize the in-memory layout of the decode table during execution, for example, by shuffling token placements or permuting internal indexing structures. This changes the mapping between token IDs and cache sets, invalidating previously collected traces and disrupting the learned leakage model. However, an active adversary may re-profile the victim after each re-randomization event. Thus, randomization primarily increases the attack cost rather than eliminating the underlying leakage channel. Process Lifetime Reduction. Our reconstruction model is process-specific and does not transfer across independent instances due to ASLR, heap allocation differences, and randomized data structure layouts. Periodic restarts or short-lived workers can therefore limit the time available for profiling. However, frequent model initialization increases latency and reduces responsiveness. Moreover, this mitigation does not eliminate the leakage, as an adversary can re-profile each new instance. Microarchitectural and OS-level Defenses. Disabling SMT, such as Intel’s Hyper-Threading (Marr et al., 2002), prevents an attacker from sharing a physical core with the victim and therefore blocks L1 Prime+Probe (Tromer et al., 2010). However, disabling SMT incurs a significant performance cost (Section 3.1), making it unattractive for resource-constrained local LLM deployments. Cache partitioning, such as page coloring (Ye et al., 2014), and hardware mechanisms that randomize cache indexing or eviction (Qureshi, 2018) can also reduce the available signal, although profiling may partially adapt. These defenses are generally not enabled on consumer systems due to limited support and performance or deployment overhead (Mushtaq et al., 2020), making them more suitable for multi-tenant or high-assurance environments. 7. Related Works Privacy Attacks on Language Models. LLMs expose privacy risks at the application and network levels. Deployment optimizations such as KV-cache reuse across tokens or sessions have been exploited to infer user prompts and model outputs through fine-grained decoding timing (Song et al., 2024) or probing shared KV-cache entries in multi-tenant settings (Wu et al., 2025). At the network level, observing the length and structure of encrypted token streams can leak model outputs (Weiss et al., 2024). Other works show that adversarial queries can elicit hidden system prompts or reconstruct prior conversations, revealing sensitive context through repeated interaction (Hui et al., 2024; Yang et al., 2024; Chu et al., 2024; Debenedetti et al., 2024). Together, these studies highlight non-hardware side channels that persist even under strict access isolation. Hardware Side-Channel Attacks on Deep Learning. Hardware side channels have been used to infer neural-network inputs and outputs through power analysis, electromagnetic emanations, timing variations, or memory bus contention (Liu et al., 2023; Shukla et al., 2023). Other studies extract model architectures and weights, including layer parameters, connectivity, and numerical values (Gao et al., 2024; Batina et al., 2019; Horváth et al., 2024). These attacks exploit structured, data-dependent behavior in DNN execution. Cache-based attacks pursue similar goals. Prior work shows that cache activity can leak sensitive user inputs (Yuan et al., 2022; Zhang et al., 2024b; Yuan et al., 2021) or reconstruct model architectures and weights across deployment settings (Liu et al., 2024; Yan et al., 2020; Wang et al., 2022). Autoregressive LLMs, however, exhibit fundamentally different execution characteristics: they generate outputs token-by-token, rely on large vocabulary lookups, and induce input-dependent, non-repetitive memory access patterns. These properties make prior techniques, which assume static or highly regular execution, difficult to apply directly. Hardware Side-Channel Attacks on LLMs. Recent work has demonstrated hardware side-channel leakage from local LLM inference, but existing attacks rely on leakage sources that are present only under particular model or deployment conditions. Table 4 summarizes these requirements and contrasts them with ours. One line of work exploits shared model data, particularly token embeddings. Adiletta and Sunar (Adiletta and Sunar, 2025) use Flush+Reload on embedding vectors exposed through CUDA unified CPU/GPU memory to leak tokens and partially recover API keys, requiring a non-default CUDA memory configuration. Gao et al. (Gao et al., 2025) similarly monitor embedding-table accesses through shared model pages, requiring both the model data to be shared (e.g., through mmap or page deduplication) and the embedding lookup to execute on the CPU. When the model fits entirely in GPU memory, as is common in local inference, the embedding layer remains GPU-resident, and this leakage channel is absent. In contrast, our attack targets CPU-side detokenization after token generation, avoiding these model-data visibility and placement requirements altogether. Table 4. Comparison of deployment assumptions across local LLM side-channel attacks. "Special" denotes non-standard shared resources, while "standard" denotes commonly shared resources in default deployments. Model Assumptions System Assumptions Attack Weights Arch SMT Shared Resources IKWYS (Gao et al., 2025) CPU None None Model data; special Spill the Beans (Adiletta and Sunar, 2025) CPU None None Model data; special MoEcho-GPU (Ding et al., 2025) None MoE None GPU counters; special MoEcho-CPU (Ding et al., 2025) None MoE Yes Expert pages; special Ours None None Yes Code only; standard Another line of work focuses on specific model architectures. Ding et al. (Ding et al., 2025) show that MoE models leak expert activation patterns, enabling prompt inference and response reconstruction. Their attack variants additionally rely on specialized observability, such as GPU performance counters or shared expert data pages. More fundamentally, however, the leakage source is the MoE routing mechanism itself. As a result, the attack does not extend to standard dense models, such as common Llama-style deployments. In contrast, our attack targets detokenization, a model-agnostic step performed after each generated token. This different leakage source also creates a substantially weaker observation channel. Prior embedding attacks observe shared data at cache-line granularity (Adiletta and Sunar, 2025; Gao et al., 2025), while MoE attacks exploit large, structured expert-execution footprints (Ding et al., 2025). Network attacks similarly expose stable observables such as response size or latency (Weiss et al., 2024; Wu et al., 2025; Song et al., 2024). A detokenization event, by contrast, is short-lived and touches few cache lines. Prime+Probe further collapses many token-dependent accesses onto the same cache sets. Individual traces therefore do not directly reveal token identities. We overcome this by mapping noisy traces to stable symbolic representations and using language context to resolve the resulting ambiguity. Overall, prior attacks expose important leakage channels in local LLM inference, but their applicability is tied to either model-internal data exposure or architecture-specific execution behavior. To our knowledge, the decode table has not previously been examined as a leakage source. Our work shifts the attack surface to detokenization, a default component of the generation pipeline, enabling cache-based output reconstruction across a broader range of local LLM deployments than previously demonstrated. 8. Conclusion We presented a new cache-based attack that reconstructs the text generated by locally hosted LLMs by observing CPU cache activity during detokenization. By targeting the decode table, our attack avoids the deployment-specific assumptions required by prior work and instead exploits a leakage source that is present in default LLM inference pipelines. We showed how to combine Flush+Reload for decode detection, Prime+Probe for cache-trace capture, and a clustering-and-language-model pipeline for text reconstruction from noisy observations. Our findings identify detokenization as a practical and widespread leakage surface in local LLM serving and highlight the need for stronger isolation and defenses in privacy-sensitive deployments. 9. Acknowledgments The authors would like to thank Lital Badash from Microsoft for her help in managing the project. References Abdin et al. (2024) M. Abdin, J. Aneja, H. Awadalla, A. Awadallah, A. A. Awan, N. Bach, A. Bahree, A. Bakhtiari, J. Bao, H. Behl, et al. Phi-3 technical report: a highly capable language model locally on your phone. arXiv preprint arXiv:2404.14219. Cited by: §1, §5.1, §5.6. Adiletta and Sunar (2025) A. Adiletta and B. Sunar Spill the beans: exploiting cpu cache side-channels to leak tokens from large language models. arXiv preprint arXiv:2505.00817. Cited by: §1, §3.1, Table 4, §7, §7, footnote 1. Anand et al. (2023) Y. Anand, Z. Nussbaum, B. Duderstadt, B. Schmidt, and A. Mulyar GPT4All: training an assistant-style chatbot with large scale data distillation from gpt-3.5-turbo. GitHub. Note: https://github.com/nomic-ai/gpt4all Cited by: §1. Batina et al. (2019) L. Batina, S. Bhasin, D. Jap, and S. Picek \csi\\n\: Reverse engineering of neural network architectures through electromagnetic side channel. In 28th USENIX Security Symposium (USENIX Security 19), p. 515–532. Cited by: §7. Bhattacharyya et al. (2019) A. Bhattacharyya, A. Sandulescu, M. Neugschwandtner, A. Sorniotti, B. Falsafi, M. Payer, and A. Kurmus Smotherspectre: exploiting speculative execution through port contention. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, p. 785–800. Cited by: §3.1. Brown et al. (2020) T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, et al. Language models are few-shot learners. Advances in neural information processing systems 33, p. 1877–1901. Cited by: Appendix C, §1, §5.1. Chaudhary (2023) S. Chaudhary Code alpaca: an instruction-following llama model for code generation. GitHub. Note: https://github.com/sahil280114/codealpaca Cited by: §1, §5.1. Chowdhery et al. (2023) A. Chowdhery, S. Narang, J. Devlin, M. Bosma, G. Mishra, A. Roberts, P. Barham, H. W. Chung, C. Sutton, S. Gehrmann, et al. Palm: scaling language modeling with pathways. Journal of Machine Learning Research 24 (240), p. 1–113. Cited by: Appendix C, §1, §5.1. Chu et al. (2024) J. Chu, Z. Sha, M. Backes, and Y. Zhang Reconstruct your previous conversations! comprehensively investigating privacy leakage risks in conversations with gpt models. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, p. 6584–6600. Cited by: §7. Chung et al. (2024) H. W. Chung, L. Hou, S. Longpre, B. Zoph, Y. Tay, W. Fedus, Y. Li, X. Wang, M. Dehghani, S. Brahma, et al. Scaling instruction-finetuned language models. Journal of Machine Learning Research 25 (70), p. 1–53. Cited by: §4.4.2. Crupi et al. (2025) G. Crupi, R. Tufano, A. Velasco, A. Mastropaolo, D. Poshyvanyk, and G. Bavota On the effectiveness of llm-as-a-judge for code generation and summarization. IEEE Transactions on Software Engineering. Cited by: §5.1. Debenedetti et al. (2024) E. Debenedetti, G. Severi, N. Carlini, C. A. Choquette-Choo, M. Jagielski, M. Nasr, E. Wallace, and F. Tramèr Privacy side channels in machine learning systems. In 33rd USENIX Security Symposium (USENIX Security 24), p. 6848–6861. Cited by: §7. Deng et al. (2025) Z. Deng, Y. Guo, C. Han, W. Ma, J. Xiong, S. Wen, and Y. Xiang Ai agents under threat: a survey of key security challenges and future pathways. ACM Computing Surveys 57 (7), p. 1–36. Cited by: §1. Dettmers and Zettlemoyer (2023) T. Dettmers and L. Zettlemoyer The case for 4-bit precision: k-bit inference scaling laws. In International Conference on Machine Learning, p. 7750–7774. Cited by: §1, §2.2. Ding et al. (2023) N. Ding, Y. Chen, B. Xu, Y. Qin, Z. Zheng, S. Hu, Z. Liu, M. Sun, and B. Zhou Enhancing chat language models by scaling high-quality instructional conversations. External Links: 2305.14233 Cited by: §1, §5.1. Ding et al. (2025) R. Ding, T. Xu, X. Shen, A. A. Ding, and Y. Fei MoEcho: exploiting side-channel attacks to compromise user privacy in mixture-of-experts llms. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, p. 2159–2173. Cited by: §1, §3.1, Table 4, Table 4, §7, §7. Gao et al. (2024) Y. Gao, H. Qiu, Z. Zhang, B. Wang, H. Ma, A. Abuadbba, M. Xue, A. Fu, and S. Nepal Deeptheft: stealing dnn model architectures through power side channel. In 2024 IEEE Symposium on Security and Privacy (SP), p. 3311–3326. Cited by: §7. Gao et al. (2025) Z. Gao, J. Hu, F. Guo, Y. Zhang, Y. Han, S. Liu, H. Li, and Z. Lv I know what you said: unveiling hardware cache side-channels in local large language model inference. arXiv preprint arXiv:2505.06738. Cited by: Appendix C, §1, §3.1, §5.3, Table 4, §7, §7, footnote 1. Gast et al. (2023) S. Gast, J. Juffinger, M. Schwarzl, G. Saileshwar, A. Kogler, S. Franza, M. Köstl, and D. Gruss Squip: exploiting the scheduler queue contention side channel. In 2023 IEEE Symposium on Security and Privacy (SP), p. 2256–2272. Cited by: §3.1. Gerganov (2023) G. Gerganov Llama.cpp: inference of llama models in pure c/c++. Note: https://github.com/ggerganov/llama.cppAccessed: 2026 Cited by: §1, §1. Grattafiori et al. (2024) A. Grattafiori, A. Dubey, A. Jauhri, A. Pandey, A. Kadian, A. Al-Dahle, A. Letman, A. Mathur, A. Schelten, A. Vaughan, et al. The llama 3 herd of models. arXiv preprint arXiv:2407.21783. Cited by: §1, §5.1. Gruss et al. (2016) D. Gruss, C. Maurice, K. Wagner, and S. Mangard Flush+ flush: a fast and stealthy cache attack. In Detection of Intrusions and Malware, and Vulnerability Assessment: 13th International Conference, DIMVA 2016, San Sebastián, Spain, July 7-8, 2016, Proceedings 13, p. 279–299. Cited by: §2.3. Gu et al. (2024) J. Gu, X. Jiang, Z. Shi, H. Tan, X. Zhai, C. Xu, W. Li, Y. Shen, S. Ma, H. Liu, et al. A survey on llm-as-a-judge. The Innovation. Cited by: §5.1. Haller (2020) M. Haller Revisiting microarchitectural side-channels. Cited by: §4.3. Horváth et al. (2024) P. Horváth, D. Lauret, Z. Liu, and L. Batina SoK: neural network extraction through physical side channels. In Proceedings of the 33rd USENIX Conference on Security Symposium, p. 3403–3422. Cited by: §7. Hui et al. (2024) B. Hui, H. Yuan, N. Gong, P. Burlina, and Y. Cao Pleak: prompt leaking attacks against large language model applications. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, p. 3600–3614. Cited by: §7. Intel Corporation (n.d) Intel Corporation What Is Hyper-Threading?. Note: Online External Links: Link Cited by: §3.1. Jiang et al. (2023) A. Q. Jiang, A. Sablayrolles, A. Mensch, C. Bamford, D. S. Chaplot, D. de las Casas, F. Bressand, G. Lengyel, G. Lample, L. Saulnier, L. R. Lavaud, M. Lachaux, P. Stock, T. L. Scao, T. Lavril, T. Wang, T. Lacroix, and W. E. Sayed Mistral 7b. External Links: 2310.06825, Link Cited by: §1. Khosla et al. (2020) P. Khosla, P. Teterwak, C. Wang, A. Sarna, Y. Tian, P. Isola, A. Maschinot, C. Liu, and D. Krishnan Supervised contrastive learning. Advances in neural information processing systems 33, p. 18661–18673. Cited by: §4.4.1. Kwon et al. (2023) W. Kwon, Z. Li, S. Zhuang, Y. Sheng, L. Zheng, C. H. Yu, J. Gonzalez, H. Zhang, and I. Stoica Efficient memory management for large language model serving with pagedattention. In Proceedings of the 29th symposium on operating systems principles, p. 611–626. Cited by: §1, §2.2. Lee et al. (2021) K. Lee, D. Ippolito, A. Nystrom, C. Zhang, D. Eck, C. Callison-Burch, and N. Carlini Deduplicating training data makes language models better. arXiv preprint arXiv:2107.06499. Cited by: §5.1. Li et al. (2023) Y. Li, Z. Li, K. Zhang, R. Dan, S. Jiang, and Y. Zhang Chatdoctor: a medical chat model fine-tuned on a large language model meta-ai (llama) using medical domain knowledge. Cureus 15 (6). Cited by: §1, §5.1. Lin (2004) C. Lin Rouge: a package for automatic evaluation of summaries. In Text summarization branches out, p. 74–81. Cited by: §5.1. Liu et al. (2015) F. Liu, Y. Yarom, Q. Ge, G. Heiser, and R. B. Lee Last-level cache side-channel attacks are practical. In 2015 IEEE symposium on security and privacy, p. 605–622. Cited by: §3.1, §4.3. Liu et al. (2023) J. Liu, H. Homayoun, C. Fang, N. Miao, and H. Wang Side channel-assisted inference attacks on machine learning-based ecg classification. In 2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD), p. 1–9. Cited by: §7. Liu et al. (2024) Z. Liu, Y. Yuan, Y. Chen, S. Hu, T. Li, and S. Wang Deepcache: revisiting cache side-channel attacks in deep neural networks executables. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, p. 4495–4508. Cited by: §7. Lloyd (1982) S. Lloyd Least squares quantization in pcm. IEEE transactions on information theory 28 (2), p. 129–137. Cited by: §4.4.1. Loshchilov and Hutter (2017) I. Loshchilov and F. Hutter Decoupled weight decay regularization. arXiv preprint arXiv:1711.05101. Cited by: §4.4.2. Ma et al. (2023) X. Ma, G. Fang, and X. Wang Llm-pruner: on the structural pruning of large language models. Advances in neural information processing systems 36, p. 21702–21720. Cited by: §1, §2.2. Marr et al. (2002) D. T. Marr, F. Binns, D. L. Hill, G. Hinton, D. A. Koufaty, J. A. Miller, and M. Upton Hyper-threading technology architecture and microarchitecture.. Intel Technology Journal 6 (1). Cited by: §6. Mushtaq et al. (2020) M. Mushtaq, M. A. Mukhtar, V. Lapotre, M. K. Bhatti, and G. Gogniat Winter is here! a decade of cache-based side-channel attacks, detection & mitigation for rsa. Information Systems 92, p. 101524. Cited by: §6. [42] OpenClaw Foundation OpenClaw: your own personal ai assistant. any os. any platform.. Note: https://github.com/openclaw/openclawAccessed: 2026 Cited by: §1, §1, §5.6. Qureshi (2018) M. K. Qureshi CEASER: mitigating conflict-based cache attacks via encrypted-address and remapping. In 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), p. 775–787. Cited by: §6. Raiaan et al. (2024) M. A. K. Raiaan, M. S. H. Mukta, K. Fatema, N. M. Fahad, S. Sakib, M. M. J. Mim, J. Ahmad, M. E. Ali, and S. Azam A review on large language models: architectures, applications, taxonomies, open issues and challenges. IEEE access 12, p. 26839–26874. Cited by: §1. Rauscher et al. (2025) F. Rauscher, C. Fiedler, A. Kogler, and D. Gruss A systematic evaluation of novel and existing cache side channels. In Network and Distributed System Security Symposium (NDSS) 2025, Cited by: §2.3, §4.2, §4.3. Reimers and Gurevych (2019) N. Reimers and I. Gurevych Sentence-bert: sentence embeddings using siamese bert-networks. In Proceedings of the 2019 conference on empirical methods in natural language processing and the 9th international joint conference on natural language processing (EMNLP-IJCNLP), p. 3982–3992. Cited by: §5.1. Shukla et al. (2023) S. Shukla, M. Alam, S. Bhattacharya, P. Mitra, and D. Mukhopadhyay “Whispering mlaas”: exploiting timing channels to compromise user privacy in deep neural networks. IACR Transactions on Cryptographic Hardware and Embedded Systems, p. 587–613. Cited by: §7. Song et al. (2024) L. Song, Z. Pang, W. Wang, Z. Wang, X. Wang, H. Chen, W. Song, Y. Jin, D. Meng, and R. Hou The early bird catches the leak: unveiling timing side channels in llm serving systems. arXiv preprint arXiv:2409.20002. Cited by: §7, §7. Team (2026) O. Team Ollama official documentation. Note: Online External Links: Link Cited by: §1, §2.2. Tong and Zhang (2024) W. Tong and T. Zhang Codejudge: evaluating code generation with large language models. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, p. 20032–20051. Cited by: §5.1. Tromer et al. (2010) E. Tromer, D. A. Osvik, and A. Shamir Efficient cache attacks on aes, and countermeasures. Journal of Cryptology 23, p. 37–71. Cited by: §6. Van Bulck et al. (2018) J. Van Bulck, M. Minkin, O. Weisse, D. Genkin, B. Kasikci, F. Piessens, M. Silberstein, T. F. Wenisch, Y. Yarom, and R. Strackx Foreshadow: extracting the keys to the intel \sgx\ kingdom with transient \out-of-order\ execution. In 27th USENIX Security Symposium (USENIX Security 18), p. 991–1008. Cited by: §5.5. Walton (2019) S. Walton How Screwed is Intel without Hyper‑Threading?. Note: Online External Links: Link Cited by: §3.1. Wang et al. (2019) D. Wang, Z. Qian, N. Abu-Ghazaleh, and S. V. Krishnamurthy Papp: prefetcher-aware prime and probe side-channel attack. In Proceedings of the 56th Annual Design Automation Conference 2019, p. 1–6. Cited by: §5.5. Wang et al. (2022) H. Wang, S. M. Hafiz, K. Patwari, C. Chuah, Z. Shafiq, and H. Homayoun Stealthy inference attack on dnn via cache-based side-channel attacks. In 2022 Design, Automation & Test in Europe Conference & Exhibition (DATE), p. 1515–1520. Cited by: §7. Wang et al. (2024) L. Wang, C. Ma, X. Feng, Z. Zhang, H. Yang, J. Zhang, Z. Chen, J. Tang, X. Chen, Y. Lin, et al. A survey on large language model based autonomous agents. Frontiers of Computer Science 18 (6), p. 186345. Cited by: §1. Weiss et al. (2024) R. Weiss, D. Ayzenshteyn, G. Amit, and Y. Mirsky What was your prompt? a remote keylogging attack on \ai\ assistants. In 33rd USENIX Security Symposium (USENIX Security 24), p. 3367–3384. Cited by: §4.4.1, §4.4.2, §7, §7. Wolf et al. (2020) T. Wolf, L. Debut, V. Sanh, J. Chaumond, C. Delangue, A. Moi, P. Cistac, T. Rault, R. Louf, M. Funtowicz, et al. Transformers: state-of-the-art natural language processing. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, p. 38–45. Cited by: §1. Wu et al. (2025) G. Wu, Z. Zhang, Y. Zhang, W. Wang, J. Niu, Y. Wu, and Y. Zhang I know what you asked: prompt leakage via kv-cache sharing in multi-tenant llm serving. In Proceedings of the 2025 Network and Distributed System Security (NDSS) Symposium. San Diego, CA, USA, Cited by: §7, §7. Xu et al. (2025) D. Xu, H. Zhang, L. Yang, R. Liu, G. Huang, M. Xu, and X. Liu Fast on-device llm inference with npus. In Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1, p. 445–462. Cited by: §2.2. Yan et al. (2020) M. Yan, C. W. Fletcher, and J. Torrellas Cache telepathy: leveraging shared resource attacks to learn \dnn\ architectures. In 29th USENIX Security Symposium (USENIX Security 20), p. 2003–2020. Cited by: §7. Yang et al. (2024) Y. Yang, C. Li, Y. Jiang, X. Chen, H. Wang, X. Zhang, Z. Wang, and S. Ji PRSA: prompt stealing attacks against large language models. arXiv preprint arXiv:2402.19200. Cited by: §7. Yarom and Falkner (2014) Y. Yarom and K. Falkner \flush+ RELOAD\: a high resolution, low noise, l3 cache \side-channel\ attack. In 23rd USENIX security symposium (USENIX security 14), p. 719–732. Cited by: §2.3, §3.1, §4.2, §4.2, footnote 1. Yarom (2016) Y. Yarom Mastik: a micro-architectural side-channel toolkit. Australia. Cited by: §4.2, §4.3. Ye et al. (2014) Y. Ye, R. West, Z. Cheng, and Y. Li Coloris: a dynamic cache partitioning system using page coloring. In Proceedings of the 23rd international conference on Parallel architectures and compilation, p. 381–392. Cited by: §6. Yuan et al. (2024) Y. Yuan, R. Kong, Y. Li, and Y. Liu Wip: an on-device llm-based approach to query privacy protection. In Proceedings of the Workshop on Edge and Mobile Foundation Models, p. 7–9. Cited by: §2.2. Yuan et al. (2022) Y. Yuan, Q. Pang, and S. Wang Automated side channel analysis of media software with manifold learning. In 31st USENIX Security Symposium (USENIX Security 22), p. 4419–4436. Cited by: §3.1, §5.3, §7. Yuan et al. (2021) Y. Yuan, S. Wang, and J. Zhang Private image reconstruction from system side channels using generative models. In International Conference on Learning Representations, Cited by: §3.1, §7. Zhang et al. (2024a) S. Zhang, Y. Ma, L. Fang, H. Jia, S. D’Alfonso, and V. Kostakos Enabling on-device llms personalization with smartphone sensing. In Companion of the 2024 on ACM International Joint Conference on Pervasive and Ubiquitous Computing, p. 186–190. Cited by: §2.2. Zhang et al. (2024b) Z. Zhang, Z. Lai, and U. Parampalli R+ r: demystifying ml-assisted side-channel analysis framework: a case of image reconstruction. In 2024 Annual Computer Security Applications Conference (ACSAC), p. 393–409. Cited by: §3.1, §5.3, §7. Zheng et al. (2023) L. Zheng, W. Chiang, Y. Sheng, S. Zhuang, Z. Wu, Y. Zhuang, Z. Lin, Z. Li, D. Li, E. Xing, et al. Judging llm-as-a-judge with mt-bench and chatbot arena. Advances in neural information processing systems 36, p. 46595–46623. Cited by: §5.1. Appendix A Open Science We use publicly available models, frameworks, and datasets throughout this work, including Phi-3-mini, Llama-3, Llama.cpp, HuggingFace Tokenizers, UltraChat, ChatDoctor, and Code-Alpaca. We do not provide exploit artifacts or components that could directly enable misuse against real deployments. To support reproducibility, we present our code, reconstruction pipelines, and evaluation scripts at the following link: https://github.com/royweiss1/Detokenization-Leaks. Appendix B Ethical Considerations All experiments are conducted on local machines using open-source models and controlled datasets. No real user data or human subjects are involved. The identified vulnerabilities have been responsibly disclosed to relevant parties, including HuggingFace and Llama.cpp maintainers. Appendix C Data Cleaning To reduce redundancy in the training data, we applied an 8-gram deduplication procedure to the user prompts, following the approach adopted in PaLM and GPT-3 training (Brown et al., 2020; Chowdhery et al., 2023). A training sample is removed if its prompt shares its first 8 words with any previously seen prompt, or if more than 70% of its 8-grams overlap with those of any previously seen prompt. This deduplication criterion has also been employed in prior work (Gao et al., 2025). Additionally, we applied further cleaning to the UltraChat dataset to remove empty or generic responses (e.g., “As an AI, I can’t help with that”). See Table 5 for dataset statistics before and after filtering. Dataset Before After Cleaned (%) Code-Alpaca 121,959 98,540 18.8% ChatDoctor 112,165 96,084 14.3% UltraChat 577,747 358,545 37.9% Table 5. Dataset sizes before and after cleaning, with percentage removed. Appendix D LLM Prompts Suppose R0=R_0= “Based on the medical information you provided, here is an explanation of the results.” and R1=R_1= “The report indicates that the tiredness you feel is due to stress and recommends follow-up testing.” The training inputs take the form: Training Prompts LLMALLM_A (first segment) Translate the symbolic tokens to English. Symbolic Tokens: ⟨SYM12⟩⟨SYM7⟩⟨SYM31⟩⟨SYM4⟩⟨SYM18⟩⟨SYM12⟩⟨SYM3⟩… _12 \ _7 \ _31 \ _4 \ _18 \ _12 \ _3 \ … LLMBLLM_B (middle segment) Translate the symbolic tokens to English, given the context. Context (reconstructed): Based on the medical report you gave, here is an explanation of the diagnosis. Symbolic Tokens: ⟨SYM5⟩⟨SYM22⟩⟨SYM9⟩⟨SYM41⟩⟨SYM5⟩⟨SYM14⟩⟨SYM27⟩… _5 \ _22 \ _9 \ _41 \ _5 \ _14 \ _27 \ … Reconstruction Judge Prompt System Prompt (UltraChat): "You are a privacy-leakage evaluator for reconstructed responses from side-channel observations; judge whether the prediction reveals meaningful and accurate information about the reference rather than quality, and answer Yes if it captures the same topic, intent, structure, style, or key points even if partial or noisy, otherwise No; output only Yes or No." System Prompt (ChatDoctor): "You are a privacy-leakage evaluator for reconstructed medical responses from side-channel observations; judge whether the prediction reveals meaningful and accurate clinical information about the reference rather than quality or safety, and answer Yes if it reflects the same specific symptoms, conditions, diagnoses, treatments, medications, reasoning, or structured advice even if partial or noisy, otherwise No; output only Yes or No" System Prompt (Code-Alpaca): "You are a privacy-leakage evaluator for reconstructed code from side-channel observations; judge whether it reveals meaningful and accurate information about the original code rather than correctness, and answer Yes if it reflects the same general topic, structure, frameworks, APIs, algorithms, or templates even if partial or noisy, otherwise answer No; output only Yes or No." User Prompt: Reference: <Original> Prediction: <Reconstructed> Figure 8. LLM judge prompts for reconstruction evaluation. Appendix E Additional Modeling Details Trace preprocessing and representation. Each trace is represented as a 64-dimensional latency vector. We subtract the per-trace mean and apply feature-wise standardization over the profiling set. During training, batches are constructed by sampling token IDs and drawing multiple traces per token, producing multiple positives per token alongside cross-token negatives for contrastive learning. Clustering and symbolization. Following encoding, we compute a single centroid per token by averaging the embeddings of its profiling traces. We then cluster these centroids using K-means with cosine similarity. At inference, each trace is encoded and assigned to its nearest cluster center to obtain a symbolic token. This two-stage approach—encoding followed by K-means—consistently outperforms applying K-means directly to the raw traces, with particularly pronounced gains on lower-performing tokens (2× improvement on the worst-performing 10% of tokens). We attribute this to the encoder’s ability to suppress noise and amplify token-discriminative structure in the latent space. Clustering quality. We evaluate clustering quality on held-out traces (20 test traces and 30 training traces) by measuring, for each token, the fraction of its traces assigned to the same cluster as its centroid, then averaging across tokens. This yields a mean clustering accuracy of approximately 75% across all trace datasets. Reconstruction and decoding. Training examples for LLMBLLM_B pair the preceding segment text as context with the current symbol sequence and target text. Unless stated otherwise, decoding is performed with beam search (4 beams, no sampling, maximum generation length of 38 tokens). Appendix F K Ablation Study We sweep K∈1,16,32,48,64,128K∈\1,16,32,48,64,128\ on UltraChat (Llama.cpp, Desktop, Phi-3-mini), training a separate pipeline for each K on 100,000100,000 training samples and evaluating on 5,0005,000 held-out samples. As shown in Figure 9, K=1K=1 collapses to near-zero ASR, confirming the model cannot reconstruct text from an uninformative symbol alphabet. ASR rises sharply and peaks around K=48K=48–6464, then declines as larger K fragments the per-symbol training signal. K=48K=48 and K=64K=64 are within noise of each other; we use K=64K=64. Figure 9. Reconstruction fidelity across different numbers of symbol clusters K on UltraChat first-segment reconstruction. Appendix G High-Fidelity Reconstructions While the main evaluation characterizes reconstruction quality across the full test set, we additionally examine the upper end of the fidelity distribution. Table 6 reports the fraction of reconstructions with high semantic similarity (ϕ≥0.9φ≥ 0.9), high lexical overlap (R1 ≥0.9≥ 0.9), and low normalized edit distance (ED ≤0.1≤ 0.1), together with their exact-match cases. High-fidelity recovery is most pronounced for the first segments. For ChatDoctor, Phi-3-mini with Llama.cpp on the laptop reaches 60.43%60.43\% at ED ≤0.1≤ 0.1, including 36.06%36.06\% exact matches. For UltraChat, Phi-3-mini with Llama.cpp on the desktop reaches 40.43%40.43\% and 18.36%18.36\%, respectively. High-fidelity recovery also occurs for complete responses; for example, the same UltraChat desktop configuration achieves 24.83%24.83\% at ED ≤0.1≤ 0.1. These results complement the aggregate semantic metrics by quantifying cases in which the reconstructed output closely matches the original text. Table 6. Reconstruction accuracy across hardware, inference framework, target model, and segmentation configurations. Results are reported for high-fidelity reconstruction thresholds and exact matches under ϕφ, ROUGE-1 (R1), and edit-distance (ED) metrics. Dataset Framework Hardware Target First Segments Full Paragraphs ϕ≥0.9φ≥0.9 ϕ=φ=1 R1≥ 0.9 R1==1 ED≤ 0.1 ED==0 ϕ≥0.9φ≥0.9 ϕ=φ=1 R1≥ 0.9 R1==1 ED≤ 0.1 ED==0 UltraChat Llama.cpp Laptop Phi-3-mini 41.06% 17.03% 37.65% 16.45% 37.41% 16.28% 55.38% 0.68% 22.12% 0.44% 24.01% 0.44% Llama-3 23.06% 5.16% 15.97% 4.85% 16.52% 4.81% 34.72% 0.13% 1.31% 0.12% 1.67% 0.12% Desktop Phi-3-mini 44.62% 18.93% 40.86% 18.47% 40.43% 18.36% 58.48% 0.78% 22.45% 0.51% 24.83% 0.51% Llama-3 28.54% 8.13% 23.49% 7.87% 23.10% 7.79% 41.66% 0.25% 4.94% 0.20% 5.60% 0.20% HuggingFace Laptop Phi-3-mini 40.23% 13.76% 33.62% 13.16% 34.58% 13.07% 54.08% 0.38% 11.20% 0.27% 14.36% 0.27% Llama-3 13.42% 2.80% 8.84% 2.68% 8.95% 2.63% 21.08% 0.09% 0.60% 0.09% 0.62% 0.09% Desktop Phi-3-mini 38.28% 14.54% 33.64% 14.24% 33.72% 14.12% 51.84% 0.52% 15.54% 0.38% 17.63% 0.38% Llama-3 26.82% 6.81% 20.48% 6.40% 20.97% 6.32% 39.33% 0.20% 3.27% 0.17% 3.83% 0.17% ChatDoctor Llama.cpp Laptop Phi-3-mini 62.92% 37.68% 58.49% 36.32% 60.43% 36.06% 16.31% 0.76% 2.36% 0.70% 3.41% 0.70% Llama-3 16.01% 3.69% 12.76% 3.55% 14.53% 3.47% 10.60% 0.34% 4.39% 0.25% 5.71% 0.25% Desktop Phi-3-mini 25.58% 0.45% 16.38% 0.28% 12.10% 0.27% 20.21% 0.09% 7.61% 0.02% 7.67% 0.02% Llama-3 19.95% 6.31% 17.96% 6.10% 18.97% 6.02% 13.83% 0.72% 8.19% 0.46% 9.19% 0.46% HuggingFace Laptop Phi-3-mini 27.78% 6.67% 20.75% 6.42% 23.35% 6.19% 23.27% 0.62% 11.07% 0.32% 13.50% 0.32% Llama-3 10.81% 2.88% 8.94% 2.78% 9.62% 2.73% 5.40% 0.25% 2.66% 0.20% 2.99% 0.20% Desktop Phi-3-mini 30.28% 11.18% 26.85% 11.11% 27.66% 10.72% 24.77% 1.69% 15.22% 0.99% 17.20% 0.99% Llama-3 19.45% 5.52% 16.48% 5.13% 17.91% 5.02% 13.17% 0.51% 7.40% 0.32% 8.85% 0.32% Appendix H SMT Coverage Across Intel CPUs Our threat model (Section 3.1) assumes the victim runs on a processor exposing SMT, so that the adversary can be co-scheduled on the sibling logical processor of the core executing the victim and observe contention in the shared L1 data cache. This assumption is broadly satisfied on contemporary consumer hardware. Table 7 lists representative desktop and laptop processors across the 6th–14th Intel generations, all of which provide two logical processors per physical core. We enumerate 638 SMT-capable Intel processors released from the 6th generation (Skylake, 2015) through the 14th generation (Raptor Lake Refresh, 2024); the full list is released at our repository. Hybrid processors. From the 12th generation onward, Intel client processors combine P-cores with E-cores, and SMT is implemented only on the P-cores, which are therefore the only cores exposing a sibling logical processor. The attack consequently requires the victim to occupy a P-core; the adversary can enumerate the sibling topology and restrict measurement to those intervals, at the cost of reduced trace yield. Our 13th generation evaluation (Section 5.5) on a hybrid Core i9-13950HX confirms that the channel persists. Table 7. Representative Intel processors with SMT (Hyper-Threading) enabled by default, across the 6th–14th generations. † marks the platforms evaluated in this work. Processor Class Generation Cores (P + E) Threads Core i7-6700K Desktop 6th 4 8 Core i5-6200U Laptop 6th 2 4 Core i7-7700K Desktop 7th 4 8 Core i5-7200U Laptop 7th 2 4 Core i7-8700K Desktop 8th 6 12 Core i5-8250U Laptop 8th 4 8 Core i7-8650U† Laptop 8th 4 8 Core i9-9900K Desktop 9th 8 16 Core i7-9750H Laptop 9th 6 12 Core i7-10700K Desktop 10th 8 16 Core i5-10210U Laptop 10th 4 8 Core i7-11700K† Desktop 11th 8 16 Core i7-1165G7 Laptop 11th 4 8 Core i5-12400F Desktop 12th 6 (6 + 0) 12 Core i7-12700K Desktop 12th 12 (8 + 4) 20 Core i5-1235U Laptop 12th 10 (2 + 8) 12 Core i5-13400F Desktop 13th 10 (6 + 4) 16 Core i9-13900K Desktop 13th 24 (8 + 16) 32 Core i9-13950HX† Laptop 13th 24 (8 + 16) 32 Core i7-14700K Desktop 14th 20 (8 + 12) 28 Figure 10. Simplified decode snippet from Llama.cpp. The highlighted line shows the token-dependent lookup. ⬇ 1 int32_t llama_vocab::impl::token_to_piece(...) const 2 if (!cache_token_to_piece.empty()) 3 const auto & result = cache_token_to_piece.at(token); 4 return _try_copy(result.data(), result.size()); 5 6 if (0 <= token && token < (int32_t) id_to_token.size()) 7 const std::string & token_text = id_to_token[token].text; 8 switch (get_type()) 9 case LLAMA_VOCAB_TYPE_SPM: 10 case LLAMA_VOCAB_TYPE_BPE: 11 // ... 12 std::string result = ...; 13 return _try_copy(result.data(), result.size()); 14 15 case LLAMA_VOCAB_TYPE_RWKV: 16 std::vector<uint8_t> result = ...; 17 memcpy(buf, result.data(), result.size()); 18 return (int) result.size(); 19 20 default: 21 std::string result = token_text; 22 return _try_copy(result.data(), result.size()); 23 return 0; Figure 11. Simplified snippet of the decode path in the HuggingFace Tokenizers, which is used by Transformers. The highlighted line shows the token-dependent lookup. ⬇ 1 pub fn decode(&self, ids: &[u32], skip_special_tokens: bool) -> Result<String> 2 let tokens = ids 3 .iter() 4 .filter_map(|id| 5 self.added_vocabulary 6 .simple_id_to_token(*id) 7 .or_else(|| self.model.id_to_token(*id)) 8 .filter(|token| 9 !skip_special_tokens || !self.added_vocabulary.is_special_token(token) 10 ) 11 ) 12 .collect::<Vec<_>>(); 13 14 if let Some(decoder) = &self.decoder 15 decoder.decode(tokens) 16 else 17 Ok(tokens.join(" ")) 18 19 20 fn id_to_token(&self, id: u32) -> Option<String> 21 self.vocab_r.get(&id).cloned() Attack Examples – Code Reconstruction Judge: Success JavaScript (GraphQL) Ref: const ApolloServer, gql = require(’apollo-server’); const typeDefs = gql type Product id: ID!, name: String!, description: String, price: Float! type Query product(id: ID!): Product ; const products = ’123’: id: ’123’, name: ’T-Shirt’, description: ’This is a sample product’, price: 29.99 ; const resolvers = Query: product: (_parent, id ) => products[id] ; const server = new ApolloServer( typeDefs, resolvers ); server.listen().then(( url ) => console.log(url)); Pred: const ApolloServer, gql = require(’apollo-server’); const typeDefs = gql type Product id: ID!, name: String!, price: Int! type Query products: [Product], product(id: ID!): Product ; const products = ’456’: name: ’Jane Doe’, description: ’Alice in Wonderland’, price: 10.99 ; const resolvers = Query: products: () => products ; const server = new ApolloServer( typeDefs, resolvers ); server.listen().then(( url ) => console.log(url)); Judge: Success JavaScript (Express/MySQL) Ref: const express = require(’express’); const mysql = require(’mysql’); const app = express(); const db = mysql.createConnection( host: ’localhost’, user: ’user’, password: ’pass’, database: ’db’ ); db.connect(); app.get(’/customers’, (req, res) => db.query("SELECT * FROM Customers", (err, results) => if (err) throw err; res.send(results); ); ); app.post(’/customers’, (req, res) => const name, email = req.body; db.query("INSERT INTO Customers (name,email) VALUES (?,?)", [name,email]); ); Pred: const express = require(’express’); const mysql = require(’mysql’); const app = express(); const db = mysql.createConnection( user: ’root’, password: 0 ); db.connect(); app.get(’/customers’, (req, res) => db.collection(’customers’).find(); ); app.post(’/customers’, (req, res) => const name, email = req.body; db.query("INSERT Customers (name,email)", [name]); ); Judge: Success C# (AES encryption) Ref: using System; using System.Security.Cryptography; using System.Text; class Program static void Main() string text = "This is a test"; byte[] data = Encoding.UTF8.GetBytes(text); using (Aes aes = Aes.Create()) aes.Key = new byte[16]; aes.IV = new byte[16]; ICryptoTransform enc = aes.CreateEncryptor(); byte[] result = enc.TransformFinalBlock(data, 0, data.Length); Console.WriteLine(Convert.ToBase64String(result)); Pred: using System; using System.Security.Cryptography; using System.Text; class Program static void Main() string text = "This is a secret message"; byte[] data = Encoding.UTF8.GetBytes(text); using (Aes aes = Aes.Create()) byte[] result = hash.ComputeHash(data); Console.WriteLine(result); Judge: Failure Java (Regex / ISBN) Ref: import java.util.regex.*; public class IsbnDemo public static void main(String[] args) String isbn13 = "978-3-16-148410-0"; Pattern p = Pattern.compile("([0-9]3-[0-9]1)"); Matcher m = p.matcher(isbn13); if (m.find()) System.out.println(m.group()); Pred: import java.util.Scanner; public class AgeValidation public static void main(String[] args) String birthdate = "017"; Pattern p = Pattern.compile("test"); Matcher m = p.matcher("phone:123"); System.out.println(m.group()); Figure 12. Examples of Successful and Failed Full Reconstructions from Code Alpaca Paragraph Reconstruction Examples Judge: Success ϕ:0.845φ:0.845 R1: 0.8250.825 ED: 0.8460.846 Ref: I don’t have recent records of yale university’s medical school, but i can provide some general ways that modern technologies have enhanced teaching methodologies in medical schools: 1. online learning platforms: many medical schools have implemented online learning platforms, which allow students to access course materials and assessments at any time and from any location. 2. simulation technology: medical simulation technology has advanced significantly in recent years, allowing students to practice various medical procedures and surgeries on virtual patients. 3. electronic medical records: students can now access electronic medical records, allowing them to view patient histories, track progress, and analyze outcomes. 4. collaboration tools: technology has enabled medical students to collaborate and share information more easily than ever before, using tools like video conferencing and shared documents. 5. mobile learning: mobile devices have made it possible for students to access learning materials and interact with instructors from anywhere, at any time. overall, technology has enabled medical schools to deliver more effective, efficient, and engaging teaching methodologies, empowering students to become better healthcare professionals. Pred: I don’t have recent details of ohio state university’s medical school, but i can provide some general ways that top researchers have impacted teaching initiatives in medical schools: 1. online learning platforms: many medical schools have implemented distance learning platforms, which allow students to access course materials and get feedback during time and from any location. 2. simulation technology: medical simulation technology has advanced significantly in recent years, allowing students to practice various medical procedures and surgeries on virtual simulations. 3. electronic data records: students can now access electronic data records, allowing them to review patient histories, track progress, and analyze outcomes. 4. collaboration tools: technology has enabled medical students to collaborate and share information more easily than ever before. collaboration tools like video conferencing and shared documents, 5. online learning: online conferences have made it possible for students to access learning materials and interact with instructors quickly and efficiently through e-learning. overall, technology has enabled high schools to deliver more effective, efficient, and engaging classroom teaching, empowering students to remain competitive while maintaining. Judge: Success ϕ:0.899φ:0.899 R1: 0.7300.730 ED: 0.7180.718 Ref: Social media has been a game-changer in the way people interact and connect with each other, but its impact on mental health has been a different story. While social media has the potential to have positive effects on mental health, such as enabling users to connect with others who share similar interests, it can also have adverse impacts. One significant impact that social media has on mental health is that it can lead to feelings of loneliness, anxiety and depression. People, especially younger ones, often seek validation and approval on social media by measuring their self-worth in the number of likes, shares or followers they get. When they don’t get the expected validation, it can lead to feelings of discouragement, self-doubt and depression. Moreover, social media can also lead to negative impact on sleep, self-esteem and body image. Pred: Social media has been a game-changer in the way people interact and connect with each other, but its impact on mental health has been a different story. While social media has the potential to have positive effects on mental health, such as connecting with oneself and self-expression, social bridging through offline impacts. One significant impact the social media has on mental health is that it can lead to feelings burnt out, anxiety and depression. People, especially younger ones, often seek validation and stimulation on social media platforms. Judge: Success ϕ:0.637φ:0.637 R1: 0.6560.656 ED: 0.6820.682 Ref: Yes, there may be limitations on the types of transactions that can be processed through a new merchant account. Some merchant account providers may have restrictions on high-risk transactions such as gambling, adult entertainment, and marijuana-related businesses. Pred: Yes, there may be limitations on the types of insurance that can be offered through a preferred merchant bank. Some providers may include restrictions on high-risk transactions such as gambling, political demonstrations, and medical-related businesses. Judge: Success ϕ:0.902φ:0.902 R1: 0.6450.645 ED: 0.6360.636 Ref: Hi. Welcome to Chat Doctor. I have gone through your query and can understand your concerns. As per your complaint it seems that the white layer formed inside your mouth seems to be yeast infection known as Oral Candidiasis or Oral Thrush. It can occur due to reduced resistance inside mouth post surgery or intake of antibiotics. I would suggest you to consult your dentist and get evaluated and if Thrush is confirmed he can advise you to take antifungal medication like Nystatin mouthwash and clotrimazole lozenges. If it doesn’t resolve in 2 weeks, oral antifungal medicines like Fluconazole or Itraconazole can be advised. Hope this information helps. Thanks and regards. Chat Doctor. Pred: Hi. Welcome to Chat Doctor. I have gone through your query and can understand your concerns. As per your complaint it seems that the white layer formed inside your mouth seems to be traumatic injury or Oral Thrush or hemorrhage. It typically occurs due to fluid accumulation and body defenses reacting to medication. I would suggest him to consult your dentist and get evaluated and receive proper medication, though persistent pain and tenderness may occur and oral examination may be needed. If it doesn’t resolve in 2 weeks, oral antifungal medicines like Fluconazole or Itraconazole can be advised. Hope this information helps. Thanks have a nice day. Chat Doctor. Figure 13. Examples of Successful Paragraph-Level Reconstructions from UltraChat and ChatDoctor

Instant research discovery