8386 IEEE INTERNET OF THINGS JOURNAL, VOL. 11, NO.

5, 1 MARCH 2024

Control Logic Attack Detection and Forensics

Through Reverse-Engineering and Verifying
PLC Control Applications
Yangyang Geng , Xin Che, Rongkuan Ma , Qiang Wei , Mufeng Wang, and Yuqi Chen

Abstract—Industrial control systems (ICSs) are prevalent in I. I NTRODUCTION

critical infrastructures, where programmable logic controllers
NDUSTRIAL control system (ICS) provide controlling and
(PLCs) and physical instruments are integrated. However,
multiple successful attacks against PLC control logic programs
have caused significant damage to ICSs, which has led to an
I monitoring functionality for industrial processes, and play a
key role in critical infrastructure, such as gas, electricity, water
urgent need for detection and forensics of such attacks. Although treatment, chemical, pharmaceutical, and food [1], [2], [3],
several off-the-shelf defending mechanisms have been presented [4]. Recently, cyber attacks against these critical systems have
in the past, few of them can detect and locate the control logic
attacks at run time. In this article, we propose a practical and caused widespread and significant consequences on society. In
automatic control logic attack detection and forensics framework particular, programmable logic controllers (PLCs) are vulnera-
(CLADF) to conduct control logic attack detection and foren- ble to control logic attacks. Attackers can manipulate physical
sics in ICSs. Specifically, the core of CLADF includes: 1) a processes by modifying the control logic program of compro-
control application extraction module to extract PLC binary
mised PLCs. For example, the Stuxnet [5] infected Siemens
control applications by simulating PLC normal upload func-
tionality; 2) a control application reverse engineering module to S7-300 PLCs to tamper with the control logic program, and
disassemble binary control applications; and 3) an attack detec- sabotaged Natanz’s nuclear facility silently by periodically
tion and forensics module for verifying the integrity of PLC modifying the motor speed of the centrifuge. The TRITON [2]
control applications, recovering the normal control application, was designed to reprogram the control logic and manipu-
and locating the modified control instructions. We extensively
evaluated CLADF in five different application scenarios and late the controllers of Triconex safety instrumented systems,
two real-world Schneider PLCs. For each PLC, we generated causing unexpected downtime and financial losses to energy
three types of 150 mutated control logic attacks. The results facilities in the Middle East.
demonstrate that CLADF can effectively extract the run-time Upon further investigation, the attackers typically manipu-
binary control application in different application scenarios
late the target PLC to perform malicious functions by inserting,
and disassemble these binary control applications into assembly
instructions. Moreover, CLADF can accurately detect the attacks deleting, and modifying the control program’s source code [6],
and locate the modified subroutines. [7] or the compiled binary control application files [8], [9],
Index Terms—Attack detection and forensics, control [10], [11], [12], [13], [14], [15], [16]. These control logic
logic attacks, industrial control systems, programmable logic attacks compromised the integrity of the binary control logic
controllers. program in PLCs. To protect the PLC control logic pro-
gram, lots of mitigation solutions have been presented. We
group them into the following categories: 1) performing for-
mal verification on the high-level source code [17], [18], [19],
[20] and 2) verifying the integrity of the binary control logic
Manuscript received 7 June 2023; revised 22 August 2023; accepted bytecode [21], [22], [23], [24].
19 September 2023. Date of publication 25 September 2023; date of cur- Unfortunately, previous methods suffer from different lim-
rent version 21 February 2024. This work was supported in part by the
National Key Research and Development Program of China under Grant itations. First, accessing the PLC source code is not always
2020YFB2010900; in part by the National Natural Science Foundation of possible due to intellectual property concerns, as it may be
China under Grant 61833015; and in part by the Program for Innovation considered a trade secret for integration companies and not
Leading Scientists and Technicians of Zhongyuan under Grant 224200510002.
(Corresponding author: Rongkuan Ma.) open source for end users. Additionally, generating plant
Yangyang Geng, Rongkuan Ma, and Qiang Wei are with Information behavior models for different industries requires domain-
Engineering University, Zhengzhou 450001, China (e-mail: young9471@ specific expert knowledge. These models rely on open-source
163.com; [email protected]; [email protected]).
Xin Che is with the State Key Laboratory of Industrial Control Technology, libraries and automated verification frameworks to simulate
Zhejiang University, Hangzhou 310000, China (e-mail: [email protected]). physical properties. However, existing defense approaches
Mufeng Wang is with the China Industrial Control Systems
Cyber Emergency Response Team, Beijing 100040, China (e-mail:
based on formal verification [17], [18], [19], [20] assume that
[email protected]). the source code of the PLC and the plant behavior model
Yuqi Chen is with the School of Information Science and Technology, of the system are available. Second, different PLC vendors
ShanghaiTech University, Shanghai 201210, China (e-mail: chenyq@
shanghaitech.edu.cn).
apply custom compilers and proprietary binary file formats,
Digital Object Identifier 10.1109/JIOT.2023.3318988 making manual reverse-engineering of a single PLC binary
2327-4662 
c 2023 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
GENG et al.: CONTROL LOGIC ATTACK DETECTION AND FORENSICS 8387

file laborious and time consuming [15]. Furthermore, there is for Schneider M340 and M580 PLCs, respectively. Third, our
still a lack of automated reverse-engineering methods for con- solution can detect control logic attacks and locate modi-
trol applications of closed-source PLC devices (e.g., Schneider fied control program subroutines with an accuracy of 100%.
PLCs). Fortunately, most vendors utilize a common instruc- Finally, we measured the performance of CLADF. The result
tion set architecture (ISA) [e.g., Advanced RISC Machines shows that CLADF can automatically execute the whole pro-
(ARM)], enabling us to refer to established ARM-based meth- cess within an acceptable time (less than 3.340 s per detection
ods for reverse-engineering binaries automatically. Finally, cycle) and memory (less than 1 MByte/h) overhead.
existing techniques primarily concentrate on detecting whether We summarize our contributions as follows.
the control logic program has been modified, without offering 1) We introduce CLADF, a novel framework for PLC con-
the capability to perform a forensic analysis on the spe- trol logic attack detection and forensics. CLADF is capa-
cific modified control instructions. Consequently, conducting ble of automatically extracting the control application
a thorough analysis of the attacker’s intention and accurately for closed-source PLCs and reverse-engineering PLC
assessing the potential impacts on the physical processes and proprietary binary files. With this capability, CLADF
field instruments becomes a significant challenge. For instance, can effectively detect control logic attacks, facilitate
approaches based on the control logic program integrity vali- post-attack recovery, and pinpoint the modified con-
dation [21], [22], [23], [24] heavily rely on captured network trol logic subroutines, all without needing access to the
traffic during PLC control logic program upload or down- PLC source program, plant behavior model, or network
load. However, readily available upload and download network captures. To the best of our knowledge, CLADF is the
captures for runtime detection pose challenges. first assembly-level run-time PLC control logic attacks
To solve the aforementioned challenges and limitations, we forensics scheme.
propose a control logic attack detection and 2) We design and implement a control logic attack
forensics framework (CLADF) to effectively conduct detection and forensics tool on Schneider M340 and
control logic attack detection and forensics without the PLC M580 series PLCs. We develop a proprietary protocol
source program, plant behavior model, and any network communication client to extract PLC control appli-
captures. Moreover, we apply assembly-level instruction com- cations and then implement an interactive disassem-
parison to locate the modified instructions in the PLC control bler professional (IDA Pro) plugin to reverse-engineer
application and assess the attack impacts to the physical binary control applications into assembly instructions.
processes and industrial instruments. The key observation is Subsequently, we verify the control applications and
that the control logic attacks will destroy the integrity of the assembly instructions to conduct control logic attack
binary control applications and modify specific subroutines, detection and forensics.
and their control instructions. Therefore, it is possible to detect 3) We evaluate CLADF on five typical industrial con-
control logic attacks by verifying the PLC runtime control trol application scenarios and two Schneider PLCs. To
application, and perform a forensic analysis by comparing the demonstrate its effectiveness and generality, we generate
assembly-level control instructions in diverse subroutines. We three types of 150 mutated control logic attacks for each
make a realistic assumption that we can extract the control PLC. The evaluation result shows that CLADF can accu-
application from PLC via simulating PLC’s typical function- rately detect control logic attacks and further perform
ality (e.g., uploading program). CLADF is implemented in the forensics on the attacked subroutines and instructions in
following phases. First, we develop a protocol communication the PLC control application.
client to simulate PLC upload operation, based on which we This article is organized as follows: In Section II, we
extract the PLC binary control application. Second, we present introduce the relevant preliminaries. Section III presents an
an automatic reverse engineering approach for PLC binaries. overview of our threat model and generates three types of
Specifically, we reverse-engineer PLC binaries by identifying control logic attack vectors. Section IV details the design of
ISA, disassembling PLC binaries into assembly instructions, CLADF and Section V describes the specific implementation.
and generating an assembly log file (ALF). Finally, based Section VI presents the experimental analysis of the effec-
on the generated ALF, we propose a run-time control logic tiveness of our detection and forensics solution. Section VII
attack detection and forensics solution, including verifying the introduces the related work of PLC control logic attacks and
integrity of the PLC control application, recovering the normal detection methods. Finally, Section VIII concludes this article
control application, and locating the malicious instruction. and considers some limitations in our paper.
To evaluate the effectiveness and generality of CLADF
on control application extraction, control application reverse II. P RELIMINARY
engineering, and attack detection, recovery, and location,
This section first introduces the essential preliminaries for
we performed experiments on five different control applica-
ICS and PLC program and then illustrates a motivating
tion scenarios and two Schneider PLCs. And, we generated
example.
150 mutated control applications for each PLC. First, our eval-
uation result shows that CLADF can extract different control
applications with an accuracy of 100%. Second, CLADF is able A. Industrial Control Systems
to disassemble the extracted control program into assembly- ICS is a general term that encompasses several types of con-
level instructions with an accuracy of 98.15% and 98.14% trol systems and associated instrumentation for operating and

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
8388 IEEE INTERNET OF THINGS JOURNAL, VOL. 11, NO. 5, 1 MARCH 2024

integrated development environment (IDE), a compiler, and an

assembler. The compiler translates high-level source code into
assembly code, and the assembler converts assembly code into
binary machine code. Subsequently, the PLC will execute the
compiled machine code to automate the control of the physical
process.
High-Level Programming Language: IEC 61131-3 [27]
defined five types of graphical or textual programming lan-
guages for PLCs, including ladder diagram (LD), structured
text (ST), instruction list (IL), function block diagram (FBD),
and sequential function chart (SFC). The vendor-specific pro-
gramming IDEs typically support one or more of the IEC
61131-3-compliant programming languages. Fig. 3 shows an
example of programming a motor self-locking control program
in three commonly used PLC programming languages.
Assembly Code: The IEC 61131-3-compliant compiler com-
piles the source code from a high-level programming language
to diverse assembly codes according to different processor
Fig. 1. ICS architecture. architectures. For example, the Schneider Control Export
programming software compiles the ST language into arm
assembly instructions.
automating industrial processes, including devices, systems,
Binary Machine Code: The assembler then translates
networks, and controls [25], [26]. There are several types of
the compiled assembly instructions into proprietary binary
ICS, where the most common are supervisory control and data
machine code, the file format of which is not well documented.
acquisition (SCADA) systems, and distributed control systems
For example, Siemens S7 PLCs apply custom proprietary
(DCSs). As shown in Fig. 1, ICS typically contains three lay-
MC7 machine code. Therefore, interpreting the PLC binary
ers: 1) the supervisory layer; 2) control layer; and 3) process
machine code requires proprietary PLC runtime.
layer.
PLC Runtime: PLC runtime is a process executed by the
1) Supervisory Level: The supervisory level is responsi-
PLC’s operating system, which is responsible for loading and
ble for monitoring and controlling physical processes,
executing the binary machine codes that allow your controller
which involves the engineering workstation (EWS),
to communicate with other components in your automation
human–machine interface (HMI), and historian. The
environment. The PLC runtime program is infinitely executed
EWS runs engineering and maintenance applications,
in a scan cycle, in which PLC collects the input, executes the
enabling supervisors to configure and diagnose con-
PLC program, and then updates the output.
trol devices. The HMI serves to execute the interaction
between the human operator and the controller hardware,
monitoring status information and configuring control C. Motivating Example
parameters. The historian is a centralized database for
To better understand the proposed framework, we launch a
recording all process data within the ICS environment.
control logic attack and introduce how CLADF conducts detec-
2) Control Level: This layer contains the controllers in ICS,
tion and forensics on such an attack. Fig. 4 shows an example
such as PLCs. PLC is a rugged computer designed for
of normal operator replacement attack. Fig. 4(a) lists the nor-
industrial automation. PLC periodically monitors the sta-
mal control logic program snippet of the car capacity in a
tus of the input devices and calculates control commands
parking lot. When there are less than 100 cars, the indicator
based on custom programs to control the status of the
light will be green. When the number of cars reaches 100,
output devices.
the red light will be on, indicating that the parking lot is full.
3) Process Level: The process level consists of field instru-
Fig. 4(b) shows the malicious control program, where the red
mentation with several sensors and actuators. The sen-
light turns on when the number of cars in the parking lot
sors measure the physical properties (e.g., temperature,
reaches 10.
pressure, and flow) of industrial instrumentation and
To conduct detection and forensics on this control logic
send them to controllers as controlled variables. The
attack, CLADF first periodically extracts the control applica-
actuators (e.g., motors, control valves, and switch) are
tions in the PLC and verifies their integrity. When the mali-
used to manipulate the controlled process directly on
cious control application in Fig. 4(b) is injected into the PLC,
commands from the controller.
CLADF will detect the inconsistent control application by cal-
culating and comparing its hash with the original correct hash
B. PLC Program copy. Once the PLC is detected to be compromised, we down-
The process of compiling and downloading the PLC con- load the initial copy of the control application into the PLC to
trol application is illustrated in Fig. 2. Engineers develop PLC recover the normal process. Subsequently, we reverse-engineer
control programs in EWS, which is usually equipped with an the original and the extracted PLC control application into

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
GENG et al.: CONTROL LOGIC ATTACK DETECTION AND FORENSICS 8389

Fig. 2. PLC control application compilation and download process.

TABLE I
E XAMPLE OF L OCATING THE M ODIFIED S UBROUTINE AND I NSTRUCTION

Fig. 3. Example of PLC programming languages.

assembly instructions, respectively. Afterwards, we compare

the assembly instructions between the original control appli-
cation and the malicious control application to locate the modi-
fied subroutines and control instructions. Table I illustrates the
log of locating the modified subroutines and control instruc-
tions. As shown in Table I, two instructions in LogicFunc_1()
are modified in the normal operator replacement attack of
Fig. 4(b). For example, the parameter value of the instruction
with the address offset of 0x00000150 in the LogicFunc_1()
subroutine is modified from 0x640000 (100) to 0xA0000 (10).
Finally, based on the modified control instructions, we can Fig. 4. Example of normal operator replacement attack. (a) Normal control
program. (b) Modified control program.
disassemble the assembly instructions into source code and
analyze the attacker’s attack behavior and intention. And we
further evaluate the impact on the parking lot and discover that present paper. Since launching an MITM attack between a
this attack modifies the car capacity in a parking lot, which PLC and their EWS will increase the communication delay
leads to incorrect capacity indications and economic losses. and the attacker needs to simulate the normal communica-
tion behavior of the compromised PLC, which requires a lot
III. ATTACK OVERVIEW of preattack efforts. To mitigate the MITM attack against our
In this section, we first formulate our threat model and then detector, we can also use existing successful solutions [28],
summarize three types of control logic attacks against PLCs. [29], [31]. Moreover, we assume that our detector is secure
Threat Model: We assume a similar threat model to the and trustworthy, i.e., compromising the detector is out of our
existing work for ICS attacks [28], [29], [30]. We assume that scope. Furthermore, we also assume that CLADF can read or
the adversary can access PLCs remotely through the network, write PLC binaries to extract and recover its normal control
which enables the use of available tools to send control logic program. This is a realistic assumption as an adversary
logic attack signals to PLCs. In addition, we do not con- can achieve this by simulating PLC common communication
sider that the attackers continuously launch attacks between functionalities (e.g., upload/download). The control program
PLCs and EWS, i.e., the attackers only launch instantaneous typically remains constant once configured and applied in
control logic attacks, such as inserting, deleting, or modify- PLC. Any changes to the compiled binaries will sabotage the
ing the control logic program directly. And, we assume that integrity of the PLC control program. Therefore, we propose
the man-in-the-middle (MITM) attack is not considered in the an approach for conducting PLC control logic attack detection

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
8390 IEEE INTERNET OF THINGS JOURNAL, VOL. 11, NO. 5, 1 MARCH 2024

TABLE II
C ONTROL P ROGRAM M UTATION O PERATION

Fig. 5. Overview of CLADF.

and forensics by verifying the integrity of the PLC control 2) Malicious Instruction Insertion Attack: The attacker can
application and identifying the assembly-level attack location insert carefully constructed malicious instructions in a
in the compiled control application. PLC. As described in Table II, the attacker can insert
Attack Vector Generation: The existing control logic attacks malicious logical connector, statement, and subroutine.
against PLCs focus on modifying their control program to For example, the attacker can insert a new subroutine
execute malicious commands [7], [8], [9], [10], [11], [12]. into PLC and insert a jump instruction into the main
These control logic attacks are implemented by exploiting pro- function. When the PLC executes the control program,
tocol vulnerabilities. In this article, we develop three types it will first call the malicious subroutine. Representative
of control logic attacks against PLCs, including: 1) normal attacks include [9], [10], [12], [15].
operators replacement attack; 2) malicious instruction inser- 3) Normal Instruction Deletion Attack: Similar to insert-
tion attack; and 3) normal instruction deletion attack. Table II ing malicious instructions, As illustrated in Table II, the
illustrates the mutation operations of launching these control attacker can delete normal instructions in PLC to dis-
logic attacks [32]. These attacks are described as follows. rupt normal operating physical processes. For instance,
1) Normal Operator Replacement Attack: The attacker the attacker can delete logical connector, statement, and
can modify different operators in the normal con- subroutine. Representative attacks include [2], [16].
trol logic program. As shown in Table II, the attacker
can manipulate the control logic program by modi-
fying normal operators, such as replacing scalar vari- IV. CLADF D ESIGN
able, arithmetic operator, relational operator, logical In this section, we present the design of CLADF, which
connector, assignment operator, contact type, timer or is designed to: 1) extract and reverse-engineer the real-world
counter configuration, and timer and counter type. PLC binary control applications to convert them into assembly
Representative attacks include [5], [8]. instructions and 2) generate ALF based on the obtained

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
GENG et al.: CONTROL LOGIC ATTACK DETECTION AND FORENSICS 8391

assembly instructions to detect, locate, and perform post- ISA Identification: Since the majority of ICS vendors use
attack recovery of control logic attacks. We give an overview proprietary, undocumented PLC binaries, we first judge the
of CLADF’s architecture, which is illustrated in Fig. 5. The ISA used in diverse PLC binary files. The existing binary
architecture of CLADF includes three main phases: 1) control embedded systems file format analysis methods are helpful
application extraction; 2) control application reverse engineer- in this step [33], [34]. For example, we can identify the file
ing; and 3) attack detection and forensics. In the first phase, header and byte order with the existing firmware analysis tool
we extract PLC control application in the real-world ICS (①). Binwalk [35] to judge the ISA of the target binary files.
Specifically, we simulate the upload functionality of PLC to Disassembly: To recover the assembly instructions of the
extract its binary control application. In the second phase, target binary application, we break down the procedure of
we reverse-engineer the extracted binary files through three disassembly into the following four steps.
steps: 1) ISA identification; 2) disassembly; and 3) ALF gen- 1) Control Application Loading: In the control application
eration (②). In the last phase, we first detect control logic extraction phase, we extract all binary control applica-
attacks by calculating the hash values of the extracted control tion files. In this step, we load the extracted binaries
application file and verifying its integrity (③). Once an incon- into the disassembly tool (e.g., IDA Pro). For example,
sistent control logic program hash is detected, we then write we extract all machine code in the control applica-
the original control application to the PLC and recover the tion binaries with the IDA Pro interface function (e.g.,
normal operational processes(④). Finally, we perform foren- get_bytes).
sics by locating the modified subroutine and instruction in the 2) Function Prologue Location: PLC binaries include both
control program, which is helpful to assess attackers’ intention code and data sections. We need to find the exact func-
and attack’s impacts. tion entry in the PLC binaries. Therefore, we search for
In the following, we present the design of the critical function prologue sequences in the extracted machine
components in CLADF. code to locate the beginning assembly instructions.
For example, in the control application compiled by
A. Control Application Extraction Schneider PLC programming software (Control Expert),
the beginning assembly instructions can be located by
In this phase, CLADF aims at extracting the run-time binary
searching for two common ARM architecture function
control application from the real-world ICS. Therefore, we can
prologue machine code sequences. The machine code
subsequently reverse-engineer the extracted binary files and
sequences and assembly instructions of the function
defend PLC against control logic attacks. The procedure for
prologue are shown as follows.
control application extraction consists of two steps: 1) upload
simulation and 2) binary files extraction.
Upload Simulation: Since PLC programming software usu-
ally supports upload functionality, allowing reading the control
applications from PLCs, we can simulate the upload opera-
3) Unaligned Sequence Fixing: When a string is defined
tion between programming software and PLCs. To simulate
in the code, there may be machine code sequences
the upload operation, we need to obtain the protocol request
that are not 4-byte aligned. Therefore, we determine
sequences of the upload functionality. Specifically, we per-
whether each function prologue offset address is aligned.
form the upload operation and capture the network packets
If they are not aligned, the function prologue machine
between programming software and PLCs. Subsequently, we
code sequences need to be fixed. To align the offset
replay the request sequences in the network packets to simulate
address, we calculate whether the function prologue off-
the upload operation.
set address can be divided by 4. If it is divisible, we
Binary Files Extraction: The programming software con-
consider the function prologue address to be aligned. If
verts the source program (e.g., ladder logic) into binary
it is not divisible, we prefix the function prologue with
machine code during the compilation process. To extract
several 00 characters as padding to make it divisible
the run-time binary files in PLC, we extract the response
by 4.
data from the PLC when executing the upload operation as
4) Function Reconstruction: When compiling a project file,
the binary control application, containing the PLC control
the programming software usually generates a com-
program, variable data, configuration data, etc.
piled program file in text format, which records most
of the compiled assembly instructions and comments on
B. Control Application Reverse Engineering the function names. Therefore, we can use these com-
In the second phase, we propose a generic automated ments to recover the symbol table of the function. For
method for reverse-engineering PLC binaries. The goal is to the unrecoverable function names, we directly use their
disassemble the binary bytecode into assembly instructions addresses to represent the function names.
and generate ALF to locate the modified instructions in con- ALF Generation: In this step, we generate ALF from
trol logic programs. We break down this phase into three assembly instructions to facilitate the forensics of control
steps: 1) identifying the ISA of proprietary PLC binaries; logic attacks. Specifically, we obtain the function name
2) disassembling the binary file into assembly instructions; FuncName, the function start loading address FuncLoadAddr,
and 3) generating ALF with assembly instructions. and the Function size FuncSize as a tuple (FuncName,

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
8392 IEEE INTERNET OF THINGS JOURNAL, VOL. 11, NO. 5, 1 MARCH 2024

FuncLoadAddr, FuncSize) for each function in the control larger or smaller than the initial functions, which indicates
application. Subsequently, we store each disassembled instruc- that the attacker has inserted malicious control programs or
tion and its loaded address in a log file. An example of the ALF deleted normal control programs. Once detected inconsistent
is illustrated as follows. DebugLabel() represents the main instructions, we can subsequently locate the compromised
function of control program, 0x00006758 indicates the start control logic program subroutine according to the modified
loading address of DebugLabel(). 0x60 denotes the size of instructions. Finally, the modified operators or control pro-
DebugLabel(). gram snippets are recorded into a log file in human-readable
form as forensics evidence.
In a given industrial scenario, there are usually multiple
control processes (e.g., a parking control system contains an
entrance control process and an exit control process), where
each control process contains multiple control parameters (e.g.,
the parking capacity in the entrance control process). After
detecting a control logic attack and locating the compromised
physical process and control parameters, CLADF generates
forensics evidence. For instance, the normal operator replace-
ment attack in Fig. 4(b) compromises the entrance control
C. Attack Detection and Forensics process in the parking control system and manipulates its
In the last phase, we propose a method for conducting con- parking capacity parameters. Based on the generated forensics
trol logic attack detection and forensics, which consists of two evidence, the operator can further analyze the intention of the
steps: 1) detection and 2) forensics. The goal of the detection attacker and assess the attack impact on the physical processes
step is to periodically verify the integrity of the control logic associated with the modified control logic program. For exam-
program. This step ensures that any modifications or tampering ple, The normal operator substitution attack in Fig. 4(b) is
in the program can be detected promptly and accurately. By intended to interfere with the normal operating control logic
regularly checking the integrity, we can provide early indi- of the parking capacity indicator, causing economic loss to the
cations of potential attacks and take necessary measures to parking lot.
mitigate their impact. The second step is aimed at locating
the tampered control instructions. By identifying the specific
modified control instructions, we gain insights into the pur- V. I MPLEMENTATION
pose of the attack. This information is crucial for conducting To evaluate CLADF experimentally, we have implemented a
a detailed analysis of the attacker’s intention and accurately prototype of CLADF in two Schneider PLCs. The implemen-
assessing the potential impacts on both the field instruments tation details of its most relevant components are described as
and physical processes. follows.
Detection: After the engineer executes the configuration and Control Application Extraction: To extract the control appli-
download operation, we immediately extract the PLC’s control cation of Schneider PLCs, we developed an unified messaging
application file and calculate its hash as the original com- application services (UMASs) proprietary protocol communi-
parison hash copy. Specifically, during the detecting phase, cation client with 435 Lines of Code (LoC) in Python. The
we periodically verify the integrity of the control application. UMAS client is able to automatically upload/download control
We first perform the uploaded operation to extract the PLC applications while the PLC is running.
control application file. Subsequently, we calculate the hash Control Application Reverse Engineering: After extracting
of the extract control application file. Finally, we compare the control application, we automatically started IDA Pro
the calculated hash with the original hash copy. If the hash and loaded the target control application via system com-
is inconsistent, which indicates that the control application mands. Subsequently, we developed an IDA Pro plugin to
is compromised. To recover the normal physical process, we reverse analyze the control application with 329 LoC in
replace the abnormal control application with the original nor- Python. Specifically, this plugin first aligns the control appli-
mal control application by performing the download operation cation. Then, it applies the IDAPython API function provided
with our developed protocol client. by IDA Pro for subsequent reverse engineering. Finally, it
Forensics: Once the control logic attack is detected, we fur- writes the recovered function names, addresses, and assembly
ther locate the modified subroutines and instructions in the instructions to the log file.
control logic program to perform attack forensics. Specifically, Attack Detection and Forensics: We wrote a total of 892
we first calculate the number of each function assembly LoC in Python for verifying the integrity of the control
instruction for various subroutines to determine the type of application, recovering the original control application after
control logic attack. If the numbers of the assembly instruc- the PLC is compromised, and locating the modified control
tion for diverse subroutines are unchanged, we consider that logic program. Specifically, we detect the control logic attack
the attacker may manipulate the operator in the control pro- by comparing its SHA-256 hash with the original hash copy.
gram. Therefore, we compare each instruction sequentially Once detected the change in the control logic program, the ini-
to locate the tampered instruction. Furthermore, if the num- tial backup of the control application will be downloaded to
bers of the disassembled functions for various subroutines are the PLC to recover normal operation with the UMAS client.

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
GENG et al.: CONTROL LOGIC ATTACK DETECTION AND FORENSICS 8393

TABLE III
D EVELOPED 150 C ONTROL L OGIC ATTACKS

To verify the detection and forensics ability of CLADF

against PLC control logic attacks, we developed 3 types of
150 control logic attacks against the five tested industrial con-
trol application scenarios with the proposed attack vectors in
Section III, which is illustrated in Table III. In Table III, S1–5
represent five different application scenarios. For each appli-
Fig. 6. Environment setup.
cation scenario, we generated 3 types of 30 different attack
mutated test cases based on the control program mutation
Moreover, we apply the Difflib library to compare the dis- operations in Table II, which include inserting, deleting, or
assembled log file, locating the modified subroutines, and replacing PLC control logic operations.
instructions in the control program.
B. Research Questions
VI. E VALUATION Our evaluation addresses the following key
A. Experiment Settings research questions (RQs).
We evaluated the performance and effectiveness of CLADF 1) RQ1: Is our method effective for extracting different
in two PLCs from five typical industrial control application control applications?
scenarios. These five scenarios are common application in the 2) RQ2: Can CLADF accurately disassemble the PLC
real-world, and we have designed these five scenarios with ref- binary byte code?
erence to existing standard implementations. Fig. 6 illustrates 3) RQ3: Is our approach effective in conducting control
the environment setup, including the Schneider M340 and logic attack detection and forensics?
M580 PLCs, an EWS installed with Schneider Control Export 4) RQ4: What about the time and memory overhead of
programming software, an HMI deployed with the simulated CLADF?
control application scenarios, and a detector equipped with RQ1 considers the effectiveness of CLADF for extracting
CLADF. Fig. 7 describes the diagram of the tested five con- diverse control applications from PLCs. RQ2 measures the
trol application scenarios, which consist of a parking control accuracy of reverse-engineering PLC’s control application.
system programmed in ST, a forward/reverse motor control RQ3 is concerned with the effectiveness of detecting and per-
system programmed in IL, a traffic light control system, a forming forensics of control logic attacks. RQ4 evaluates the
four-section conveyor control system, and a multiliquid mixing performance of our defense solution.
control system programmed in LD.
Parking Control System (S1): The parking control system is C. Experiments
designed for controlling cars entering and leaving the parking We design experiments to answer these RQs.
lot, which is illustrated in Fig. 7(a). RQ1: In the first RQ, we evaluate the generality and effec-
Forward/Reverse Motor Control System (S2): The for- tiveness of extracting binary control applications, i.e., whether
ward/reverse motor control system is used to control the our approach enables the extraction of control application
forward or reverse rotation of the motor to drive the conveyor files programmed by diverse types of programming languages,
belt, as shown in Fig. 7(b). which cover different control scenarios in different PLCs.
Traffic Light Control System (S3): The traffic light control To investigate this, we tested the effectiveness of extracting
system is designed to safely manage vehicle, bicycle, and binary control applications on Schneider’s M340 and M580
pedestrian traffic by controlling the sequence of the lights, PLCs, respectively. Although we only conducted experiments
which is depicted in Fig. 7(c). in Schneider PLCs, our control application extraction solution
Four-Section Conveyor Control System (S4): The four- can easily extend to PLCs from other manufacturers. Since
section conveyor control system is an efficient mechanical PLC programming software usually supports upload/download
handling apparatus for automatically transporting materials functions, we can simulate PLC upload/download operations
from one point to another, as described in Fig. 7(d). to read/write PLC binary control applications.
Multiliquid Mixing Control System (S5): The multiliquid Table IV shows the result of extracting control applica-
mixing control system is used for mixing three differ- tions in different application scenarios. For each PLC, we
ent compositions of liquids according to the desired recipe tested the effectiveness of the extracted control programs with
composition, as reflected in Fig. 7(e). 150 generated malicious control programs ranging across five

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
8394 IEEE INTERNET OF THINGS JOURNAL, VOL. 11, NO. 5, 1 MARCH 2024

Fig. 7. Diagram of five typical industrial control application scenarios. (a) Parking control system. (b) Forward/reverse motor control system. (c) Traffic light
control system. (d) Four-section conveyor control system. (e) Multiliquid mixing system.

TABLE IV
R ESULT OF E XTRACTING C ONTROL A PPLICATIONS

Fig. 8. Examples of inconsistent assembly instructions.

the accuracy of reverse-engineering binary control applica-

application scenarios and three programming languages. To tions by comparing the ground truth (intermediate files) of
verify the accuracy of the extracted control application, we the assembly instructions generated in the compilation phase
write the extracted binary file (e.g., .apx file in Schneider con- with those ALFs generated in the disassembly phase of
trol application files) to the PLC. The evaluation results show CLADF. Due to a large amount of redundant information
that CLADF is able to extract control application files for dif- and mismatched instruction formats existing in the compila-
ferent programming languages and application scenarios with tion and disassembly phases, it is necessary to standardize
100% accuracy. the instructions in both phases. Therefore, we first remove
RQ2: Our second RQ aims to measure the accuracy of the file comments (e.g., the assembly instruction comments
reverse-engineering PLC binary control applications. in IDA Pro and the assembly segment description in the
To investigate this, we tested the accuracy of CLADF intermediate file). Afterward, we standardize three types of
for reverse engineering the binary control applications on inconsistent assembly instructions, which are described as fol-
Schneider M340 and M580 PLCs. For each PLC, we tested lows. Fig. 8 illustrates examples of these inconsistent assembly
150 mutated control applications, as illustrated in Table III. instructions.
Since the programming software generates intermediate files 1) Type I: Inconsistent instruction format. We set the rules
of the assembly instructions when compiling (e.g., .asm of synonymous instruction format, such as MOV and
files in Schneider control application files), we calculate LDR in Fig. 8 are functionally equivalent instructions.

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
GENG et al.: CONTROL LOGIC ATTACK DETECTION AND FORENSICS 8395

TABLE V
R ESULT OF D ISASSEMBLING PLC B INARY C ONTROL A PPLICATIONS

2) Type II: Inconsistent register aliases. We unify the name standardizing instructions, For M340 PLC, we tested a total of
of diverse registers. For example, IP is an alias for R12 46 842 instructions, of which 29 519 matched, with an accu-
of the internal process register. racy of 64.02%. For M580 PLC, we tested a total of 46 707
3) Type III: Inconsistent immediate value format. We stan- instructions, of which 28 844 matched, with an accuracy of
dardize the format of the immediate value. For instance, 61.76%. After standardizing instructions, For M340 PLC, we
we normalize the immediate value −0x130 to the 32-bit tested a total of 46 842 instructions, of which 45 974 matched,
0xFFFFFED0. with an accuracy of 98.15%. For M580 PLC, we tested a total
Table V illustrates the evaluation result of disassembling of 46 707 instructions, of which 45 839 matched, with an accu-
control applications in five diverse application scenarios pro- racy of 98.14%. Subsequently, we analyzed the unmatched
grammed with three mainstream PLC programming languages. instructions and discovered that these instructions involved
In Table V, Num_BS and Num_AS serve as indicators of the unresolved symbol tables in the jump instructions. For exam-
accuracy of disassembling control applications both before ple, a jump instruction BNE, LD_$labEndIf 1 is disassembled
and after undergoing standardization. the Accuracy_BS column as BNE, loc_46A4
signifies the accuracy of disassembling control applications
before standardization. This metric is determined using (1). Num_T − Num_BS
Accuracy_BS = (1)
In (1), Num_T corresponds to the total count of instructions Num_T
in the ten control programs tested for each type of attack. Num_T − Num_AS
Accuracy_AS = . (2)
Num_BS denotes the total number of unmatched instructions Num_T
across the ten control programs assessed for each attack
type in every application scenario, before the instructions RQ3: In this RQ, we evaluate the effectiveness of detecting
undergo standardization. The Accuracy_AS column signifies control logic attacks and performing post-attack forensics.
the accuracy of disassembling control applications after To investigate this, we first generated 150 diverse con-
standardization. This accuracy is calculated using (2). In (2), trol logic attacks (illustrated in Table III) for M340 and
Num_T represents the total number of the instructions within M580 PLCs, respectively. We automatically download the
the set of ten control programs tested for each attack type. 150 malicious control applications to the PLC at different
Num_AS indicates the total count of unmatched instructions moments and CLADF periodically detects if the PLC is com-
across the ten control programs evaluated for each attack promised (e.g., per 5 s). Since these malicious control logic
type in each application scenario, after the instructions have attacks can compromise the integrity of the control logic pro-
been standardized. The experimental results show that the gram. When CLADF detects a hash inconsistency of the control
accuracy of disassembling PLC binary control applications is application, we consider that the PLC is compromised and
significantly improved after standardizing instructions. Before further locate the modified control instructions.

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
8396 IEEE INTERNET OF THINGS JOURNAL, VOL. 11, NO. 5, 1 MARCH 2024

TABLE VI
R ESULT OF D ETECTING AND L OCATING C ONTROL L OGIC ATTACKS

TABLE VII
Table VI shows the result of detecting and locating con- T IME OVERHEAD OF CLADF
trol logic attacks. In Table VI, Accuracy_D represents the
accuracy of detecting control logic attacks, Accuracy_LS indi-
cates the accuracy of locating the modified subroutines, and
Accuracy_LI means the accuracy of locating the modified
instructions. The evaluation result shows that CLADF can
detect all these 150 attacks and locate their modified subrou-
tines with an accuracy of 100%. As for further locating the
modified instruction in the subroutine, for the normal opera-
tor replacement attacks (Type I), CLADF can easily locate the
modified operators. For malicious instruction insertion attacks
(Type II) and normal instruction deletion attacks (Type III),
locating the malicious control logic programs programmed in
ST(S1) and IL(S2) languages works well. However, the accu-
racy of locating the modified instruction written in LD (S3–S5)
language is not high. Since a large number of jump instructions
in LD are introduced when inserting or deleting the control
logic program snippets.
RQ4: Our last RQ is concerned with the performance of
our detection and forensics solution. We evaluate the time and
memory overhead of CLADF.
Time Overhead: To evaluate the time overhead of the
CLADF on detecting control logic attacks, we tested the aver- on PLC operation. In fact, extracting control logic program
age time overhead for different scenarios and attack types in only reads PLC memory data, which has little effect on PLC
M340 and M580 PLCs, respectively. The result of the time operation. However, the recovery phase will affect the PLC
overhead of CLADF is illustrated in Table VII. For the M340 operation. In this phase, we should first set the PLC in the
and M580 PLCs, the total time overhead is about 3.137 and Stop state, then download the original control program into
3.340 s, respectively. The time overhead of the CLADF is PLC, and finally set the PLC in the Run state.
divided into four phases: 1) extraction time (T1); 2) detection 1) Extraction Time: The extraction time indicates the
time (T2); 3) recovery time (T3); and 4) location time (T4). time taken to extract the control application files from
Among them, only T1 and T3 phases require to communi- the PLC, which depends on the size of the control
cate with PLC. We tested the effect of extracting control logic application files and the communication speed of the

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
GENG et al.: CONTROL LOGIC ATTACK DETECTION AND FORENSICS 8397

PLCs. The time overhead for extracting the control Modify PLC Binary Control Program: This type of attack
application file is less than 0.632 and 0.848 s for M340 manipulates the behavior of the PLC by modifying the
and M580 PLCs, respectively. binary control logic program. To launch stealthy attacks,
2) Detection Time: The detection time is used to calculate some researchers reverse-engineered PLC binary control pro-
and compare the hash values between the extracted con- grams and then generated attack payloads [13], [14], [36].
trol application and the original hash copy, which takes McLaughlin [13] constructed a dynamic payload to disrupt the
less than 0.01 s for each PLC. physical processes. The malware was generated by decoding
3) Recovery Time: The recovery time represents the proprietary binary formats of control processes with a format
time to download the correct control application into library and identifying attack targets with security viola-
PLC after the attack is detected, which assumes less tions. Another automated attack generation tool, SABOT [14],
than 0.572 and 0.757 s for M340 and M580 PLCs, uploaded the binary control program from the compromised
respectively. PLC and decompiled it into a logic model. SABOT then
4) Location Time: The control logic attack location phase applied model checking to find variable mappings, based on
spends most of the time throughout the entire process, which generic malicious payloads were generated for the PLC
including the time overhead of opening and closing dis- physical processes. Keliris and Maniatakos [36] implemented
assembly tools, disassembling binaries, and comparing a more general decompiler, ICSREF, enabling automatically
assembly instructions. The average time overhead on this reverse-engineering CodeSys-based binary control programs
phase is less than 2.050 and 1.883 s for M340 and M580 and generating malicious payloads.
PLCs, respectively. In addition, there also exist efforts on directly modify the
Memory Overhead: The memory overhead of CLADF is binary control program [8], [9], [10], [15], [16]. Klick et al. [9]
regarding the detection and location logs. Since we only explored PLC runtime and implemented a new PLC back ori-
recorded the inconsistent hash values, and the information of fice for Siemens PLCs, PLCinject. PLCinject implemented
the modified subroutines and control instructions, the memory an SNMP scanner and an SOCKS proxy network services
overheads can be negligible. We tested the memory over- using uploaded MC7 code. PLC-Blaster [10] implemented
head for 1 h of normal CLADF operation (detected per 5 s), the proprietary Siemens protocol and inserted an additional
consuming less than 1 MB of memory space. malicious organization block to target PLC by recording and
modifying the data blocks transferred during the download
VII. R ELATED W ORK operation. Formby et al. [16] developed a cross-vendor PLC
ransomware, LogicLocker. LogicLocker bypassed PLC’s weak
Several researchers have studied control logic modification
security mechanism and then replaced the normal control pro-
attacks against PLCs and their detection methods in the past.
gram with a logic bomb. Furthermore, if the payment is not
received by a certain deadline, the normal program will be
A. PLC Control Logic Attack deleted and the logic bomb in the PLC will start damaging
The existing control logic tampering attack manipulates the device. CLIK [15] automatically modified the control logic
the control logic program in PLC by inserting, deleting, and program running in the remote target PLC in four steps, includ-
replacing its source program or binary control logic program. ing compromising the security measures, stealing the control
Therefore, we categorize control logic modification attacks logic program, decompiling the compiled binaries, and build-
into two types: 1) modify PLC source program and 2) modify ing and injecting the infected binaries into the PLC. Yoo and
PLC binary control program. Ahmed [8] explored the packet manipulation of control logic
Modify the PLC Source Program: This type of attack programs to develop control logic attacks on PLC. These
assumes that the attacker is able to control the compro- attacks keep overwriting the noise data one byte per packet
mised engineering station, modifying the original source pro- with the actual code bytes in successive memory locations.
gram based on IEC 61131-3-compatible languages directly to After transferring all the packets to the target PLC, the whole
generate attacks with vendor-specific programming software. control logic code is modified. The majority of the above con-
Several existing efforts [6], [7] implemented malicious attacks trol logic attacks are inserting/removing control logic program
based on ladder logic language. Serhane et al. [6] focused on snippets or modifying the operators in the PLC control pro-
the weak points embedded within the ladder logic code that gram. However, CLADF can verify the integrity of the PLC
could be exploited by malicious attacks. 12 types of vulnera- control application and compare the assembly-level control
bilities in ladder logic code derived from bad code practices instructions to detect and locate diverse PLC control logic
or human error were discussed. For example, when two timers attacks.
in the control logic program are racing with each other, result-
ing in inconsistent results and even damage to the device.
Govil et al. [7] discussed ladder logic bombs (LLBs) written B. PLC Control Logic Attack Detection
in ladder logic, which attempted to hide from manual logic To mitigate the impact of control logic attacks against
code inspection. These LLBs were designed to disrupt the PLCs, researchers have proposed several defense solutions.
normal operation of PLCs by continuously changing behavior Some researchers focus on performing model checking [17],
or waiting for a specific trigger signal to activate malicious [18], [19], [20] on the control program before it downloads
behavior. to PLCs, aiming at finding some security vulnerabilities in

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
8398 IEEE INTERNET OF THINGS JOURNAL, VOL. 11, NO. 5, 1 MARCH 2024

advance. McLaughlin et al. [17] presented a trusted safety subroutines and instructions. In the end, we evaluated its
verifier (TSV) for verifying the PLC control program. TSV effectiveness and performance on five industrial applica-
translated the binary control program into ILIL language and tion scenarios. The results illustrate that CLADF can accu-
performed symbolic execution and model checking, trans- rately detect different control logic attacks and locate their
forming an ILIL program into a temporal execution graph. modified subroutines and instructions for two Schneider
Kottler et al. [18] modeled the PLC ladder logic pro- PLCs.
gram with NuSMV and verified it using the computational We consider some threats to the validity and limitation
tree logic specification. Chang et al. [19] proposed a state of our work. First, our defense mechanism ignore defend
verification-based method for detecting malicious behavior against MITM attacks. However, there are simple mitigation
of PLC Programs. Xie et al. [20] modeled the PLC system mechanisms that can be implemented. First, the detection of
with satisfiability modulo theory constraints and generated the communication delays can be utilized as an indicator of a
detection rules based on invariant extraction and rule design potential MITM attack. By monitoring the upload response
pattern. Qasim et al. [21], [23], Yoo et al. [22], and Senthivel data and analyzing the delays, it is possible to identify abnor-
et al. [24] focused on verifying binary control logic in PLC. mal delays that may indicate an ongoing attack. Second, we
Qasim et al. [21], [23] developed forensic tools, transforming highlight the importance of implementing a dynamic checking
PLC binary control logic into a high-level source code. These mechanism during the data upload process. This mechanism
tools recovered control logic from network traffic to detect can involve the verification of the integrity and authenticity
control logic attacks for Modicon and Allen–Bradley PLCs. of the uploaded data, ensuring that it has not been manip-
Cutter [24] reverse-engineered programmable controller com- ulated during transmission. Second, we only evaluate the
munication commands (PCCC) protocol and extracted control performance of CLADF in two different Schneider PLCs,
logic program from PCCC network traces. Subsequently, and we will consider validating CLADF in multiple types of
Cutter compared the extracted control logic program with the PLCS from different manufacturers. Third, CLADF only con-
original code to detect control logic attacks. Shade [22] main- siders that PLC does not enable the password authentication
tained a local copy of the PLC control logic program to detect mechanism, and the attackers can indeed apply our meth-
control logic attacks by performing deep packet inspection ods to perform control logic attacks. Therefore, to deal with
on network packets written to PLC. However, these methods this problem, other additional security measures need to be
require ICS network traffic on uploading/downloading control introduced in the future work, such as setting up network seg-
programs, making it difficult to perform runtime detection. In mentation, configuring the access control list, and setting up
contrast, our proposed runtime detection method against PLC a VPN between the Modicon PLC modules and the EWS.
control logic attack does not rely on network traffic. Finally, while CLADF adeptly handles tasks, such as auto-
In addition, there exists literature on detecting attacks mated extraction of PLC control applications, disassembly of
on PLC control logic programs via anomaly detec- proprietary binaries, and detection of tampered programs, we
tors [28], [29], [37]. Salehi and Bayat-Sarmadi [28] detected acknowledge that further steps are required. Specifically, in the
the control logic attack with a physics-based anomaly detec- context of locating tampered subroutines, human assessment
tor, preserving the control behavior integrity of ICS. Ghaeini is still essential to evaluate the impact of attacks on the physi-
et al. [37] attested to the integrity of the control logic pro- cal processes. To address this, our ongoing research endeavors
gram based on the measured sensor values, which enabled focus on introducing an intelligent attack impact assessment
the detection of control logic attacks. Geng et al. [29] per- scheme that synergizes the system’s security constraints with
formed sanity checks for the PLC’s control logic program by operational considerations.
periodically checking the hash values and dynamic checksum
values.
R EFERENCES
[1] M. Zhang et al., “Towards automated safety vetting of PLC code in
VIII. C ONCLUSION AND F UTURE W ORK real-world plants,” in Proc. IEEE Symp. Security Privacy (SP 2019),
In this article, we present a practical reverse-engineering- San Francisco, CA, USA, 2019, pp. 522–538.
based detection and forensics solution that detects control [2] A. Di Pinto, Y. Dragoni, and A. Carcano, “TRITON: The first ICS
cyber attack on safety instrument systems,” in Proc. Black Hat USA,
logic attacks and performs post-attack forensics after a PLC Las Vegas, NV, USA, 2018, pp. 1–26.
is compromised. CLADF is implemented with three main [3] M.-A. Russon. “US fuel pipeline hackers ‘didn’t mean to create prob-
phases: 1) control logic extraction; 2) control application lems.” 2021. [Online]. Available: https://www.bbc.com/news/business-
57050690
reverse engineering; and 3) attack detection and foren- [4] K. Liu, M. Wang, R. Ma, Z. Zhang, and Q. Wei, “Detection and
sics. In addition, as examples, we implemented a prototype localization of cyber attacks on water treatment systems: An entropy-
system with Schneider M340 and M580 PLCs. Specifically, based approach,” Front. Inf. Technol. Electron. Eng., vol. 23, no. 4,
pp. 587–603, 2022.
we first automatically extract the binary control application [5] R. Langner, “Stuxnet: Dissecting a cyberwarfare weapon,” IEEE Security
from the PLC. Subsequently, we disassemble the extracted Privacy, vol. 9, no. 3, pp. 49–51, May/Jun. 2011.
binary file into assembly instructions. Finally, we verify the [6] A. Serhane, M. Raad, R. Raad, and W. Susilo, “PLC code-level vulner-
integrity of extracted control application to detect attacks. abilities,” in Proc. Int. Conf. Comput. Appl. (ICCA), 2018, pp. 348–352.
[7] N. Govil, A. Agrawal, and N. O. Tippenhauer, “On ladder logic bombs
If the PLC is compromised, we recover the original con- in industrial control systems,” in Proc. Comput. Security, Oslo, Norway,
trol application to PLC and further locate the modified 2017, pp. 110–126.

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
GENG et al.: CONTROL LOGIC ATTACK DETECTION AND FORENSICS 8399

[8] H. Yoo and I. Ahmed, “Control logic injection attacks on industrial [32] R. A. DeMillo, R. J. Lipton, and F. G. Sayward, “Hints on test data
control systems,” in Proc. IFIP Int. Conf. ICT Syst. Security Privacy selection: Help for the practicing programmer,” Computer, vol. C-11,
Protect., Lisbon, Portugal, 2019, pp. 33–48. pp. 34–41, Apr. 1978.
[9] J. Klick, S. Lau, D. Marzin, J.-O. Malchow, and V. Roth, “Internet- [33] W. Cui, M. Peinado, K. Chen, H. J. Wang, and L. Irun-Briz, “Tupni:
facing PLCs–A new back orifice,” in Proc. Black Hat USA, Las Vegas, Automatic reverse engineering of input formats,” in Proc. 15th ACM
NV, USA, 2015, pp. 1–9. Conf. Comput. Commun. Security, 2008, pp. 391–402.
[10] R. Spenneberg, M. Brüggemann, and H. Schwartke, “PLC-blaster: [34] J. Zaddach and A. Costin, “Embedded devices security and firmware
A worm living solely in the PLC,” in Proc. Black Hat Asia, reverse engineering,” in Proc. Black Hat USA, Las Vegas, NV, USA,
Marinabaysands, Singapore, 2016, pp. 1–16. 2013, pp. 1–104.
[11] S. Senthivel, S. Dhungana, H. Yoo, I. Ahmed, and V. Roussev, “Denial [35] P. Eacmen. “Binwalk.” 2022. [Online]. Available: https://github.com/
of engineering operations attacks in industrial control systems,” in Proc. ReFirmLabs/binwalk
8th ACM Conf. Data Appl. Security Privacy, New York, NY, USA, 2018, [36] A. Keliris and M. Maniatakos, “ICSREF: A framework for automated
pp. 319–329. reverse engineering of industrial control systems binaries,” in Proc. Netw.
[12] R. Langner. “A time bomb with fourteen bytes.” [EB/OL]. Distrib. System Security Symp. (NDSS2019), San Diego, CA, USA, 2019,
2011. [Online]. Available: https://www.langner.com/2011/07/a-time- pp. 1–1.
bomb-with-fourteen-bytes/ [37] H. R. Ghaeini et al., “PAtt: Physics-based attestation of control systems,”
[13] S. McLaughlin, “On dynamic malware payloads aimed at programmable in Proc. Int. Symp. Res. Attacks, Intrusions Defenses ({RAID} 2019),
logic controllers,” in Proc. SENIX Workshop Hot Topics Security Beijing, China, 2019, pp. 165–180.
(HotSec 11), 2011, pp. 1–6.
[14] S. McLaughlin and P. McDaniel, “SABOT: Specification-based payload
generation for programmable logic controllers,” in Proc. ACM Conf.
Comput. Commun. security, 2012, pp. 439–449. Yangyang Geng received the B.Sc. degree in
[15] S. Kalle, N. Ameen, H. Yoo, and I. Ahmed, “CLIK on PLCs! attack- information security from Xidian University, Xi’an,
ing control logic with decompilation and virtual PLC,” in Proc. Binary China, in 2016, and the M.S. degree in computer
Anal. Res. (BAR) Workshop, Netw. Distrib. System Security Symp. (NDSS science and technology and the Ph.D. degree in
2019), San Diego, CA, USA, 2019, pp. 1–12. cyberspace security from Information Engineering
[16] D. Formby, S. Durbha, and R. Beyah, “Out of control: Ransomware University, Zhengzhou, China, in 2019 and 2022,
for industrial control systems,” in Proc. RSA Conf., San Francisco, CA, respectively.
USA, 2017, pp. 1–8. He is currently a Lecturer with Information
[17] S. E. McLaughlin, S. A. Zonouz, D. J. Pohly, and P. D. McDaniel, Engineering University. His primary research
“A trusted safety verifier for process controller code,” in Proc. Netw. interests encompass cyber–physical system security
Distrib. System Security Symp. (NDSS2014), San Diego, CA, USA, 2014, and network security.
pp. 1–15.
[18] S. Kottler, M. Khayamy, S. R. Hasan, and O. Elkeelany, “Formal verifi-
cation of ladder logic programs using NuSMV,” in Proc. SoutheastCon
2017, 2017, pp. 1–5.
[19] T. Chang, Q. Wei, W. Liu, and Y. Geng, “Detecting PLC program mali- Xin Che received the M.S. degree in electronics and
cious behaviors based on state verification,” in Proc. Int. Conf. Cloud communication engineering from Xidian University,
Comput. Security, 2018, pp. 241–255. Xi’an, China, in 2020.
He is a Security Researcher with the College
[20] Y. Xie, R. Chang, and L. Jiang, “A malware detection method using
of Control Science and Engineering, Zhejiang
satisfiability modulo theory model checking for the programmable logic
University, Hangzhou, China. His research interest
controller system,” Concurr. Comput. Pract. Exp., vol. 34, no. 16, 2020,
is industrial control system security.
Art. no. e5724.
[21] S. A. Qasim, J. Lopez, and I. Ahmed, “Automated reconstruction of
control logic for programmable logic controller forensics,” in Proc. Int.
Conf. Inf. Security, New York, NY, USA, 2019, pp. 402–422.
[22] H. Yoo, S. Kalle, J. Smith, and I. Ahmed, “Overshadow PLC to
detect remote control-logic injection attacks,” in Proc. Int. Conf. Detect.
Intrusions Malware, Vulnerability Assess., Gothenburg, Sweden, 2019,
pp. 109–132. Rongkuan Ma received the Ph.D. degree from
[23] S. A. Qasim, J. M. Smith, and I. Ahmed, “Control logic forensics frame- Information Engineering University, Zhengzhou,
work using built-in decompiler of engineering software in industrial China, in 2021.
control systems,” Forensic Sci. Int.: Digit. Investig., vol. 33, Jul. 2020, He is a System Security Researcher. His research
Art. no. 301013. interests include program analysis and embedded
[24] S. Senthivel, I. Ahmed, and V. Roussev, “SCADA network forensics of system security, iCPS security, and Web security.
the PCCC protocol,” Digit. Investig., vol. 22, pp. S57–S65, Aug. 2017.
[25] K. Stouffer, S. Lightman, V. Pillitteri, M. Abrams, and A. Hahn, “Guide
to industrial control systems (ICS) security,” Nat. Inst. Stand. Technol.,
Gaithersburg, MD, USA, document NIST SP 800-82, 2011, pp. 16–16.
[26] Wikipedia. “Industrial control system.” 2022. [Online]. Available:
https://en.wikipedia.org/wiki/Industrial_control_system
[27] M. Tiegelkamp and K.-H. John, IEC 61131-3: Programming Industrial
Automation Systems, vol. 166. Berlin Heidelberg, Germany: Springer,
2010.
[28] M. Salehi and S. Bayat-Sarmadi, “PLCDefender: Improving remote
attestation techniques for PLCs using physical model,” IEEE Internet
Things J., vol. 8, no. 9, pp. 7372–7379, May 2021. Qiang Wei received the Ph.D. degree in computer
[29] Y. Geng et al., “Defending cyber-physical systems through reverse engi- science and technology from China National Digital
neering based memory sanity check,” IEEE Internet Things J., vol. 10, Switching System Engineering and Technological
no. 10, pp. 8331–8347, May 2023. Research Center, Zhengzhou, China, in 2008.
He is currently a Professor with the State
[30] M. Ike, K. Phan, K. Sadoski, R. Valme, and W. Lee, “SCAPHY:
Key Laboratory of Mathematical Engineering and
Detecting modern ICS attacks by correlating behaviors in SCADA and
Advanced Computing. His research interests include
PHYsical,” 2022, arXiv:2211.14642.
network security, industrial Internet security, and
[31] A. Le, U. Roedig, and A. Rashid, “LASARUS: Lightweight attack sur-
vulnerability discovery.
face reduction for legacy industrial control systems,” in Proc. Int. Symp.
Eng. Secure Softw. Syst., 2017, pp. 36–52.

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.
8400 IEEE INTERNET OF THINGS JOURNAL, VOL. 11, NO. 5, 1 MARCH 2024

Mufeng Wang received the Ph.D. degree in con- Yuqi Chen received the B.Sc. degree in computer
trol science and engineering from South China science from South China University of Technology,
University of Technology, Guangzhou, China, in Guangzhou, China, in 2015, and the Ph.D. degree
2019. from Singapore University of Technology and
He was a Research Fellow of Control Science and Design, Singapore, in 2019.
Engineering with Zhejiang University, Hangzhou, He is currently an Assistant Professor with the
China, from 2019 to 2021. He is currently a Senior School of Information Science and Technology,
Engineer with China Industrial Control Systems ShanghaiTech University, Shanghai, China. Before
Cyber Emergency Response Team, Beijing, China. that, he was a Research Scientist with the
His research interests include analysis and synthe- System Analysis and Verification Group, Singapore
sis of security for industrial control systems and Management University, Singapore. His research
cyber–physical systems. interest lies in cyber–physical system security in general. Specifically, he
applied techniques, such as testing, reverse engineering, program analysis,
and formal method to secure and analyze CPSs (e.g., autonomous vehicles,
industrial control systems, and robotics systems).

Authorized licensed use limited to: Virginia Commonwealth University. Downloaded on July 23,2024 at 13:23:03 UTC from IEEE Xplore. Restrictions apply.