arXiv CSopen access

Exploiting Software-level Abstractions To Support Practical Hardware Trojan Attacks

Exploiting Software-level Abstractions To Support Practical Hardware Trojan Attacks Athanasios Moschos Kevin Valakuzhy Georgios Kokolakis Fabian Monrose Angelos D. Keromytis

arXiv:2609.23173v1 [cs.CR] 19 Sep 2026

Georgia Institute of Technology Atlanta, Georgia, USA {amoschos, kevinv, gkokolakis6, angelos}@gatech.edu, [email protected]

community’s early concerns about the potential of processor hardware hosting powerful trojan implementations [4–10]. The interplay between hardware and software in modern processors is, nonetheless, complex. Binary-level code execution becomes essential to leverage hardware features buried deep in the microarchitecture. As a case in point, the exploitation chain of Operation Triangulation starts with a zero-day exploitation [2] which leads to arbitrary code execution on the victim devices. Likewise, typical hardware trojan threat models [5, 6, 8, 9] assume attackers can activate trojans via arbitrary machine-level instructions. This ability, however, is not the attack outcome but rather a prerequisite necessary to jump-start the offensive campaign. While easy in theory, practical realization of arbitrary code execution requires chaining multiple software-level flaws into viable gadget chains [11]. Yet, operating system (OS) diversity, coupled with heterogeneous software stacks and security configurations, renders this realization a daunting task. Thus, the common assumption that attackers have readily available fine-grained execution rights on target devices, despite the difficulty of obtaining them at scale, can create a false sense of security about the relevance of hardware trojan threats to end-user devices. We posit that attackers can embed trojans in client-device CPUs that obviate the need for arbitrary code execution during activation, minimizing reliance on additional device or software stack vulnerabilities. Our work explores this alternative by leveraging execution engines of runtime systems for trojan triggering. Runtime engines are integral to applications processing untrusted content (e.g., browsers, document readers), exhibit stable behavior across diverse hardware platforms and can therefore serve as reliable activation vectors. Building on these observations, we introduce S URF-trigger circuits, which exploit predictable hardware manifestations of softwarelevel computations to activate malicious payloads. Specifically, we show that an attacker can leverage a runtime engine to stimulate an embedded S URF trojan, which then locates and executes malicious machine-level code injected in the memory of an otherwise bug-free runtime system. In summary: • We introduce S URF -trigger circuits and explore the practicality of stimulating them via JavaScript-level integer operations executed inside the popular V8 engine. • We prototype a S URF trojan inside a Linux-capable RISC-V processor on FPGA and exploit the effective ad-

Abstract—Hardware trojan (HT) attacks against CPUs typically assume threat scenarios where an attacker targeting a system with a trojanized CPU is able to execute arbitrary code (i.e. machine-level instructions) to reliably interact with the implanted trojan. On end-user devices (i.e., mobiles, laptops), achieving arbitrary code execution in practice requires software exploits tailored to each specific target. Such strong adversarial premises reduce the generality of existing threat models casting doubt on CPU trojan attacks as a pragmatic threat vector. To push the envelope on HT attacks against client devices, we introduce the S URF class of CPU-trojans that can be activated without arbitrary code execution. Our key insight is that integer operations expressed in a high-level language can be mapped to microarchitectural side-effects distinguishable by a S URF trigger circuit. This observation unlocks HT activation via runtime engines, constrained environments executing untrusted highlevel code. We demonstrate a S URF trojan inside a RISC-V processor and exploit JavaScript-level memory indexing operations inside Google’s V8 engine to perform a code injection attack. Importantly, we show that S URF trojans remain effective across multiple JavaScript engine versions, enabling long-term compromise of endpoint devices. To facilitate research, we opensource S URF’s design and supporting software. Index Terms—Hardware Trojans, Computer Architecture

I. I NTRODUCTION Hardware trojans are often associated with offensive campaigns against high-value military systems [1] and are typically attributed to state-level actors. The offensive security community, however, recognizes that similarly valuable targets include personnel within accredited organizations (e.g., diplomats) and security-critical corporations such as cybersecurity firms. The disclosure of recent activities like Operation Triangulation [2, 3] demonstrates how third-party intellectual property (3PIP) in commercial endpoint devices can be weaponized against special interest individuals who own them. Albeit not a hardware trojan per se, Operation Triangulation is the closest instance we have of a large-scale offensive campaign designed to exploit a silicon feature in a third-party processor to gain a persistent adversarial foothold on end-user devices incorporating it. More broadly, the incident points to an important realization: advances in the defensive posture of modern endpoint devices have raised the bar beyond what pure software exploits can reliably achieve, increasingly pushing sophisticated attacks toward the exploitation of hardware logic. This real-world incident lends credence to the research

1

activation stage trigger stimulus

trigger circuit

TABLE I T ROJAN ACTIVATION M ODELS IN CPU H ARDWARE T ROJAN ATTACKS

attack stage trigger signal

payload circuit

payload effect

Publication

Activation Stage Ability

Trigger Stimulus

[13] [27] [14]

a) b) arbitrary code execution arbitrary code execution arbitrary code execution arbitrary code execution arbitrary code execution a) arbitrary code execution b) control a type-safe interface a) arbitrary code execution b) arbitrary code execution arbitrary code execution a) arbitrary code execution b) influence over D$ arbitrary code execution compiler allocation of targeted registers

a) no trigger; always-on design b) repetitive instruction pattern precise instruction pattern repetitive instruction pattern repetitive instruction pattern mix of legal & illegal instructions a) virtual address of a bounds check b) instructions of a bounds check manipulation of targeted registers integer operations* memory operations a) memory operations b) network packets POSIX clock time event network packets

S URF

high-level code execution

integer operations

[4] [7] [26] [5] [12]

Fig. 1. Operational stages of a hardware trojan attack.

[8]

dress calculation of JS-level memory indexing operations to perform a code injection attack. • Using different V8 engine releases, we evaluate the robustness of S URF-triggers in terms of (i) resisting possible detection efforts and (ii) operating under diverse workload conditions, among an evolving software stack. Altogether, our practical trojan activation approach highlights the threat posed by HTs to modern endpoint devices.

[9] [6]

Table I, along with the adversarial ability required to generate the trigger circuit stimulus necessary for the trojan activation. Trigger circuits are often constructed using wires with low switching activity [5, 7, 26]. Stimulating such wires typically requires carefully crafted instruction sequences that may (i) enforce precise ordering, (ii) access special-purpose registers, (iii) use specific immediates or offsets, (iv) select particular registers or (v) combine legal with illegal instruction encodings. The latter approach is also used as a stimulus in Zhang et al. [12]. Additional trigger design considerations may necessitate high-frequency repetition of these instruction streams within short time windows [4, 5, 26]. To meet these constraints, activation models in prior work assume attackers capable of executing arbitrary binary-level code on the victim systems. Similar assumptions underlie alternative activation strategies, including trojans triggered via a wall-clock timer configured through a debug logic backdoor (e.g., in the scan chains) [27] and those relying on the virtual address (VA) reconnaissance of the victim software stack [8]. Likewise, approaches based on register manipulation [9] or arbitrary memory operations [6, 13] assume attackers can first deploy their own process on the target system at the activation stage. In security parlance, this attacker capability fueling the above activation models is commonly referred to as arbitrary code execution. Only a minority of trojans feature activation conditions that do not require this capability [8, 13, 14]. Frequently, the focal point in offensive research of hardware trojan attacks is either the hardware-level design novelty, the insertion method, or the attack stage functionality, with each serving to highlight the potential impact of this clandestine threat. As a result, authors often gloss over the preconditions that, in practice, define a favorable setting for the activation stage of an offensive. In prior literature, such settings are typically reduced to overly simplified assumptions in which adversaries either possess a user account on the victim system [5, 6, 12], operate within a virtualized environment [5, 8], or can execute malicious software [6, 13, 27]. In reality, though, obtaining user-level access on large

II. BACKGROUND A. CPU Hardware Trojan Attacks Hardware trojans comprise a trigger and a payload circuit, with HT offensives reflecting two distinct operational stages, activation and attack, illustrated in Figure 1. During the activation stage, the trigger monitors for a special condition to enable the payload, while in the attack stage the payload manifests the malicious behavior. A trojan implementation is practical only if it can be reliably activated at the attacker’s behest. In CPU-based hardware trojans, activation—that is, the generation of the trigger signal—typically depends on the execution of attackercontrolled software on the target system [5, 6, 9, 12] or on the injection of adversarial data that is observable by the malicious hardware [13, 14]. Crucially, establishing that a trojan is controllable requires attackers to reason explicitly about their assumed level of access to a victim system equipped with an infected CPU. For the remainder of this paper, we refer to this reasoning as the trojan activation model. The activation model, typically part of the attack’s threat model, delineates not just the trigger stimulus, but also the capabilities an adversary must have to successfully start a hardware trojan offensive. Specifying this model enables stakeholders to assess if they fall within a trojan’s effective threat surface and develop defenses that disrupt its activation. B. Trojan Activation Models The efforts of Chuah et al. [10] and Moschos et al. [9] survey the main research on processor HTs. Since the methodologies and scopes of these studies vary widely, we filter them to create a body of works that explicitly discuss details about the underlying activation model of each trojan. First, we exclude works that do not analyze HT controllability or activation conditions [15–21]. Cryptographic accelerators [22– 24] are monolithic circuits with no OS support and therefore outside our scope. On these principles, we exclude the work of Hepp and Sigl [25] on the Riscy microcontroller. The resulting papers considered in our analysis are summarized in

* Authors only consider use of assembly to form the integer operations.

2

populations of endpoint devices is impractical. Establishing a foothold on end-user devices becomes a case-by-case task (e.g., with victim-specific software exploits), as their diverse operating systems and software stacks lead to heterogeneous security configurations. Additionally, frequent software updates or patching can shorten or eliminate such windows of opportunity to leverage a trojan. In light of these considerations, we argue that activation models dependent on arbitrary code execution can significantly diminish the credibility of hardware trojans as a viable threat against endpoint devices.

streams executed within the CPU. Consequently, runtime engines deprive user control over (i) the machine instructions emitted, (ii) their ordering, (iii) the registers or immediates they operate on, or (iv) their precise timing and frequency. These are the bedrock of several prior work activation models [4, 5, 7, 9, 26]. Such limitations are not favorable either to activation models founded on malicious software execution on the target system [6, 13, 27] or hunting for virtual addresses via cache side-channels [8]. Lastly, the runtime compilers and interpreters cannot issue illegal instruction encodings featured in the stimuli of [12, 26]. Taken together, the above factors make runtime engines not applicable for the activation models seen in prior work. In the following sections we present a novel approach, applicable to runtime engines, that leverages integer operations expressed in high-level code for activating hardware trojans.

C. Trojan Activation Via Runtime Engines Given these constraints, trojan activation on endpoint devices calls for strategies independent of arbitrary code execution. Instead, achieving remote interaction with HTs at scale demands ubiquitous software platforms on the device side that expose interfaces capable of influencing the underlying hardware behavior from a distance (e.g., over the network). To offer consistent user experience across different hardware platforms, commercial applications rely heavily on the use of runtime systems. Hence, we consider runtime environments in modern software stacks as a practical substrate that combines both ubiquity and remotely accessible interfaces. Runtime systems incorporate execution engines to enable seamless software deployment across devices and operating systems. Acting as intermediates between software and hardware, they offer the following benefits: • Code portability, as execution engines translate highlevel code into (local system) machine-level instructions, enabling cross-platform application compatibility. • Execution consistency, ensuring predictable application behavior across heterogeneous systems. In essence, runtime engines (i) are native components of the system’s software stack (e.g., not installed by attackers), (ii) are common in applications that that process attackercontrolled content (e.g., web browsers and document readers), and (iii) expose code structures (e.g., functions) with stable behavior across systems. Consequently, we argue that runtime execution engines constitute promising access vectors for triggering hardware trojans, as they can decouple activation from the preconditions of arbitrary code execution. Contrast to arbitrary code execution: Adversarial access to runtime engines is substantially easier to obtain as modern endpoint devices intentionally expose environments designed to execute untrusted code. Reaching these execution contexts typically requires only content delivery (e.g., visiting a webpage, loading remote user interface content, or opening a document). Importantly, runtime engines by design preclude processing of machine-level instructions. Instead, the code is expressed in high-level abstractions (e.g., objects, functions) that lack direct machine code equivalents, a disconnect commonly referred to as the “semantic gap”. To bridge this gap, runtime engines use interpreters or just-in-time compilers to translate the high-level code into machine instructions. These intermediate software layers— and not the adversaries—ultimately determine the instruction

III. T HREAT M ODEL Our work adopts the threat model of a 3PIP vendor attack [28–30], where a trojan is embedded within a third-party processor IP integrated by the design house or SoC developer. Vendors typically sell 3PIPs in a black-box form, either as a netlist description or a tape-out-ready layout representation, to protect their proprietary designs, maintain their competitive advantage and preserve profitability. Due to this black-box nature [31], a malicious IP will be incorporated as is with the rest of the chip, therefore increasing the likelihood of a stealthy attack. We deem this a plausible attack route, given the widespread integration of 3PIPs in modern SoCs [28, 32]. We assume the chip with the malicious processor has passed any security-relevant industry standard checks and launched on the market as a commercial off-the-shelf (COTS) product. This is considered feasible as existing verification methods and applicable detection techniques [28] cannot guarantee the nonexistence of additional (malicious) behaviors, especially if the nominal functional design specification is unmodified [33]. To the best of our knowledge, trojan detection methods are not yet an industry standard and thus, there is no guarantee that IPs are tested against them before integration. Operationally, we consider an attacker who can remotely interface with a trojan-infected endpoint device. The victim system offers no exploitable hardware or software vulnerabilities an attacker can leverage during S URF’s activation stage, and runs an application with a bug-free execution environment. A canonical example is a web browser, which provides both a network-facing interface and a runtime execution environment (e.g., a JavaScript engine); however, other applications exposing runtime environments, such as document viewers, also fit our model. By executing untrusted code (e.g., via phishing links, malicious advertisements, compromised legitimate sites or malicious documents), the attacker influences the machinelevel instructions executed by the runtime engine. Specifically, the adversary can induce computations expressed in high-level code (e.g., JavaScript). Our trigger mechanism leverages the predictable manifestation of these JavaScript-level computations in the underlying CPU hardware to activate the trojan

3

payload. From an attacker’s perspective, the JavaScript path is preferable over WebAssembly execution, since the latter is not available in document readers. Moreover, in the context of browsers, WebAssembly is widely regarded as a potential red flag [34, 35] that can expose an offensive campaign.

free operand

static operand

IO:START = IO:RESET = {constant value, start value} IO:X = {constant value, stage-X value} IO:RESET IO:RESET

Init

IV. S URF T RIGGER C IRCUITS

0

The lack of precise control over the machine code emitted by runtime systems complicates their use for trojan activation. Consequently, attackers must rely on alternative sources of determinism to interact with HTs. To this end, we observe that integer operations (e.g., arithmetic and logical) expressed in high-level code exhibit predictable and observable microarchitectural effects, suitable for stimulating S URF-trigger circuits.

IO:START

1

IO:2

2

...

K-2

IO:K-1

K-1

IO:RESET

Fig. 2. Finite state machine of a SURF trigger circuit.

B. Trigger Circuit Design An IOP is identified by the trigger circuit depicted in Figure 2, implemented as a finite state machine (FSM). The designated integer operation to initiate an IOP sequence is denoted as IO:START. In this operation, the start value inside the static operand signals the FSM to latch onto the constant value carried by the free operand. To advance through subsequent states, the trigger mechanism monitors the instruction stream for integer operations whose source registers simultaneously satisfy (i) the latched constant value and (ii) the expected static value for the next state. If these conditions are not met, the FSM remains at its current state; benign integer operations may execute without affecting key recognition, in accordance with the IOP properties. Upon observing the final operation contributing to the IOP, the trigger signal is asserted and the activation stage shown in Figure 1 is concluded. During the CPU operation, benign instruction sequences that partially satisfy the IOP criteria can transiently advance the FSM. To prevent such scenarios from blocking a subsequent attacker-directed activation attempt, we integrate a reset mechanism that re-initializes the FSM upon the arrival of an operation satisfying the IO:START characteristics. This operation, denoted as IO:RESET in Figure 2, re-latches the fresh value of the free operand, overriding the previously captured value. So IO:RESET and IO:START are functionally equivalent.

A. Trigger Stimulus Integer operations: In general-purpose microarchitectures, integer operations such as addition, subtraction, and bitwise logic (e.g., AND, OR, XOR) constitute fundamental architectural primitives—meaning built-in, lowest-level operations that the hardware directly supports. In high-level languages, these operations are typically expressed with two explicit operands. Runtime interpreters and compilers preserve their semantics when lowering them to architectural instructions (e.g., add, sub, and, or, xor for RV64I ISA) which operate on the values held in their source registers. Ultimately, by selecting the operands of high-level integer operations, attackers can influence the source register values of the machine instructions these operations map to. The S URF-trigger circuits can identify the manifestation of these instructions in the processor’s hardware by tracing their operand values. Integer Operation Pattern: A S URF trojan is activated when a key, a sequence of integer operations (IOs) with attacker-controlled operands, is executed in the processor. We refer to this activation key as an Integer Operation Pattern or IOP. An IOP is characterized by properties that govern how the trigger stimulus is constructed and identified. First, it comprises an arbitrarily long sequence of integer operations. Second, each instruction’s operand pair is asymmetric: one operand, referred to as free, is unconstrained and may take any value, while the other, named static, is restricted to a predefined set of values decided at design time. Importantly, although the free operand may assume any value at runtime, it must remain constant across the entire IOP sequence to form a valid key. This structure increases triggering flexibility without compromising trigger stealthiness, as we show in Section VI-A. Third, the sequence itself is fixed: both the static operand set and the order in which these values need to appear are decided at design time. While the corresponding operations must occur in this order, they need not be contiguous in the instruction stream. Therefore, unrelated computations may interleave with IOP elements without preventing successful key recognition. Finally, the attacker may choose at runtime any mix of integer operations to form the IOP sequence.

V. S URF -E NABLED C ODE I NJECTION ATTACKS Our goal is to demonstrate that S URF trojans not only enable a more relaxed activation model but can also establish powerful footholds within their host devices. To this end, we craft a S URF-based trojan that locates and executes machine code injected into the memory of a running process. We evaluate our trojan implementation on the V8 platform, Google’s opensource, high-performance JavaScript engine, that empowers browsers like Chrome, Brave, Opera and Microsoft Edge. Given Chrome’s dominant market share [36], our choice ensures broad practical relevance. This attack utilizes untrusted JavaScript executed within the V8 environment to enable both the activation stage and the attack stage depicted in Figure 1. Attack Impact: A successful code injection attack yields the ability to execute arbitrary code inside Chrome’s renderer process. This constitutes a critical security exposure [37] that, when paired with independent vulnerabilities or policy flaws

4

Compiler Pipeline Parser

JS Code

Interpreter “Ignition”

Bytecode

Compiler “Turbofan”

Optimized Machine Code

virtual or physical addresses to the programmer. Memory allocation is handled by the V8 engine backend, while operatingsystem-enforced address space layout randomization (ASLR) randomizes its virtual memory layout. As a result, the adversary is oblivious to the virtual address of the JS object carrying the software payload. Nevertheless, at the JavaScript-level, the adversary can access the object through memory indexing operations (e.g., reading or writing its elements). At the machine-code level, such operations require computing the effective address of the accessed element by adding the object’s randomized base address to the attacker-chosen index. Consequently, a sequence of these calculations can satisfy the IOP properties outlined in Section IV-A: the randomized base address serves as the free operand, while the selected indices correspond to the values of the static operand drawn from a predefined set. More importantly, repeated accesses to the same object preserve the base address in the free operand, regardless of the index used. This high-to-low code transformation contributing to the S URF key generation is illustrated in Figure 3. A byte read from a JavaScript object is lowered to RV64 instructions, where the source registers of an add instruction expose the object’s raw base pointer and the index used to compute the effective-VA. This raw base-pointer corresponds to the virtual address in the V8 address space, prior to its translation into a physical address by the memory management unit. Hence, the trigger circuit presented in Section IV-B can recover the software payload’s virtual address, effectively bypassing ASLR, and facilitate control-flow hijacking. Importantly, S URF achieves this entirely within the processor, without external memory disclosures or software-level information leaks. The trigger circuit recovers the address as a byproduct of the activation procedure, eliminating the need for auxiliary disclosure channels. In contrast, the ROP-based attack in [8] requires arbitrary code execution on the victim system to break ASLR via cache-based side channels, before trojan activation.

High-Level Code // JavaScript temp = object[index];

Bytecode // V8 Bytecode Mul r4, [2] Add r3, [1] GetKeyedProperty r2, [3] SetKeyedProperty r0, r1, [5]

Machine Code // RV64 machine code beq a7,t3,24 add a4,a5,a4 add a4,t0,a4 lbu a4,0(a4)

Fig. 3. Overview of the V8 engine compiler pipeline and the representation of JavaScript code within it. Highlighted is the machine instruction responsible for the effective address calculation contributing to the IOP generation.

(e.g., a browser sandbox escape) in other runtime components or the operating system kernel, can lead to total compromise of the endpoint device. Crucially, this capability enables the deployment of most CPU trojans in Table I, whose operation assumes arbitrary code execution on the target device. The V8 engine: Execution engines use interpreters and compilers to dynamically translate high-level code into machine instructions at runtime and optimize its execution. V8 engine’s execution pipeline primarily relies on two language processors, the Ignition interpreter and the Turbofan compiler [38]. As shown in Figure 3, JavaScript code is initially parsed and forwarded to Ignition which generates and intermediate bytecode representation and dispatches for execution the corresponding pre-compiled machine-code handler of each bytecode instruction. In parallel, Ignition profiles execution to identify frequently executed bytecode regions, which are passed to the just-in-time TurboFan compiler, for translation into optimized machine code. Figure 3 illustrates the resulting code representation at each stage of this pipeline. A. Code Injection Attack Stages Activation Stage: During this stage, the attackercontrolled JavaScript executed by the runtime engine serves two purposes. First, it injects a software payload into the V8 engine’s virtual memory as a JavaScript object (e.g., an array) containing native machine instructions in byte form. Second, it performs integer computations that serve as trigger stimuli, forming the IOP trojan activation key. Attack Stage: Upon activation, the trojan hijacks the control flow of the V8 process and redirects execution from the JS code to the byte contents of the injected object. The injected native instructions execute until control is restored to the original JS code, which concludes the attack by issuing an IOP to deactivate the trojan. Fundamentally, successful redirection first requires recovering the virtual address of the injected software payload. Next, we describe how the S URFtrigger mechanism enables this recovery, followed by the implementation of the trigger and payload circuits.

C. S URF Trojan Implementation We evaluate our S URF trojan inside the 5-stage, in-order Rocket Core microarchitecture [39], which reflects the fundamental execution and memory structure of a Linux-capable general-purpose core implementing a modern instruction set. Integer Operand Visibility: As discussed in Section IV-B, the trigger circuit requires visibility into both operands of an integer computation. The Rocket Core pipeline abstraction in Figure 4—floating-point portion is omitted for simplicity—illustrates such candidate monitoring locations. Operands originating from the runtime engine’s virtual memory are loaded into architectural registers and subsequently read from the register file by integer instructions that reach the decode stage (ID). Before reaching the execution stage (EX) and the inputs of the arithmetic logic unit (ALU), they pass through the bypass network to resolve data hazards and get latched into pipeline registers. Thus, multiple candidate locations exist between the ID and EX stages expose operand values to detect the IOP activation pattern.

B. V8 Engine Memory Reconnaissance To enable code portability and enhanced security, JavaScript abstracts direct memory management and does not expose

5

trigger logic A payload B

logic existing data bus

PC

Frontend IF

PC Generation 4

payload wire

ITLB & Exception Generation

Core ID B

EX ALU

Integer RF

5

Instruction Decode

I$ Access

1

2

A

Integer Execution

3

MEM DTLB

Commit D$ Access

Rocket Core Pipeline

trj_disable_xcpt = 1 imem.req.bits.pc = recovered VA imem.req.valid = 1

trigger operation payload operation

attack stage

activation stage 1 VA recovery

2

WB

Sent trigger signal and VA

3

Taint the Spoof a valid PC 4 next PC change request

5

Mask instructions as executable

SURF trojan operation timeline

Fig. 4. The Rocket Core pipeline with a S URF trojan for code injection attacks. The trojan horses signify logic modifications, while the enumerated circles signify operational activity related either with the trigger or the payload logic.

Trigger Circuit: We implement our S URF-trigger inside the arithmetic logic unit (blue trojan horse symbol in Figure 4). Compared to earlier pipeline locations, the ALU has visibility to source registers of integer instructions only, reducing the volume of data variance in the trigger stimuli. The circuit implements the state machine depicted in Figure 2 and passively monitors the ALU’s two 64-bit inputs. The trigger logic implementation addresses two challenges: (i) reliably distinguishing IOP stimuli from benign integer computations, and (ii) the lack of control, at high-level code, over which ALU input receives the injected object’s address versus its index. For the first, we exploit the expected form of operand values (i.e., a virtual address) involved in our attack scenario, to isolate the trigger stimuli. Rocket Core uses a page-based 39-bit virtual address space; therefore the FSM’s free operand in Figure 2 is restricted to canonical user-space addresses (e.g., values with bits [63:39] equal to zero). We further require at least one bit within a predefined subset of the lower 32 bits to be set, filtering out very small integer values. For the static operand, values must match the indices selected during the trojan design phase, with their upper bits set to zero. Together, these constraints distinguish the trigger stimuli from varying traffic generated by benign computations. Turning to the second challenge, high-level code cannot control which ALU input receives the address and which the index value. However, we observe that runtime interpreters and compilers rely on fixed, pre-compiled machine-code stubs (e.g., V8 Built-in functions), yielding consistent selection of ALU inputs across repeated executions of an integer operation. We therefore duplicate the FSM with swapped ALU inputs, reliably identifying an IOP irrespective of its operand ordering. Payload Circuit: A successful attack requires redirecting the PC outside the normal V8 execution flow, and permitting execution at the target address. Our hardware payload achieves both by “tainting” the next-PC generation with the JavaScript object’s address while suppressing exceptions that would prevent its execution. We realize this by modifying the core’s EX stage logic and the frontend’s exception logic, shown by the red trojan horse symbols in Figure 4.

Rocket Core’s execution stage issues PC-change requests to the frontend through a dedicated bus in response to controlflow changes, exceptions or stalls. Our payload modifies this logic—marked as A —to spoof a control flow change, by driving the target address on the (imem.req.bits.pc) bus and asserting the imem.req.valid to indicate a valid PCchange request. The payload logic then protects this request against microarchitectural events that could invalidate the redirection. For example, a subsequent memory instruction incurring a cache miss will be replayed, reverting execution from the injected instruction stream. To prevent this, payload logic suppresses subsequent PC-change requests by holding the imem.req.valid low until the first instruction fetched from the redirected stream executes. In the frontend, the multiplexer marked B is controlled by the trj_disable_xcpt trojan wire, which suppresses instruction page faults and access exceptions upon trojan activation. This enables the execution of injected instruction streams in protected or non-executable memory. D. S URF Trojan Operation We prototype our Rocket Core S URF trojan on a Genesys 2 FPGA board to evaluate the practicality of our code injection attack inside a Debian environment (Linux Kernel 6.9.6). Limitations in Rocket Core’s performance make it difficult to evaluate our proof-of-concept on a complete runtime environment as the number of processes spawned by a fullblown browser exceed the core’s capacity. As an alternative analysis, we test our attack using the V8 engine (version 13.0) to process the adversarial JavaScript code. Figure 4 depicts the trojan operation throughout the attack. Activation Stage: The trigger circuit constantly monitors the ALU operands for an IOP activation key. The JavaScript code accesses selected indices of the injected object, forming this key via the effective address additions generated for each access, as described in Section V-B. Depending on the operand ordering of these additions, only one of the trigger FSMs will reach the final state, recovering the base-pointer of the software payload (operation 1 in Figure 4). The recovered

6

virtual address and the trigger signal are then forwarded to the payload circuit in the EX stage (operation 2 ). Attack Stage: Upon triggering, the payload spoofs a PCchange request in the following clock cycle (operation 3 ) through the existing communication bus between the core and the frontend. Once the next-PC is tainted (operation 4 ), the execution flow of the V8 process is diverted and Rocket Core starts fetching instructions from the injected array. Because V8 heap pages storing JS objects are non-executable, these instruction fetches would normally raise a page fault exception. Instead, the payload multiplexer forces instructionrelated exceptions to zero, suppressing faults detected by the translation lookaside buffer (operation 5 ), and allowing injected instructions to proceed to decoding. We successfully activate the S URF trojan using both the Ignition interpreter and the TurboFan compiler, bypassing the ASLR mechanism that randomizes V8’s address space, and conclude a code injection attack before restoring the V8 execution to its normal control flow.

1 2 3 4

1 2 3

1

2 3 4 5 6

1 2

VI. S URF -T RIGGER ROBUSTNESS A NALYSIS

3 4

Native hardware support for integer operations across platforms ensures that their high-level counterparts are consistently lowered to the same hardware primitives. Hence, we focus our S URF-trigger robustness analysis around effective address calculations, being potentially more prone to variation across code samples and runtime versions. To evaluate our trigger prototype, we combine our FPGA setup with QEMU-based emulation of V8 engine’s operation. Specifically, we use a RISC-V user-mode QEMU instance, extended with a custom plugin that tracks every machine instruction executed by V8. The resulting instruction traces provide fine-grained visibility into the engine’s software evolution, while the FPGA platform evaluates S URF-trigger effectiveness under realistic operating system conditions. Both experimental environments use identical V8 binaries and JS workloads.

Listing 1. Main let fsm_states = 7, stride = 17, i = 0; let temp = new Array(1); const object = new Array(); function main(){ trigger(); } Listing 2. For – Trigger function trigger(){ for(i = 0; i < fsm_states; i++){ temp = object[offset_start + i * stride];}} Listing 3. Recursive – Trigger function recursive(i, max, offset, stride, x, y ){ if (i >= max) return; y = x[offset + i * stride]; recursive(i + 1, max, offset, stride, x, y);} function trigger(){ recursive(0, fsm_states, offset_start, stride , object, temp);} Listing 4. While – Trigger function trigger(){ offset = offset_start; while(i < fsm_states){ temp = object[offset]; offset += stride; i ++;}}

Fig. 5. Semantically equivalent but structurally different JavaScript trigger functions for IOP generation. TABLE II S TRUCTURAL COMPARISON OF DIFFERENT TRIGGER FUNCTION IMPLEMENTATIONS , USING THE NORMALIZED L EVENSHTEIN DISTANCE ON MNEMONICS OF INSTRUCTION TRACES CAPTURED IN QEMU. Language Processor

V8 Version

Structures Compared

Mnemonics Similarity (%)

Ignition

13.0

For vs. While For vs. Rec While vs. Rec

60 37 31

control-flow constructs. To quantify their structural similarity at the machine-code level, we execute each variant in V8 under QEMU to collect instruction traces, retaining only the trigger function instructions generated by the Ignition interpreter. We measure similarity using the normalized Levenshtein distance of the instruction mnemonics. The Levenshtein distance [43] measures the minimum number of single entity edits required to transform one sequence into another. We compare mnemonics rather than raw instruction bytes to capture structural differences in the V8 source code while disregarding register allocation. Table II shows that the instruction sequences differ substantially despite producing identical effective address calculations. Consequently, IOP generation remains consistent across structurally diverse code samples, enabling S URF-trigger activation while complicating signature-based detection, analogous to polymorphic malware [44]. Resisting IOP Exhaustive Search: The trigger design in Section IV-B supports arbitrarily long sequences of integeroperation stimuli, making accidental formation of an IOP key during benign software execution highly improbable. Targeted

A. Detection Resilience For an attacker, detection resilience determines whether a hardware trojan remains a durable foothold or is rapidly neutralized. If trigger generation maps to a fixed code signature, defenders can detect and block it at scale. Conversely, triggers generated using diverse code sequences weaken signaturebased defenses by eliminating a stable detection pattern. Likewise, if defenders can trivially discover the trigger condition, they can deliberately activate and analyze the trojan to accelerate reverse engineering and fleet-wide remediation. Resilience against both signature-based detection and exhaustive trigger discovery preserves trojan stealthiness, prolongs persistence, and prevents rapid containment. Evading Signature-based Detection: Code polymorphism is a well-known technique for evading signature-based detection [40–42], whereby malicious programs maintain semantic equivalence while varying their code structure. The trigger functions in Figure 5 exemplify this property by performing identical memory indexing operations through distinct

7

activation attempts, however, pose a stronger threat. We therefore analyze a defender who possesses partial knowledge of the trojan and attempts to expose it. Following the attack scenario of Section V, we assume that the defender gained insight to the object size required to generate the relevant memory indexing operations for the IOP. However, the defender has no knowledge of the index values forming the IOP key. The defender can thus use this information to exhaustively exercise candidate indices and force the trojan from its dormant state. The time to fully activate the trigger is termed as trigger time [5]. A reasonable search strategy is to sequentially access every object element, to ensure all indexes in the predefined set are exercised. To guarantee activation for any key, the defender must traverse the entire object once for each state of the trigger FSM. Approximating each effective address calculation as an addition instruction, the worst-case search requires BFinstructions = ST × OS

TABLE III T RIGGER FUNCTION ’ S MNEMONICS SIMILARITY USING THE NORMALIZED L EVENSHTEIN DISTANCE . M NEMONICS GENERATED BY I GNITION ACROSS DIFFERENT V8 VERSIONS . Similarity Against V8 10.0 (%) 10.0 10.7 11.0 12.0 13.0 100 100 100

(2)

where IPC is the number of instructions retired per cycle and CT is the clock period in ns per cycle. Under our 3PIP threat model, the attacker aims to maintain processor performance during the trojan integration. Realistically, to harden the design against IOP brute-force attacks, the adversary can tune both the number of FSM states and the largest predefined index, therefore affecting the size of the object in our attack scenario. We consider a seven-state S URF FSM implemented in a 4 GHz processor with an IPC of 1. With an object size of 16 K elements, Equation 2 yields a maximum trigger time of approximately 24 µs, providing insufficient resistance to exhaustive search. To address this, we introduce a new tunable parameter, Trials, that regulates the number of integer operations sharing a constant free operand that may occur in selected FSM states. Exceeding this threshold resets the FSM to its initial state. The trigger logic can consequently contain both regular and limited states, which permit at most Trials operations. The resulting worst-case instruction count is: BFinstructions = (STR × OS + Trials) × (

OS STL ) Trials

66 74 62

50 65 48

Code Injection

For Recursive While

✓ ✓ ✓

✓ ✓ ✓

Operational resilience determines whether an HT can maintain a persistent and controllable foothold in an infected system under realistic operating conditions as the surrounding software stack evolves. A trigger mechanism tightly coupled to fragile software artifacts may fail under routine updates, recompilation, or structural changes, compromising long-term persistence [8]. Similarly, unrealistic execution assumptions about the trigger software (i.e., uninterrupted control flow [9]) can undermine reliable and repeatable activation in the presence of normal operating system behavior. Designing trigger circuits that tolerate software evolution and OS-level dynamics is therefore essential for maintaining robustness over time. Software Evolution Resilience: Runtime engines continuously evolve to support the performance and security demands of their host applications. Beyond updates of individual functions, these systems may also undergo drastic architectural changes that can impact the trojan’s activation mechanism. To evaluate the resiliency of our attack to V8 software evolution, we use QEMU to examine the prevalence of the baseplus-offset addressing strategy relied upon in Section VI-A across five distinct V8 versions [45]. The versions span a three-year development period, from January 2022 to January 2025. For each version, we collect the machine instruction mnemonics generated by the V8 engine’s language processors during the trigger function execution. We then use the normalized Levenshtein distance to quantify the mnemonic-sequence similarity across V8 versions. Table III presents our findings for Ignition. Results for Turbofan are nearly identical. Measurement-wise, similarity drops sharply after version 11.0, suggesting substantial source code variance. To identify the origin of this drop amid the thousands of files modified in each release, we collect the symbols associated with each logged instruction in the traces. Using the instruction population per symbol as our metric, we compare versions 10.0, 12.0 and 13.0, focusing on differences exceeding 30%. The primary contributors are (i) additional runtime checks, (ii) increased loop-dispatching handling, (iii) restructured inline caching and property-lookup for JS object access, and (iv) changes to load/store handlers. Despite these changes, we validate on Rocket Core that S URF trojans successfully trigger and perform code injection across all tests in Table III. These findings show that the S URF-enabled code injection attack of Section V can persist over time, as IOP generation remains consistent over years of V8 engine evolution.

(1)

BFinstructions × CT IPC

90 90 92

S URF Activation

B. Operational Resilience

where ST represents the state transitions and OS represents the object size in elements. This yields a maximum trigger time BFtrigger-time =

91 91 92

JS Code

(3)

where STR is the number of regular states and STL the number of limited states, respectively. This modified reset condition in the number of limited states, makes exhaustive IOP-key search exponentially long. For reference, limiting the final three states of the seven-state FSM to two integer operations each increases the maximum trigger time to approximately 71 days. These results show that S URF trojans can be hardened against exhaustive key-recovery attempts with modest logic changes in the trigger FSM. To ensure clarity, the FSM implementation in Section V-C incorporates limited states.

8

Cumulative Probability (%)

Operand 1

under traffic interference on the ALU inputs from multiple endpoint workloads. We perform the relevant resiliency experiments on the Rocket Core FPGA implementation. To identify rare start value candidates for the IO:RESET pair used in our attack, we generate background traffic across the three main operational axes of a JavaScript runtime: justin-time compilation, garbage collection, and runtime execution. For this purpose, we use the widely adopted Sunspider, Octane, and Kraken JavaScript benchmark suites, which subject V8 to sustained computations beyond typical browser activity. Our setup counts ALU operand pairs whose free operand exhibits the address-like form described in Section V-C. We restrict the static operand start value to the range 0–0x3FFF (0–16383), for two reasons: (i) address-related integer operations may heavily populate values up to 0xFFF, as the RISCV addressing modes extensively use the 12-bit immediate field for effective address calculations, and (ii) extending the range to 0x3FFF provides sufficient room to move beyond this dense region while keeping the object size required by our attack practical and inconspicuous. We execute each suite for its recommended number of iterations on V8 versions 10.0 and 13.0, with individual measurements lasting up to 17 hours. Start values are grouped in sets of 1024 values, yielding a total of 16 sets. Because JavaScript does not control which ALU input receives each IOP operand, our setup tracks both operand orderings. Figure 6 shows the cumulative distribution of the measured start values. The results reveal a strongly skewed distribution for integer operations pairing address-like values with small operands. More than 90% of these small operands fall within the lowest 10 bits (i.e., at or bellow 0x3FF), while 99% lie below the 0x2000 threshold. This motivates selecting an infrequent start value just beyond 0x2000, where benign occurrences become substantially less likely while the object size remains practical. We empirically validate our findings by measuring the trigger success rate for eight start values above 0x2000 while concurrently executing varying workloads. Representative endpoint activity is hard to model because it spans highly heterogeneous resource demands. We therefore combine the above JS benchmark suites with the Phoronix Test Suite [46]. The latter provides standardized Linux benchmarks representative of common endpoint resource usage: storage and database activity with FIO and SQLite benchmarks; network traffic with iPerf; memory and cache stress workloads with MBW and Multichase; program launching and scheduling with OSBench and Hackbench; and compute-intensive cryptographic, compression, and image decoding workloads via Stress-NG. We use the default configuration of each selected benchmark and randomly select two start values from each of the sets 9, 10, 11 and 13, to experiment on Rocket Core. Each experiment includes the parallel execution of two processes. The first sequentially executes the above benchmarks spanning a period of approximately 4 hours. During this time period, the second process randomly selects one of the trigger functions in Figure 5, starts the V8 engine, and executes the selected code using either Ignition or Turbofan. Since the S URF trojan

Cumulative Probability (%)

100 98 96 94 92 90

V8 Version - Benchmark v8_10.0 - Octane v8_13.0 - Octane v8_10.0 - Kraken v8_13.0 - Kraken v8_10.0 - Sunspider v8_13.0 - Sunspider

Operand 2

100 98 96 94 92

[0 [0x x0,0 40 x3F 0,0 F] x7 FF [0x ] C0 0,0 xF [0x FF 14 ] 00 ,0x 17 [0x FF 1C ] 00 ,0x 1F [0x FF 24 ] 00 ,0x 27 [0x FF 2C ] 00 ,0x 2F [0x FF 34 ] 00 ,0x 37 [0x FF 3C ] 00 ,0x 3F FF ]

90

V8 Version - Benchmark v8_10.0 - Octane v8_13.0 - Octane v8_10.0 - Kraken v8_13.0 - Kraken v8_10.0 - Sunspider v8_13.0 - Sunspider

Start Value Sets for a 16K Element Object

Fig. 6. Cumulative probability distribution of IOP start values in Octane, Kraken and Sunspider benchmark suites.

Context Switching Resilience: Over a CPU’s lifetime, benign workloads may inadvertently advance the trigger FSM. The reset mechanism of Section IV-B protects S URF-enabled offensives from such transient progressions, but introduces a caveat during the activation stage. As execution of the HT control software is time-sliced by the OS-enforced context switching, a benign integer operation satisfying the reset condition may abort an offensive midway its activation stage. This is consistent with prior work highlighting context switching as a challenge for HT offensives [4, 6, 9]. Nevertheless, the activation window is short—determined by the FSM depth, the trigger code, and its runtime realization—relative to the processor uptime, making this risk tolerable. Importantly, attackers can further minimize the risk by carefully selecting a “rare” enough start value for the IO:RESET pair of Figure 2. We note here that rareness in general-purpose computing is inherently workload-dependent. Accordingly, prior work approximates it empirically through representative benchmarks [5, 7, 8, 12, 26] or heuristics [6, 8, 9, 14, 27]. We evaluate the resilience of our trigger circuit—and consequently of the code injection attack—to context switching interference. Our methodology consists of two stages. First, we explore from the S URF-trigger’s point of view, the existence of rare start values in runtime-related traffic. Second, we select several of these rare start values to test the attack’s robustness

9

uses the same IOP to alternate between the enable and disable state, we execute the trigger function twice. The process then sleeps for a few seconds before repeating the cycle of random selection and execution for a total of 1600 times, yielding 3200 total trigger toggles per start value. The results across all tested offsets show a trigger success rate that exceeds 99%. We argue that IOPs remain highly resilient to context switching events, enabling reliable activation and deactivation of S URF trojans under realistic operating conditions.

TABLE IV S URF S TAND -A LONE M ETRICS .

Design

# Comb. Cells

# Seq. Cells

Frequency (GHz)

Static Leakage (mW)

Dynamic Power (mW)

S URF

518

100

2.0

0.35

4.32

vectorized to track operand pairs across ALUs, letting a shared FSM to advance on their aggregated result. A key concern is the simultaneous processing of multiple IOP elements in the same cycle, since the FSM advances by only one state per cycle. To avoid this, IOP elements must reach ALUs in separate cycles. This separation arises naturally in JavaScript due to the intermediate instructions added by runtime checks. For example, lowering the For function in Figure 5 under V8 version 13.0 places more than 2000 instructions between consecutive IOP-relevant calculations, allowing the FSM to maintain correct pattern recognition. Likewise, this large spacing mitigates out-of-order effects, allowing IOP instructions to mirror their program order upon execution. Consider also that RISC-V is a load-store architecture, performing address calculations via integer execution units. In contrast, register-memory architectures like x86 [59–62] delegate this calculation to address generation units or AGUs. Thus, an adversary will target the AGUs to track the IOP. To verify that V8 preserves the same base-plus-index addressing strategy across architectures, we execute the trigger functions in Figure 5 on an x86 build of V8 on QEMU. Ignition and Turbofan traces show that array accesses use movzbl instructions with indexed addressing. The effective address is computed through an AGU adding two architectural registers containing the array base pointer and the accessed index. Thus, the activation principle underlying our strategy in Section V-B extends naturally to x86-class processors. Finally, we synthesize the S URF trojan we used in our code injection attack on a 28nm node process using the Genus tool from Cadence. The synthesis results in Table IV indicate that its timing is compatible with clock frequencies reported by commercial x86 processors at the same process node [63].

VII. S OFTWARE - BASED D EFENSES Our threat model assumes a processor 3PIP containing a S URF trojan is integrated into a chip, passes standard security evaluations, and reaches the market as a COTS product. Trust verification in deployed COTS devices is particularly challenging [21], as many trojan defenses rely on assumptions unavailable in this setting. Approaches requiring hardware design modifications (e.g., sensor implants [47]), white-box access to the design IP [48, 49] or golden reference models (e.g., sidechannel signatures [50]) are unsuitable on a finished product. Processing element redundancy [51] is likewise impractical for cost-sensitice end-user devices. In practice, manufacturers often mitigate hardware faults through software, even at the expense of performance [52]. Because S URF trojans target end-user devices at scale, runtime detection and mitigation is particularly important, as product recalls can be prohibitively expensive [53, 54]. We therefore focus on software-based defenses [21, 55] that require no hardware modifications. The work of Hasan et al. [21] aims at trojan detection via software execution redundancy. Their approach partitions programs into code blocks, generates structurally different but semantically equivalent variants, and executes them to induce different internal switching activity that may expose HT behavior. However, their approach is vulnerable to trojans triggered through diverse code variants. This renders it ineffective against S URF trojans, which can be activated by different integer instructions and structurally dissimilar code as shown in Tables II and III. Moreover, their method targets payloads that induce transient data corruption, and may therefore miss attacks such as ours that restore the original program state. In a similar direction, Marcelli et al. [55] prevent trojan activation via code obfuscation. Their technique applies four functionality-preserving assembly-level mutations to eliminate instruction patterns used as trigger sequences, including those of the A2 trojan [5]. However, the authors note their method is ineffective against trigger circuits that monitor values on data paths, which is the principle our trigger operates on.

IX. C ONCLUSIONS This work introduces S URF, a new class of hardware trojans that can be reliably activated without requiring arbitrary code execution on the victim CPU. To achieve that, S URF-trigger circuits leverage the predictable hardware manifestation of integer operations that can be expressed in high-level code and reach the victim system through runtime systems prevalent in modern software stacks. We prototype a S URF trojan inside a RISC-V processor and demonstrate a code-injection attack that hijacks the control flow of the V8 JavaScript engine in a Linux environment, enabling arbitrary machine code execution. Our analysis shows that S URF-triggers can evade signaturebased defenses through diverse activation stimuli, resist exhaustive key search attempts, and remain robust to context switching events and runtime software updates. Together, these properties allow S URF trojans to maintain a durable

VIII. S URF -T RIGGER (M ICRO ) ARCHITECTURAL P ORTABILITY A portable S URF-trigger provides a reusable primitive that can target multiple microarchitectures with limited modification. Rocket Core features a single ALU, unlike industrygrade RISC-V [56–58] and x86 [59, 60] superscalar processors. Superscalar execution, however, does not fundamentally constrain a design stage attacker: the trigger logic can be

10

and evasive foothold, enabling prolonged offensive campaigns that target end-user devices. To the best of our knowledge, this work is the first to systematically address the practical challenges of activating CPU hardware trojans via runtime engines, demonstrating their threat to end-user devices.

[15] J. Zhang and Q. Xu, “On hardware trojan design and implementation at register-transfer level,” in 2013 IEEE International Symposium on Hardware-Oriented Security and Trust (HOST), 2013. [16] A. Hepp, T. Perez et al., “A pragmatic methodology for blind hardware trojan insertion in finalized layouts,” in Proceedings of the 41st IEEE/ACM International Conference on Computer-Aided Design, 2022. [17] S. Parvin, M. Goli et al., “Trojan-d2: Post-layout design and detection of stealthy hardware trojans - a risc-v case study,” in Proceedings of the 28th Asia and South Pacific Design Automation Conference, 2023. [18] J. Rajendran, V. Vedula, and R. Karri, “Detecting malicious modifications of data in third-party intellectual property cores,” in 2015 52nd ACM/EDAC/IEEE Design Automation Conference (DAC), 2015. [19] D. Li, Q. Zhang et al., “Hardware trojan detection using effective property-checking method,” 2022. [20] N. Fern, S. Kulkarni, and K.-T. T. Cheng, “Hardware trojans hidden in RTL don’t cares — automated insertion and prevention methodologies,” in IEEE International Test Conference (ITC), 2015. [21] M. Hasan, J. Cruz et al., “Trojan resilient computing in COTS processors under zero trust,” 2022. [22] Y. Jin, N. Kupp, and Y. Makris, “Experiences in hardware trojan design and implementation,” in IEEE International Workshop on Hardware-Oriented Security and Trust, 2009. [23] D. G. Mahmoud, W. Hu, and M. Stojilovic, “X-attack: Remote activation of satisfiability don’t-care hardware trojans on shared FPGAs,” in 30th International Conference on Field-Programmable Logic and Applications (FPL), 2020. [24] W. Hu, L. Zhang et al., “Why you should care about don’t cares: Exploiting internal don’t care conditions for hardware trojans,” in IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 2017. [25] A. Hepp and G. Sigl, “Tapeout of a RISC-V crypto chip with hardware trojans: a case-study on trojan design and pre-silicon detectability,” in Computing Frontiers Conference, 2021. [26] C. Kison, O. M. Awad et al., “Security implications of intentional capacitive crosstalk,” IEEE Trans. Inf. Forensics Secur., 2019. [27] M. Kuo, C. Hu, and K. Lee, “Time-related hardware trojan attacks on processor cores,” in 2019 IEEE International Test Conference in Asia (ITC-Asia), 2019. [28] M. Xue, C. Gu et al., “Ten years of hardware trojans: a survey from the attacker’s perspective,” IET Comput. Digit. Tech., 2020. [29] Y. Alkabani and F. Koushanfar, “Extended abstract: Designer’s hardware trojan horse,” in IEEE International Workshop on Hardware-Oriented Security and Trust, 2008. [30] M. Tehranipoor and F. Koushanfar, “A survey of hardware trojan taxonomy and detection,” IEEE Design &

R EFERENCES [1] S. Adee, “The hunt for the kill switch,” IEEE Spectrum, 2008. [2] B. Larin. Operation triangulation: The last (hardware) mystery. [Online]. Available: https://securelist.com/ope ration-triangulation-the-last-hardware-mystery/111669/ [3] D. Goodin. 4-year campaign backdoored iPhones using possibly the most advanced exploit ever. [Online]. Available: https://arstechnica.com/security/2023/12/exp loit-used-in-mass-iphone-infection-campaign-targeted-s ecret-hardware-feature/ [4] N. G. Tsoutsos and M. Maniatakos, “Fabrication attacks: Zero-overhead malicious modifications enabling modern microprocessor privilege escalation,” IEEE Trans. Emerg. Top. Comput., 2014. [5] K. Yang, M. Hicks et al., “A2: Analog malicious hardware,” in IEEE Symposium on Security and Privacy (SP), 2016. [6] A. De, M. N. I. Khan et al., “Hartbleed: Using hardware trojans for data leakage exploits,” IEEE Trans. Very Large Scale Integr. Syst., 2020. [7] V. Gohil, H. Guo et al., “Attrition: Attacking static hardware trojan detection techniques using reinforcement learning,” in ACM SIGSAC Conference on Computer and Communications Security, 2022. [8] K. Dharsee and J. Criswell, “Jinn: Hijacking safe programs with trojans,” in 32nd USENIX Security Symposium, 2023. [9] A. Moschos, F. Monrose, and A. D. Keromytis, “Towards practical fabrication stage attacks using interrupt-resilient hardware trojans,” in IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2024. [10] C. S. Chuah, A. Hepp et al., “Trojan assets and attack vectors in processors,” in 25th International Symposium on Quality Electronic Design (ISQED), 2024. [11] K. Z. Snow, F. Monrose et al., “Just-in-time code reuse: On the effectiveness of fine-grained address space layout randomization,” in IEEE Symposium on Security and Privacy (SP), 2013. [12] J. Zhang, Y. Zhang et al., “HIT: A hidden instruction trojan model for processors,” in Design, Automation & Test in Europe Conference & Exhibition (DATE), 2020. [13] S. T. King, J. Tucek et al., “Designing and implementing malicious hardware,” in USENIX Workshop on LargeScale Exploits and Emergent Threats (LEET), 2008. [14] A. Moschos, K. Valakuzhy, and A. D. Keromytis, “On the feasibility of remotely triggered automotive hardware trojans,” in 2022 International Conference on Electrical, Computer, Communications and Mechatronics Engineering (ICECCME), 2022.

11

Test of Computers, 2010. of the 11th International Workshop on Cryptographic [31] A. Dauman, “Opening up the black box [ip encryption],” Hardware and Embedded Systems, 2009. Electronics Systems and Software, 2006. [49] E. Love, Y. Jin, and Y. Makris, “Proof-carrying hardware [32] E. Persson. The suppliers making the iPhone possible. intellectual property: A pathway to trusted module acqui[Online]. Available: https://quartr.com/insights/compan sition,” IEEE Transactions on Information Forensics and y-research/the-suppliers-making-the-iphone-possible Security, 2012. [33] N. G. Tsoutsos, C. Konstantinou, and M. Maniatakos, [50] L. N. Nguyen, C. Cheng et al., “Creating a backscattering “Advanced techniques for designing stealthy hardware side channel to enable detection of dormant hardware trojans,” in Proceedings of the 51st Annual Design Autrojans,” IEEE Trans. Very Large Scale Integr. Syst., tomation Conference (DAC), 2014. 2019. [34] M. Musch, C. Wressnegger et al., “New kid on the [51] M. Beaumont, B. Hopkins, and T. Newby, “Safer path: web: A study on the prevalence of webassembly in Security architecture using fragmented execution and the wild,” in Detection of Intrusions and Malware, and replication for protection against trojaned hardware,” in Vulnerability Assessment, 2019. Design, Automation & Test in Europe Conference & [35] H. Harnes and D. Morrison, “Sok: Analysis techniques Exhibition (DATE), 2012. for webassembly,” Future Internet, 2024. [52] P. Kocher, J. Horn et al., “Spectre attacks: Exploiting [36] J. Vijayan. (2024) Google chrome zerospeculative execution,” in IEEE Symposium on Security day bug under attack, allows code injection. and Privacy (SP), 2019. https://www.darkreading.com/cloud-security/google[53] E. Smith, “How a minor calculation error cost intel half chrome-zero-day-bug-attack-code-injection. a billion dollars,” 2020. [37] CVE-2026-11645: Google Chrome V8 RCE Vulnerability. [54] M. Isaac, “Fast action holds intel error to mere $1 [Online]. Available: https://www.sentinelone.com/vulner billion,” 2011. ability-database/cve-2026-11645/ [55] A. Marcelli, E. Sanchez et al., “Defeating hardware [38] V. Team. (2017) Launching ignition and turbofan. trojan in microprocessor cores through software obfushttps://v8.dev/blog/launching-ignition-and-turbofan. cation,” in IEEE 19th Latin-American Test Symposium [39] K. Asanović, R. Avizienis et al., “The rocket chip (LATS), 2018. generator,” Tech. Rep., 2016. [Online]. Available: [56] C. Chen, X. Xiang et al., “Xuantie-910: A commercial http://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EE multi-core 12-stage pipeline out-of-order 64-bit high perCS-2016-17.html formance risc-v processor with vector extension : Indus[40] P. Szor and P. Ferrie, “Hunting for metamorphic,” in trial product,” in ACM/IEEE 47th Annual International Virus bulletin conference, 2001. Symposium on Computer Architecture (ISCA), 2020. [41] Z. Zuo, Q. Zhu, and M. Zhou, “On the time complexity [57] W. Wang, “Enabling risc-v total computing solutions into of computer viruses,” IEEE Transactions on Information future applications,” https://www.andestech.com/wp-con Theory, 2005. tent/uploads/04 Andes Enabling-RISC-V-Total-Compu ting-Solutions-into-Future-Applications.pdf, 2025. [42] Y. Song, M. E. Locasto et al., “On the infeasibility of modeling polymorphic shellcode,” in Proceedings of the [58] C. Lam, “Inside sifive’s p550 microarchitecture,” https://chipsandcheese.com/p/inside-sifives-p55014th ACM Conference on Computer and Communicamicroarchitecture, 2025. tions Security (CCS), 2007. [43] L. Yujian and L. Bo, “A normalized levenshtein distance [59] WikiChip. (2019) Zen 2 - Microarchitectures - AMD. [Online]. Available: https://en.wikichip.org/wiki/amd/m metric,” IEEE transactions on pattern analysis and maicroarchitectures/zen 2 chine intelligence, 2007. [44] M. Polychronakis, K. G. Anagnostakis, and E. P. [60] AMD. Software optimization guide for the amd zen4 microarchitecture. [Online]. Available: https: Markatos, “An empirical study of real-world polymor//docs.amd.com/v/u/en-US/57647 phic code injection attacks,” in Proceedings of the 2nd USENIX Conference on Large-Scale Exploits and Emer- [61] D. Kanter, “Intel’s sandy bridge microarchitecture,” https://www.realworldtech.com/sandy-bridge/7/, 2011. gent Threats (LEET), 2009. [45] V8. V8 javascript engine - releases. [Online]. Available: [62] INTEL. Intel 64 and ia-32 architectures optimization reference manual, volume 2. [Online]. Available: https://github.com/v8/v8/tags https://www.intel.com/content/www/us/en/content-detai [46] Phoronix test suite. [Online]. Available: https://www.ph ls/787036 oronix-test-suite.com/ [47] Y. Cao, C.-H. Chang, and S. Chen, “A cluster-based dis- [63] U. Pirzada. VIA benchmarks Isaiah II brand new x86 processor to rival Intel Bay Trail and AMD Kabini tributed active current sensing circuit for hardware trojan platforms. [Online]. Available: https://wccftech.com/via detection,” IEEE Transactions on Information Forensics -demos-isaiah-ii-x86-bay-trail-amd-kabini-platforms/ and Security, 2014. [48] R. S. Chakraborty, F. Wolff et al., “Mero: A statistical approach for hardware trojan detection,” in Proceedings

12