Bypassing software-based remote attestation using debug registers

Abstract

Remote attestation (RA) is an essential feature in many security protocols to verify the memory integrity of remote embedded devices susceptible to malware infections. The attestation process needs to be consecutive and atomic to prevent a self-relocating malware from evading detection. Most of the prior attestation techniques disable interrupts during execution to prevent another process from interrupting the integrity check. This paper investigates the shortcomings of existing software-based attestation techniques and stresses the threat of debug exceptions to existing software-based attestation. We present Debug Register-based Self-relocating Attack (DRSA), a novel self-relocating malware against software-based attestation based on debug registers. DRSA gains control of the checksum function by raising debug exceptions and erasing itself before the next attestation. We further implement DRSA on commodity OSes and validate its effectiveness based on two existing software-based proposals. Our evaluation demonstrates that DRSA incurs low overhead, and it is extremely difficult for the verifier to detect it. can bypass the attestation with very little attack overhead.

Keywords:

• Remote attestation
• debug exceptions
• indisputable code execution
• self-relocating malware

1. Inroduction

With the development of the Internet of Things and the increase in the variety and number of special-purpose embedded devices, the security threats faced by these devices are increasing. Preferred targets of malware change from general-purpose computers to numerous and inter-connected embedded devices mainly because of the latter's lack of security protections. As our society is gradually becoming surrounded by these low-end embedded devices, their safety cannot be ignored must be addressed, although security is typically not the highest priority due to cost, power constraints, or size.

To achieve higher security with lower power consumption, some lightweight security mechanisms such as lightweight cryptography (Jammula et al., 2022), access control (Ji et al., 2021; J. Zhang et al., 2021) and privacy protection (Liu et al., 2023; Xu et al., 2023) are applied to IoT devices. Remote Attestation (RA) is a distinct security service for detecting malware on embedded devices. RA is typically realised as a challenge-response protocol. In this protocol, RA allows a trusted verifier ($\mathcal{V}\mathcal{R}\mathcal{F}$) to compute a checksum of an untrusted Prover ($\mathcal{P}\mathcal{R}\mathcal{V}$)'s memory to attest its integrity. Since the $\mathcal{V}\mathcal{R}\mathcal{F}$ is assumed to know the hardware configuration and exact memory contents of the $\mathcal{P}\mathcal{R}\mathcal{V}$, it can compute the expected checksum and compare it with the received one. Mismatched values indicate that the device has most likely been compromised. Software-based RA (Ammar et al., 2021); Kumar et al., 2021; Mansouri et al., 2021; Seshadri et al., 2005, 2004; Shaneck et al., 2005; X. Yang et al., 2015) is an approach particularly suitable for verifying the trustworthiness of low-end embedded devices because it does not rely on hardware to control the execution of the integrity-ensuring function. Compared with hybrid RA (based on hardware/software co-design) (Aman et al., 2020; Carpent et al., 2018; Eldefrawy et al., 2017; Ren et al., 2022) and hardware-based RA (e.g. those based on a TPM Trusted Computing Group, 2017 or other dedicated hardware modules Kucab et al., 2021; Nunes et al., 2021), which require some level of hardware support, software-based RA is less costly.

Most of the previously proposed software-based RA techniques perform an integrity check on the whole memory content of a low-end sensor node because the memory of this kind of device is usually small enough. For example, Mica2 and MicaZ sensors that use an ATMega128L microcontroller (Corporation, A., 2023) have 128 KBytes of program memory, which means it will take a few seconds to perform an integrity check. Due to the rapid technological growth, the usage of middle-end and high-end devices (Ojo et al., 2018) is increasing. These devices can perform tentative computations such as deep learning network training (Guo et al., 2019), executing complex protocols and authentication algorithms (Q. Zhang et al., 2019; Zheng et al., 2018; Zhu et al., 2018). However, attesting the whole memory content is time-consuming for such devices with large amounts of memory (e.g. Raspberry Pi). Moreover, part of the device's memory might have dynamic data or cryptographic secrets, which are impractical to be verified. To gain security guarantees without attesting the whole memory, a primitive called Indisputable Code Execution (ICE) is proposed to establish a trusted computing base on the untrusted remote node (Seshadri et al., 2006). The trusted computing base checks the integrity of the target executable and invokes it atomically. It ensures that the execution will not be tampered with by any malicious code on the untrusted remote node. Otherwise, the transient and self-relocating malware – the type of malware that can move around, can interrupt the successive attestation process and move (by copying and erasing) to evade detection.

Motivation. To defend against the transient and self-relocating malware, the typical approach is disabling interrupts upon entry of the attestation code. In middle-end and high-end devices with enough resources, such as a powerful processor with x86 architecture, to run a traditional OS such as Linux, however, uninterruptibility is more challenging to achieve. By setting hardware breakpoints provided by debugging architecture, debug exceptions can also interrupt the execution of the attestation process. Unfortunately, previously proposed software-based RA schemes did not pay enough attention to the threat of debug exceptions. This motivates our work.

Contributions. In light of shortcomings of existing software-based RA schemes, we propose a novel self-relocating malware using debug registers provided by the debugging architecture, which is available on most of the processors today. To the best of our knowledge, this is the first self-relocating malware designed based on debug exceptions. Our contributions can be described as follows:

• We present Debug Register-based Self-relocating Attack (DRSA), a malicious program that circumvents attestation by relocating itself and restoring the contents before it is measured. DRSA utilises debug registers to monitor an RA measurement's beginning and end, erases itself, and restores the original program memory contents before attestation. The malicious code can be restored after the RA procedure to regain control over the compromised device.

• We introduce the design details of DRSA and implemented two different prototypes under Windows and Linux operating system in the form of a Kernel-Mode Driver (KMD) and a Loadable Kernel Module (LKM), respectively.

• We present a comprehensive experimental evaluation based on real-world software-based RA schemes to show that DRSA can bypass the attestation with very little attack overhead. The experimental results highlight the threat of debug exceptions to existing software-based attestation.

In addition to academic research contributions, verifying the internal state of a remote embedded device is essential in many scenarios (e.g.industrial control systems, smart medical devices, and military sensors). Our work can also motivate improvements in attestation techniques for industrial devices. We want to attract a lot of attention from both the research community and industry to the threat of debug exceptions. The symbols used throughout this paper are given in Table 1.

Table 1. Symbol definition.

Term	Declaration
$\mathcal{V}\mathcal{R}\mathcal{F}$	a trusted entity to remote verify the software integrity of other entities
$\mathcal{P}\mathcal{R}\mathcal{V}$	an untrusted entity to prove its trustworthiness by performing RA procedure
IDT	the interrupt descriptor table used by the x86 architecture
trap	a flag of the EFLAGS register that permits operation of a processor in single-step mode
resume	a flag of the EFLAGS register used by the debug registers to turn off certain exceptions
tracer	a process that can observe and control the execution of another process
tracee	a process inspected and controlled by tracer

The remainder of this paper is organised as follows: Section 2 provides a preliminary overview of software-based attestation technologies and the x86 debugging architecture. Section 3 discusses the threat model and assumptions of this work. Section 4 presents a detailed description of DRSA. Section 5 introduces the design and implementation details. The effectiveness and efficiency of DRSA are evaluated and discussed in Section 6. Section 7 discusses related work, and Section 8 concludes this paper.

2. Background

2.1. Software-based attestation

Existing software-based RA techniques are all realised as a challenge-response protocol where the $\mathcal{V}\mathcal{R}\mathcal{F}$ challenges a $\mathcal{P}\mathcal{R}\mathcal{V}$ (a target untrusted remote device) to compute a checksum of its specified memory region. We describe the basic challenge-response protocol and list the existing software-based RA schemes.

2.1.1. Challenge-response protocol

A typical challenge-response paradigm uses a checksum function to compute the checksum of the memory content, the procedure of which can be described as follows:

1. $\mathcal{V}\mathcal{R}\mathcal{F}$ sends an attestation request with a challenge to $\mathcal{P}\mathcal{R}\mathcal{V}$. This request also contains a nonce generated by the $\mathcal{V}\mathcal{R}\mathcal{F}$ to be involved in the checksum computing to prevent pre-computation or replay attacks.

2. $\mathcal{P}\mathcal{R}\mathcal{V}$ receives the request and computes a challenge-based authenticated integrity check over a pre-defined memory region.

3. $\mathcal{P}\mathcal{R}\mathcal{V}$ returns the result to $\mathcal{V}\mathcal{R}\mathcal{F}$.

4. $\mathcal{V}\mathcal{R}\mathcal{F}$ receives the result and checks whether it matches the expected checksum.

The timeline illustrating this attestation process is shown in Figure 1. Since the usual RA threat model assumes that the target device is fully compromised, software-based RA must protect the checksum function from the potential malware without hardware support. Prior works rely on strict time constraints or filling the empty memory locations to prevent malicious code. For an adversary trying to bypass RA schemes with tight time constraints, the main challenge is to relocate the malicious code and compute the correct checksum within a limited time. For RA schemes with looser time constraints, the adversary will face the challenge of lack of space to store the malicious code or the original values.

Figure 1. Timeline of a typical RA protocol. req denotes attestation request, resp refers to the respond.

2.1.2. Attestation based on entire memory verifying

Several software-based RA schemes allow an external $\mathcal{V}\mathcal{R}\mathcal{F}$ to check the entire memory contents of a target device. To defend against memory copy attack, which modifies the original code and redirects the memory accesses to a correct copy stored elsewhere in memory, some software-based RA relies on a strict time constraint because they claim that the overhead caused by redirection would be easily detected by the $\mathcal{V}\mathcal{R}\mathcal{F}$. Checksum functions of these approaches must, therefore, be simple and highly time-optimised, leaving no room for the adversary to compress the attest time. However, it is difficult to assess the best attack against a certain approach, which makes the security of this approach uncertain. Several attacks have been proposed (Castelluccia et al., 2009) and demonstrated the weaknesses of time constraints. Moreover, most time-based attestation require disabling interrupts during attestation procedure execution to ensure that the adversary can not move malware around during attestation by forcing an interrupt. However, disabling interrupts will affect the normal operation of the device and result in low availability.

To overcome the weakness of tight time constraints, some software-based RA schemes fill the free program memory with random noise before deployment to prevent the adversary from storing its malware. However, the adversary can compress the original code to gain free space for storing and executing its malware. Moreover, memory filling is only suitable for sensor devices where the memory layout is known in advance. For some devices with dynamic or inaccessible data in their memory, memory filling will not work because the pre-filled noises may be overwritten during program execution.

2.1.3. Attestation based on indisputable code execution

ICE primitive could provide the untampered code execution mechanism on the untrusted devices without verifying the entire memory. To achieve untampered code execution, the following process should be executed atomically. (1) Execute the self-checksumming code of the ICE verification function. This ensures that the ICE verification function itself executes untampered. (2) Check the integrity of the executable. This ensures that the executable that the verifier wants to invoke has not been modified. (3) Invoke the executable to execute. Only if the entire process outlined is atomic can the external $\mathcal{V}\mathcal{R}\mathcal{F}$ obtain an indisputable guarantee on the untrusted device.

A way of ensuring atomic execution is disabling interrupts. Specifically, they set the corresponding CPU state and incorporate them into the checksum. Most existing ICE approaches assume that the CPUs under consideration do not support exceptions, and setting the interrupt-disable bit ensures that no other code can execute. However, these protocols are vulnerable when applied to devices that support exception-handling mechanisms. With the widespread application of high-end sensor nodes, these devices should not be excluded.

2.2. X86 debugging architecture

The debugging architecture is supported by most of the processors today to facilitate on-chip debugging. There are eight debug registers (DR0 through DR7) in x86 architecture, supporting debug exceptions and hardware breakpoints required by software debuggers (Guide, 2011). Among them, DR0 to DR3 is used to specify memory addresses or I/O locations to be monitored by the debugger. The processor raises a debug exception when an instruction or memory address matches the address stored in one of these four registers. The address monitoring process is performed in parallel with the usual virtual to physical address translation, and thus, no additional expensive intercept-and-check-in software is required. DR4 and DR5 are reserved, while DR6 is used to report the status of the debugging conditions when a debugging exception is raised. Bn bit of DR6 indicates that the nth breakpoint was reached. BS and BT bits signify that single stepping and task switching trigger the exception, respectively. DR7 is used to control/configure the trigger condition of the debug exception when the address matches. By setting the corresponding Ln or Gn bit in DR7, the nth breakpoint could be enabled or disabled. Ln bit and Gn bit enable the nth breakpoint for the current and all tasks, respectively. The corresponding breakpoint is disabled when both Ln and Gn bits are cleared. R/Wn field configures the trigger mode of the nth breakpoint. For example, the data read or write in the monitored memory address will raise a debugging exception if value 11 is set. The instruction execution of the specific memory address can also be monitored by set value 00. The size of the monitored memory location of the nth breakpoint can be set through the LENn field.

3. Hardware platform and assumptions

3.1. Hardware platform description

DRSA is implemented on devices with x86 architecture, the storage of which is not physically separated. An architecture with separated storage (e.g. the Harvard architecture) gives the attacker a vulnerability to evade attestation. The attacker can hide malicious code in data memory and pass the attestation protocol that does not attest the data memory. While the presented attack is validated on an x86 architecture-based device, it is not specific to x86 architecture. Instead of relying on data memory to hide malicious code, it exploits the characteristics of the debugging architecture supported by the processor. Thus, DRSA is applicable to any device that uses similar debugging features, such as tracing and monitoring.

3.2. Adversarial assumptions

In this work, we assume that the adversary aims to avoid the malicious code installed in the target device from being detected during attestation process. The adversary has complete control over the whole device memories. We also assume that the attacker has no direct control of the device at attestation time. The attack succeeds if the device passes the attestation while the malicious code resides in memory. We do not address the details of how attackers install malicious code on devices because it is beyond the scope of this paper. Finally, we assume that the attacker does not modify the device hardware or induce hardware faults. The attestation requirements and security requirements are that the $\mathcal{V}\mathcal{R}\mathcal{F}$ imposes a time limit within which the $\mathcal{P}\mathcal{R}\mathcal{V}$ responds. To guarantee security, the checksum response must also be correct.

4. Debug register-based self-relocating attack

In this section, we introduce the implementation of DRSA. The attack is formed based on the debugging features of x86 debugging architecture. It circumvents malware detection by detecting the start of the attestation and restoring the original contents before it is measured. This is achieved by monitoring instruction execution and data access events using debug registers.

Figure 2 illustrates the overview of DRSA. The memory layout of the target device is also depicted. The attack core comprises a data read and write handler, a single-step handler, a hook (a jump instruction) and the malicious code. When an attestation request is received, the target device switches from the initial state to the attestation state and its memory layout also changes. The numbers represent the transfer order of the control flow. As stated above, the memory layout of the target device with x86 architecture is not divided into program memory and data memory. Moreover, the existing remote attestation routine for x86 architecture, Pioneer, only verifies part of the memory content rather than the entire memory (Seshadri et al., 2005). The checksum code of Pioneer is self-checksumming and computes a checksum over the whole attestation function and the executable. The correct checksum guarantees that the verification function code is unmodified and establishes a trusted computing base called the dynamic root of trust. Once established, the dynamic root of trust verifies the integrity of the executable and invokes it. The executable is guaranteed to be trusted if it is unmodified and executed uninterrupted. DRSA inserts a hook (a jump instruction) into the attestation routine to replace the invoke instruction during the attestation procedure function. When the dynamic root of trust tries to invoke the origin executable, the control flow will be hijacked, and malicious code will be invoked.

Figure 2. Overview of DRSA. The numbers represent the transfer order of the control flow.

However, simply modifying the attestation function will be detected during the attestation procedure because it will lead to an invalid checksum. To escape detection, DRSA utilises two types of hardware breakpoints to monitor the checksum function's operation of reading the memory content and modifying the memory content in the corresponding exception handlers. Specifically, the following is a detailed description of the attack scenario presented in Figure 2:

1. The malicious code is installed on the victim device beforehand, and the existing exception handlers are replaced with our own handlers to implement DRSA's core function. Next, we insert a hook to the attestation code by replacing the executable invoke instruction of the attestation function with a jump.

2. A data read/write breakpoint and a single-step breakpoint are set respectively to trigger the corresponding exception handler. Specifically, the data read/write breakpoint is set beforehand, while the single-step breakpoint is set at runtime.

3. The victim device switches to the attestation state when an attestation request is received. The attestation function will access the memory of the attestation region and compute the checksum. The data read/write breakpoint will be triggered when the attestation function accesses the address of the hook, and the data read/write exception handler will be invoked.

4. The data read/write exception handler receives control and sets the original executable invoke instruction back to what it was. Then, the single-step breakpoint is set before the control flow transfers back to execute the memory access instruction.

5. The single-step breakpoint is triggered after the single memory access instruction executes. The single-step exception handler receives control and installs the hook to replace the executable invoke instruction of the attestation function again. Then, the control flow transfers back to continue executing the next memory access instruction.

6. The attestation function will compute a valid checksum because the modified memory content is restored to the original content before its memory access instruction is accessed. The victim device switches back to the initial state, but the hook is still present in the memory without being detected by the verifier.

The attestation function is, therefore, executed over the clean memory of the attestation region. Since neither the exception handlers nor the malicious code are in the attestation region, their presence will not affect the checksum result. Thus, the valid checksum is sent to the verifier and the integrity of the executable will be measured. Since the content of the executable has not been modified, it can pass the integrity measurement and is ready to be invoked. Once the original executable is invoked, the control flow will be redirected to execute the malicious code.

5. Design and implementation

To achieve the attack process mentioned above, DRSA utilises debugging architecture, which provides hardware breakpoints and exception mechanisms to transfer execution to custom handlers, relocating malicious content before detection. In this section, we explain the detailed setting of the debug registers and the key implementation steps of DRSA under the x86 architecture.

5.1. Memory restoring via data read and write breakpoint

DRSA uses the debugging architecture of the underlying platform to provide hardware breakpoints on code execution, data, and memory access. Support for debugging architecture on most processors is in the form of debug registers. The breakpoint trigger conditions can have various attributes such as execution, write, read/write, etc. To achieve memory Restoration via data read and write breakpoint, the address and attributes of breakpoint should be set through corresponding registers.

In the x86 architecture, current processors typically provide 4 locations of hardware breakpoints, the addresses of which can be set through DR0-DR3. We use the first debug register, DR0, and set its value as the address of the hook to monitor any memory access to it. DR7 controls the specific attributes of the breakpoint. Table 2 shows the detailed setting of each bit of DR7. L0 bit and G0 bit control the scope of the first breakpoint. It can be set as persistent or nonpersistent during its creation by setting the G0 bit to 1 or the L0 bit to 1, respectively. We set the G0 bit to 1 so that every access to the hook address will trigger the read and write breakpoint. GD bit is set to prevent debug registers from being modified by other programs. Instructions that access debug registers will raise an exception, and DR6 will record the relevant information of the debugging exception. R/W0 is controlled by bits 16 and 17 of DR7, which determines the trigger condition of the breakpoint. We set R/W0 to 01 so that the breakpoint will be triggered by the read/write operation of the address assigned by DR0. Finally, LEN0 is set to 00 to specify the memory size monitored by the breakpoint as 1 byte.

Table 2. DR7 settings for data read/write breakpoint.

Bit Name	Bit Number	value	Description
L0	0	1	the breakpoint will only be valid for the current task
G0	1	0	the breakpoint will be valid for all the tasks
GD	13	1	instructions that access debug registers will raise an exception
R/W0	16&17	01	the breakpoint will be triggered by read or write operations
LEN0	18&19	00	specify the memory size monitored by the breakpoint as 1 byte

DRSA installs its data read and write handler, replacing the existing handler to implement the restoration of original memory content. When the data read and write handler is invoked due to a memory access exception, the handler erases the hook code and restores the original memory contents. Finally, the handler prepares for a single-step exception and transfers the control flow back to the attestation function.

5.2. Hook re-installing via single-stepping

DRSA employs a single-step exception for hook re-installing. The single-step exception is a standard exception on all processor architectures triggered upon execution of each instruction when a certain processor flag (also called the trap flag) is activated. The exception generated by a single step is consistent with the exception generated by the hardware breakpoint. Thus, the single-step exception makes use of the trap flag for its functioning. In the x86 architecture, the trap flag can be set through the EFLAGS register. The position of the trap flag in the EFLAGS register is shown in Figure 3. DRSA installs its own single-step handler, replacing the existing handler to implement hook re-installing. The single-step handler is installed on demand from the data read and write handler.

Figure 3. The trap flag in the EFLAGS register. A trap flag permits operation of a processor in single-step mode.

In the data read and write handler, the trap flag (bit 8) is set to 1 to enable single-step mode for debugging before the control flow transfers back to execute the memory access instruction of the attestation function. Then the single-step exception will be triggered after the execution of the memory access instruction. When the single-step handler is invoked due to a single-step exception, the handler reinstalls the hook to replace the executable invoke instruction of the attestation function again. Then, the handler resets the trap flag, uninstalls itself, and issues an end of the exception.

5.3. Framework composition and source organization under windows OS

The framework of DRSA is implemented as a loadable KMD under the Windows operating system that is able to monitor the memory access operation initiated by the attestation function and relocate malicious content before it is detected. Figure 4 illustrates how DRSA performs memory access monitor and malicious content relocating. The left part is the framework of the DRSA in the Windows driver form, while the right part is the attestation process's address space. The driver is mainly composed of three essential parts (pseudo-code shown in Figure 4):

Figure 4. Implementation of DRSA under Windows OS. DRSA is implemented in the form of a loadable KMD.

Hook original handler: To install its exception handlers, DRSA intercepts calls to the interrupt descriptor table IDT and registers the custom handler function. After the DriverEntry initialises driver-wide data structures and resources, the DRSA driver creates a hook to replace the original exception handler. Specifically, it obtains the base address of the IDT and then extracts the address of the corresponding original handler function from an interrupt descriptor. The write protect bit is turned off (by modifying the CR0 register), and the interrupt is disabled (by using the CLI instruction) to avoid being interrupted by other interrupts when modifying the IDT. Finally, it points the target interrupt descriptor to a new handler function, reloading the CR0 register and enabling interrupts. When an exception is raised, the custom exception handler function will be invoked instead of the original exception handler.

Set hardware breakpoint: The data read/write breakpoint is set during the driver's loading process. It mainly includes setting the DR0 register and the DR7 register. Specifically, the DR0 register is assigned the address of the hook we installed in the attestation function, while the DR7 register is assigned the specific value summarised in section 5.1 so that the trigger condition of the breakpoint is set to read/write. During the driver development routine, we achieve direct control of the DR registers through inline assembly. The original handler hooking and hardware breakpoint setting procedure is executed as shown in Algorithm 1.

Custom exception handler: The custom exception handler is developed as part of the driver and loaded into memory when the driver is installed. To achieve malicious code relocating, the custom exception handler keeps a copy of the original memory content and malicious code to be installed in the attestation code. When a raised exception invokes it, the value of the DR6 register is first obtained to determine the interrupt source. The value of BD (bit 13), as mentioned in Section 5.1, indicates whether the exception is triggered by the breakpoint set by the DR0 register. The BD bit of 1 indicates a program trying to access the memory address (read or write) monitored by the DR0 register. Then, the custom exception handler will restore the original content of the attestation code (an executable invoke instruction) and set the trap flag of the EFLAGS register to 1. Next, it will chain to the original exception handler to complete its original function. If the exception is raised by single stepping, the custom exception handler will reinstall the hook and reset the trap flag and chain to the original exception handler. Other interrupt sources will not trigger the execution of additional code in the custom handler and will transfer the control flow to execute the original handler instead.

Owing to the debug architecture's capabilities, the malicious modification of the target memory content can successfully escape the detection of the attestation function. The custom exception handler is executed as shown in Algorithm 2.

5.4. Framework composition and source organization under linux OS

DRSA under Linux OS is implemented using ptrace, a system call provided by Unix, and several Unix-like operating systems. By attaching to another process using the ptrace call, a tool has extensive control over the operation of its target. It can also single-step through the target's code and observe and intercept system calls and their results. More importantly, ptrace provides requests to control the debug registers directly, which facilitates the implementation of our attack method. The framework of DRSA based on ptrace is shown in Figure 5. DRSA is implemented as one single process (the “tracer”) to observe and alter the execution of another attestation process (the “tracee”), achieving malicious code relocation at runtime.

Figure 5. Implementation of DRSA under Linux OS. DRSA is implemented in the form of a LKM.

The left part of Figure 5 illustrates the execution flow of DRSA based on ptrace. DRSA process commences tracing by having the attestation process do a $\mathrm{PTRACE}\mathrm{\_ATTACH}$. Then, the attestation process will stop, and the DRSA process can use various ptrace requests to inspect and modify the attestation process. DRSA process first sets the data read/write breakpoint at the hook address of the attestation process. By using ptrace requests $\mathrm{PTRACE}\mathrm{\_POKEUSER}$, the DRSA process sets the DR0 register and DR7 register to the specific values summarised in Section 5.1. Then the call $\mathrm{PTRACE}\mathrm{\_CONT}$ is delivered to continue executing the attestation process. The attestation process will stop again when the attestation function triggers the data read/write breakpoint. The DRSA process restores the original content of the attestation function by using $\mathrm{PTRACE}\mathrm{\_POKETEXT}$, which can modify the code segment of tracee directly. After that, the DRSA process issues a $\mathrm{PTRACE}\mathrm{\_SINGLESTEP}$ request to restart the stopped attestation process, but arranges for it to be stopped after executing a single instruction (the memory access instruction in our scenario). The hook code (a jump instruction) will be reinstalled in the attestation function during this suspension, and DRSA process then makes the ptrace-stopped attestation process rerun by using $\mathrm{PTRACE}\mathrm{\_CONT}$.

By utilising ptrace, the attestation process will not be aware of the existence of the DRSA process. Additionally, attaching to the tracee will not add additional instructions in the attestation region, which will not affect the result of the checksum calculation.

6. Evaluation

In this section, we measured the effectiveness of DRSA on some specific code attestation schemes. We mainly focus on Pioneer (Seshadri et al., 2005) and SWATT (Seshadri et al., 2004). We chose Pioneer because it is a remote attestation routine explicitly designed for x86 architecture. To the best of our knowledge, it is the only RA scheme that attempts to defend against the threat of debug exceptions. We chose SWATT because it is based on strict time constraints and can be used as a baseline for the effectiveness of our proposed scheme. Additionally, we can quantify the attack overhead by comparing it with existing attack methods against SWATT. The untrusted platform used in our experiment is a PC with a 3.41 GHz Intel i7-6700 processor running Windows 10.

6.1. Attestation time overhead

In this subsection, we tested the time overhead of DRSA on existing protocols. Our goal is to show that the proposed attack could escape from the detection of the target attestation routine.

We first tested the attack on our implementation of Pioneer. We implemented two versions of the Pioneer on the experiment platform–a legitimate version and an attacker's version that assumes that the attacker has compromised the attestation function of Pioneer. For the attacker's version, we tested the theoretically best attack in Pioneer and DRSA, respectively. We set the number of memory accesses (equal to the number of iterations of the main loop) by the attestation procedure to 2,500,000, which is consistent with the experimental settings in Pioneer. We ran each version of the attestation procedure and obtained the running time. We run our experiments for one hour, and the attestation procedure of each version is performed every 2 minutes. Figure 6 shows the results of our experiments, which contain four sets of data: the running time of legitimate code, the running time of the theoretically best adversary in Pioneer, the running time of DRSA, and the adversary detection threshold. According to Pioneer, the adversary detection threshold is set to the sum of the legitimate code's running time and the theoretically best adversary's time advantage. The theoretically best adversary's time advantage is fixed to be 0.2516 ms. Based on the results, we observe that the running time of the theoretically best adversary in Pioneer is greater than the adversary detection threshold. In comparison, the running time of DRSA is always less than the adversary detection threshold in each attestation procedure. This shows that DRSA incurs little attack overhead, which is hard for Pioneer to detect.

Figure 6. Results on Pioneer.

The author claimed that the time overhead of the the theoretically best attack against their protocol will increase linearly with the number of iterations of the checksum loop. This is because the additional instructions inserted by the attacker to the attestation function will be executed on every iteration. However, in DRSA, the memory region we modified will not be accessed on every iteration because the additional handler code will only be executed during the iteration round of accessing the monitored memory. As existing protocols basically use pseudo-random sequence memory traversal for the main loop of the verification procedure, the number of accesses to the monitored memory address will be much smaller than the total number of iterations with high probability.

We also tested DRSA on our implementation of SWATT. The original SWATT was implemented based on an ATMega163L microcontroller with 16 KBytes of program memory. To simulate SWATT on the x86 platform, we ported SWATT's attestation function and made it verify the specified 128 KBytes memory region, including itself. We further implemented an attacker's version that assumes that DRSA has compromised the attestation function of SWATT. Table 3 shows the results indicating the attack overhead introduced by DRSA. We compared it with the original SWATT attack. We also compared the attack overhead imposed by DRSA with those presented by Castelluccia et al. (2009), including the memory shadowing attack and rootkit-based attack. The memory shadowing attack flips one bit of a memory address to hide malicious code. The rootkit-based attack invokes hooks at the beginning of the attestation routine, and, after the attestation function returns to move the malicious code between program memory and non-executable memory. Note that we obtained the overhead of rootkit-based attack measures from the previously published articles because it can only be implemented on a Harvard memory architecture.

Table 3. Overhead of different attacks.

Method	Time of Execution (ms)	Attack Overhead (ms)	Attack Overhead (%)
Original SWATT	11,061	–	–
Original SWATT Attack	–	–	13%
SWATT (MicaZ)	13,103	–	–
Rootkit-based Attack (MicaZ)	–	42.3	0.32%
SWATT (x86)	56.5	–	–
Shadow Attack (x86)	60.1	3.7	6.47%
DRSA	56.9	0.4	0.71%

To facilitate the comparison of different attack overhead, timings are collected on three implementation versions of SWATT. The original SWATT attack represents the best attack expected by the designers of SWATT, which checks each address generated in the pseudo-random sequence. This attack would add 3 cycles for test and redirection. Since the original attestation function main loop is 23 cycles long, the malicious attestation function incurs 13% attack overhead. The rootkit-based attack is implemented on a MicaZ device with 128 KBytes of program memory in Castelluccia et al. (2009). The authors ported SWATT on MicaZ and tested their rootkit-based attack on it. The experimental results show that the time required for the rootkit-based attack to hide the malicious code is less than 50 milliseconds, introducing about 0.32% overhead.

The last three rows in Table 3 summarise the execution time of x86-based SWATT, the attack overhead of DRSA and shadow attack based on our x86 platform. On the x86 platform, the number of SWATT cycles should be increased, according to the Coupon's Collector Problem. Due to the high CPU frequency of the experimental platform, we further double the number of iterations to get more accurate results. Compared to the running time of x86-based SWATT, DRSA introduced 0.71% of overhead. The experimental results show that the attack overhead of DRSA is much smaller than the original SWATT attack and shadow attack. While it is a bit slower than the rootkit-based attack, it's hard for the verifier to detect this delay. The main reason for the difference in the overhead of DRSA and the rootkit-based attack is the execution times of the additional malicious code. The rootkit-based attack inserts the hook and triggers the rootkit hiding functionality, which will delete the rootkit code from the program memory at the beginning of the attestation function. Thus, the additional malicious code is executed only once during an entire attestation routine. In DRSA, however, the execution times of the exception handlers depend on the number of times the modified memory location is accessed during an attestation routine. Therefore, additional malicious code may be triggered multiple times, which incurs more execution time.

6.2. Status information on the stack

The authors of Seshadri et al. (2005) have considered that an adversary generates a non-maskable interrupt or exception by setting a breakpoint to gain control. Their defense method is to use the stack to store a part of the checksum. They claimed that all CPUs automatically save some state on the stack when an interrupt or exception occurs. If the stack pointer points to the checksum on the stack, any interrupt or exception will cause the processor to overwrite the checksum. However, this stack trick does not work for DRSA because the status information will be saved in debug registers instead of on the stack if the exception is generated by a hardware breakpoint.

To confirm this conclusion, we obtained the address of the stack pointer before and after the execution of the exception handlers to verify whether it has changed. We experimented on the ptrace-based DRSA. The experiment platform used in our experiment is a PC with a 3.41 GHz Intel i7-6700 processor, running the Ubuntu 18.04 operating system. By using $\mathrm{PTRACE}\mathrm{\_GETREGS}$ request, the DRSA process (the “tracer”) could copy the general-purpose or floating-point registers of the attestation process (the “tracee”) to its address data. By accessing the RSP register, we can obtain the stack pointer. To compare the difference between hardware and software breakpoints, we implemented a process of gaining control from the attestation function through a software breakpoint. As shown in Figure 7, the first instruction of the attestation function is replaced with an INT3 instruction. This instruction is a one-byte instruction to temporarily replace an instruction in a running program to set a software breakpoint. When the attestation code tries to run, a debug exception will be raised, thereby gaining control. We also record the stack pointer before and after the software breakpoint is triggered. The experimental results are shown in Table 4.

Figure 7. Gaining control from the attestation function through a software breakpoint.

Table 4. The value of the stack pointer.

Breakpoint Type	sp/ Before.bp	sp/ After.bp	sp/ After.ss
Software Breakpoint	0x7FFF6F6DAB78	0x7FFF6F6DAB60	–
Hardware Breakpoint (DRSA)	0x7FFCDE29DDB8	0x7FFCDE29DDB8	0x7FFCDE29DDB8

Notes: Stack pointer before the breakpoint triggers (sp/ Before.bp), stack pointer after the breakpoint triggers (sp/ After.bp) and stack pointer after the single stepping (sp/ After.ss).

The experimental results illustrate that exceptions raised by the data read/write hardware breakpoint and single stepping in DRSA do not cause the stack pointer to move. In a comparative experiment, however, the stack pointer points to different locations before and after the execution of INT3 instruction. The state information will overwrite the checksum and cause the manipulations to be detected by the attestation function. We conclude that DRSA can escape detection of the existing attestation routine on the x86 platform.

6.3. CPU condition information

The status register on the x86 architecture, flags register, contains the current state of the CPU. Some flags of the flags register reflect information about restrictions placed on the CPU, such as the prohibition of executing some “privileged” instructions and preventing some interrupts from triggering. Incorporating the flags register into the checksum can mask the interrupts and prevent attackers from abusing them. For example, the $\mathrm{interrupt}\mathrm{enable}$ flag (bit 9) of the EFLAGS register in the 32-bit x86 architecture can be set to the disable state to ensure no interrupts are triggered when the checksum code executes. The Intel 64 and IA-32 architectures provide the resume flag (bit 16) in the EFLAGS register (Guide, 2011) to prevent looping on a generated debug exception. The resume flag is set when the processor returns from the exception handler to prevent the recurrence of the instruction breakpoint. However, as described in the manual, it does not prevent the data read/write breakpoint used in our attack. We verified it by setting the resume flag before the checksum loop and observing whether the data read/write breakpoint is triggered. We manually record the changes in the EFLAGS register without and with the resume flag set during an attack. The results are summarised in Tables 5 and 6, respectively. If the resume flag is not set manually before the checksum loop, it will be set by the processor after the data read/write breakpoint is triggered and cleared after the exception handler exits. However, the results in Table 6 show that even if it is set manually before the checksum loop, the data read/write exception will still be raised by the data read/write hardware breakpoint of DRSA. In other words, DRSA can not be prevented by setting the resume flag to disable the state before the checksum loop. Additionally, DRSA cannot be detected by incorporating the trap flag into the checksum because it is only set during the single-step exception.

Table 5. The value of the EFLAGS register without setting the resume flag in advance.

Item	v/ Before.bp	v/ After.bp	v/ After.tf	v/ During.ss	sp/ After.ss
EFLAGS register	0x246	0x10202	0x10302	0x312	0x212
resume flag (bit 16)	0	1	1	0	0
trap flag (bit 8)	0	0	1	1	0

Notes: Value before the breakpoint triggers (v/ Before.bp), value after the breakpoint triggers (v/ After.bp), value after the trap flag set (v/ After.tf), value during the single stepping (v/ During.ss), value after the single stepping (sp/ After.ss).

Table 6. The value of the EFLAGS register with the resume flag set in advance.

Item	sp/ Before.bp	sp/ After.bp	sp/ After.ss	sp/ After.ss	sp/ After.ss
EFLAGS register	0x10246	0x10206	0x10306	0x312	0x212
resume flag (bit 16)	1	1	1	0	0
trap flag (bit 8)	0	0	1	1	0

Notes: Value before the resume flag is set (v/ Before.rf), value after the resume flag is set (v/ After.rf) and stack pointer after the single stepping (sp/ After.ss).

7. Discussion

By comparing our proposed scheme with Pioneer and SWATT, the first observation from our experiments is that DRSA can successfully bypass the attestation within a limited time. The debug exception takes over the control flow of the attestation process and executes the custom handler. The custom handler relocates the malicious content before the checksum loop, avoiding the attacker overhead increasing linearly with the number of checksum loops. Second, the current software-based RA schemes achieve uninterruptibility by disabling interrupts, which does not prevent debug exceptions from being raised. Although Pioneer has considered the threat of debugging exceptions, the experimental results show that it cannot detect hardware breakpoints based on debugging registers.

We then discuss several possible mitigation and detection methods against DRSA. First, monitoring the of certain APIs in current operating systems can mitigate against DRSA. In Windows, the SetThreadContext function is often used for changing the registers of remote threads, while the $\mathrm{PTRACE}\mathrm{\_POKEUSER}$ request is used in Linux operating systems for the same purpose. The corresponding API will be invoked if the adversary puts an address inside one of the debug address registers (DR0-DR3). Thus, monitoring the unexpected calls to these APIs is a strong indicator for identifying potential threats of DRSA. In this approach, however, the attack designer may modify the status of the debug registers directly and avoid using suspicious APIs. To tackle this, another mitigation method is to eliminate the potential malicious activity of the debugging functions at the beginning of the remote attestation process. Specifically, the attestation protocol needs to execute a piece of initialisation code to reset the contents of debug registers. The initialisation code, which runs before the checksum loop, resets the debug address registers (DR0-DR3) to prevent malicious behaviour from hooking the address in them. Then, it should also reset DR6 and DR7 to prevent the misuse of hardware breakpoints. Another equivalent mitigation method is to guarantee that the exception handlers are non-malicious. It can be achieved by replacing the existing exception handlers with code that consists only of a return instruction in the initialisation code. Thus, this non-malicious handler immediately returns control to whatever code was running before the exception occurred.

Nonetheless, the adversary can skip the initialisation code and jump directly into the checksum loop. In order to make attest code immutable, it is possible to place it in the Read-Only Memory (ROM) available on most platforms. This is based on the assumption that the adversary can not perform hardware modifications to the target device, e.g. the ROM-resident code, which resets the debug registers, cannot be interrupted or skipped. In contrast, hybrid-based attestation or hardware attestation can better mitigate the threat of DRSA. In general, if the mitigation method is implemented by software running in the non-secure mode (e.g.the OS), the malware with kernel privilege may bypass it easily. Additionally, since the attacker needs kernel privilege to access debug registers, another defense method is to prevent attackers from gaining kernel privileges. The regular approach to executing code with kernel privilege is to load an LKM. Then, it is possible to disable the loading of the LKMs to prevent arbitrary code execution since the LKMs are not highly needed in remote device scenarios.

8. Related work

A. software-based attestation

SWATT (Seshadri et al., 2004) is an early software attestation scheme based on challenge-response protocol. It requires a strict running time of the attestation procedure to prevent an attacker from redirecting the memory regions. The fact that SWATT relies on optimised function execution and a strict time limit is considered a drawback. Also, it needs to check the entire memory contents of the device, which is only suitable for low-end devices with less memory. Distributed (Y. Yang et al., 2007) uses memory filling to overcome the time constraints imposed by SWATT. The device's free memory is filled with randomness before deployment, preventing the attacker from having empty memory to evade detection during attestation. However, schemes based on memory filling are threatened by compression attack (Castelluccia et al., 2009), which compresses the original program of the victim device, opening up space for the malicious code. To prevent attackers from hiding malicious code through return-oriented programming, Cao et al. propose a “filling memory at attestation-time” mechanism and introduce a reputation mechanism to assist their attestation (Cao et al., 2022). SAGE (Ivanov et al., 2023) is a purely software-based approach for trusted GPU execution. SAGE enables untampered code execution on NVIDIA GPUs, providing properties of code integrity and computation integrity, as well as data integrity in the presence of malicious code. With the rapid evolution of Internet-of-Things (IoT), swarm attestation schemes have attracted great attention for attesting large-scale IoT devices. In swarm attestation protocols, the verifier hopes to attest the whole swarm with just one interaction. SWARNA (Kumar et al., 2021) is a software-based swarm attestation for legacy and next-generation IoT deployments without trusted hardware. FADIA (Mansouri et al., 2021) is an lightweight collaborative remote attestation protocol that enables fair distribution of load/tasks on the attesting devices to achieve better performance. The evaluation shows that FADIA can decrease the remote attestation runtime on heterogeneous embedded devices. DIALED (Nunes et al., 2021) is the first Data-Flow Attestation (CFA) technique applicable to the most resource-constrained embedded devices. DIALED aims to detect data-only attacks that only corrupt intermediate computation results stored in data memory. FeSA (Kuang et al., 2022) is a automatic swarm attestation protocol based on federated learning. It enables the verifiers to identify the suspicious devices by a neural network model and then attest them.

B. Hardware attestation and hybrid-based attestation

To address outlined limited of software attestation schemes, hardware-based approaches rely on trusted computing architectures such as TPM (Trusted Computing Group, 2017), ARM TrustZone (ARM, A., 2009), Sancus (Noorman et al., 2013). Despite their strong security guarantees, the requirement for security hardware that is costly for IoT platforms makes hardware-based protocols incompatible with many low-end devices. To this end, hybrid-based solutions, such as TyTAN (Brasser et al., 2015), leverage the best properties of software-based and hardware-based RA approaches to establish Root-of-Trust by relying on minimal hardware assumptions. In particular, hybrid solutions require hardware modification to ensure atomic and secure code execution of RA protocols. SIMPLE (Ammar et al., 2020) is a hypervisor-based RA scheme for resource-constrained IoT devices that aims to fill the gap between software-based and hybrid-based RA schemes. It relies on a software-based memory isolation technique called Security MicroVisor (SμV) (Ammar et al., 2019). SμV uses assembly-level code verification and selective software virtualisation to shield a software-based Trusted Computing Module (TCM) from untrusted software. However, this approach introduces increased execution time. HAtt (Aman et al., 2020) is a hybrid remote attestation using physical unclonable functions (PUFs) to protect the secrets of an IoT device from physical attacks. The proposed attestation technique ensures the high availability of IoT devices during the attestation routine. RATA (De Oliveira Nunes et al., 2021) aims to detect transient malware that compromises a device and erases itself before the next attestation. SARA (Dushku et al., 2020) is an attestation protocol that aims to attest a large number of devices. SARA exploits asynchronous communication capabilities among IoT devices to attest a distributed IoT service executed by them. LIRA-V (Shepherd et al., 2021) is a lightweight system that aims to attest constrained devices using the RISC-V architecture. It uses RISC-V Physical Memory Protection (PMP) primitive and read-only memory to build a trust anchor for remote attestation. SCRAPS (Petzi et al., 2022) is a collective RA scheme that achieves scalability by outsourcing verifier duties to a smart contract and mitigates DoS attacks against both provers and verifiers.

Nevertheless, most of the works focus on the integrity of the lightweight embedded devices, and the proposed attestation protocols need to check the whole memory of the target devices. However, high-end IoT devices with a large amount of memory and installed operating system are widely deployed. The memory of these devices is also at risk of malicious tampering. DRSA focuses on challenging the remote attestation schemes on devices with more processing power and memory. By utilising debug registers, DRSA can relocate itself and escape detection from existing software attestation schemes.

C. Attacks on remote attestation

Several attacks have been countered against the existing software-based attestation schemes. The adversary might predict the challenge and precompute the result of the victim's original state, try to get a correct response by modifying the attestation code or altering the memory contents (Li et al., 2014). The attacker can also keep either the full copy of the original memory content or only the modified locations, then redirect the memory access to these locations during attestation (Armknecht et al., 2013). Another attack might divide the storage of the original memory contents or divide the attestation process by colluding with other compromised nodes (Steiner & Lupu, 2016). The attacks mentioned above all refer to semi-intrusive and invasive attacks because they both need to capture the device physically. Non-intrusive attacks, e.g. side-channels attacks (Carlet et al., 2020) are usually resisted by some physical means, where RA is unsuitable. With the adoption of the RA mechanism, attackers may utilise some weaknesses of the schemes to launch attacks. For example, an attacker may launch DoS attacks (Chew et al., 2021) by sending forged attestation requests frequently to the provers. DRSA attempts to bypass the RA mechanism by exploiting debug exceptions not considered by existing schemes.

9. Conclusion and future work

In this paper, we presented DRSA, a new specific attack against existing software attestation techniques on the x86 platform. DRSA circumvents attestation by relocating itself and restoring the contents before it is measured. It leverages debug registers provided by the debugging architecture to monitor an RA measurement's beginning and end, erase itself and restore the original program memory contents before attestation. We designed and implemented the prototype of DRSA under the Windows and Linux operating systems, respectively. From our experience, we can conclude that DRSA incurs very little attack overhead, which is difficult to detect by the existing time-based attestation schemes on the x86 platform. We also stress that an attacker can hide malicious code using debug registers, which is not taken into account by existing attestation schemes. We argue that attestation schemes should pay more attention to the high-end devices with debug architectures and more memory. For future work, we will investigate software-based attestation protocols that can guarantee security for devices with operating systems and more complex mechanisms.

Disclosure statement

No potential conflict of interest was reported by the author(s).