Keywords

1 Introduction

A signal that represents a continuous range of values that varies over time is referred to as an analog signal [30]. Such signals can also be characterized by natural phenomena, such as lightning, earthquake, wind speed, volcano, sound waves, weight measurements, etc. Analog signals are often in the form of electrical energy, such as voltage, current or electromagnetic power. These signals typically come from sound, light, temperature or motion sensors. However, analog signals, which have more than 2 distinct readings, are not compatible in digital computation. This is because, digital devices, such as computers and microcontrollers (MCUs)Footnote 1, operate only on binary or digital values, i.e., 0 s and 1 s. As such, it is required to convert analog signals to digital values (i.e., discrete-time values) in order to process them using digital devices. This is where the analog-to-digital converter (ADC) [23] comes in handy. As the name implies, ADC is a system that converts an analog signal (i.e., continuous voltage values) to digital values, which can be understood by most computers and MCUs for digital computation. Most state-of-the-art MCUs have an inbuilt ADC. Therefore, such binary encoding of analog signals facilitates the interface between digital circuits and the real world. The analog-to-digital conversion logic of ADC typically involves three steps: sampling and holding (S/H), quantization and encoding [33].

ADCs are widely used in most digital systems that involve analog signals in its computations. These includes IoT, control systems (e.g., ICS/CPS), image processing, digital multimeters, cell phones, and medical imaging, to name a few. For example, PLCs [2] in ICS [34]/CPS [24, 39] often make control decisions based on the inputs obtained from analog sensors (e.g., temperature, pressure and force sensors). However, they cannot directly use analog inputs as they cannot understand analog signals. Hence, they have inbuilt ADCs that serve to convert the analog signals into digital values. The PLCs will then use these digital values to make control decisions [21].

Since ADC is an integral and critical part of most computing systems, such as IoT and ICS/CPS, it has been targeted by various types of cyber criminals. The attackers may exploit vulnerabilities that could be found in the hardware or software of ADCs. For example, Bolshev et al. [5] has exploited vulnerabilities in the sampling frequency and dynamic range of the ADC conversion logic. There are also attacks that exploited the strong correlation between the ADC digital output codes and the ADC supply current waveforms [17]. Other attacks exploited fast attack automatic gain control (AGC) vulnerability in ADC [3, 16, 19]. Other class of attacks exploited the DAC-to-DAC crosstalk vulnerability in the ADC conversion logic [22, 31, 36]. Numerous side-channel attacks have also exploited various types of vulnerabilities in ADC [4, 11, 13, 26, 27, 29]. Hardware trojan attacks were also launched on the analog circuits of ADCs [12]. Other researchers have conducted a security analysis on the output signals of the ADC datapath and its control unit [35] and ADC power noise measurement attacks [37]. However, we are not aware of existing attack techniques in the literature that specifically exploit vulnerabilities related to ADC registers (the smallest and fastest memory locations that are built into the processor). Hence, this work aims to bridge this gap in ADC security.

In this work, we first conduct a deeper analysis and study on ADCs to explore exploitable vulnerabilities in the analog-to-digital conversion logic. In particular, we study the various types of ADC registers involved in the analog-to-digital conversion process. After systematically analyzing the nature of these registers, we find out that most of them are vulnerable to a manipulation attack. This is because, registers for low-end MCUs are often controllable by user code and have no or little protections built in against unauthorized manipulations. Consequently, an attacker may modify or clear certain values or flags of the registers to deceive the output of the ADC conversion logic. Moreover, the attacks can be performed in a stealthy way so that it will be very hard to be detected using conventional techniques. The attacks can also be carried out physically or remotely through malicious code injection or malevolent system configuration. In control systems, such as ICS/CPS, systematically manipulated ADC outputs can mislead PLCs to make wrong control decisions. This may, in return, result in a disaster to the physical plant of the ICS/CPS. To the best of our knowledge, there are no prior attacks presented in the literature that specifically targeted ADC registers to deceit the ADC conversion process.

To scrutinize the actual exploitability of the registers, we design EARIC (Exploiting ADC Registers in IoT and Control systems) – a scheme comprising the three types of attacks we designed to manipulate the ADC conversion logic. In EARIC, we particularly target three critical ADC registers that are commonly used in the ADC conversion logic. This includes, ADC multiplexer selection register (ADMUX), analog comparator control and status register (ACSR), and two ADC data registers (i.e., ADC High register (ADCH) and ADC Low register (ADCL)). By systematically manipulating the values or flags of these registers, we manage to deceive or interrupt outputs of the ADC. That means, we force the ADC to return undesirable digital values from analog signals. To this end, we design and perform three types of attacks on the ADC conversion logic: (1) Deceiving the ADC conversion process - changing the expected ADC output into a totally different value; (2) Creating denial of service (DoS) in the ADC process - hanging the ADC conversion process and causing system unavailability; (3) Resetting the ADC conversion process - making the ADC to always return an empty output. Finally, we assess and evaluate the effectiveness of the proposed attacks using a minimalist CPS (mini-CPS) testbed we designed using IoT devices, such as Arduino (as a soft PLC), analog sensors and actuators.

In general, the main motivation of this work is to show that dangerous stealthy attacks can be launched into critical systems by exploiting certain ADC registers. In this work, we make the following technical contributions.

  1. 1.

    We conduct a deeper study in the ADC conversion logic and identify vulnerabilities on the ADC registers used in the analog-to-digital conversion process.

  2. 2.

    We design and perform three types of attacks by exploiting the vulnerabilities we identified.

  3. 3.

    We assess and evaluate the effectiveness (in terms of accuracy, efficiency and impact) of the proposed attacks using an IoT-based mini-CPS testbed we designed.

2 Background

In this section, we provide relevant background information to this work. Specifically, we provide a high-level information on the ADC conversion logic and cyber-physical systems (CPS). For easy reference, Table 1 lists out all the relevant acronyms and notations used in this paper.

Table 1. Description of acronyms and notations
Full size table

2.1 Overview of ADC

Analog and Digital Signals. As highlighted in the introduction, analog signals are electromagnetic signals that are characterized by a series of continuous values that varies with time. These signals are illustrated in Fig. 1. Such signals can be obtained from sound, temperature, light, and motion phenomena using analog sensors.

Analog signals can be used as an input to solve various real-world problems. For example, IoT services and control systems can use them to automate or control processes. However, these signals cannot be directly used since digital devices, such as computers and microcontrollers, can read only digital values. Hence, the analog signals need to be first converted to digital signals before it is used by digital devices further computations. Unlike analog signals, which are represented by a sequence of continuous values, digital signals are broken down into a set of discrete values with time series or sampling rates. It usually have only two values – high (1) and low (0). Consequently, all values in digital signal transmissions are in the form of 0’s and 1’s. Digital signals are illustrated in Fig. 2.

Fig. 1.
figure 1

Analog signals

Full size image
Fig. 2.
figure 2

Digital signals

Full size image

Analog to Digital Conversion. The conversion of analog signals to digital signals is carried out by an analog-to-digital converter (ADC). In other words, ADCs serve to convert continuous-time analog signals to discrete-time digital signals, which will be consumed by digital devices for digital computations. Hence, most digital devices have builtin ADC, integrated with their processors. They can also be connected to an external ADC.

ADCs convert analog signals to digital signals using pulse code modulation (PCM)Footnote 2 method, which involves three main steps – sampling, quantizing and encoding [15, 32]. ADCs on most microcontrollers, e.g., PIC32Footnote 3, typically have a 10-bit wide resolution, i.e., with 1024 quantization levels. Most microcontrollers also have multiple analog input channels due to their multiplexed ADC. For example, the PIC32MX460F512LFootnote 4 microcontroller has 16 10-bit wide ADC channels. The ADC analog comparator [25] is an essential building block in ADC that compares two input voltages and produces an output. ADCs also involve a wide-range of memory registers that play various roles in the analog-to-digital conversion process. For example, the ADC’s output data, i.e., the converted digital value, is stored in a 16-bit double data registers, i.e., ADCH (8-bit size) and ADCL (8-bit size). A high-level architecture of the ADC conversion logic involving the main memory registers is illustrated in Fig. 3. A detailed discussion of some of the registers is also provided in Sect. 4.

2.2 Overview of CPS

Cyber-physical systems (CPS) are engineering systems where computations and communications are firmly integrated with physical entities to automate and control industrial processes through feedback control [24, 39]. It comprises the following main entities [6]: physical plant (the physical system where actual processes take place), sensors (devices that read state information of physical processes), PLCs (embedded devices that issue control commands based on sensor inputs), actuators (physical entities that implement control commands issued by PLCs), SCADA [38] (a software designed for process monitoring and controlling), HMI (a system to display the state information of physical processes), and historian server (a server used to store operational and historical data). A typical CPS is also constrained by stringent real-time and availability requirements [9].

As discussed above, the PLC is at the heart of the CPS. It issues control commands based on the inputs obtained from sensors. However, the sensors could be digital or analog. In the latter case, the PLC cannot read analog signals like many other digital devices (see the discussion in Sect. 2.1). Hence, the ADC is required to convert the analog signals to digital values before the PLC uses them to make control decisions. To facilitate the conversion process, most PLCs nowadays come with inbuilt ADCs.

3 Threat Model

In our threat model, we consider adversaries that target digital systems, such as IoT and control systems, by exploiting vulnerabilities of the ADC registers that are used in the analog-to-digital conversion logic. The goal of the assumed adversary is manipulating outputs of the ADC in a stealthy manner so that it cannot be easily detected using conventional techniques. In fact, detecting the assumed attack is even more difficult since it is to be performed on the interface between the physical and digital worlds.

In reality, no attack would be successfully performed without creating a connection with the targeted device. Therefore, in our threat model, we assume that a connection can be established with the targeted digital devices (e.g., PLCs in CPS) either physically (e.g., via a serial connection) or remotely (e.g., via the Internet). Hence, we consider both physical attacks (e.g., insider attacks) and remote attacks (i.e., cyberattacks) in our threat model. In the former case, the attack can be performed by injecting malicious code to the targeted device through a serial connection. In the latter case, the attack can be launched by uploading malicious code to the targeted device over Internet. Note that most digital devices (including IoT and control devices) nowadays are connected to the Internet to facilitate over-the-air OS/firmware update or remote code upload to the devices. For example, the Arduino board has an Ethernet bootloaderFootnote 5 that allows users to upload code remotely. Such facilities may allow the adversary to remotely upload malicious code to the devices.

In either physical or remote attack, the adversary is required to systematically tailor malicious code that allows him to control the registers of low-end MCUs. Note that the ADC registers can be controlled by user code and have no or little underlying protections against manipulation attacks. Hence, the adversary can manipulate the default values of the registers using his tailored malicious code. The designed malicious code can be injected to the device’s firmware. In some cases, the attacks might be performed through malevolent system configurations. In our case, we perform the attacks by injecting our malicious code into the Arduino firmware (details are provided in Sect. 4).

Fig. 3.
figure 3

A high-level architecture of ADC with registers

Full size image

4 EARIC: The Proposed Attacks

4.1 Overview

In this section, we introduce EARIC – a scheme comprising the three attack techniques we designed. As discussed in the preceding sections, we propose and develop new ADC attack techniques by exploiting the registers used in the analog-to-digital conversion logic. To simplify the presentation of our proposed attacks, it is essential to highlight how the ADC conversion logic works and the relevant registers involved in the process. As discussed in Sect. 2.1, ADC converts the voltage value on the analog input pin and returns a digital value from 0 to 1023 (for a 10-bit wide ADC), relative to the reference value. The analog input channel is selected using an analog multiplexer [18], and the input value is processed in ADC with a reference voltage for certain clock timings. When the analog-to-digital conversion is completed, the output result (often called the “ADC output data”) is stored in the two ADC data registers, i.e., ADCH and ADCL (each 8-bit wide). More precisely, for a 10-bit ADC resolution, the ADC output will be stored in the \(9^{th}\) to \(0^{th}\) bits of the ADCH and ADCL data registers (cf. Fig. 4). A typical schematic of ADC is illustrated in Fig. 3. In Fig. 3, ADC0 to ADC7 represents the input pins for the analog input signals. The multiplexer (MUX) selects the input voltage from the pins and transfers it to the registers.

As shown in Fig. 3, several registers are involved in the ADC conversion logic. As highlighted in the preceding sections, these registers are vulnerable to attacks since its default values (data or flags) can be manipulated by an attacker. This is because, there are no security mechanisms in place to protect these registers against such malevolent manipulations. In this work, we exploit such weaknesses to perform three types of attacks on the ADC conversion logic. A detailed account of the attacks is provided in the following section.

4.2 The Proposed Attacks

As mentioned in the preceding sections, we perform three types of attacks on ADC to scrutinize exploitability of its registers. In particular, we perform the attacks by exploiting three of the most critical ADC registers, such as ADMUX, ACSR, and the ADC data registers (i.e., ADCH and ADCL). The attacks are tested using a mini-CPS testbed simulating an alarm system based on an analog temperature sensor. In brief, the system triggers an alarm when the temperature read is beyond a threshold. A detailed account of the testbed is provided in Sect. 5. Below, we discuss each of the proposed attack techniques and its respective outcomes.

Deceiving the ADC Conversion Logic (Attack 1).

With the first attack, we deceive the ADC conversion logic by manipulating the ADMUX register. The ADMUX register is used to select the reference voltage as well as to determine which analog input channel is to be chosen. Furthermore, this register is used to determine whether the ADC output data should be left-justified (i.e., the output data is to be read from the left-most bits) or right-justified (i.e., the output data is to be read from right-most bits) with respect to the 16-bit ADC data registers (i.e., ADCH + ADCL). As shown in Table 2, the ADMUX register comprises 8 bits. A high-level discussion of the bits is provided as follows.

- REFS (Reference Selection Bits): REFS1 (Bit 7) and REFS0 (Bit 6) are reference selection bits in ADMUX that are used to select the voltage reference for the ADC. The internal voltage reference options may not be used if an external reference voltage is applied to the AREF pin.

- ADLAR (ADC Left Adjust Result): ADLAR (Bit 5) affects the presentation of the ADC output data in the ADC data registers (refer Sect. 4.2). Depending on the value set to the ADLAR bit, the ADC output data can be either right-justified (i.e., ADLAR = 0) or left-justified (i.e., ADLAR = 1) in the ADCH and ADCL data registers. The default mode is right-justified. The left-justified mode is not supported by most microcontrollers, including the Arduino board we used in our experimental setup (cf. Sect. 5).

- MUX3 (Multiplexer): MUX3 (Bit 0 to 3) are the analog channel selection bits that are used to select the analog input channel (refer ADC0 to ADC7 in Fig. 3). A detailed account of how the analog channel selection bits work in ADC can be found in [28].

Table 2. ADMUX register bits with its default values
Full size table

Attack Synopsis: The default values of the ADMUX register bits are shown in Table 2. That is, REFS1 is ‘1’, REFS0 is ‘1’, ADLAR is ‘0’, and MUX0 to MUX3 is ‘0’. As discussed above, the value of ADLAR affects the presentation of the ADC output data in the ADCH and ADCL data registers. By default, the ADC output data is right-justified (i.e., ADLAR = 0). That means, the output data will be read from the \(9^{th}\) to \(0^{th}\) bits of the ADCH and ADCL data registers (for a 10-bit ADC resolution). The ADCH and ADCL data presentation with respect to the ADLAR value (i.e., ‘0’ or ‘1’) is illustrated in Fig. 4. However, as shown in Table 3, the ADLAR bit of the ADMUX register can be set to ‘1’ to reverse the ADC output data presentation (i.e., left-justified). Meaning, the ADC output data will be read from the \(15^{th}\) to \(6^{th}\) bits, where the \(15^{th}\) to \(10^{th}\) bits contain garbage (junk) data as shown in Fig. 4. When the digital device (e.g., the PLC in CPS) tries to read the ADC output data, it will be referred to the garbage location, which returns an undesirable value (often a very high value). In practice, this attack might be achieved in different ways. For example, it could be launched by sending a malicious ADC command to the PLC at runtime or by systematically synthesising and injecting a malicious code to the PLC firmware. In our case, we follow the latter. We inject the following code into the Arduino firmware, which sets the ADLAR bit to ‘1’.

$$\begin{aligned} ADMUX\;| = (1<< 5); \end{aligned}$$

After performing the above attack on our experimental setup, the ADC was forced to return a temperature of 1588.13\(^{\circ }\)C from the analog temperature sensor even though the actual temperature reading was 24.49\(^{\circ }\)C. The output of this attack is depicted in Fig. 5. This misleads the PLC to issue and send a wrong control command (i.e., “ON” command) to the actuator, i.e., a siren alarm set in our experimental setup (refer Sect. 5). As a result, the siren alarm was triggered even though the actual temperature was below the threshold. That means, the wrong ADC read from the garbage location misleads the PLC to make a wrong control decision, which in turn could cause a disaster or damage to the CPS plant.

In sum, the main aim of this attack is deceiving the ADC output data presentation on the ADC data registers (i.e., ADCH and ADCL) by manipulating the ADLAR value on the ADMUX register. Consequently, PLCs will be forced to read undesirable ADC output data, hence misleading them to make wrong control decisions. A high-level architectural illustration of this attack is provided in Fig. 6. As shown in Fig. 6, the attack is performed on the ADLAR flag of the ADMUX register and, consequently, the ADCH and ADCL data registers are impacted.

Table 3. ADMUX register bits after manipulating the ADLAR bit
Full size table
Fig. 4.
figure 4

ADC output data presentation in ADCH and ADCL registers with respect to the ADLAR value Note: “G” is for garbage data, “x” (from bit 9 to 0) represents the ADC output data values in binary format, i.e., 0’s and 1’s. For example, Table 4 shows how a temperature reading of 24.49\(^{\circ }\)C is stored in the ADCH and ADCL data registers.

Full size image
Fig. 5.
figure 5

Output of Attack 1

Full size image

Creating a DoS Attack on the ADC Process (Attack 2).

In this attack, we create a denial of service (DoS) attack on the ADC conversion process by manipulating the ADC analog comparator control and status register (ACSR). As highlighted in Sect. 2, the ADC analog comparator [25] is an essential part of the ADC conversion process. It is managed and controlled by the ACSR register. As depicted in Table 5, the ACSR register is represented by 8 bits comprising Analog Comparator Interrupt Mode Select (ACIS0 and ACIS1), Analog Comparator Input Capture Enable (ACIC), Analog Comparator Interrupt Enable (ACIE), Analog Comparator Interrupt (ACI), Analog Comparator Output (ACO), Analog Comparator Band Gap (ACBG) and Analog Comparator Disable (ACD). All the ACSR bits except bit 5 (which is read-only) are readable and writable (R/W). The default value of these bits is ‘0’ except ACO, which is not applicable (NA).

Attack Synopsis: Each logical bit in the ACSR register plays different roles and functionalities in the ADC conversion logic, depending on the logical value (i.e., ‘0’ or ‘1’) set to it. For example, the analog comparator will be disabled if the logical bit ACD is set to ‘1’, the analog comparator interruption will be enabled if the logical bit ACIE is set to ‘1’, etc. A detailed information regarding the roles and functionalities of the ACSR bits in the ADC conversion logic can be found in [28]. When we simultaneously set the ACD and ACIE bits to ‘1’ in the ACSR register, the ADC conversion process will hang, hence leading to DoS attack. This will render system unavailability, which is a critical concern in time-sensitive systems, such as CPS. Our construction of Attack 2 (i.e., DoS attack) in the ADC conversion logic is formally captured as follows:

$$\begin{aligned} DoS\_Attack:= (ACD == 1) \wedge (ACIE ==1) \end{aligned}$$

In our experimental setup, we perform this attack by injecting the code “ACSR |= 0b10001000;” into the Arduino firmware. Here, the 4\(^{th}\) bit (i.e., ACIE) and 8\(^{th}\) bit (i.e., ACD) of the ACSR register are set to ‘1’, which causes the system to hang (the output is shown in Fig. 7).

Table 4. The ADC output data presentation in data registers
Full size table
Table 5. ACSR register bits
Full size table
Fig. 6.
figure 6

Attacking the ADMUX register

Full size image
Fig. 7.
figure 7

The output of Attack 2

Full size image

4.2.1 Resetting the ADC Process (Attack 3)

In this attack, we reset the ADC process by manipulating the ADC data registers, such as ADCH and ADCL. As discussed in the preceding sections, ADC has two 16-bit wide data registers, i.e., ADCH and ADCL. These registers are used to store the ADC digital output obtained from the analog conversion. For example, Table 4 shows how our temperature sensor reading of 24.49\(^{\circ }\)C is stored in the ADC data registers. The equation to translate the sensor reading temperature value to binary format and vice versa can be referred in [1].

Attack Synopsis: Like the other ADC registers, the ADC data registers (i.e., ADCH and ADCL) can also be manipulated by an attacker. One way to manipulate these registers would be by clearing the ADC outcome data stored in them. However, we cannot directly do that since these registers are read-only. Meaning, we can only read the data stored in these registers, but not modifying it. So, how can we achieve the attack on the ADC data registers? We discuss details of our proposed attack technique as follows.

The ADC output data is read by the the "analogRead()" function – a function (often used in Arduino) that reads the digital value from a specified analog pin. However, there are some implicit tasks to be performed before reading the digital value. First, the analog value (e.g., the voltage between 0 and 5V) from the analog pin will be converted to a digital value between 0 to 1023 (for a 10-bit long ADC). As discussed in the preceding sections, this digital value (i.e., the ADC output) will be then stored in the ADCH and ADCL registers. Then, the "analogRead()" function defines two variables, say "low" and "high", to read the ADC output from the ADCL and ADCH data registers, respectively. That means, the "low" variable reads values from the ADCL register and the "high" variable reads values from the ADCH register. The final ADC output will be a combination of the two variables, i.e., \( low = ADCL \; \& \& \; high = ADCH\). However, we can attack this logic by including a malicious script in the device’s (the Arduino in our case) firmware, and particularly in the "analogRead()" function. Instead of assigning the ADCL and ADCH register values to the "low" and "high" variables mentioned above, we can maliciously assign ‘0’ to both. That means, we inject the "\(low = 0;\)" and "\(high = 0;\)" codes to the source-code of the "analogRead()" function in the Arduino firmware. This might also be done through system configuration. This leads the ADC output to be always ‘0’ instead of the actual result. We tested this attack on our temperature reading setup. Even though the actual temperature was 24.17\(^{\circ }\)C, the temperature reading after launching the attack was always 0\(^{\circ }\)C. The outcome of this attack is shown in Fig. 8. Therefore, this attack can also mislead the control decision of PLCs in CPS. In a similar way, more critical and complex attacks can also be performed on the ADC data registers.

Fig. 8.
figure 8

Output of Attack 3

Full size image

5 Experimental Design

In this section, we present details of our experimental setup designed to test the proposed attack techniques. Our experimental setup simulates a temperature-based alarm control system. In brief, the system periodically reads the surrounding temperature, and it triggers an alarm when the temperature value is above a threshold, e.g., 30\(^{\circ }\)C.

To simulate the above process, we design a mini-CPS testbed using IoT devices, sensors and actuators. Specifically, we use Arduino MEGAFootnote 6 as a soft PLC, which makes control decisions based on the temperature readings of the sensor. We use an analog temperature sensor LM35Footnote 7 to read the surrounding temperature and feed it to the PLC. We use an 8\(\Omega \) siren alarmFootnote 8 as an actuator, which activates the alarm when it receives an “ON” command from the PLC. A high-level schemata of the experimental setup is depicted in Fig. 9.

As shown in Fig. 9, the analog temperature sensor (LM35) is connected to the Arduino board (via the analog input A0) to read the surrounding temperature. The sensor is also connected to the internal voltage reference 3.3V. The Arduino board has 16 analog input pins and 54 digital input/output pins. It also contains an inbuilt ADC and MCU. The inbuilt ADC (integrated in the same electrical circuit board with the MCU) converts the analog temperature values to a discrete-time digital values. The MCU acts as a PLC and makes control decisions, such as triggering the alarm, based on the digital temperature value obtained from the ADC. More specifically, it issues an “ON” or “OFF” control command depending on the the temperature value and the threshold set. The “ON” control command triggers the alarm while the “OFF” control command turns off the alarm. An 8\(\Omega \) mini speaker (a siren alarm) is connected to the Arduino board to act as an actuator. It activates the alarm when it receives an “ON” command from the PLC, and it turns off the alarm otherwise.

Fig. 9.
figure 9

Schematic diagram of the experimental setup

Full size image

Due to lack of access, we did not conduct our experiments on real-world CPS testbeds with vendor-supplied PLCs. Yet, we believe that our experimental setup described above is substantially sufficient to evaluate the effectiveness of the proposed attach techniques. This is because, Arduino boards are widely used both in experimental and production settings. For example, it is widely used in various IIoT, ICS and CPS systems. Hence, protecting such systems against ADC-based attacks is also desirable. Moreover, the analog-to-digital conversion logic and software/hardware design of most ADCs are very similar. Hence, the ADC architecture (including its memory registers) of Arduino-based PLCs is highly likely to be similar with that of real-world PLCs. Therefore, we expect that the presented ADC attacks will also be effective when applied to real-world PLCs, which is left as a future work.

6 Evaluation and Discussion

In this section, we discuss a detailed evaluation of our proposed attacks. In brief, we evaluate the proposed attack techniques along three dimensions: 1) Accuracy 2) Efficiency and 3) Impact. Furthermore, we discuss possible countermeasures to prevent such types of ADC attacks.

6.1 Attack Accuracy

There were no much significant internal or external factors that could influence our experimental results. The only sensible factor or variable is the temperature environment. Hence, we conduct the experiments in different temperature conditions, such as cold (\(<16^{\circ }\)C), mild (16\(^{\circ }\)C–25\(^{\circ }\)C) and hot (\(>25^{\circ }\)C). In all such circumstances, the proposed attacks always produced the expected results. Meaning, we have not observed any false positive or false negative results in all our experiments. Therefore, the proposed attacks are very accurate in achieving the intended goal.

6.2 Attack Efficiency

The proposed attack techniques are simple to be launched. The attacks are performed by systematically manipulating the flag or data values of the targeted ADC registers. At runtime, there was not any significant overhead observed, both in CPU and memory usage. It takes only a few microseconds to conduct each of the three attacks. To experimentally show the execution time of each attack, we performed 50 simulations for each attack. The experimental results are depicted in Table 6. That means, the execution time of Attack 1 and Attack 3 are 60.2 \(\mu \) and 60.3 \(\mu \), respectively. However, we could not measure the execution time of Attack 2 since the system immediately hangs after this attack is performed. Therefore, outputs of the attacks are almost instantaneous. Meaning, impacts of the attacks can be reflected in real-time – without any significant delay.

6.3 Attack Impact

ADCs are commonly used in a wide-range of critical systems, such as ICS, CPS, and IoT, among others. Hence, manipulating the ADC conversion logic may result in a catastrophic impact to the systems. For example, the ADC outcome (i.e., the converted digital value) is a crucial input to the PLC to make control decisions in CPS. If the ADC outcome is manipulated, it will mislead the PLC to make wrong control decisions. This will result in incorrectly controlling the physical process in CPS. Hence, the entire CPS system could be severely impacted, including destruction of the physical plant. Although the proposed attacks are tested on an Arduino-based soft PLC, we believe that it can also be applied and tested on real-word CPS systems (refer the discussion in Sect. 5).

Table 6. The average execution time of the attacks for 50 simulations
Full size table

6.4 Proposed Countermeasures

As discussed in the preceding sections, attacking the ADC logic can result a catastrophic impact on various systems and infrastructures. In particular, manipulating values of the ADC registers is a critical stealthy attack that might not even be easily detected. Therefore, it is essential to design appropriate countermeasures against these attacks. In this work, we highlight possible countermeasures and research directions to overcome such security concerns.

Enforcing write-protected policy to ADC registers As discussed, the register manipulation attacks are carried out by overwriting the exiting data or flags of certain critical registers in ADC, such as ADMUX, ACSR and the ADC data registers. One possible direction to address such attacks is by systematically enforcing a stringent"write-protected" policy to critical ADC registers and other memory locations. Such measures may help to prohibit an unauthorized overwriting of ADC registers, hence preventing manipulation attacks in ADC registers.

Authorizing and tracking firmware updates Properly authenticating and authorizing PLCs would be another approach to prevent ADC-based attacks. To minimize attacks that inject malicious ADC commands to the PLC firmware, only authorized users should be allowed to make such changes. A logging system should also be in place that tracks and traces all authorized and unauthorized software/firmware changes made or inputs provided to the system.

7 Related Work

In this section, we discuss prior works that are closely related to the security of ADC. In particular, we discuss prior attacks performed on the ADC logic.

As discussed in the introduction, ADCs have been targeted by various types of attackers. Attackers often target certain vulnerabilities that can be discovered in the hardware or software of ADCs. Bolshev et al. [5] has conducted an extensive study both on the hardware and software based vulnerabilities of ADCs. They then developed an attack technique by exploiting vulnerabilities in the sampling frequency and dynamic range of the ADC conversion logic. There are also side-channel attacks that exploited the strong correlation between the ADC digital output codes and the ADC supply current waveforms [17]. If the power side-channel attack (PSA) of the ADC is exploited, it can expose the private signal change data [16]. When applied to a successive approximation register (SAR) without PSA protection, the power supply current waveforms of the SAR are attacked. Other side-channel attacks have been also developed by exploiting various vulnerabilities in ADC [4, 11, 13, 20, 26, 27, 29].

Other class of attacks have exploited fast attack automatic gain control (AGC) vulnerability in ADC to deceive the outcome of the analog to digital conversion [3, 16, 19]. Some other attacks exploited the DAC-to-DAC crosstalk vulnerability in the ADC logic [22, 31, 36]. However, we are not aware of any existing attack techniques that exploit vulnerabilities related to ADC registers.

In CPS, an attacker who has access to the PLCs can generate a signal with a frequency that is interpreted as being valid by the ADC, when in reality it can cause serious damage to the physical process [19]. In spite of ADCs having anti-aliasing filter that restricts the bandwidth of a signal, these filters do not prevent frequency attacks. Another ADC-related CPS attack involves manipulating the device’s input and output (I/O) at a low level, which allows the attacker to control the PLC without triggering any alarms [20].

System-on-Chip (SoC) integrators may design a Hardware Trojan with the intention of perturbing the ADC from malfunctioning by manipulating input or output signals or by affecting the modulator’s output bit [36]. Another stealthy hardware trojan attack was also recently launched on the analog integrated circuits (ICs) of ADCs [12]. However, all these attacks did not specifically target the ADC registers.

Memory corruption attacks are another common threats against IoT devices or PLCs in ICS/CPS. They typically exploit memory-safety vulnerabilities, such as buffer overflows and dangling pointers, that could be found in the software or firmware of the devices to corrupt the process memory or execution flow of programs at runtime [7, 8, 10, 14]. However, these attacks target the runtime process memory of the devices, not specifically the ADC memory registers.

In summary, there are several types of ADC-related attacks presented in the literature. To the best of our knowledge, none of them specifically target ADC registers. In this work, we identify and exploit certain ADC registers used in the analog-to-digital conversion process, which appear to be the unexplored attack surfaces in ADC.

8 Conclusion

ADCs are integral components in most critical systems, such as IoT and control systems. However, ADCs have been targeted by a wide range of physical or cyber attacks. The attackers may exploit various types of vulnerabilities that could be found in the software or hardware of ADCs. In this work, we first conducted a more in-depth study of the ADC conversion logic to discover relevant ADC vulnerabilities that were not well explored by previous work. Consequently, we managed to find relevant vulnerabilities on ADC registers. To demonstrate its exploitability, we developed three types of ADC attacks and tested it in an IoT-based mini-CPS environment.

By manipulating the ADC registers, we showed that it is possible to deceive the ADC outcome or maliciously halt the analog-to-digital conversion process. The ADC process can be forced to return an output that is much different from the expected result. This is carried out by changing the flag in the ADC multiplexer selection register, called ADMUX. An attack can also be carried out by manipulating the analog comparator control and status registers, called ACSR. We managed to maliciously hang the ADC conversion process by simultaneously enabling the ACD (analog comparator disable) and ACIE (analog comparator input enable) bits of the ACSR register, which resulted in system unavailability. We also showed that the ADC conversion process can be rendered useless by setting its output values to zero. This is achieved by resetting the data reader when it reads the ADC output from the ADCH and ADCL data registers. This was an attempt to show that ADC registers can most definitely be manipulated if no underlying protection mechanism is set for the ADC conversion process.

In the future, we plan to extend our experiments on real-world CPS testbeds using vendor-supplied PLCs. We also intend to conduct additional research to further explore key ADC vulnerabilities. Proposing and developing appropriate countermeasures for register-based ADC attacks is also left as a future work.