arXiv:2607.01356v1 [cs.CR] 1 Jul 2026
Chameleon: Recovering Cyber-Physical Systems from Memory Corruption Attacks via ML Surrogates Mohsen Salehi
Karthik Pattabiraman
The University of British Columbia Vancouver, Canada [email protected]
The University of British Columbia Vancouver, Canada [email protected]
Abstract—Cyber-physical systems (CPSs) are increasingly deployed in every aspect of our lives and can be compromised through memory corruption vulnerabilities, allowing attackers to hijack the control flow and take over the system. Existing techniques mostly focus on detecting such attacks but respond by terminating or halting execution upon attack detection, which is not acceptable in CPSs used in safety-critical tasks, as interrupted tasks can have catastrophic consequences. Other techniques replace compromised CPS components with simplified defaults that degrade system behavior, or reboot the system upon attack detection. We propose Chameleon, a novel framework for automatically recovering CPSs from memory corruption attacks using machine learning (ML)-based surrogates trained at compartment granularity that nearly replicate their original compartments’ behavior but do not have the same memory corruption vulnerabilities. Upon attack detection, Chameleon replaces the compromised compartment with its trained surrogate. We implemented Chameleon using the LLVM compiler and evaluated its efficiency and effectiveness on seven different robotic vehicles (RVs), including simulated and real ones. We found that Chameleon can generate surrogates that closely approximate the original compartments (with an average R2 =0.96), successfully recover the system despite real-world memory corruption attacks unlike prior approaches, and complete their tasks while incurring low performance and memory overhead.
1. Introduction Cyber-physical systems (CPSs) are deployed across safety-critical infrastructures from medical devices to robotic vehicles (RVs). Most CPS software, including firmware, is developed using languages such as C and C++, which are prone to memory corruption vulnerabilities (e.g., buffer overflows). For instance, a study of two widely used open-source RVs’ firmware [1], ArduPilot [2] and PX4 [3], found that more than half of all patched firmware bugs stem from memory corruption. An attacker who exploits such a vulnerability can hijack the control flow, and potentially cause loss of control resulting in catastrophic failure (§2.1). Existing software defenses such as control flow integrity (CFI) [4], [5] and data flow integrity (DFI) [6] can detect
memory corruption attacks, but they either terminate the process, or halt execution upon error detection. However, this response is insufficient for CPSs, as these systems operate continuously in safety-critical environments. For example, abruptly terminating or halting execution of an RV midoperation can cause it to crash. Thus we need techniques for recovering CPSs after an attack has occurred, i.e., resilience. Different techniques have been proposed for resilience, and they fall into three main categories: (i) physical recovery, (ii) software or hardware redundancy, and (iii) memory corruption attack recovery. All of these techniques face fundamental limitations. (1) Physical attack recovery techniques [7], [8], [9], [10] are only effective against physical attacks such as GPS spoofing and not memory corruption attacks. (2) Software or hardware redundancy techniques [11], [12], [13] are effective against random faults, but are insufficient against memory corruption attacks, since redundant instances have the same underlying vulnerability. (3) Approaches such as rebooting system components [14], [15], [16], or replacing the compromised system part with a simplified instance that returns a default value [17], either have long recovery times or result in unsafe behavior, making them impractical for CPSs with real-time and safety constraints such as RVs. Our main insight is that if we replace the compromised part of the system at compartment granularity with a behaviourally equivalent form in a different representation, such as an arithmetic form, the system will be resilient to memory corruption attacks. This is because the arithmetic form will not contain the same vulnerabilities as it will not have low-level code such as pointer manipulations. This is backed by our observation that many aspects of the CPS perform computations exhibiting consistent behavioral patterns that can be learned via ML techniques such as neural network (NN) models. This insight is inspired by a long line of work in approximate computing [18], [19] and high-performance computing (HPC) [20], [21], [22], where parts of an application are replaced with similar ML models for performance acceleration (not for security). We propose Chameleon, a technique for recovering CPSs from memory corruption attacks. Chameleon replaces the compromised compartment with an equivalent form that preserves the same functionality and behavior even
under attack. Chameleon has two main innovations: (1) Training ML-based surrogates at compartment granularity that achieve fine-grained behavioral approximation, respect CPS resource constraints, and do not contain the memory corruption vulnerabilities of the original compartment, and (2) automatically identifying the input-output variable sets of each firmware compartment to enable accurate surrogate training, with no manual effort from developers. Innovation 1. Existing ML-based detection methods train the model on the entire system as a blackbox (i.e., the input-output relationship of the entire CPS), limiting their detection to coarse-grained anomalies in overall system behavior. Even if these techniques are adapted for recovery,they would require replacing the entire system even when only a single component is compromised, removing features the system needs for mission completion. On the other hand, training surrogates at the function level improves accuracy but incurs prohibitive performance overheads given the large number of functions in CPS firmware. To address this granularity trade-off, Chameleon uses software compartmentalization [23], which provides a balanced level of granularity to partition the CPS firmware and train an ML-based surrogate for each compartment to approximate its behavior while meeting CPS resource constraints. However, training surrogates at the compartment level introduces the challenge of determining the appropriate input-output variable sets to collect and train on for closely approximating each compartment’s behavior, which Innovation 2 addresses. Innovation 2. In contrast to coarse-grained recovery and detection approaches that only consider physical inputs and outputs of an entire CPS (e.g., sensor measurements in RVs), Chameleon employs automated dataflow analysis to identify the input-output variable sets and CPS state variables (e.g., position, velocity, sensor measurements) at a finer granularity (i.e., at the compartment level). This enables Chameleon to collect training data in benign environments using the identified variable sets and train an ML surrogate to approximate each compartment’s behavior. At runtime, upon attack detection, Chameleon replaces the compromised compartment with the ML surrogate without inheriting the vulnerabilities of the original compartment. At runtime, Chameleon leverages existing detection techniques (i.e., CFI and DFI) [17] to detect memory corruption attacks and identify the corresponding compromised compartment. Upon attack detection, Chameleon disables the compromised compartment and replaces it with the trained ML surrogate, which replicates the compartment’s behavior, to compensate for the disabled compartment and maintain the system’s functionality. Since the surrogate is an ML model composed of arithmetic operations, it is unlikely to have exploitable memory corruption vulnerabilities. Therefore, the CPS is able to complete its tasks with nearly the same functionality even under attack (as we show later). To the best of our knowledge, Chameleon is the first attack recovery technique that automatically generates surrogate compartments with similar behavior to the original compartments using ML models, and replaces the compromised compartment at runtime upon attack detection with
the corresponding trained surrogate to successfully recover the system from memory corruption attacks. We use RVs for evaluating Chameleon because they are widely deployed in safety-critical applications, and are susceptible to memory corruption attacks; however, Chameleon can be generalized to other CPSs. Contributions. We make four contributions as follows. • Propose a recovery technique that trains an ML-based surrogate at the compartment level to approximate each compartment’s behavior and, upon attack detection, replaces the compromised compartment with its trained ML-based surrogate that closely preserves the original compartment’s behavior. • Propose an automated dataflow analysis that identifies input-output variable sets for each compartment and collects training datasets across different tasks. • Design Chameleon, a framework that integrates the above techniques to enable CPSs to recover from memory corruption attacks. Chameleon is implemented using the LLVM compiler [24], making it portable across different CPS devices. • Evaluate Chameleon on four simulated and three real RVs, all running one of two widely used open-source autopilot systems, ArduPilot or PX4, across a diverse range of scenarios and missions. We also evaluate it against realistic memory corruption attacks. The results demonstrate that (1) Chameleon can generate surrogate compartments that closely approximate compartment behavior, achieving an average R2 =0.96. (2) Chameleon successfully completes multiple types of missions with only minimal deviation from the original mission destinations, achieving a mean deviation of 5.4 ± 2.2m. (3) Across five missions, under attack scenarios, Chameleon successfully recovers all missions with a mean deviation of 7.9m, while Gecko [17], an approach that replaces the compromised compartment with a simplified version returning default values results in mission failures (i.e., deviation > 10 m) across all five missions. (4) Chameleon incurs an average performance overhead of 8.5% and an average firmware size overhead of ≈9% on real RVs. We also find that the RVs satisfy their real-time constraints with no deadline misses even after Chameleonis deployed.
2. Background 2.1. Memory Corruptions Embedded systems software, including RV firmware, is typically written in C and C++ because they enable low-level hardware control and efficient execution. Unfortunately, these languages provide no built-in memory safety, resulting in memory corruption vulnerabilities such as buffer overflows. Attackers can exploit such vulnerabilities to manipulate device behavior or take full control of the system’s execution flow [25], e.g., control-flow hijacking attacks. Control flow hijacking attacks occur when a code pointer, such as a function pointer (forward edge) or a return
address (backward edge), becomes corrupted. By hijacking the control flow, attackers can either execute malicious payloads injected into the application stack [25] (code injection attacks) or reuse existing code sequences (gadgets) from the victim application [26] (code reuse attacks). Security mechanisms like Data Execution Prevention (DEP), which marks memory regions as either writable or executable (i.e., W ⊕ X ), mitigate code injection attacks. However, code reuse attacks bypass these defenses by injecting addresses of existing instructions into corrupted code pointers, altering the original control flow in an arbitrarily expressive way. Code reuse attacks are categorized into Return-Oriented Programming (ROP) [26] and Jump-Oriented Programming (JOP) [27], based on whether the corrupted pointers target return instructions or function pointers, respectively.
2.2. Robotic Vehicle Control As mentioned, we focus on RVs in our evaluation. Therefore, we explain their operation in this section. As shown in Figure 1, RVs rely on a combination of autopilot software and hardware components, including onboard sensors and actuators such as GPS and gyroscope, to execute their missions. ArduPilot [2] and PX4 [3] are two widely used open-source autopilot software platforms that implement the core control algorithms and system management functions required for autonomous operation.
Sensors (GPS, ...)
yaw
Actuators (Motors) roll
Autopilot Software Input
Output
Parameters
Parameters
pitch
Figure 1: RV Control Loop. In addition to flight control, autopilot software supports the following functionalities: ground communication, which maintains telemetry with a ground control station (GCS); mission management, which involves defining mission plans and controlling operational modes such as takeoff and landing; and safety monitoring, which handles obstacle avoidance. Autopilot software operates as a periodic workload executed in a loop, including tasks such as update receive, which processes incoming MAVLink messages from the GCS. Autopilot software runs in both simulated and physical vehicles. In simulation, environments such as SITL [2] and Gazebo [28] reproduce real-world conditions, enabling safe testing without the cost and risk of physical deployment. In real RVs, the autopilot software is embedded within the firmware, where it directly interacts with physical sensors and actuators to control flight operations. The onboard sensors capture the attitude and movement of an RV across six degrees of freedom (6DoF), which include three axes (x, y, z) and three rotational directions: roll, pitch, and yaw. These sensor measurements, such
as accelerometer and gyroscope readings, alongside other inputs received from the ground control station, are fed into the main control loop in the autopilot software. The control loop then computes the appropriate outputs through a controller module, such as a proportional-integral-derivative (PID) controller, based on the current vehicle state. Finally, the resulting signals are forwarded to actuators, such as motors, to drive the vehicle’s physical behavior.
3. Motivation and Threat Model In this section, we explain the main limitations of current defense techniques (§3.1). We then describe how Chameleon addresses these limitations (§3.2), and discuss the assumptions and threat model of our work (§3.3). Finally, we show an example of how RVs operate and the insight behind Chameleon (§3.4).
3.1. Current Techniques’ Limitations L1: No Recovery. Although many detection techniques have been proposed to address memory corruption attacks, they do not provide recovery after attack detection. For instance, techniques such as control flow integrity (CFI) [29], [30], [31], [32] and memory protection [33], [34], [35] terminate the process or halt execution upon detection, resulting in task failure. Other techniques require hardware redesign to prevent or detect memory corruption vulnerabilities [36], [37]. This makes them unsuitable for many CPS deployments and, like the techniques discussed above, they provide no recovery upon attack detection. L2: Incur High Overheads. Another class of techniques uses redundancy, either in software, such as Nversion programming [11], [12], or in hardware, such as BlueBox [13], to recover from attacks. These approaches run multiple instances simultaneously and switch to a backup when an attack is detected. Other techniques simply reboot the system upon attack detection [38]. These techniques incur high overhead or depend on rebooting upon attack detection, which makes them unsuitable for CPS that are often resource-constrained and have real-time requirements. L3: Physical-attacks Only. Techniques [9], [10] have been proposed to recover RVs by replacing the PID controller or sensors with ML-trained models. However, these techniques are designed for physical attacks on RVs’ sensors, whereas in memory corruption attacks, the attacker exploits memory vulnerabilities to manipulate software behavior, such as hijacking the control flow. Thus, replacing the PID controller or sensors with trained models is not sufficient to recover from such attacks. L4: Removing Functionalities. Some recovery techniques have been proposed to replace a compromised component, whether hardware or software, with a simpler version to recover the device from attacks. A technique for RVs [10], replaces a compromised sensor with a software prediction, under physical attacks. In another approach for CPS [17] called Gecko, a compromised software component is replaced with a degraded version that returns a default
value. However, these techniques remove the main functionality, which can not only fail to recover the system but also cause system failure, thus compromising safety. L5: Coarse Granularity. In recent years, different techniques have leveraged advances in ML to improve the security of CPSs. However, these techniques have two main limitations. First, they focus on detection [39] (L1) or recovery from physical attacks in RVs [7] rather than memory corruption attacks in CPSs (L3). Second, most of them [40] treat the entire system as a blackbox and rely only on sensor measurements. As a result, they can only detect discrepancies at a macro level (entire system) in system behavior. If these techniques are adapted for recovery, they replace the entire system with a blackbox-trained model that lacks the fine-grained features that are often required for mission completion, such as updating CPS state variables.
3.2. Our Approach: Chameleon We introduce Chameleon, a new recovery technique that provides three solutions (S1-3) to address the current techniques’ limitations (L1-L5). S1: Addressing L3 and L5. Chameleon trains ML-based surrogates at a finer granularity than prior ML-based detection techniques, which treat the entire CPS as a blackbox (L5), to approximate the behavior of each compartment, enabling replacement of only the compromised component with its surrogate rather than the entire system. To do so, Chameleon partitions CPS firmware into task-level compartments [23], detailed in §4.1. Since surrogates are unlikely to contain the memory-unsafe operations such as pointer arithmetic they are less susceptible to memory corruption vulnerabilities (L3). S2: Addressing L1, L2, and L4. At runtime, Chameleon leverages existing CFI and DFI techniques to monitor the compartments and detect memory corruption attacks (L3). Upon attack detection, the compromised compartment is isolated and replaced with its trained ML surrogate, preserving the compartment’s functionality (L4) and allowing the CPS to complete its task despite the attack (L1). Therefore, Chameleon requires neither hardware modifications nor redundancy in running simultaneous instances (L2). S3: Addressing L5. To train an ML-based surrogate at a finer granularity (i.e., compartment level), we propose an automated dataflow analysis that employs two heuristics (discussed in §4.2) to identify the entry and exit functions of each compartment, the corresponding input and output variables, and the relevant CPS state variables (e.g., position and velocity in RVs), to capture each compartment’s behavior, which is then used to collect the training dataset. Table 1 summarizes the prior techniques and their limitations. As shown, none of the prior techniques addresses all limitations entirely, while Chameleon does.
3.3. Assumptions and Threat Model Assumptions. We make the following four assumptions. First, we assume that Chameleon has access to either the
TABLE 1: Summary of current techniques and their limitations. : some approaches in the category do not have the limitation. ”-”: the limitation is not applicable. Techniques
Recovery? (L1)
Traditional Detection N-version Programming Physical Attack Recovery Gecko Chameleon
% ! ! ! !
Low Overhead (L2) % ! !
Attack Types (L3)
Keep Functionality (L4)
Memory corruption Physical attacks Memory corruption Memory corruption
! % !
Fine-grained (L5)
% ! !
firmware’s source code or its LLVM intermediate representation (IR) [24], since Chameleon operates on LLVM IR. Second, we assume that an attacker cannot interfere with the training process, including poisoning the training data for the ML models. This is reasonable because NN training is typically conducted in a controlled environment that is isolated from external modifications [41]. Third, we assume the existence of a security reference monitor (i.e., CFI and DFI) that can detect when a memory corruption vulnerability (e.g., buffer overflows) has been exploited. This is a standard assumption in recovery techniques [9], [17] - attack detection is orthogonal to our technique and is addressed by existing work. Fourth, hardware components (e.g., I/O peripherals), the privileged software components (e.g., firmware), and Chameleon’s own components are considered trustworthy. Threat Model. We consider an adversary who can carry out remote attacks against the target system without having root privileges or physical access. We further assume that the core system software is written by honest developers and is benign; however, it may include memory corruption vulnerabilities such as buffer overflows. An adversary who discovers and exploits such a vulnerability can redirect the firmware’s control flow and invoke security-critical functions through code-reuse attacks (control-flow violations, §2.1). Further, we do not consider code injection attacks due to the presence of memory protection unit (MPU) [17], [23]. Hardware-level corruptions, physical attacks such as sensor spoofing, data-only attacks, and side-channel attacks are outside the scope of this work.
3.4. Motivating Example: Robotic Vehicles To illustrate the main insight behind Chameleon, we use an example drawn from RVs. Figure 2 shows an example function of the update receive task in ArduPilot, a popular autopilot used in RVs. We injected a buffer overflow vulnerability into this function (Lines 5 and 9), which receives messages from the GCS, processes them, and acts accordingly, such as changing state variables. If an attacker exploits this vulnerability, they can hijack the control flow of safety-critical components such as the flight control program, potentially causing the RV to crash. The main insight behind Chameleon is that if this task is replaced with an ML-based surrogate such as a long short-term memory (LSTM) neural network, the system can continue operating safely despite the attack. Figure 3 shows a high-level overview of LSTM, a variant of recurrent neural
1 2 3 4 5 6 7 8 9 10
void GCS_MAVLINK::update_receive(uint32_t max_time_us) { // Allocation Variables uint16_t nbytes = _port->available(); uint8_t buf[128]; // Fixed-size receive buffer for (uint16_t i=0; i<nbytes; i++){ buf[i] = _port->read(); // No bounds check: Overflows when nbytes > 128 // Process received message } // ... }
1 2 3 4 5 6 7 8 9 10 11 12 13
// All sizes are compile-time constants from model architecture void lstm_step(float input[INPUT_SIZE],float h[ HIDDEN_SIZE], float c[HIDDEN_SIZE]) { float f[HIDDEN_SIZE], ig[HIDDEN_SIZE], g[HIDDEN_SIZE], o[HIDDEN_SIZE]; mat_mul(Wf, input, f); sigmoid_ip(f,HIDDEN_SIZE); mat_mul(Wi, input, ig); sigmoid_ip(ig,HIDDEN_SIZE); mat_mul(Wc, input, g); tanh_ip(g,HIDDEN_SIZE); mat_mul(Wo, input, o); sigmoid_ip(o,HIDDEN_SIZE); for (int j = 0; j < HIDDEN_SIZE; j++) { c[j] = f[j]*c[j] + ig[j]*g[j]; h[j] = o[j] * tanh(c[j]); } }
Figure 2: An example function of the update receive task with an injected buffer overflow vulnerability.
networks (RNNs) that computes arithmetic operations on fixed weight matrices to predict the next output. As shown in Figure 4, LSTM inference operates on fixed-size tensors whose dimensions are determined by the model architecture at load time, with no user-controlled buffer lengths, no pointer arithmetic, and no dynamic memory allocation during inference. These are precisely the conditions that make the original compartment exploitable, and they are structurally absent from the surrogate’s inference path. While inference libraries are themselves written in C/C++ and may contain memory corruption vulnerabilities, the attack surface differs fundamentally: the original vulnerability is triggered by raw, attacker-controlled byte streams with user-controlled lengths, whereas the surrogate receives only a fixed-size vector of typed floating-point values. Library vulnerabilities, even if they exist, are typically triggered by malformed model files at load time, not by runtime inputs. As we are the ones training the model and providing the model files (at training time), the original exploit cannot be redirected at the surrogate.
Input
LSTM Layers W·x + U·h + b [Matrix Calculations]
Fully Connected Layer W·h + b [Matrix Calculations]
Output
Figure 3: High-level architecture of the LSTM-based surrogate model. Each layer performs fixed arithmetic operations on weight matrices.
4. Design: Chameleon In this section, we present the design of Chameleon, our attack recovery technique for CPSs that addresses the limitations discussed in §3. Figure 5 shows Chameleon’s workflow, consisting of four main phases (labeled with black circles): (1) compartmentalization and instrumentation, (2) dataflow analysis, (3) data collection and training, and (4) runtime monitoring. Chameleon generates ML-based surrogates that replicate each compartment’s behavior enabling runtime replacement when a compartment is exploited, thereby allowing the CPS to recover and continue its task. We describe the different phases of the system (§4.1-§4.4).
Figure 4: Pseudocode of one LSTM inference step. All array dimensions are compile-time constants; no user-controlled lengths or pointer arithmetic appear in the inference path. The first three phases of Chameleon (i.e., Compartmentalization & Instrumentation, Dataflow Analysis, and Model Construction) are all executed offline.
4.1. Compartmentalization & Instrumentation Compartmentalization. Unlike prior ML-based detection techniques [40], [42], [43], [44] that consider the entire system as a blackbox and train models on the input-tooutput relationship of the entire system, Chameleon trains surrogates at a finer granularity to improve behavioral approximation accuracy and replace only the compromised part rather than the entire system (S1 in §3.2). A straw man solution to address this limitation would be training a surrogate for each function inside CPS firmware, but this would incur significant overhead and is hence not suitable for resource- and time-constrained CPSs. Therefore, there is a trade-off among performance, memory overhead, and model accuracy in terms of behavioral similarity to the original firmware part. Our key insight is that the optimal granularity is to partition firmware into groups of closely related functions that together represent a CPS task, and frequently interact at runtime, minimizing cross-partition calls while keeping each partition semantically meaningful in terms of behavior. Thus, Chameleon uses firmware compartmentalization [17], [23] to partition the firmware based on CPS tasks (e.g., update altitude in RVs), enabling both efficient surrogate training for each compartment instead of each function and efficient recovery by replacing only the exploited partition rather than the entire system. A compartment consists of an isolated code region together with its associated data, peripherals, and permitted control transfers. Each instruction belongs to exactly one compartment [23]. Firmware compartmentalization is formulated as a graph partitioning problem [23], where the process begins by constructing a program dependence graph [45] (PDG) that captures all control-flow, global data, and peripheral dependencies of the firmware, with type-based alias analysis [46] used to resolve pointer targets, as done in prior work [23]. Based on factors such as performance constraints and the
1 Instrumentation & Compartmentalization
3 Dataset Collection & Training Model 2
F1
Firmware Code
Firmware Analysis (LLVM Compiler)
F3
Program Dependence Graph (PDG)
4 Runtime Monitoring, Detection, Recovery
Instrumented Firmware
Run on the Device + Trained Models
INs
F3
OTs
INs
INs
F3 F4
F3 OTs
F1
OTs INs INs
Running on Set of Missions
F4
F1 INs
F2
F4
OTs
F2
INs
DataFlow Analysis (LLVM Compiler)
F2
INs
F1 OTs
F2
INs
OTs
INs
F4
F3
Model F1 OTs
F2
INs
OTs
INs
F4
Figure 5: Overview of Chameleon’s operation, including its four main phases: the first three are performed offline, while the fourth is performed online. compartmentalization policy (i.e., task-based partitioning in Chameleon), the algorithm groups related functions into individual partitions called compartments, aiming to minimize calls between compartments at runtime. Additionally, all data shared across compartments, such as global variables, are grouped into a shared compartment. At the end of the compartmentalization process, the firmware is partitioned into different compartments based on tasks. Instrumentation for Detection and Recovery. After the firmware is divided into different compartments, it needs to be instrumented for three purposes: (1) monitoring intercompartment transitions, (2) checking CFI and DFI within compartments, and (3) replacing the compromised compartment with its trained surrogate upon attack detection. For (1) and (3), Chameleon instruments compartment transitions to invoke the Chameleon Monitor, which verifies the validity of each transition according to the PDG. Also, the instrumentation allows Chameleon to replace the compromised compartment with its corresponding trained surrogate upon detecting an attack, compensating for the disabled compartment (§4.4). For (2), Chameleon monitors the control flow of indirect calls and memory writes within each compartment. It detects an attack when one of them constitutes a malicious write or control transfer, and identifies the compromised compartment at runtime. This part of the process (i.e., (1) monitoring compartment transitions and (2) CFI/DFI checking) is orthogonal to Chameleon [17], [23].
4.2. Dataflow Analysis Once compartmentalization is complete and the compartments are identified, the next phase of the Chameleon process is static dataflow analysis to identify (1) the entry and exit functions of each compartment and (2) the input and output variable sets of each compartment. The key insight is that, in order to train a surrogate that accurately approximates the behavior of the original compartment efficiently for resource-constrained CPSs, we train the model based on entry and exit functions, since they characterize each compartment’s behavior, rather than considering all functions within each compartment. Therefore, these identified entry and exit functions, along with their input and output variable sets, are then used in the next phase to collect the training dataset and train a surrogate for each compartment (§4.3).
To perform this phase automatically, Chameleon provides a component called Chameleon Identifier that implements two heuristics in two sub-processes. First, the Chameleon Identifier takes the compartments and generated PDG as input and outputs the list of entry and exit functions for each compartment. To do so, it performs static analysis on the call instructions (in LLVM IR) of each function in a compartment and applies three conditions. First, if a function in one compartment invokes a function in another compartment, the Chameleon Identifier records the caller as an exit function for its compartment and the callee as an entry function for its corresponding compartment (e.g., F1 and F2 in Figure 5). Second, if a function has outgoing calls but no other function ever calls it, it is identified as an entry function, since such functions are typically invoked directly by the system scheduler (e.g., the controller in RVs) rather than by other firmware functions. Third, if a function is called by other functions within the same compartment but itself makes no calls, it is identified as an exit function, as it represents a terminal computation node whose output propagates either upward through the compartment’s call chain or to the user. Algorithm 1 demonstrates how the Chameleon Identifier identifies the entry and exit functions for each compartment. As an initialization step (lines 2–15), Chameleon Identifier first iterates through all functions and their call instructions in each compartment to populate two auxiliary sets: CalledF uncs, which records every function that is called by at least one other function (line 9), and IntraCalledF uncs[Ci ], which records callees that reside within the same compartment (lines 10–12). In the next step (lines 16–32), for each call instruction I of every function f in compartment Ci , if the callee belongs to a different compartment Cj , the Chameleon Identifier records f as an exit function of Ci and the callee as an entry function of Cj (lines 20–23). After processing all call instructions of f , the two additional conditions are checked: if f has no callers anywhere in the firmware, i.e., f ∈ / CalledF uncs, yet has at least one call instruction, i.e., calls(f ) ̸= ∅, it is added to EntryF uncs[Ci ] (lines 25–27); if f is called by at least one function within the same compartment, i.e., f ∈ IntraCalledF uncs[Ci ], but has no call instructions, i.e., calls(f ) = ∅, it is added to ExitF uncs[Ci ] (lines 28–30). The output consists of the EntryF uncs and
ExitF uncs sets for each compartment (line 33).
Algorithm 1 Identifying Entry and Exit Functions Input: Set of compartments C = {C1 , . . . , Cn }, each Ci containing a set of functions; calls(f ) = the set of call instructions in f Output: EntryF uncs[Ci ], ExitF uncs[Ci ] for each Ci ∈ C 1 function I DENTIFY E NTRY E XIT(Compartments) 2 for each compartment Ci ∈ C do 3 EntryF uncs[Ci ] ← ∅ 4 ExitF uncs[Ci ] ← ∅ 5 IntraCalledF uncs[Ci ] ← ∅ 6 for each function f ∈ Ci do 7 for each call instruction I in f do 8 callee ← target of I 9 CalledF uncs ← CalledF uncs ∪ {callee} 10 if callee ∈ Ci then 11 IntraCalledF uncs[Ci ] ← IntraCalledF uncs[Ci ] ∪ {callee} 12 end if 13 end for 14 end for 15 end for 16 for each compartment Ci ∈ C do 17 for each function f ∈ Ci do 18 for each call instruction I in f do 19 callee ← target of I 20 if ∃ Cj ∈ C, Cj ̸= Ci s.t. callee ∈ Cj then 21 ExitF uncs[Ci ] ← ExitF uncs[Ci ] ∪ {f } 22 EntryF uncs[Cj ] ← EntryF uncs[Cj ] ∪ {callee} 23 end if 24 end for 25 if f ∈ / CalledF uncs ∧ calls(f ) ̸= ∅ then 26 EntryF uncs[Ci ] ← EntryF uncs[Ci ] ∪ {f } 27 end if 28 if f ∈ IntraCalledF uncs[Ci ] ∧ calls(f ) = ∅ then 29 ExitF uncs[Ci ] ← ExitF uncs[Ci ] ∪ {f } 30 end if 31 end for 32 end for 33 return EntryF uncs, ExitF uncs 34 end function
Second, once the entry and exit functions of each compartment are identified, Chameleon Identifier determines the input and output variables of these functions for each compartment. The purpose of this sub-process is to capture the value changes of these variables along with CPS state variables (e.g., velocity and position in RVs) to construct the input and output vectors of the learning model, which are then used in the next phase, surrogate training (§4.3). Algorithm 2 demonstrates how the Chameleon Identifier identifies the input and output variable sets for each compartment. It takes the list of identified entry and exit functions as input, and iterates through the instructions within all basic blocks of each function (lines 5–21). Then, it classifies variables according to two criteria: (1) input variables are those used but not defined within the function, such as function arguments or global variables (lines 8– 12); (2) output variables are those assigned a value that is propagated outside the function, excluding purely local variables (lines 13–18). The Chameleon Identifier repeats this for all entry and exit functions of each compartment and finalizes the InputV ars and OutputV ars sets (line 23), which, along with CPS state variables, describe the
behavior of that compartment and are then used in the next phase for training surrogates (§4.3). Algorithm 2 Identifying Input, Output Variables Input: EntryF uncs[Ci ], ExitF uncs[Ci ] for each compartment Ci ∈ C Output: InputV ars[Ci ], OutputV ars[Ci ] for each Ci ∈ C 1 function I DENTIFY IOVARS(EntryF uncs, ExitF uncs) 2 for each compartment Ci ∈ C do 3 InputV ars[Ci ] ← ∅ 4 OutputV ars[Ci ] ← ∅ 5 for each function f ∈ EntryF uncs[Ci ] ∪ ExitF uncs[Ci ] do 6 for each basic block B in f do 7 for each instruction I in B do 8 for each operand v used by I do 9 if v is not defined within f then 10 InputV ars[Ci ] ← InputV ars[Ci ] ∪ {v} 11 end if 12 end for 13 if I is a store or return instruction then 14 Let v be the value stored or returned 15 if v escapes f (non-local) then 16 OutputV ars[Ci ] ← OutputV ars[Ci ] ∪ {v} 17 end if 18 end if 19 end for 20 end for 21 end for 22 end for 23 return InputV ars, OutputV ars 24 end function
4.3. Chameleon’s ML-based Model Construction After identifying the task-based compartments and the input/output variable sets of their entry and exit functions in the prior phases, this phase proceeds in three steps: (1) instrumenting the firmware to log the identified variable values along with CPS state variables at runtime, (2) collecting a benign dataset capturing each compartment’s behavior, and (3) training a surrogate ML model for each compartment offline for runtime deployment (§4.4). (1) Instrumentation for Logging. To train ML-based surrogates, Chameleon needs to collect a benign dataset capturing each compartment’s behavior. To this end, Chameleon provides an instrumentation component called Logger that takes as input the firmware and the identified entry and exit functions along with their input and output variables from the previous phase. Logger iterates through the firmware and, upon identifying one of those functions, inserts logging calls at the start and end of that function to record the value changes of the input and output variables along with CPS state variables at runtime. (2) Dataset Collection. Since there is no standard and public training dataset available for CPSs, we need to collect a comprehensive dataset for model training that captures each compartment’s behavior from both simulated and real systems in different scenarios and environmental conditions. To do so, we provide an automated component that generates diverse tasks across different scenarios and exe-
cutes the instrumented CPS firmware from the previous step. Then, Logger collects the time-series dataset of input/output variable changes along with the CPS state variables (e.g., velocity, position, body angular rates in RVs) during those missions. For instance, in RVs (ArduCopter, a firmware variant of ArduPilot [2]), a mission includes taking off, following different paths to different waypoints, and finally returning to the launch point and landing. Given the default logging frequency of the system (e.g., 10 Hz in ArduCopter, i.e., every 100 milliseconds), Logger will collect 600 data samples (e.g., input and output vector pairs) in a 60-second mission, which are then used for offline training. To train ML-based surrogates that capture the behavior of each compartment, Chameleon requires a dataset consisting of sequences of past identified inputs along with CPS state variables for that compartment used to predict the corresponding outputs and CPS state variables. However, the dataset collected through logging is time-series data in a vector-to-vector format. To improve the accuracy and robustness of Chameleon’s learning model, we apply a sliding window to convert it into a windowed sequential dataset, where each sample pairs a sequence of past observations as input with a single predicted output at the next time step (window-based framing). For instance, Chameleon trains surrogate A for compartment A using a sequence of past inputs and CPS state variables of compartment A within a window of W time steps (e.g., tk , . . . , tk+W ) to predict the corresponding outputs and CPS state variables at the next time step tk+W +1 . Finally, the output of this step is the processed training dataset, which is used to train the surrogates in the next step. (3) Offline Training. After collecting and processing the dataset, Chameleon uses long short-term memory (LSTM) neural networks, a type of recurrent neural network (RNN), to train a surrogate that approximates the behavior of the corresponding compartment by learning the mapping between its input and output sequences. Chameleon uses LSTM for the following three reasons: (1) ML techniques such as logistic regression and random forests, are primarily designed for classification or regression on static, labeled datasets, whereas our goal is prediction based on the sequential history of time-series data. Furthermore, LSTMs can model nonlinearities, enabling them to learn complex relationships between the inputs and outputs of CPSs [7]. (2) LSTM uses a sequence of data for training instead of a single input, which improves model accuracy, as discussed in the previous step. (3) LSTM’s gated memory architecture enables the model to retain and selectively propagate information across long input sequences, which is critical for capturing the temporal dependencies in CPS dynamics, e.g., Euler angles in RVs. Gradient-based models such as Convolutional Neural Networks (CNNs) and simple RNNs do not preserve these dependencies due to the vanishing gradient problem [39], [47]. Our generated LSTM surrogates must be lightweight due to resource-constrained CPSs and can closely approximate the behavior of their compartments. To address this, Chameleon employs a hyperparameter optimization process
to tune key settings such as the number of layers, hidden units, and recurrent cell types, using cross-validation on different mission datasets to ensure accuracy and convergence of the trained surrogate. The details are discussed in §6.2. Since the purpose of Chameleon is not classification, we do not use a softmax layer. Furthermore, the model uses dropout regularization during training and ReLU activation on the dense layers, with a final linear output layer for continuous regression. The model is trained using mean squared error (MSE) as the loss function and the Adam optimizer.
4.4. Chameleon Runtime After generating surrogates for each compartment, the final phase of the Chameleon process is runtime monitoring: monitoring the system and, upon attack detection, replacing the compromised compartment with its trained surrogate so that the system continues its mission with nearly the same functionality of the replaced compartment. This phase has two steps: (1) Attack Detection and (2) Runtime Recovery. (1) Attack Detection. The instrumented firmware from phase 1 (§4.1) is deployed on the system, which adds the Chameleon Monitor that monitors the inter-compartment transitions, CFI and DFI within compartments, and detects memory corruption attacks and identifies the compromised compartment upon detecting an attack. Once an attack is detected and the compromised compartment is identified, the Chameleon Monitor triggers the recovery mode and isolates the compromised compartment and replaces it with the corresponding ML surrogate. (2) Runtime Recovery. When the recovery mode is triggered and the compromised compartment is invoked by other compartments or by the system scheduler (e.g., the controller in RVs), the Chameleon Monitor sends the current input variables and CPS state variables to the corresponding ML surrogate that replaced it. The surrogate’s predicted outputs are then used as the outputs of the compromised compartment instead of the compartment’s outputs. By replacing the compromised compartment with its ML surrogate, Chameleon preserves the compartment’s functionality through behavioral approximation while eliminating the exploited vulnerability. Since the surrogate operates in a numerical representation rather than unsafe low-level code, it will not contain the same memory corruption vulnerability, preventing the attacker from continuing to hijack the control flow after the replacement.
5. Chameleon Implementation Compartmentalization & Instrumentation. Chameleon builds on top of existing compartmentalization and instrumentation infrastructure [17], [23] to partition the firmware into task-based compartments and instrument it, but modifies the infrastructure to invoke Chameleon Monitor at compartment transitions and replace the compromised compartments with their corresponding surrogates upon attack detection. Both components are implemented as LLVM passes [48].
Dataflow Analysis. This phase is implemented as a component called Chameleon Identifier with two LLVM analysis passes and a Python program that operate on the compartmented firmware’s IR. The first LLVM pass and the Python program identify entry and exit functions by iterating over the PDG and call instructions within each firmware’s function and checking the conditions discussed in §4.2. The second pass takes the identified entry and exit functions of each compartment as input, iterates over the instructions of those functions within their basic blocks, and identifies their input and output variables based on Algorithm 2. Training. Logger is implemented as an LLVM module pass that takes the firmware, compartment information, and the identified entry and exit functions of each compartment along with their input and output variables as input. After collecting data from the instrumented CPS at runtime, an LSTM surrogate model for each compartment is trained offline using TensorFlow 2.18 [49] and Keras 3.10. The resulting surrogate models are then integrated into the CPS software, such as RV’s autopilot software. Runtime Monitoring. The Chameleon Monitor is implemented in C++ and integrated into the instrumented firmware image (e.g., the RV’s autopilot software).
6. Chameleon Evaluation This section describes our experimental setup and the evaluation of Chameleon across two aspects: effectiveness and efficiency. Effectiveness measures Chameleon’s ability to generate surrogates that can approximate compartment behavior and recover the device upon attack detection, while efficiency captures the runtime and memory overhead of Chameleon, both during offline training and at runtime.
6.1. Experimental Setup Subject RVs. We evaluated Chameleon on three real RVs (shown in Figure 6), an Aion R1 ground rover (Aion rover) [50] and a DIY drone (Pixhawk drone) [51], and a Tarot 650 drone (Tarot drone), and four simulated RV systems, running across two popular open-source autopilot platforms, ArduPilot [2] and PX4 [3], specifically: (1) ArduPilot’s quadplane [52] (ArduPlane), (2) ArduPilot’s quadcopter [53] (ArduCopter), (3) ArduPilot’s ground rover [54] (ArduRover), and (4) PX4’s quadcopter [55] (PXCopter). For the simulated systems, we used QGroundControl [56], APM SITL (Software-In-The-Loop) [2], and Gazebo [57]. The real RVs are commodity systems based on the Pixhawk platform [58], which is built on an ARM Cortex architecture and integrates ArduPilot or PX4 firmware, a flight management unit (FMU), memory, sensors, and I/O interfaces. Dataset. Since no standard publicly available dataset exists for training and evaluating Chameleon surrogate models, we conduct more than 100 missions for each subject RV with varying mission distances, durations, environmental conditions, and flight paths (circular, polygonal, and straightline paths with multiple waypoints) to capture representative real-world RV behavior. Each mission lasts between 1 and
(a) Aion rover
(b) Pixhawk drone
(c) Tarot drone
Figure 6: Real RV systems used in the experimental setup. 10 minutes, producing 600 to 6000 timesteps logged at 10 Hz (every 100 ms). The collected data is merged into a single dataset per compartment, then partitioned into 70% for training, 15% for validation, and 15% for testing.
6.2. Effectiveness Ablation Studies. To select the surrogate model architecture, we evaluate different candidate designs varying in the number of layers, hidden units, and recurrent cell types, balancing predictive performance against model complexity across the subject RVs. Figure 7 shows the results for the four most representative candidate architectures. M0 uses three stacked LSTM layers with widths 256, 128, and 64 followed by two fully-connected layers of 128 and 64 units, totaling 545K parameters. M1 reduces depth to two LSTM layers of widths 256 and 128 with two fully-connected layers of 128 and 64 units (504K parameters). M2 replaces standard LSTM layers with bidirectional LSTM layers of widths 128 and 64 followed by two fully-connected layers (420K parameters), while M3 (our selected design) uses two LSTM layers both of width 128 followed by two fullyconnected layers of 64 and 32 units (230K parameters). M3 achieves R2 =0.974, representing the best predictive performance-overhead trade-off, as M0, M1, and M2, despite marginally higher R2 scores of 0.979, 0.981, and 0.980, respectively, each require more than 1.8× more parameters. Furthermore, M2’s bidirectional design incurs higher memory overhead since bidirectional LSTMs maintain hidden states for both forward and backward passes, doubling the memory overhead at runtime. Therefore, we employ M3 as the surrogate architecture for all compartments across all subject RVs in our experiments. Surrogate Convergence. After identifying the best surrogate architecture, we train M3 independently for compartments across the subject RVs. To ensure the reliability of the reported results, we conduct 10 independent training runs with different random weight initializations. Figure 8 reports the mean training MSE loss (red solid line) and mean validation MSE loss (blue dashed line) across all 10 runs at each epoch, where the shaded region represents the standard deviation (std-dev) across runs. Both losses decrease steadily from an initial value of approximately 3 × 10−4 and converge within 100 epochs to a final value of approximately 6 × 10−5 . The training and validation loss curves remain close to each other throughout the entire training process, indicating that the model learns generalizable patterns from the training data. The narrow standard deviation bands confirm that M3 reaches consistent
Parameter Count (K)
600K
M0: 3LSTM(256 128 64) +2FC(128 64)
500K
M1: 2LSTM(256 128) +2FC(128 64)
400K
M2: 2BiLSTM(128 64) +2FC(128 64) Optimal
300K
M3: 2LSTM(128 128) +2FC(64 32)
200K
R²=0.95
5 0.9 0.97 8 1.0 0
0
0.9
R² Score
0.9
5 0.8
0 0.8
5 0.7
0.7
0
100K
Figure 7: Predictive performance-overhead trade-off across surrogate model architectures. Each point represents a candidate architecture evaluated on R2 (higher is better) and parameter count (lower is better). M3 achieves competitive R2 =0.974 while requiring more than 1.8× fewer parameters than all other top-performing architectures.
predictions against the actual value for two of the RV state variables over a 150-second mission in Figure 9. For Velocity, the surrogate achieves R2 =0.9995 with a mean absolute error of 0.1971 m/s, with the predicted values closely tracking the actual measurements across the full dynamic range of the signal (±30 m/s). For Yaw, the surrogate achieves R2 =0.9997 with a mean absolute error of 0.0062, demonstrating precise heading prediction throughout the flight. In both cases, the absolute error remains small and stable over time, confirming that the surrogate closely approximates the compartment behavior. Across the 10 training runs described in ”Surrogate Convergence”, the surrogate consistently achieves R2 =0.9995 ± 0.0001 with MAE of 0.197 ± 0.006 m/s for Velocity and MAE of 0.006 ± 0.0003 for Yaw, demonstrating robust and reproducible approximation of compartment behavior across diverse initializations. 30
train_loss val_loss
0.4
10 0 10
0.3 0.2 0.1
20 30
0.0 0
25
50
75
Time (s)
100
125
150
0
25
50
75
Time (s)
100
125
150
(a) Surrogate model prediction vs. actual Velocity, showing R2 = 0.9995 with a mean absolute error of 0.1971 m/s. 1.00
Actual Predicted
0.75
10 4
Mean MAE = 0.0062
0.020
0.50
0.015
|Error|
0.25
Yaw
Loss
Mean MAE = 0.1971
0.5
|Error| (m/s)
Velocity (m/s)
convergence quality across all 10 runs, regardless of weight initialization, with a final training loss of 6.64 × 10−5 (stddev: 6.45 × 10−6 ) and validation loss of 6.05 × 10−5 (stddev: 1.85 × 10−5 ) at the final epoch. The validation loss remains marginally below the training loss throughout training, consistent with the expected behavior of regularized neural network models [59].
Actual Predicted
20
0.00 0.25 0.50
0.010 0.005
0.75
10 5
1.00
25
50
75
100
Epoch
125
150
175
200
Figure 8: Training and validation loss convergence over 10 independent runs with different random weight initializations. Solid and dashed lines represent the mean training and validation MSE loss, respectively, with shaded regions denoting ±1 standard deviation across runs. Surrogate Fidelity. We evaluate the fidelity of the trained surrogates through three aspects: (1) average predictive performance measured by R2 and mean absolute error (MAE), (2) time-series prediction on compartment outputs, and (3) the deviation in missions’ trajectories after replacing a compartment with its trained surrogate at runtime. We discuss the results for each of these. (1) Prediction Metrics. We measure the average R2 and MAE of the trained surrogates across different compartments of subject RVs discussed in §6.1. Across 10 independent training runs, surrogates achieve an average of R2 =0.96 and MAE=0.20, demonstrating consistent and reliable approximation of compartment behavior. (2) Time-series Prediction. We illustrate the surrogate
0.000 0
25
50
75
Time (s)
100
125
150
0
25
50
75
Time (s)
100
125
150
(b) Surrogate model prediction vs. actual Yaw, showing R2 = 0.9997 with a mean absolute error of 0.0062.
Figure 9: Surrogate model evaluation on two RV state variables. Each subfigure shows the predicted vs. actual timeseries (left) and the corresponding absolute error over time (right). Lower values are better. (3) Missions Deviation. To evaluate that surrogates can be replaced by compartments and they can closely approximate their behavior, we replace different compartments and run different missions and calculate the deviation from the target destination. We consider Chameleon as successful in recovery if at the end of the mission, the deviation from the original destination is less than 10m. This threshold accounts for the inherent positioning uncertainty of commodity GPS modules, which carry a typical accuracy offset of 5m [7], [60]. Since both the vehicle’s reported position and the destination coordinates are each subject to this uncertainty, these compound to a combined bound of 10m, which we adopt as the success criterion, similar to prior work [7], [9].
30
Actual Predicted
20
1.50
10 0 10
0.75
0.00 0
25
50
75
Time (s)
100
125
150
0
Actual Predicted
0.75
|Error|
Yaw
1.00
400
600
800
1000
Mission Distance (in meters)
1200
1400
Figure 10: Average deviation from the original destination after replacing the compartment with its surrogate across 10 different missions by Chameleon. Deviation less than 10m indicates mission success. Surrogate Generalization. To evaluate generalization across varying mission conditions, we assess the surrogate from Figure 9 on different missions. Among these, we report results on one of the most challenging missions (the worst-performing mission) - a 150-second mission spanning a cruise-to-maneuver transition in which the vehicle accelerates from steady cruise into full dynamic maneuver. Figure 11a and Figure 11b show the surrogate predictions against actual values for Velocity and Yaw, respectively, with the absolute prediction error shown on the right side of each subfigure. The surrogate achieves R2 scores of 0.9653 and 0.9994 with mean absolute errors of 0.5754 m/s and 0.0129 for Velocity and Yaw, respectively, confirming that the surrogate maintains reliable approximation of compartment behavior across different missions without retraining. Attack Evaluation. To evaluate Chameleon in realistic attack scenarios, we use the memory corruption vulnerabilities in RVs from Salehi et al. [61], which are inspired by realworld vulnerabilities [62], [63]. A buffer overflow is injected into a function that processes user input, allowing an attacker to hijack the control flow of the firmware. We run five missions with different distances, considering an attacker who exploited this vulnerability and injected corrupted data to manipulate the mission. We then measure the deviation from the target destination when Chameleon is triggered and replaces the compromised compartment with its trained surrogate. As mentioned earlier, a mission is considered successfully recovered if the deviation remains below 10m. Figure 12 (blue line) shows that all of five missions are successfully recovered by Chameleon with a mean deviation of 7.9m (range: 5.1–9.7m). For safety reasons, we performed
Mean MAE = 0.0129
0.03
0.00 0
200
150
0.01
0.75
0
125
0.02
0.50
2
100
0.04
0.00 0.25
4
75
Time (s)
0.05
0.25
6
50
0.06
0.50
8
25
(a) Surrogate model prediction vs. actual Velocity.
10
Deviation (in meters)
1.00
0.25
1.00
0
1.25
0.50
20 30
Mean MAE = 0.5754
1.75
|Error| (m/s)
Velocity (m/s)
We run 10 different missions on simulated RVs, as simulation allows accurate deviation measurement and closely reflects real-system behavior, with different scenarios including different distances (100m-1500m) and replace the compartment with its trained surrogate and measure the deviation from the original destination. As shown in Figure 10, we find that all 10 missions are successfully finished with a mean deviation of 5.4 ± 2.2m, with a maximum deviation of 8.9m, demonstrating that the surrogate model maintains mission accuracy within acceptable bounds (of 10m).
25
50
75
Time (s)
100
125
150
0
25
50
75
Time (s)
100
125
150
(b) Surrogate model prediction vs. actual Yaw.
Figure 11: Surrogate model evaluation on a different complex mission (cruise-to-maneuver transition), demonstrating generalization across varying mission conditions.
this evaluation on simulated RVs; however, we also tested the feasibility of the attack on the Aion rover. Comparison with Gecko. To demonstrate the necessity of preserving compartment behavior during recovery, we repeat the same five missions under the same attack, but replacing the compromised compartment with its default value, similar to the approach by Gecko [17]. Since Gecko’s publicly released implementation does not fully realize the system described in their paper, we re-implemented the relevant components based on their paper’s description and the partially available code to ensure a fair comparison. As can be seen in Figure 12, none of the missions with Gecko completes successfully under attacks, with deviations ranging from 29.4m to 69.2m and a mean deviation of 48.4m, which is 6× the mean deviation of Chameleon. This confirms that naive replacement without behavioral approximation is insufficient for mission recovery. We also observed that during Gecko’s recovery, the RV unexpectedly gained altitude before descending and landing or stalled (i.e., froze in place). This is because the default value (e.g., velocity) used by Gecko includes a vertical component recorded at mission start, which no longer reflects the vehicle’s actual state at recovery. Furthermore, we evaluated the same missions with no recovery mechanism (i.e., no-protection). Without recovery, the RV continues flying with corrupted values indefinitely; in practice, it would eventually crash (e.g., due to collisions or battery exhaustion from flying off-course). Therefore, we force-land it after a time equal to the average of Chameleon’s and Gecko’s completion time for each corresponding mission to ensure a fair comparison. As shown in Figure 12, deviations range from 26.9m to 380.3m with a
Deviation from Waypoint (m)
400
No Protection Gecko Chameleon
350 300 250 200 150 100 50 10
0
200
400
600
800
1000
Mission Distance (m)
1200
1400
Figure 12: Deviation under attack across five different missions: No-Protection, Gecko, and Chameleon. mean of 271m, and no mission completes successfully. The relatively low deviation in mission 1 (26.9m) is coincidental, as the forced landing happened to occur close to the waypoint, not because the RV was navigating correctly. Thus, Chameleon consistently recovers all missions with a deviation within the 10m threshold, achieving a 6× reduction in mean deviation compared to Gecko and 34× compared to no-protection.
6.3. Efficiency CPU and Memory Overheads. As discussed in §4.4, the only phase of Chameleon that is executed on the system at runtime is Chameleon Runtime. We measure its CPU overhead on the three real RVs described in §6.1, as simulated RVs depend on the computing platform and are thus unsuitable for this evaluation. There is a scheduler in these systems that tracks the total CPU time incurred by each task, and we use it to calculate the CPU overhead of Chameleon by analyzing the additional CPU time recorded by the scheduler when the RV is equipped with Chameleon. We find that the average CPU overhead incurred by Chameleon on real RVs is 8.5%, ranging from 8% to 9%. Further, Chameleon does not increase the RV’s overall mission time, and the RVs satisfy the real-time constraints despite Chameleon. Finally, the integration of Chameleon into the RV autopilot introduces an average firmware size overhead of ≈9%.
7. Discussion Although Chameleon addresses the limitations of current security techniques discussed in §3.1, it still has some limitations and opportunities for future work. Scalability. Although we evaluated Chameleon on RVs, Chameleon does not rely on any RV-specific hardware or firmware. Since Chameleon is implemented using the LLVM compiler, it can be applied to other CPSs as long as they meet the compartmentalization requirements of ACES [23], namely the presence of an MPU. Furthermore, the CPS must have sufficient computational resources to execute surrogates; for severely resource-constrained systems, model compression or quantization techniques may be required to meet real-time constraints.
Detection Techniques. Chameleon relies on existing CFI and DFI techniques for attack detection, whose accuracy affects recovery. In the case of a false positive, where a benign execution is incorrectly flagged as an attack, Chameleon replaces the compartment with its trained surrogate, which closely approximates the original behavior (R2 =0.96 on average, §6.2). Since the surrogate closely preserves the compartment’s functionality, a false positive results in only a minor behavioral deviation and is unlikely to disrupt the mission. In the case of a false negative, however, where an actual attack goes undetected, the compromised compartment may continue to execute without replacement. This is a limitation of the underlying detection technique rather than Chameleon itself; improving the sensitivity of CFI/DFI detection is an orthogonal research direction that, if addressed, would directly benefit Chameleon. Adaptive Attacks. An attacker aware of Chameleon may attempt to subvert the recovery mechanism through three strategies. First, the attacker may continue sending corrupt inputs to the compromised compartment after recovery is triggered. As discussed earlier, the surrogate does not have the same memory corruption vulnerabilities as the original compartment, and it is unlikely to be exploitable in the same manner. Although corrupt inputs may cause the surrogate to produce degraded outputs, the attacker can no longer hijack the control flow of the system, reducing the attack impact from a full system compromise to bounded output degradation. Second, the attacker may attempt to evade CFI/DFI detection entirely so that recovery is never triggered. As discussed in the Detection Techniques, this is a limitation of the underlying detection mechanism, and improving its sensitivity is an orthogonal direction that would directly benefit Chameleon. Finally, the attacker may attempt to tamper with the trained surrogate model. Since surrogates are trained offline prior to deployment, and attacks on ML training are outside the scope of this work, we do not consider such attacks. Furthermore, since the surrogates are integrated into the firmware and are assumed to be trustworthy, modifying them would require root privileges or physical access, which falls outside our threat model (§3.3).
8. Related work Attack Detection. Various techniques have been proposed to detect memory corruption attacks, including stack protection [64], [65], control flow integrity (CFI) [5], [32], data flow integrity (DFI) [6], memory protection [61], [66], [67], [68], hardware-based methods [36], [37], [69], [70], and compartmentalization-based approaches [23], [71] that apply the least-privilege principle. Mini-Me [39] employs an LSTM-based model to predict the RV controller’s expected ouputs, triggering a failsafe mechanism when the difference between the prediction and real measurements exceeds a threshold, to detect dataoriented attacks such as sensor spoofing. However, they focus solely on detection and, upon detecting an attack, terminate the process and alert the user without providing any recovery capability. Furthermore, unlike our work, they
do not consider training the ML model at a compartment granularity, which is essential for effective recovery. Attack Recovery. Recovery techniques for CPSs, particularly RVs, can be broadly categorized into three types: redundancy-based techniques, physical attack recovery, and memory corruption attack recovery. (1) Redundancy. Redundancy-based techniques are primarily designed for fault tolerance, enabling recovery by replacing faulty components with identical backup instances that execute concurrently, often involving system reinitialization. These techniques can be broadly categorized into hardware-based [13], [72], [73], [74] and software-based approaches [11], [12], [75]. Both types of techniques require either replicating physical components (e.g., processors or sensors) or maintaining multiple instances of an entire program or parts of it, such as N-version programming, switching to a backup upon failure. However, both incur significant overhead, either in hardware cost and design complexity or in concurrent execution, making them unsuitable for resource-constrained CPSs, including RVs. Furthermore, since all instances are typically implemented in memory-unsafe languages, they share the same class of memory corruption vulnerabilities and remain exploitable by an attacker, making these techniques ineffective for attack recovery. Recovery Blocks [76] (RBs) is a classic technique for fault-tolerance where an alternate implementation is invoked when an acceptance test on the primary’s output fails. While conceptually similar, Chameleon differs from RBs in two ways. First, alternates have to be manually implemented in RBs, whereas we learn surrogates automatically using ML. Second, RBs do not target security, and hence the alternates, being conventional implementations, remain susceptible to the same memory corruption vulnerabilities as the primary. Chameleon, in contrast, learns ML based surrogates that have a different representation from the original, and hence will not contain the same memory corruption vulnerabilities. (2) Physical Recovery. Many recovery techniques for physical attacks in RVs have been proposed [7], [9], [10], [77], [78], [79]. These techniques leverage two different approaches to enable recovery. First, some techniques [10], [77] use software-based pre-trained sensor models to replace the hardware sensors under attack and correct their measurements. Second, since relying solely on sensor measurements is not sufficient, other techniques [7], [9], [78] train the RV’s physical controller (i.e., PID) as a recovery controller. However, as mentioned in §3.1, these techniques focus on physical attacks in RVs and replace only the physical sensors or the PID controller upon attack detection, which is not effective for recovery from memory corruption attacks. (3) Memory Corruption Recovery. Different recovery techniques have been proposed including software rejuvenation [16], failure-oblivious computing [15], and microrebooting [80]. However, these techniques require rebooting the entire system or program each time an attack occurs, leading to prolonged unavailability [14]. Micro-rebooting techniques attempt to address this issue by rebooting only the affected part of the program or system, but it still incurs
significant overhead and, once rebooting is complete, that part remains susceptible to exploitation by attackers [17]. Failure-oblivious computing techniques attempt to prevent the program from crashing upon buffer overflow (e.g., out-of-bound reads) by returning artificial random values; however, they incorrectly alter the system’s behavior and introduce silent errors that may not manifest immediately, potentially leading to incorrect system operation [14]. Li et al. [17] proposed Gecko, which leverages software compartmentalization introduced in ACES [23] to partition firmware at the task level into individual compartments. Gecko employs CFI and DFI techniques to detect attacks at runtime. Upon detection, it replaces the compromised compartment with a simplified replacement version that returns pre-recorded default values captured during the device initialization phase, allowing other compartments to continue execution despite the removal of the original compartment. However, this replacement reduces system functionality, which may degrade overall system performance and prevent it from recovering from attacks. In our evaluation, Chameleon recovers all five missions under attacks, whereas Gecko results in failure of all of them (§6.2). Although developers can design custom compartments for recovery, doing so requires substantial manual effort, and system knowledge, making the approach time- and effort-intensive. Accelerated Substitution. Several techniques have been proposed to improve system performance by replacing parts of an application with surrogate models [18], [19], [20], [21], [22]. These approaches often leverage ML models such as NNs, which can offer higher efficiency. For example, ML surrogate models can be optimized through design choices such as the number of neural network layers, to trade off prediction accuracy and computational cost. These techniques inspired our design of Chameleon. However, they are designed for performance optimization rather than security and attack recovery. In particular, since their goal is performance, they only choose the most time-consuming code regions, train a surrogate to approximate the output, and leave the other parts of the application unchanged.
9. Conclusion We propose Chameleon, a framework for automatically recovering CPSs from memory corruption attacks using ML-based surrogates trained at compartment granularity. Chameleon addresses the limitations of existing techniques by automatically generating surrogates that closely approximate their original compartments’ behavior without being susceptible to the memory corruption vulnerabilities of low-level languages. Chameleon is implemented using the LLVM compiler and LSTM, making it portable to different CPSs. We evaluated Chameleon on seven different RVs, including both simulated and real ones, across diverse scenarios and real-world attacks. Our results show that Chameleon generates surrogates with an average of 96% behavioral similarity to the original compartments, successfully recovers the system and completes the tasks despite attacks while incurring low performance overhead. We also
compared Chameleon with Gecko [17] and a no-protection baseline across five missions under real-world memory corruption attacks. Only Chameleon successfully completed all missions (mean deviation 7.9 m), while Gecko and the noprotection baseline failed all missions with mean deviations of 48.4 m and 271 m, respectively. Finally, Chameleon incurs an average CPU overhead of 8.5% on real RVs.
References
[16] Y. Huang, C. Kintala, N. Kolettis, and N. D. Fulton, “Software rejuvenation: Analysis, module and applications,” in Twenty-fifth international symposium on fault-tolerant computing. Digest of papers. IEEE, 1995, pp. 381–390. [17] A. Li, J. Wang, and N. Zhang, “Software availability protection in {Cyber-Physical} systems,” in 34th USENIX Security Symposium (USENIX Security 25), 2025, pp. 1807–1825. [18] H. Esmaeilzadeh, A. Sampson, L. Ceze, and D. Burger, “Neural acceleration for general-purpose approximate programs,” in 2012 45th annual IEEE/ACM international symposium on microarchitecture. IEEE, 2012, pp. 449–460. [19] T. M. M. W. J. Nelson, A. Sampson, H. Esmaeilzadeh, and L. C. M. Oskin, “Snnap: Approximate computing on programmable socs via neural acceleration.”
[1]
H. Kim, M. O. Ozmen, Z. B. Celik, A. Bianchi, and D. Xu, “{PatchVerif}: Discovering faulty patches in robotic vehicles,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 3011–3028.
[2]
“Ardupilot software in the loop,” https://ardupilot.org/dev/docs/sitl-si mulator-software-in-the-loop.html, Last Accessed, June 2026.
[3]
“Px4 open source autopilot,” https://docs.px4.io/main/en/, Last Accessed, June 2026.
[4]
O. Arias, L. Davi, M. Hanreich, Y. Jin, P. Koeberl, D. Paul, A.-R. Sadeghi, and D. Sullivan, “Hafix: Hardware-assisted flow integrity extension,” 2015.
[5]
M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti, “Control-flow integrity principles, implementations, and applications,” ACM Transactions on Information and System Security (TISSEC), vol. 13, no. 1, pp. 1–40, 2009.
[22] W. Dong, G. Kestor, and D. Li, “Auto-hpcnet: An automatic framework to build neural network-based surrogate for high-performance computing applications,” in Proceedings of the 32nd International Symposium on High-Performance Parallel and Distributed Computing, 2023, pp. 31–44.
[6]
M. Castro, M. Costa, and T. Harris, “Securing software by enforcing data-flow integrity,” in Proceedings of the 7th symposium on Operating systems design and implementation, 2006, pp. 147–160.
[23] A. A. Clements, N. S. Almakhdhub, S. Bagchi, and M. Payer, “{ACES}: Automatic compartments for embedded systems,” in 27th USENIX Security Symposium (USENIX Security 18), 2018, pp. 65–82.
[7]
P. Dash, G. Li, Z. Chen, M. Karimibiuki, and K. Pattabiraman, “Pidpiper: Recovering robotic vehicles from physical attacks,” in 2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2021, pp. 26–38.
[24] “The llvm compiler,” https://llvm.org/, Last Accessed, June 2026.
[8]
F. Kong, M. Xu, J. Weimer, O. Sokolsky, and I. Lee, “Cyberphysical system checkpointing and recovery,” in 2018 ACM/IEEE 9th International Conference on Cyber-Physical Systems (ICCPS). IEEE, 2018, pp. 22–31.
[9]
P. Dash, E. Chan, and K. Pattabiraman, “Specguard: Specification aware recovery for robotic autonomous vehicles from physical attacks,” in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, 2024, pp. 1849–1863.
[10] H. Choi, S. Kate, Y. Aafer, X. Zhang, and D. Xu, “Software-based realtime recovery from sensor attacks on robotic vehicles,” in 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020), 2020, pp. 349–364. [11] S. Forrest, A. Somayaji, and D. H. Ackley, “Building diverse computer systems,” in Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No. 97TB100133). IEEE, 1997, pp. 67–72. [12] J. Ron, D. Gaspar, J. Cabrera-Arteaga, B. Baudry, and M. Monperrus, “Galapagos: Automated n-version programming with llms,” ACM Transactions on Software Engineering and Methodology, 2025. [13] F. Fei, Z. Tu, R. Yu, T. Kim, X. Zhang, D. Xu, and X. Deng, “Crosslayer retrofitting of uavs against cyber-physical attacks,” in 2018 IEEE International Conference on Robotics and Automation (ICRA). IEEE, 2018, pp. 550–557. [14] F. Qin, J. Tucek, J. Sundaresan, and Y. Zhou, “Rx: treating bugs as allergies—a safe method to survive software failures,” in Proceedings of the twentieth ACM symposium on Operating systems principles, 2005, pp. 235–248. [15] M. C. Rinard, C. Cadar, D. Dumitran, D. M. Roy, T. Leu, and W. S. Beebee, “Enhancing server availability and security through failureoblivious computing.” in Osdi, vol. 4, 2004, pp. 21–21.
[20] K. Schütt, P.-J. Kindermans, H. E. Sauceda Felix, S. Chmiela, A. Tkatchenko, and K.-R. Müller, “Schnet: A continuous-filter convolutional neural network for modeling quantum interactions,” Advances in neural information processing systems, vol. 30, 2017. [21] P. Sadowski, D. Fooshee, N. Subrahmanya, and P. Baldi, “Synergies between quantum mechanics and machine learning in reaction prediction,” Journal of chemical information and modeling, vol. 56, no. 11, pp. 2125–2128, 2016.
[25] L. Szekeres, M. Payer, T. Wei, and D. Song, “Sok: Eternal war in memory,” in 2013 IEEE Symposium on Security and Privacy. IEEE, 2013, pp. 48–62. [26] H. Shacham, “The geometry of innocent flesh on the bone: Returninto-libc without function calls (on the x86),” in Proceedings of the 14th ACM conference on Computer and communications security, 2007, pp. 552–561. [27] T. Bletsch, X. Jiang, V. W. Freeh, and Z. Liang, “Jump-oriented programming: a new class of code-reuse attack,” in Proceedings of the 6th ACM symposium on information, computer and communications security, 2011, pp. 30–40. [28] N. Koenig and A. Howard, “Design and use paradigms for gazebo, an open-source multi-robot simulator,” in 2004 IEEE/RSJ international conference on intelligent robots and systems (IROS)(IEEE Cat. No. 04CH37566), vol. 3. Ieee, 2004, pp. 2149–2154. [29] S. Etigowni, S. Hossain-McKenzie, M. Kazerooni, K. Davis, and S. Zonouz, “Crystal (ball) i look at physics and predict control flow! just-ahead-of-time controller recovery,” in Proceedings of the 34th Annual Computer Security Applications Conference, 2018, pp. 553– 565. [30] N. Burow, S. A. Carr, J. Nash, P. Larsen, M. Franz, S. Brunthaler, and M. Payer, “Control-flow integrity: Precision, security, and performance,” ACM Computing Surveys (CSUR), vol. 50, no. 1, pp. 1–33, 2017. [31] Y. Xia, Y. Liu, H. Chen, and B. Zang, “Cfimon: Detecting violation of control flow integrity using performance counters,” in IEEE/IFIP International Conference on Dependable Systems and Networks (DSN 2012). IEEE, 2012, pp. 1–12. [32] L. Davi, M. Hanreich, D. Paul, A.-R. Sadeghi, P. Koeberl, D. Sullivan, O. Arias, and Y. Jin, “Hafix: Hardware-assisted flow integrity extension,” in Proceedings of the 52nd Annual Design Automation Conference, 2015, pp. 1–6.
[33] N. S. Almakhdhub, A. A. Clements, S. Bagchi, and M. Payer, “µRAI: Securing Embedded Systems with Return Address Integrity,” in Network and Distributed Systems Security (NDSS) Symposium, 2020.
[51] L. Meier, P. Tanskanen, F. Fraundorfer, and M. Pollefeys, “Pixhawk: A system for autonomous flight using onboard computer vision,” in 2011 ieee international conference on robotics and automation. IEEE, 2011, pp. 2992–2997.
[34] J. Zhou, Y. Du, Z. Shen, L. Ma, J. Criswell, and R. J. Walls, “Silhouette: Efficient protected shadow stacks for embedded systems,” in 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 1219–1236.
[52] “Ardupilot plane,” https://ardupilot.org/plane/index.html, Last Accessed, June 2026. [53] “Ardupilot copter,” https://ardupilot.org/copter/index.html, Last Accessed, June 2026.
[35] A. A. Clements, N. S. Almakhdhub, K. S. Saab, P. Srivastava, J. Koo, S. Bagchi, and M. Payer, “Protecting bare-metal embedded systems with privilege overlays,” in 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 2017, pp. 289–303.
[54] “Ardupilot rover,” https://ardupilot.org/rover/index.html, Last Accessed, June 2026.
[36] M. T. I. Ziad, M. A. Arroyo, E. Manzhosov, R. Piersma, and S. Sethumadhavan, “No-fat: Architectural support for low overhead memory safety checks,” in 2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2021, pp. 916–929.
[56] “Qgroundcontrol,” https://qgroundcontrol.com/, Last Accessed, May 2026.
[37] P. Koeberl, S. Schulz, A.-R. Sadeghi, and V. Varadharajan, “Trustlite: A security architecture for tiny embedded devices,” in Proceedings of the Ninth European Conference on Computer Systems, 2014, pp. 1–14.
[55] “Px4 airframes,” https://docs.px4.io/v1.12/en/airframes/airframe ref erence.html, Last Accessed, May 2026.
[57] “Gazebo robot simulation,” https://gazebosim.org/home, Last Accessed, June 2026. [58] “Pixhawk,” https://ardupilot.org/copter/docs/common-pixhawk-overv iew.html, Last Accessed, June 2026.
[38] F. Abdi, C.-Y. Chen, M. Hasan, S. Liu, S. Mohan, and M. Caccamo, “Guaranteed physical security with restart-based design for cyberphysical systems,” in 2018 ACM/IEEE 9th International Conference on Cyber-Physical Systems (ICCPS). IEEE, 2018, pp. 10–21.
[59] N. Srivastava, G. Hinton, A. Krizhevsky, I. Sutskever, and R. Salakhutdinov, “Dropout: A simple way to prevent neural networks from overfitting,” Journal of Machine Learning Research, vol. 15, no. 1, pp. 1929–1958, 2014.
[39] A. Ding, P. Murthy, L. Garcia, P. Sun, M. Chan, and S. Zonouz, “Mini-me, you complete me! data-driven drone security via dnn-based approximate computing,” in Proceedings of the 24th International Symposium on Research in Attacks, Intrusions and Defenses, 2021, pp. 428–441.
[60] A. Vadduri, A. Benjwal, A. Pai, E. Quadros, A. Kammar, and P. Uday, “Precise payload delivery via unmanned aerial vehicles: An approach using object detection algorithms,” arXiv preprint arXiv:2310.06329, 2023.
[40] Y. Chen, C. M. Poskitt, and J. Sun, “Learning from mutants: Using code mutation to learn and monitor invariants of a cyber-physical system,” in 2018 IEEE Symposium on Security and Privacy (SP). IEEE, 2018, pp. 648–660. [41] D. Amodei, C. Olah, J. Steinhardt, P. Christiano, J. Schulman, and D. Mané, “Concrete problems in ai safety,” arXiv preprint arXiv:1606.06565, 2016. [42] J. Goh, S. Adepu, M. Tan, and Z. S. Lee, “Anomaly detection in cyber physical systems using recurrent neural networks,” in 2017 IEEE 18th international symposium on high assurance systems engineering (HASE). IEEE, 2017, pp. 140–145. [43] K. N. Junejo and J. Goh, “Behaviour-based attack detection and classification in cyber physical systems using machine learning,” in Proceedings of the 2nd ACM international workshop on cyberphysical system security, 2016, pp. 34–43. [44] A. Abbaspour, K. K. Yen, S. Noei, and A. Sargolzaei, “Detection of fault data injection attack on uav using adaptive neural network,” Procedia computer science, vol. 95, pp. 193–200, 2016. [45] J. Ferrante, K. J. Ottenstein, and J. D. Warren, “The program dependence graph and its use in optimization,” ACM Transactions on Programming Languages and Systems (TOPLAS), vol. 9, no. 3, pp. 319–349, 1987. [46] C. Lattner, A. Lenharth, and V. Adve, “Making context-sensitive points-to analysis with heap cloning practical for the real world,” ACM SIGPLAN Notices, vol. 42, no. 6, pp. 278–289, 2007. [47] Y. Bengio, P. Simard, and P. Frasconi, “Learning long-term dependencies with gradient descent is difficult,” IEEE transactions on neural networks, vol. 5, no. 2, pp. 157–166, 1994. [48] “Writing an llvm pass,” https://llvm.org/docs/WritingAnLLVMPass. html, Last Accessed, June 2026. [49] M. Abadi, A. Agarwal, P. Barham, E. Brevdo, Z. Chen, C. Citro, G. S. Corrado, A. Davis, J. Dean, M. Devin et al., “Tensorflow: Large-scale machine learning on heterogeneous systems,” 2015. [50] “Aion robotics,” https://www.aionrobotics.com/, Last Accessed, June 2026.
[61] M. Salehi and K. Pattabiraman, “Rvdebloater: Mode-based adaptive firmware debloating for robotic vehicles,” arXiv preprint arXiv:2602.00270, 2026. [62] “Stack buffer overflow,” https://github.com/PX4/PX4-Autopilot/issue s/5643, Last Accessed, May 2026. [63] “Cve-2022-28711,” https://nvd.nist.gov/vuln/detail/CVE-2022-2871 1, Last Accessed, May 2026. [64] C. Cowan, C. Pu, D. Maier, J. Walpole, P. Bakke, S. Beattie, A. Grier, P. Wagle, Q. Zhang, and H. Hinton, “Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks.” in USENIX security symposium, vol. 98. San Antonio, TX, 1998, pp. 63–78. [65] S. S. Vendicator, “A stack smashing technique protection tool for linux,” World Wide Web, http://www. angelfire. com/sk/stackshield/info. html, 2000. [66] C. Song, B. Lee, K. Lu, W. Harris, T. Kim, and W. Lee, “Enforcing kernel security invariants with data flow integrity.” in NDSS, 2016. [67] C. H. Kim, T. Kim, H. Choi, Z. Gu, B. Lee, X. Zhang, and D. Xu, “Securing real-time microcontroller systems through customized memory view switching.” in NDSS, 2018. [68] M. Abubakar, A. Ahmad, P. Fonseca, and D. Xu, “{SHARD}:{FineGrained} kernel specialization with {Context-Aware} hardening,” in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 2435–2452. [69] T. Nyman, J.-E. Ekberg, L. Davi, and N. Asokan, “Cfi care: Hardware-supported call and return enforcement for commercial microcontrollers,” in International Symposium on Research in Attacks, Intrusions, and Defenses. Springer, 2017, pp. 259–284. [70] Y. Zhou, X. Wang, Y. Chen, and Z. Wang, “Armlock: Hardware-based fault isolation for arm,” in Proceedings of the 2014 ACM SIGSAC conference on computer and communications security, 2014, pp. 558– 569. [71] H. Lefeuvre, N. Dautenhahn, D. Chisnall, and P. Olivier, “Sok: Software compartmentalization,” in 2025 IEEE Symposium on Security and Privacy (SP). IEEE, 2025, pp. 3107–3126.
[72] D. P. Siewiorek and P. Narasimhan, “Fault-tolerant architectures for space and avionics applications,” NASA Ames Research http://ic. arc. nasa. gov/projects/ishem/Papers/Siewi, 2005. [73] N. Aggarwal, P. Ranganathan, N. P. Jouppi, and J. E. Smith, “Configurable isolation: building high availability systems with commodity multi-core processors,” ACM SIGARCH Computer Architecture News, vol. 35, no. 2, pp. 470–481, 2007. [74] K. Qin and D. Gu, “Mvtee: Multi-variant trusted execution for secure model inference,” in Proceedings of the 26th International Middleware Conference, 2025, pp. 298–313. [75] A. Rösti, S. Volckaert, M. Franz, and A. Voulimeneas, “I’ll be there for you! perpetual availability in the a 8 mvx system,” in 2024 Annual Computer Security Applications Conference (ACSAC). IEEE, 2024, pp. 520–533. [76] B. Randell, “System structure for software fault tolerance,” IEEE Transactions on Software Engineering, vol. SE-1, no. 2, pp. 220– 232, 1975.
[77] J. Jeong, D. Kim, J.-H. Jang, J. Noh, C. Song, and Y. Kim, “Unrocking drones: Foundations of acoustic injection attacks and recovery thereof.” in NDSS, vol. 6, 2023, p. 7. [78] F. Fei, Z. Tu, D. Xu, and X. Deng, “Learn-to-recover: Retrofitting uavs with reinforcement learning-assisted flight control under cyberphysical attacks,” in 2020 IEEE International Conference on Robotics and Automation (ICRA). IEEE, 2020, pp. 7358–7364. [79] S. Park, Y. Kim, and D. H. Lee, “Scvmon: Data-oriented attack recovery for rvs based on safety-critical variable monitoring,” in Proceedings of the 26th International Symposium on Research in Attacks, Intrusions and Defenses, 2023, pp. 547–563. [80] G. Candea, S. Kawamoto, Y. Fujiki, G. Friedman, and A. Fox, “Microreboot-a technique for cheap recovery.” in OSDI, vol. 4, 2004, pp. 31–44.