Enforcing Runtime Software Integrity by Finer-grained
Self-checking
Jiaxuan Wu
jasonwuee@gmail.com
Technical University of Denmark
Kongens Lyngby, Copenhagen, Denmark
ABSTRACT
Detecting Man-At-The-End (MATE) attack remains an unsolved
problem in the literature though many efforts have attempted to mit-
igate its impact via active or passive defenses. In this work, we pro-
pose a new self-checking technique to prevent several mainstream
types of MATE attacks through program instrumentation and ker-
nel level monitoring. We conducted a literature review within this
topic to identify primary approaches. We recognized that it is high
runtime overheads that causes there was no comprehensive defense
against various runtime data overwrite. While we use an asynchro-
nous kernel monitor for self-checking, the time and space overhead
caused by instrumentation can be reduced a lot. The examples in
the evaluation section showed that our approach can effectively pre-
vent the primary MATE attacks, including code injection, data-flow
data overwrite and control-flow data overwrite.
KEYWORDS
Man-At-The-End, MATE, Software Integrity Protection, Software
Hardening, Data-flow Integrity, Data-flow Analysis, Instrumenta-
tion
1 INTRODUCTION
A major and well-known way of attack in computer security is
program vulnerabilities exploitation, which is a severe problem
for several decades [15]. However, beside network attacks, there
is another type of attacks that could potentially lead to violation
of safety and security goals of software systems. If an external or
internal attacker already has full control over the host on which
programs are being executed, they can implement serious attacks
on software systems by inspecting a program’s execution or tam-
pering with the host’s hardware or software. These attacks are
known as Man-At-The-End (MATE) attackers.[2]Typical exam-
ples of MATE attacks include, cheating in games, defeating license
checks, tampering user or operational data in enterprise server,
and stealing proprietary data (musics and movies). What’s more, if
program integrity can be ensured at runtime, the remote attacks
that exploit program vulnerabilities can also be prevented at the
same time. Ensuring program integrity is therefore a prime con-
cern for researchers and practitioners. In the last decade, several
approaches have been proposed in the literature to protect run-
time program integrity. These primary approaches explore code
obfuscation[17], customization[5], self-checking or run-time pro-
cess memory invariant checking[7, 19], and trusted hardware[6, 18]
with their subcategories.
While the aforementioned techniques have been proven effective
on benchmarks, attackers have various goals and motives in reality.
Even we only consider online gaming as attack scenario, there are
1
Zheng Zhu
s222461@dtu.dk
Technical University of Denmark
Kongens Lyngby, Copenhagen, Denmark
also many kind of attackers. The external Man-In-The-Middle
(MITM) attackers could want to gain control of a client or make
a server inaccessible by sending malicious payloads. The MATE
attacker could want to gain unfair advantages in games by viewing
or tampering related game data or using AI scripts to automatically
control character movement.[22]Here, we only consider the MITM
or MATE attackers who want to violate software integrity at run-
time. The primary literature on Windows has already approached
the problem of detecting both control and non-control data attack
by enforcing data-flow integrity[7]. [7] use static analysis to com-
pute a data-flow graph and then instruments the program to ensure
that the flow of data at runtime is allowed by the data-flow graph.
However, since the approach only consider the data-flow integrity,
it cannot prevent finer grained control instruction overwritten or
critical data overwritten.
In this work, we propose a novel approach to identify and re-
spond to program memory overwriting at runtime. We realize this
relying on static program analysis, static instrumentation and a
kernel level monitor. In static program analysis, we execute reach-
ing definitions analysis, live variable analysis, and inter-procedural
analysis to generate data flow graph [1]. After the compiler gener-
ate a intermediate representation, which is called gimple [12], it will
instruments the program in order to compute the definition that
actually reaches each use at runtime. At runtime, the instruments in
the reinforced program will communicate asynchronously with our
kernel monitor and the monitor will scan the memory space of the
program to check whether anomaly memory overwrite happens. If
the answer is yes, it will raise an exception. Our solution will not
generate false positives; when we raise an exception, there is an
attack in process.
The main contributions of our work are as follows:
• We propose a new self-checking technique to prevent sev-
eral mainstream types of MATE attacks through program
instrumentation and kernel level monitoring.
• We did a systematic literature review, and identified the
primary studies relevant to prevent MATE attacks. We sum-
marize four identified types of mitigation: code obfuscation,
customization, self-checking, and trusted hardware.
• We enforced three safety properties for self-checking: 1. the
offset of the last definition should be a factor of least common
multiple (LCM) of all possible offset of definitions; 2. the
executed definition should be the original definition of the
code; 3. the value of the variable should not be changed since
last definition.
• We evaluate our approach with several attack cases in de-
tail and show that our approach can effectively prevent the
Conference’17, July 2017, Washington, DC, USA Jiaxuan Wu and Zheng Zhu

Table 1: Full List of Collected and Examined Papers. of an executable might not apply to other customized versions.
Self-checking, also referred to as tamper-proofing, integrity check-
Author/Reference Year Citations Venue ing, and anti-tampering technology, is an essential element in an
effective tamper-resistance strategy. Self-checking detects changes
Aucsmith[5] 1996 527 Springer
in the program and invokes an appropriate response if change is
Collberg[10] 1997 1534 CSTR
detected. Our approach falls into the self-checking category.
Wang[20] 2000 271 ACM
Chang[8] 2001 374 ACM
Collberg[11] 2002 1201 IEEE
2 BACKGROUND AND DEFINITION
Petroni[19] 2004 738 USENIX In this section, we first introduce necessary knowledge of program
Castro[7] 2006 476 USENIX analysis and communication between user mode and kernel mode,
Nagra[17] 2009 520 Pearson Education two techniques used in our approach. Then, we carefully define
Baumann[6] 2015 919 ACM important concepts used in our study.

2.1 Data-flow Analysis

primary MATE attacks, including code injection, data-flow
data overwrite and control-flow data overwrite.
• We propose to use an asynchronous kernel monitor for self-
checking, which can effectively reduce the time and space
overhead caused by instrumentation.
We all put almost the same energy into this work.
Data-flow Analysis is a kind of flow-sensitive intraprocedural analy-
sis. Flow-sensitive intraprocedural analysis [1] refers to an analysis
or computation that takes into account the control flow in a pro-
gram. This means that the analysis or computation is sensitive
to the order in which statements are executed and the conditions
under which they are executed.

1.1 Literature Review
Towards checking how far we are in runtime software integrity
protection, we performed a systematic literature review based on
the guidelines provided by[21] to understand the status quo.
Keywords Identification. We resort to a set of keywords to search
for relevant publications in popular repositories.
• S1: software integrity protection
• S2: data flow integrity, data-flow analysis
• S3: software hardening
Paper Exclusion. As we aimed at collecting as many relevant pa-
pers as possible, we have simply considered all the returned results.
However, not every paper is related to runtime software integrity
protection. We there go one step further to read the abstract (and
full content if needed) of the obtained papers to only retain the
closely related ones by applying the following exclusion criteria:
(1) Short papers (i.e., less than six pages in double-column format
or 11 pages in single-column format) are excluded. (2) Papers not
targeting x86 architectures are excluded. (3) Papers not targeting
c/c++ language are excluded. (4) Papers targeting software integrity
issues but that do not concern runtime protection are excluded. (5)
Papers with few citations are excluded. After applying these exclu-
sion criteria, there are 10 papers retained that are closely related to
runtime software intrgrity protection, which are listed in table 1.
Status Quo Analysis. The approaches against MATE attacks,
moves around the four basic categories, i.e., code obfuscation[10, 17,
20], customization[5], self-checking or run-time process memory
invariant checking[7, 8, 11, 19], and trusted hardware[6, 18] with
their subcategories. Obfuscation attempts to thwart reverse engi-
neering by making it hard to understand the behavior of a program
through static or dynamic analysis. Customization takes one copy
of a program and creates many very different versions. Distributing
Many different versions of a program stops widespread damage
from a security break since published patches to break one version
2
Reaching definition. Reaching definition is one of the most com-
mon and useful data flow schemas. Using the terminology from [1],
an instruction that writes to a memory position defines the value
in the memory position, and an instruction that reads the value
is said to use the value. The analysis computes the set of reaching
definitions for each use and assigns an identifier to each definition.
It returns a map from instructions to definition identifiers and a set
of reaching definition identifiers for each use, which we call the
static data-flow graph.
In this paper’s context, We rely on a flow-sensitive intraproce-
dural analysis, which is called reaching definitions analysis [1] to
compute the static data-flow graph and determine the location to
insert the corresponding instrument.
2.2 Interprocedural Analysis
An interprocedural analysis operates across an entire program,
flowing information from the caller to its callees and vice versa.
For languages that pass parameters by reference, interprocedural
analysis is needed to determine if the same variable is passed as two
or more different arguments. Such aliases can create dependences
between seemingly distinct parameters.
Context-sensitive Interprocedural Analysis means that data-flow
analysis is required to take cognizance of what the sequence of pro-
cedure calls has been. That is, context-sensitive analysis includes
the current sequence of activation records on the stack, along with
the current point in the program, when distinguishing among dif-
ferent "places" in the program.
On the other hand, context-insensitive refers to an analysis or
computation that does not take into account the context in which
a piece of code is executed. This means that the analysis treats all
instances of the code as if they are executed in the same context. In
context-insensitive analysis, parameters and returned values are
modeled by copy statements.
In this paper’s context, we choose to use context-sensitive inter-
procedural analysis with pointer analysis [05 Improving software
Enforcing Runtime Software Integrity by Finer-grained Self-checking
security with a C pointer analysis.] because the method is more
precise to allow it to scale to large programs.
2.3 Kernel-mode Driver
Windows operating system includes both user-mode and kernel-
mode components (https://learn.microsoft.com/en-us/windows-
hardware/drivers/kernel/overview-of-windows-components). Kernel-
mode driver runs it code in kernel mode. Kernel-mode driver export
a specific call routine so that it can respond to specific calls from
the operating system and can respond to other system calls.
In this paper’s context, our kernel level monitor is actually a
kernel-mode driver, whose driver entry identifier is 0x666.
2.4 Asynchronous Communication
Data transfers can be synchronous or asynchronous. The determin-
ing factor is whether the entry point that schedules the transfer
returns immediately or waits until the I/O has been completed.
With an asynchronous I/O request to the kernel, the process is not
required to wait while the I/O is in process. A process can per-
form multiple I/O requests and allow the kernel to handle the data
transfer details.
2.5 Definition 1: Data-flow Integrity
Castro et al. introduced data-flow integrity (DFI) [7], a defensive
technique that aims to protect programs against non-control-data
attacks. Firstly, DFI generates the data-flow graph (DFG) of the
program by static analysis, secondly, it instruments the program
introducing data-flow integrity checks, and finally, it enforces at
runtime that the data-flow of the program is allowed by the DFG,
otherwise the execution is aborted.
Data-flow integrity. i.e., whenever a value is read, the definition
identifier of the instruction that wrote the value should be in the set
of reaching definitions for the read (if there is one), the definition
instruction should be the same as in the source code and remain
unchanged since the last definition.
2.6 Definition 2: Control-flow Integrity
The CFI security policy dictates that software execution must fol-
low a path of a ControlFlow Graph (CFG) determined ahead of
time [05 Control-Flow Integrity Principles, Implementations, and
Applications].
Control-flow integrity. i.e., whenever a value is read, the compar-
ison instruction should be the same as in the source code and the
value should remain unchanged since the last definition.
In this paper’s context, control-flow integrity check has been
included in flow-sensitive data-flow analysis and context-sensitive
interprocedural analysis. Thus if data-flow integrity is not violated
at runtime, then control-flow integrity is not violated.
3 APPROACH
3.1 Scenario, Threat and Goal
Scenario: While there are various attack scenarios and goals that
MATE attackers may pursue, here we particularly focus on attacks
violating online software integrity at runtime; other attacker
3
Conference’17, July 2017, Washington, DC, USA
goals are out of our scope. Runtime software integrity refers to
the integrity of executable code and memory space at runtime.
Online software, (or a web-based software) is a software that runs
on a server or a client that requires internet connection for full
functionality.
Threats: In this scenario, reputation, financial gains, sabotage,
fantasy of success and terrorism are non-exhaustive motivations
for attackers to target the integrity of software systems. Here we
mainly consider two types of MATE attacks: local attack and remote
attack[2]. Local attackers can tamper with softwares at any stage
and at any where (on-disk, in-memory and in-execution). Remote
attackers do not require physical access to the system of interest and
they have the ability to exploit the vulnerabilities of the software
which enable them to tamper with the integrity of the system.
Goal: Our overall design goal is to protect the integrity of online
software system from local and remote MATE attacks. In detail, we
need to prevent:
• Runtime code overwrite (local)
• Runtime memory overwrite (local)
• Runtime control flow data attack (remote)
• Runtime non-control flow data attack [9](remote)
3.2 Overview
Data-flow data integrity reinforcement has both compile-time and
runtime components. Figure 1 illustrates how these components
work from a top-down overview.
Figure 1: Top-down overview
The first phase uses static program analysis to compute a data-
flow graph for the target program. The second phase instruments
the program to ensure that the data-flow data is not overwritten
and matches this graph. The third phase launches the reinforced
program. When one of the instruments is executed, it will launch
an asynchronous system call to our kernel level monitor. Then the
kernel level monitor will scan specific memory addresses of the
program to check whether anomaly memory overwrite happens. If
the answer is yes, it will raise an exception. Since our solution will
not generate false positives; when we raise an exception, there is
an attack in process.
We will use the simple example in Fig 2 to illustrate how these
phases work.
The example shows a code fragment that is inspired by a vulner-
ability in SSH[23] that can be exploited to launch both control-data
and non-control-data attacks [9].
In this example, we assume that Windows exploitation protection
methods are turned off, such as ACG and StackPivot [16]. This
vulnerability could be exploited by both local MATE attack and
remote MATE attack to overwrite the return address of the function
Conference’17, July 2017, Washington, DC, USA
Figure 2: Example vulnerable code snippet in C
or to overwrite authenticated. Control-flow data attack may allow
the attacker to gain control over the execution. While non-control-
flow data attack would allow the attacker to bypass authentication
and get its packet processed. In addition, local MATE attack can
modify the definition instruction, i.e. substitute line 1 to be int
authenticated = 1. We will show how our program data integrity
reinforcement approach can prevent all these attacks.
3.3 Static Program Analysis
In the first phase, we compute reaching definitions using a combina-
tion of two analyses: a flow-sensitive intraprocedural analysis and
a context-sensitive interprocedural analysis, which are introduced
in [1]. We plan to implement both analysis based on the GNU Com-
piler Collection (GCC) [14]. They operate on GCC’s intermediate
representation [12] . Figure 3 shows the GIMPLE representation
for the vulnerable C code in Figure 2.
The intraprocedural analysis takes flow control into account.
It is implemented by traversing the static single assignment repre-
sentation [13] produced by GCC. We use this analysis to compute
reaching definitions [1] for uses of local variables that have no
definitions external to the function in which they are declared. The
interprocedural analysis considers control-flow and it takes the
calling context into account when analyzing functions. We can
use Andersen’s pointsto analysis [4] to compute the set of objects
that each pointer can point to, and we use these points-to sets to
compute reaching definitions.
We applied the analysis to the sample code in Figure 3 using the
numbers at the end of the lines to identify definitions. The set of
reaching definitions is {5, 12} for both uses of authenticated (in lines
14 and 20).
3.4 Instrumentation
We add instrumentation by inserting new high-level instructions
into the GIMPLE representation of the program. The instructions
have the form:
• __𝑠𝑒𝑡𝐷𝑒 𝑓 (𝑣𝑎𝑟, 𝑖𝑑): reserve relative offset of last definition
and next definition to RDT;
• __𝑟𝑒𝑐𝑜𝑟𝑑𝐷𝑒 𝑓 (𝑣𝑎𝑟 ): reserve assigned value of last definition
to RDT;
4
Jiaxuan Wu and Zheng Zhu
Figure 3: Example vulnerable code in GIMPLE intermediate
representation
• __𝑐ℎ𝑒𝑐𝑘𝐷𝑒 𝑓 (𝑣𝑎𝑟 ): launch a system call with corresponding
entry for RDT as the parameter.
The first instruction sets the Runtime Definition Table (RDT)
for var to id. The second one record the value of var after a definition
to RDT. The third one retrieves the runtime definition identifier
for var from the RDT and checks if the identifier is in the reaching
definitions set with name setName. The compiler maintains a map
from set names to set values that is used when lowering the high-
level instructions to the assembly of the target machine. Currently,
we only target the x86 architecture but it would be simple to target
other architectures with our high-level instrumentation.
Figure 4 shows the GIMPLE for the vulnerable code with high-
level instrumentation generated from the information computed
by the reaching definitions analysis.
Before describing how the high-level instrumentation is lowered
to assembly, we need to describe how we implement the RDT. To
enable efficient accesses, the RDT is implemented as an array with a
reserved 32-bit memory space for each variable in the instrumented
program. The exapmle RDT for variable authenticated is shown in
figure 5.
The program is instrumented to compute the definition that
reaches each read at runtime and to check if this definition is in
the set of reaching definition identifiers that was computed stat-
ically. To compute reaching definitions at runtime, we maintain
the runtime definitions table (RDT) that records the identifier
of the last instruction to write to each memory position. Every
write is instrumented to update the RDT. The instrumentation be-
fore reads uses the address of the value being read to retrieve the
Enforcing Runtime Software Integrity by Finer-grained Self-checking Conference’17, July 2017, Washington, DC, USA

__𝑟𝑒𝑐𝑜𝑟𝑑𝐷𝑒 𝑓 (_𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒𝑑) instruction is lowered to:

__𝑐ℎ𝑒𝑐𝑘𝐷𝑒 𝑓 (_𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒𝑑) instruction is lowered to:

From now on the instrumented code is no longer vulnerable to

the threats we defined in Section 3.1. We will show how we detect
and prevent each of these attacks in Section 4.

3.5 Kernel-level Monitor

Our kernel-level monitor is actually a customized kernel driver. The
overview of kernel-level monitor is shown in figure 6.

Figure 4: Example vulnerable code in GIMPLE with instru-

mentation
Figure 6: Overview of our kernel-level monitor

At runtime, the instruments in the reinforced program will com-

municate asynchronously with our kernel monitor and the monitor
will scan the memory space of the program to check whether anom-
aly memory overwrite happens. If the answer is yes, it will raise an
exception. Our solution will not generate false positives; when we
raise an exception, there is an attack in process.
Figure 5: Part of RDT for variable authenticated Kernel-mode tasks mainly do three kind of checks:
• test RDT[&authenticated_id+24] % RDT[&authenticated_id]
== 0: the offset of the last definition should be a factor of least
common multiple (LCM) of all possible offset of definitions;
• test baseaddress+RDT[&authenticated_id] ==
identifier from the RDT. Then, it checks if this identifier is in the RDT[&authenticated_id+8]: the executed definition should
statically-computed set. be the original definition of the code;
The high-level instrumentation is lowered to x86 assembly as il- • test &authenticated == RDT[&authenticated_id+16]: the
lustrated by the following examples. __𝑠𝑒𝑡𝐷𝑒 𝑓 (_𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑒𝑑, 12) value of the variable should not be changed since last defini-
instruction is lowered to: tion.
5
Conference’17, July 2017, Washington, DC, USA
4 EVALUATION
To evaluate our data-flow integrity detection system, we address
the following research questions:
• RQ1: Can data-flow integrity detection detect various MATE
attacks? We address this question by considering three sub-
questions:
– RQ1.a: Can runtime code overwrite (local) and be detected
by our approach?
– RQ1.b: Can runtime data-flow data attack (local and re-
mote) be detected by our approach?
– RQ1.c: Can runtime control-flow data attack (local and
remote) and be detected by our approach?
• RQ2: How does our approach compare to primary works?
4.1 Detect Runtime Code Overwrite
In this subsection, we will illustrate how we detect code overwrite at
runtime with the example we defined in Section 3.2. Code overwrite
means attackers may change the instructions stored in the code
segmentation of the memory space while the program is running.
For example, a hacker may change the definition instruction in
the code segmentation int authenticated = 0; to be int authenticated
= 1;. Let see what would happen if the hacker does this. When the
instruction int authenticated = 1; is executed, the instrument __set-
Def(_authenticated, 5); would record the instruction to the RDT.
Then when the variable is used in while (!authenticated), __check-
Def(_authenticated); would be executed and launch a system call to
our kernel monitor. Then it will find the instruction is inconsistent
with the original instruction int authenticated = 0;. So an exception
will be raised to prevent the program from continuing.
4.2 Detect Runtime Data-flow Data Overwrite
Then we will illustrate how we detect data-flow data overwrite at
runtime with the example we defined in Section 3.2. Data-flow data
overwrite means attackers may change the values of the variables
without definition while the program is running.
For example, a hacker may overwrite the definition instruction
on the stack of PacketParser(packet); to be int authenticated = 1;.
Then the instrument __setDef(_packet, 9); would record the in-
struction to the RDT. Then when the variable is used in Authenti-
cate(packet), __checkDef(_packet); would be executed and launch a
system call to our kernel monitor. Then it will find the instruction is
inconsistent with the original instruction PacketParser(packet);. So
an exception will be raised to prevent the program from continuing.
4.3 Detect Runtime Control-flow Data Attack
Then we will illustrate how we detect control-flow data overwrite
at runtime with the example we defined in Section 3.2. Control-
flow data overwrite means attackers may change the values of the
variables that could affect the condition judgment in control-flow
while the program is running.
For example, a hacker may overwrite the value of variable authen-
ticated to be 1 right after PacketParser(packet); is executed. Before
the next loop starts, __checkDef(_authenticated); would launch a
system call to our kernel monitor. Then it will find current value is
inconsistent with the last definition instruction int authenticated
6
Jiaxuan Wu and Zheng Zhu
= 0;. So an exception will be raised to prevent the program from
continuing.
4.4 Compared to related works
Through the previous three examples we have explained why our
approach is effective against runtime code overwrite, data-flow
data attack and control-flow data attack. However the approach
described in [7] can only partially prevent data-flow data attack.
The approach described in [3] can only partially prevent data-flow
data and control-flow attack. The root cause is that in pursuit of
low overheads, they cannot provide enough fine-grained memory
detection at runtime. Here we give anomaly detection tasks to a
kernel monitor asynchronously, so that our reinforced program
can executed forward with least system interruptions. Thus our
approach can provide more comprehensive instrumentation while
ensuring low overhead in both time and space.
4.5 Limitation
No matter how powerful the system is, it will have its Achilles’
heel. The Achilles’ heel of our system is the integrity of RDT. If
the attacker can find the location of RDT and forge part of it to be
"normal data", our kernel level monitor can detect nothing. In order
to solve this, we plan to use redundant design or customization
approach described in [5], so that MATE attackers can hardly write
a stable prove of concept (PoC) to tamper with RDT without been
detected.
5 CONCLUSION
We presented a new self-checking technique to prevent various
MATE attacks through program instrumentation and kernel level
monitoring. Basically we enforced three safety properties: 1. the off-
set of the last definition should be a factor of least common multiple
(LCM) of all possible offset of definitions; 2. the executed definition
should be the original definition of the code; 3. the value of the vari-
able should not be changed since last definition. Previously, there
was no comprehensive defense against various runtime data over-
write because of high overheads. While we are confident that our
approach can prevent all code, data-flow data and control-flow data
attacks we know about. Our design can be used in practice because
we use an asynchronous kernel monitor to reduce the overhead of
the instrumentation and it does not have false positives.
REFERENCES
[1] Alfred V Aho, Monica S Lam, Ravi Sethi, and Jeffrey D Ullman. 2007. Compilers:
principles, techniques, & tools. Pearson Education India.
[2] Adnan Akhunzada, Mehdi Sookhak, Nor Badrul Anuar, Abdullah Gani, Ejaz
Ahmed, Muhammad Shiraz, Steven Furnell, Amir Hayat, and Muhammad Khur-
ram Khan. 2015. Man-At-The-End attacks: Analysis, taxonomy, human aspects,
motivation and future directions. Journal of Network and Computer Applications
48 (2015), 44–57.
[3] Periklis Akritidis, Cristian Cadar, Costin Raiciu, Manuel Costa, and Miguel Castro.
2008. Preventing memory error exploits with WIT. In 2008 IEEE Symposium on
Security and Privacy (sp 2008). IEEE, 263–277.
[4] Lars Ole Andersen. 1994. Program analysis and specialization for the C program-
ming language. Ph. D. Dissertation. Citeseer.
[5] David Aucsmith. 1996. Tamper resistant software: An implementation. In Inter-
national Workshop on Information Hiding. Springer, 317–333.
[6] Andrew Baumann, Marcus Peinado, and Galen Hunt. 2015. Shielding applications
from an untrusted cloud with haven. ACM Transactions on Computer Systems
(TOCS) 33, 3 (2015), 1–26.
Enforcing Runtime Software Integrity by Finer-grained Self-checking
[7] Miguel Castro, Manuel Costa, and Tim Harris. 2006. Securing software by
enforcing data-flow integrity. In Proceedings of the 7th symposium on Operating
systems design and implementation. 147–160.
[8] Hoi Chang and Mikhail J Atallah. 2001. Protecting software code by guards. In
ACM Workshop on Digital Rights Management. Springer, 160–175.
[9] Shuo Chen, Jun Xu, Emre Can Sezer, Prachi Gauriar, and Ravishankar K Iyer. 2005.
Non-Control-Data Attacks Are Realistic Threats.. In USENIX security symposium,
Vol. 5. 146.
[10] Christian Collberg, Clark Thomborson, and Douglas Low. 1997. A taxonomy of
obfuscating transformations. Technical Report. Department of Computer Science,
The University of Auckland, New Zealand.
[11] Christian S. Collberg and Clark Thomborson. 2002. Watermarking, tamper-
proofing, and obfuscation-tools for software protection. IEEE Transactions on
software engineering 28, 8 (2002), 735–746.
[12] gcc.gnu.org. 2022. GIMPLE. https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html
[13] gcc.gnu.org. 2022. Static Single Assignment. https://gcc.gnu.org/onlinedocs/
gccint/SSA.html
[14] Github.com. 2022. GNU Compiler Collection. https://github.com/gcc-mirror/gcc
[15] Simon Hansman and Ray Hunt. 2005. A taxonomy of network and computer
attacks. Computers & Security 24, 1 (2005), 31–43.
[16] Microsoft. 2022. Customize exploit protection. https://learn.microsoft.com/en-
us/microsoft-365/security/defender-endpoint/customize-exploit-protection?
Conference’17, July 2017, Washington, DC, USA
view=o365-worldwide
[17] Jasvir Nagra and Christian Collberg. 2009. Surreptitious Software: Obfuscation,
Watermarking, and Tamperproofing for Software Protection: Obfuscation, Water-
marking, and Tamperproofing for Software Protection. Pearson Education.
[18] Ricardo Neisse, Dominik Holling, and Alexander Pretschner. 2011. Implementing
trust in cloud infrastructures. In 2011 11th IEEE/ACM International Symposium
on Cluster, Cloud and Grid Computing. IEEE, 524–533.
[19] Nick L Petroni Jr, Timothy Fraser, Jesus Molina, and William A Arbaugh. 2004.
Copilot-a coprocessor-based kernel runtime integrity monitor.. In USENIX secu-
rity symposium. San Diego, USA, 179–194.
[20] Chenxi Wang, Jonathan Hill, John Knight, and Jack Davidson. 2000. Software
tamper resistance: Obstructing static analysis of programs. Technical Report.
Technical Report CS-2000-12, University of Virginia, 12 2000.
[21] Claes Wohlin. 2014. Guidelines for snowballing in systematic literature studies
and a replication in software engineering. In Proceedings of the 18th international
conference on evaluation and assessment in software engineering. 1–10.
[22] Jeff Yan and Brian Randell. 2005. A systematic classification of cheating in online
games. In Proceedings of 4th ACM SIGCOMM workshop on Network and system
support for games. 1–9.
[23] Michael Zalewski. 2001. Ssh1 crc-32 compensation attack detector vulnerability.