PDIFT: A Practical Dynamic Information-Flow Tracker

Michael Kiperberg

1 a

, Aleksei Rozman

, Aleksei Kuraev

and Nezer Zaidenberg

Department of Software Engineering, Shamoon College of Engineering, Beer-Sheva, Israel

Department of Computer Sciences, Ariel University, Ariel, Israel

Keywords:

Virtualization, Hypervisor, Emulator, DIFT.

Abstract:

We present PDIFT, a hybrid dynamic information-ﬂow tracker. PDIFT is based on a thin hypervisor, which

tracks information in coarse granularity but has a negligible performance overhead. PDIFT switches to its

internally embedded emulator when the information is accessed and needs to be tracked with ﬁner granularity.

Using the combination of a thin hypervisor with an embedded emulator, we achieved a signiﬁcant improve-

ment in the overall performance. We believe that PDIFT can be used as an extension to the Android base DIFT

systems that currently struggle with native code tracking.

1 INTRODUCTION

Computer systems are exposed to constant threats tar-

geting their conﬁdential information. An attacker

can use multiple vectors to achieve her goal, from

introducing new code that alters the system’s be-

havior to the exﬁltration of conﬁdential information.

While widely-available antivirus programs concen-

trate on software analysis to detect malicious intent,

sufﬁciently sophisticated malware (e.g., metamorphic

(You and Yim, 2010)) can evade them. On the other

hand, data leakage prevention systems attempt to pre-

vent unauthorized data movement by analyzing the

data being transferred through certain critical junc-

tions, e.g., between applications, over the network,

or external ﬂash drives. They operate by preventing

the transfer of data that violates a predeﬁned set of

rules. The rules can target the context, or the content

of the data (Kiperberg, 2021). These security systems

attempt to prevent the inﬁltration of malware and the

exﬁltration of sensitive information.

Unfortunately, the widely available security sys-

tems are unaware of the history of the information be-

ing analyzed and, in particular, its origin. The origin

can form the basis for simple and precise rules regard-

ing data movement. For example, execution permis-

sions can be expressed in terms of the code origin:

only code that was downloaded from a speciﬁc do-

main can execute on the computer. Data leakage pre-

vention rules can be expressed similarly: data that is

https://orcid.org/0000-0001-8906-5940

affected by the content of a sensitive ﬁle cannot be

sent over the network. Of course, additional rules

may apply. Without the origin, it may be challeng-

ing to devise precise rules for the prevention of data

inﬁltration and exﬁltration.

Dynamic information-ﬂow tracking (DIFT) (Chen

et al., 2021) is a technique for tracing data through-

out any transformations. DIFT can establish the ori-

gin of a particular value, or more precisely, DIFT can

reason about whether a particular memory location

has been affected by another memory location. DIFT

can be implemented in hardware (Chen et al., 2008;

Venkataramani et al., 2008) and software. Software

implementations, implemented using emulators (Yan

and Yin, 2012; Xue et al., 2018) or instrumentation

(Kemerlis et al., 2012), degrade the performance by

several factors. The severe performance degradation

prohibits DIFT deployments on commodity systems.

The only area in which DIFT can be partially de-

ployed is Android. Since much of the code exe-

cuting on Android is written in Java, DIFT can be

implemented efﬁciently by analyzing the Java byte-

code inside the Java Virtual Machine (Dalvik (Born-

stein, 2008)). Unfortunately, the tracing functional-

ity of such DIFT implementations cannot cross the

Java boundary. Tracing of data in the native code

invoked by Java requires additional means (Yan and

Yin, 2012; Xue et al., 2018) implemented using the

slow emulation or instrumentation.

The realization that DIFT can be enabled selec-

tively, only during the times that the information is

tracked, led to a hybrid DIFT approach (Ho et al.,

192

Kiperberg, M., Rozman, A., Kuraev, A. and Zaidenberg, N.

PDIFT: A Practical Dynamic Information-Flow Tracker.

DOI: 10.5220/0011786800003405

In Proceedings of the 9th International Conference on Information Systems Security and Privacy (ICISSP 2023), pages 192-198

ISBN: 978-989-758-624-8; ISSN: 2184-4356

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

2006). A hybrid DIFT consists of a hypervisor and an

emulator. The hypervisor performs virtualization un-

til the system accesses the information to be tracked.

Then, the hypervisor switches to emulation, which

continues while the analyzed code manipulates the

tracked information.

This paper introduces Practical Dynamic

Information-Flow Tracker (PDIFT), a hybrid DIFT

system. PDIFT’s design makes it suitable for deploy-

ment on Android devices supporting virtualization.

We anticipate the performance of DIFT on these

devices to be optimal since direct emulation is

required only when native code manipulates tracked

information. In other cases, when Java code runs or

when native code does not manipulate the tracked

information, the performance degradation will be

minimal.

PDIFT is a thin hypervisor (Shinagawa et al.,

2009) with an embedded emulator. The hypervisor

provides hypercalls for tainting the memory regions

to be tracked and for querying whether a memory re-

gion is tainted. The hypervisor remains passive while

the tainted memory region is not accessed, thus al-

lowing it to incur only a negligible overhead ( 1.5%).

When the tracked program accesses a tainted memory

region, the hypervisor activates its embedded emula-

tor. The performance beneﬁts of embedding the em-

ulator inside the hypervisor rather than placing it in a

different environment (virtual machine) are twofold.

First, we can spare the extra transition from the hy-

pervisor to the different environment. Second, we

can spare the costly copying of the tracked program’s

memory since the emulator can access it directly.

In this paper, we make the following contribu-

tions:

• We describe PDIFT, a novel DIFT system that is

based on a thin hypervisor and an embedded em-

ulator.

• We analyze the performance of the PDIFT and

compare it with other DIFT systems.

• We outline the design of an efﬁcient DIFT system

for Android devices which supports both Java and

native code.

2 BACKGROUND

Intel introduced hardware-assisted virtualization al-

most 20 years ago. Their VT-x technology introduces

a new execution mode to the x86 architecture, the

root mode. Software executing in the root mode, the

hypervisor, has higher privileges than the operating

system, has higher precedence in interrupt handling,

and can intercept many events in the operating sys-

tem. Upon an occurrence of an event, the processor

switches to the hypervisor. The hypervisor handles

the event and continues the execution of the operating

system. The transitions to the hypervisor are called

vm-exits, and the transitions to the operating system

are called vm-entries. The hypervisor can run multi-

ple operating systems in isolated environments, called

virtual machines or guests.

In order to improve the memory management per-

formance, Intel introduced the Extended Page Table

(EPT) mechanism, also known as a secondary-level

page table (SLAT), which allows the hypervisor to

conﬁgure the correspondence between the physical

addresses as perceived by the guests to the actual

physical addresses. Similarly to the regular (process)

page table, the EPT conﬁgures the mapping and ac-

cess rights. When a guest attempts to access a mem-

ory location in violation of the set rights, a VM-exit

occurs, thus allowing the hypervisor to handle the

event.

Hypervisors can run atop an operating system

(e.g., Oracle VirtualBox (Oracle, 2022), VMware

Workstation (VMware, 2022b), KVM (Deshane et al.,

2008)) or without a hosting operating system (e.g.,

VMware ESXi (VMware, 2022a), Xen (Deshane

et al., 2008)). In the second case, the hypervisor must

boot directly from the ﬁrmware, similarly to the op-

erating system itself. PDIFT is embedded in an EFI

(Zimmer, 2009) application. The EFI ﬁrmware loads

this application, which in turn initializes the hyper-

visor. When the EFI application exits, the ﬁrmware

continues to the next EFI application, the operating

system bootloader.

3 SYSTEM DESIGN

PDIFT is a hybrid dynamic information-ﬂow track-

ing system. Figure 1 presents the high-level design

of PDIFT. In essence, PDIFT provides means for de-

termining whether a particular memory region was

affected by another memory region during a partic-

ular calculation. The main idea is to augment the

instruction-set architecture with the ability to track an

information ﬂow.

We have augmented the instruction-set architec-

ture as follows. For every memory address (byte), we

have added a bit to determine whether the memory

address contains information that needs tracking. We

say that such memory addresses are tainted. The pro-

cess of information ﬂow tracking can be divided into

three phases. In the ﬁrst phase, the input memory ad-

dresses are tainted. In the second phase, the calcu-

PDIFT: A Practical Dynamic Information-Flow Tracker

193

App 1 App 2 App 3

Operating System

Hypervisor

Emulator

Driver

Figure 1: The design of PDIFT. The hypervisor executes

with higher privileges than the operating system. The hy-

pervisor executes a single virtual machine containing the

operating system and the user applications. The applica-

tions can communicate with the operating system through

system calls (the arrow from App 2 to the Operating Sys-

tem). The applications, the operating system, and the

drivers can communicate with the hypervisor through hy-

percalls (all other solid arrows). The emulator is embed-

ded in the hypervisor and can execute (emulate) application

code.

lation is performed in the augmented instruction-set

architecture. Finally, in the third phase, the tainted

memory addresses are determined.

The main idea is to track the taints in the granular-

ity of a single instruction. For this to work correctly,

not only memory locations need to be taintable, but

also the registers. For example, a MOV instruction can

copy 4 bytes of information from memory to a register

and then copy from this register to another memory

address. In this case, if the source address is tainted,

then the ﬁrst instruction will propagate the taint to the

destination register, and the second instruction will

propagate the taint to the destination memory address.

In general, augmentations of existing instruction-

set architectures are performed either by direct hard-

ware modiﬁcations or by modifying an existing em-

ulator of the instruction-set architecture. We have

chosen the second path since it is more readily avail-

able. There are multiple available emulators (Bochs

(Lawton, 1996), QEMU (Bellard, 2005), libx86emu

(wfeldt, 2022)) that differ in performance, complex-

ity, and the completeness of the emulated instruction-

set architecture. However, they all are orders of mag-

nitude slower than virtualization-based solutions.

On the other hand, virtualization-based solutions

are incapable of modifying the behavior of instruc-

tions since those are executed directly by the CPU.

Therefore, there is a need for a hybrid solution in

which virtualization will be used most of the time in

order to provide the best possible performance, and

emulation will be used sporadically for taint propaga-

tion.

Our system is based on our thin hypervisor, which

boots from a UEFI application before the operating

system. The hypervisor creates a single virtual ma-

chine, also called the “guest”, under the hypervisor’s

full control — the operating system boots inside the

newly created virtual machine.

Our hypervisor conﬁgures the EPT with the access

rights of different pages, thus allowing it to intercept

accesses to certain memory regions. In addition, the

hypervisor provides communication means with the

guest through hypercalls, similar to the communica-

tion means provided by operating systems. Upon an

occurrence of an event that was selected for the in-

terception, a hypervisor can observe the guest’s state,

modify it and resume the guest’s execution.

We have added two new hypercalls to our hyper-

visor:

• set taint(addr, size, val) — the hypercall

sets or clears a taint (depending on the setting of

the “val” parameter) of a memory region deﬁned

by the “addr” and “size” parameters,

• get taint(addr, size) — the hypercall re-

turns true iff at least one of the bytes of a memory

region deﬁned by the “addr” and “size” parame-

ters is tainted.

These hypercalls allow an entity (kernel module or

user-mode application) to set and check the tainting

of a particular memory region. These hypercalls al-

ter and query the taint repository, a data structure that

keeps track of the tainted memory regions. In addi-

tion to modifying the taint repository, the set taint

hypercall conﬁgures the EPT to intercept accesses to

the pages containing the tainted range of addresses.

When the hypervisor gains control in response to

access to such a page, it begins the emulation process.

The emulation involves copying the guest’s state to

the emulator, running the emulator until the emulation

can be disabled, and then copying the emulator’s state

to the guest. The emulator executes inside the context

of the hypervisor in order to eliminate unnecessary

transitions. Therefore, memory accesses require the

emulator to translate the guest’s virtual addresses to

the actual physical addresses. In our current imple-

mentation, we do not cache the translation informa-

tion. Such a cache can potentially have a signiﬁcant

effect on the overall system performance. During em-

ulation, taints propagate from the memory to the reg-

isters and vice versa. The emulation proceeds while

at least one register is tainted.

The current implementation of PDIFT does not

include any optimizations to prevent costly transi-

tions to the emulator and back. Neither does the

current implementation include caches of compiled

blocks of instructions. PDIFT includes libx86emu, a

tiny x86 user-space emulator (wfeldt, 2022). Since

libx86emu, unlike Bochs (Lawton, 1996) or Qemu

(Bellard, 2005), does not have external dependencies,

it could be easily embedded in our thin hypervisor.

ICISSP 2023 - 9th International Conference on Information Systems Security and Privacy

194

On the other hand, libx86emu performs na

ıve emula-

tion and does not incorporate even basic optimization

techniques, which makes its performance suboptimal,

to say the least.

The libx86emu emulator consists of an inﬁnite

loop. On each iteration, the emulator reads the next

instruction from the location pointed by the instruc-

tion pointer. Then, the read instruction is parsed and

executed. The instruction execution may involve ac-

cess to the registers and the memory. The emulator

stores the registers in a special object that describes

the current execution context. The context object is

allocated during the initialization of the hypervisor.

We have extended this object to include a taint bit for

each general-purpose register (see Figure 2). When

the emulation process begins, the values of the actual

registers are loaded to the context object, and the taint

bits are cleared. When the emulation ends, the values

of the registers are copied back.

typedef struct

{

union {

I32_reg_t I32_reg;

I16_reg_t I16_reg;

I8_reg_t I8_reg;

} val;

int tainted; // added

} i386_general_register;

Figure 2: A data structure that describes a single general-

purpose register with the added “tainted” member.

The libx86emu emulator emulates each instruc-

tion by a dedicated function. In rare cases, sev-

eral instructions are handled by a single function.

Some instructions do not modify the taints of mem-

ory regions or registers; others do. We have modi-

ﬁed the emulation of those instructions to propagate

the taint as appropriate. Figure 3 presents an excerpt

from the x86emuOp mov word R RM instruction emu-

lation; only the handler of the MOV reg, [mem] vari-

ant is presented. The taint propagation functionality

is marked with a comment. In this example, the des-

tination register is set to be tainted iff one of the bytes

in the source memory region is tainted. The example

demonstrates two of the four macros that implement

the taint propagation functionality.

The taint propagation functionality is realized by

four macros:

• MEM TYPE GET(ADDR, SIZE) — evaluates to

TRUE if at least one of the memory bytes in the

range [ADDR,ADDR+SIZE) is tainted.

• MEM TYPE SET(ADDR, SIZE, VAL) — depend-

ing on the value of VAL, sets (if 1) or resets (if

0) the taint of the memory bytes in the range

[ADDR,ADDR+SIZE).

• REG GET MARK(REG) — evaluates to TRUE if the

• REG SET MARK(REG, VAL) — depending on the

value of VAL, sets (if 1) or resets (if 0) the taint of

the register REG. In addition, this macro modiﬁes

a special ﬁeld of the context object that counts the

number of currently tainted registers.

Figure 4 presents an excerpt from the

x86emuOp mov byte RM R instruction emulation.

It demonstrates the usage of the MEM TYPE SET and

the REG GET MARK macros. The memory taint is set

iff the source register has a taint.

4 EVALUATION

The evaluation of the proposed system was performed

on a system whose conﬁguration appears in Table 1.

We have split the evaluation into three parts: (a) cor-

rectness, (b) hypervisor performance, (c) overall per-

formance.

Table 1: Evaluation System Conﬁguration.

CPU Intel Core i7-8665U

Memory 16GB

Operating System Windows 7 x64

We demonstrate the ﬁrm information-ﬂow track-

ing abilities using an encryption program that uses

the RC4 cipher for encryption. The program reads

its two inputs from ﬁles: the encryption key and the

plaintext. The program schedules the key, encrypts

the plaintext, and stores the ciphertext in a ﬁle. We

have added two hypercalls to the program. The ﬁrst

hypercall is issued right after the inputs are read. The

hypercall requests the hypervisor to taint the memory

location that stores the key. The second hypercall is

issued before the output ﬁle is written. This hypercall

queries whether the ciphertext is tainted.

In the future, we envision these hypercalls to be

implemented by the operating system in response to

read and write requests. In this implementation, the

operating system can mark ﬁles (or their regions)

tainted by extending the ﬁlesystem. After reading

from a tainted ﬁle, the operating system can request

the hypervisor to taint the memory locations contain-

ing the read data. When writing to a ﬁle, the operating

system can check whether the memory being written

is tainted and mark the ﬁlesystem appropriately.

We assessed our implementation’s correctness by

performing the encryption on the publicly available

PDIFT: A Practical Dynamic Information-Flow Tracker

195

static void x86emuOp_mov_word_R_RM(x86emu_t *emu, u8 op1)

{

...

fetch_decode_modrm(emu, &mod, &rh, &rl);

...

if(MODE_DATA32) {

dst32 = decode_rm_long_register(emu, rh);

OP_DECODE(",");

addr = decode_rm_address(emu, mod, rl);

*dst32 = fetch_data_long(emu, addr);

REG_SET_MARK(dst32, MEM_TYPE_GET(addr, 4)); // <- taint propagation

}

...

}

Figure 3: An excerpt from the x86emuOp mov word R RM instruction emulation.

static void x86emuOp_mov_byte_RM_R(x86emu_t *emu, u8 op1)

{

...

addr = decode_rm_address(emu, mod, rl);

OP_DECODE(",");

src = decode_rm_byte_register(emu, rh);

store_data_byte(emu, addr, *src);

MEM_TYPE_SET(addr, 1, REG_GET_MARK(src)); // <- taint propagation

...

}

Figure 4: An excerpt from the x86emuOp mov byte RM R instruction emulation.

RC4 test vectors. As was explained, we tainted the

encryption key before the encryption. Then, we veri-

ﬁed that the ciphertext was correct and tainted.

We used the PCMark (Sibai, 2008) benchmark-

ing tool to measure the performance overhead of our

hypervisor and compare it to a full hypervisor. PC-

Mark runs several applications belonging to various

categories and outputs the score obtained in each cat-

egory. We executed PCMark in three different conﬁg-

urations: (a) without a hypervisor, (b) with our thin

hypervisor, (c) in a full hypervisor (we used the same

operating system in the guest). From the results in ta-

ble 2, we can see that the thin hypervisor is at least an

order of magnitude faster than a full hypervisor. The

reason for this is that PDIFT intercepts only EPT vi-

olations, hypercalls (implemented as CPUIDs), and

other events that induce VM-exits unconditionally,

while full hypervisors intercept all the interrupts.

To measure the performance of the tainting func-

tionality, we executed the encryption program ten

times with and without requesting the hypervisor to

taint the encryption key. Figure 5 presents the results.

On average, the execution time increased by 26%.

We continued to a more detailed analysis of the

execution times. Table 3 presents the number of em-

ulation transitions that were performed during each

Table 2: Performance degradation in percents with respect

to the conﬁguration without a hypervisor.

Category Thin Hypervisor VirtualBox

App start-up 2.29 44.92

Web browsing 2.66 32.75

Spreadsheet 1.18 39.91

Writing 1.54 42.66

Photo editing -0.24 38.35

Video editing 1.77 28.02

Table 3: Transitions number and handling time.

Run Transitions Total Ticks

1 2071 410227

2 2085 414746

3 2069 412529

4 2022 403379

5 2095 416943

6 2070 418251

7 2009 401620

8 2020 402534

9 2055 410003

10 2088 427738

run. In addition, the table presents the total time that

was spent in the hypervisor during these transitions.

The time is given in CPU ticks. On average, the pro-

gram performed 2058 transitions. The handling took

ICISSP 2023 - 9th International Conference on Information Systems Security and Privacy

196

1 2 3 4

5 6

7 8 9 10

0.8

0.9

1.1

·10

Run

Execution Time (µs)

Tainted

Normal

Figure 5: The execution times of the encryption program with and without tainting.

412K ticks on average, 200 ticks per transition. We

note that depending on the CPU, the transition itself

takes several hundreds of ticks. Therefore, we can

conclude that PDIFT’s performance can be improved

by reducing the number of transitions rather than im-

proving the emulation performance.

5 RELATED WORK

While taint tracking can be performed statically, in

native programs, it usually leads to tainting the entire

program memory (Slowinska and Bos, 2009). How-

ever, it is still applicable to programs written in man-

aged languages, like Java (Machiry, 2017). Dynamic

taint tracking, which can be performed using instru-

mentation (Kemerlis et al., 2012), or emulation (Ho

et al., 2006), suffers from high performance degrada-

tion, which is generally prohibitive for real-time se-

curity monitoring. Hardware solutions (Chen et al.,

2008; Venkataramani et al., 2008) are costly and prob-

ably cannot be widely deployed. Another exciting di-

rection is hybrid pruning, in which dynamically col-

lected data is injected into the static taint analysis sys-

tem to improve its precision (Das et al., 2022).

TaintDroid (Enck et al., 2014) is a widely adopted

solution for DIFT in managed portions of Android

applications. Attempts to extend this solution to na-

tive code, like DroidScope (Yan and Yin, 2012) and

NDroid (Xue et al., 2018), which are based on em-

ulation using QEMU, resulted in high performance

degradation. We believe that better results can be ob-

tained using the hybrid approach of PDIFT.

Ho et al. (Ho et al., 2006) was the ﬁrst to propose

the hybrid approach. Their implementation included a

full hypervisor and an efﬁcient emulator (Qemu). The

emulator and the analyzed code were executed in two

separate virtual machines, which degraded the perfor-

mance signiﬁcantly. In contrast, PDIFT is based on a

thin hypervisor with an embedded emulator.

Using hypervisors in security applications is not

new. Full and thin hypervisors can be used in dif-

ferent scenarios ranging from malware detection (Se-

shadri et al., 2007; Leon et al., 2019) to device protec-

tion (Shinagawa et al., 2009; Kiperberg et al., 2020).

PDIFT is another example of the thin hypervisors’

versatility.

6 FUTURE WORK

As we have stated previously, the performance of

DIFT solutions is prohibitively high for native code

and surprisingly low for managed code. Therefore, it

would be interesting to integrate PDIFT into Taint-

Droid, for example. Such integration will require

porting PDIFT to the ARM architecture and switch-

ing to a different emulator that supports ARM.

While initially, we thought that PDIFT could ben-

eﬁt from an optimized emulator, like QEMU, our

evaluation clearly shows that the performance highly

depends on the number of transitions. In addition,

porting such a large emulator with multiple dependen-

cies into a restricted environment is challenging.

In the future, we plan to analyze further whether

several transitions can be grouped. It is possible that,

in some cases, it would be more beneﬁcial to continue

that costly emulation rather than switching to virtual-

ization for a short period and then switching back.

7 CONCLUSIONS

In this paper, we presented a Practical Dynamic

Information-Flow Tracker (PDIFT) implemented as a

PDIFT: A Practical Dynamic Information-Flow Tracker

197

thin hypervisor with an embedded emulator for the

Intel architecture. We showed that PDIFT has better

performance than previous solutions. We believe that

PDIFT can form the basis for the native DIFT on An-

droid platforms, thus providing a complete solution

for the DIFT problem in these environments.

REFERENCES

Bellard, F. (2005). Qemu, a fast and portable dynamic

translator. In USENIX annual technical conference,

FREENIX Track, volume 41, pages 10–5555. Califor-

nia, USA.

Bornstein, D. (2008). Dalvik vm internals. In Google I/O

developer conference, volume 23, pages 17–30.

Chen, K., Guo, X., Deng, Q., and Jin, Y. (2021). Dynamic

information ﬂow tracking: Taxonomy, challenges, and

opportunities. Micromachines, 12(8):898.

Chen, S., Kozuch, M., Strigkos, T., Falsaﬁ, B., Gibbons,

P. B., Mowry, T. C., Ramachandran, V., Ruwase, O.,

Ryan, M., and Vlachos, E. (2008). Flexible hard-

ware acceleration for instruction-grain program moni-

toring. ACM SIGARCH Computer Architecture News,

36(3):377–388.

Das, D., Bose, P., Machiry, A., Mariani, S., Shoshitaishvili,

Y., Vigna, G., and Kruegel, C. (2022). Hybrid prun-

ing: Towards precise pointer and taint analysis. In In-

ternational Conference on Detection of Intrusions and

Malware, and Vulnerability Assessment, pages 1–22.

Springer.

Deshane, T., Shepherd, Z., Matthews, J., Ben-Yehuda, M.,

Shah, A., and Rao, B. (2008). Quantitative compari-

son of Xen and KVM. Xen Summit, Boston, MA, USA,

pages 1–2.

Enck, W., Gilbert, P., Han, S., Tendulkar, V., Chun, B.-

G., Cox, L. P., Jung, J., McDaniel, P., and Sheth,

A. N. (2014). Taintdroid: an information-ﬂow track-

ing system for realtime privacy monitoring on smart-

phones. ACM Transactions on Computer Systems

(TOCS), 32(2):1–29.

Ho, A., Fetterman, M., Clark, C., Warﬁeld, A., and Hand,

S. (2006). Practical taint-based protection using de-

mand emulation. In Proceedings of the 1st ACM

SIGOPS/EuroSys European Conference on Computer

Systems 2006, pages 29–41.

Kemerlis, V. P., Portokalidis, G., Jee, K., and Keromytis,

A. D. (2012). libdft: Practical dynamic data ﬂow

tracking for commodity systems. In Proceedings of

the 8th ACM SIGPLAN/SIGOPS conference on Vir-

tual Execution Environments, pages 121–132.

Kiperberg, M. (2021). Preventing malicious communica-

tion using virtualization. Journal of Information Se-

curity and Applications, 61:102871.

Kiperberg, M., Yehuda, R. B., and Zaidenberg, N. J. (2020).

Hyperwall: A hypervisor for detection and prevention

of malicious communication. In International Confer-

ence on Network and System Security, pages 79–93.

Springer.

Lawton, K. P. (1996). Bochs: A portable pc emulator for

unix/x. Linux Journal, 1996(29es):7–es.

Leon, R. S., Kiperberg, M., Zabag, A. A. L., Resh, A., Al-

gawi, A., and Zaidenberg, N. J. (2019). Hypervisor-

based white listing of executables. IEEE Security &

Privacy, 17(5):58–67.

Machiry, A. (2017). The need for extensible and conﬁg-

urable static taint tracking for c/c++. https://machiry:

github:io/blog/2017/05/31/static-taint-tracking.

Oracle (Accessed Nov. 2022). VirtualBox. https://www.

virtualbox.org/.

Seshadri, A., Luk, M., Qu, N., and Perrig, A. (2007).

Secvisor: A tiny hypervisor to provide lifetime ker-

nel code integrity for commodity oses. In Proceedings

of twenty-ﬁrst ACM SIGOPS symposium on Operating

systems principles, pages 335–350.

Shinagawa, T., Eiraku, H., Tanimoto, K., Omote, K.,

Hasegawa, S., Horie, T., Hirano, M., Kourai, K.,

Oyama, Y., Kawai, E., et al. (2009). Bitvisor: a

thin hypervisor for enforcing i/o device security. In

Proceedings of the 2009 ACM SIGPLAN/SIGOPS in-

ternational conference on Virtual execution environ-

ments, pages 121–130.

Sibai, F. N. (2008). Evaluating the performance of sin-

gle and multiple core processors with PCMARK® 05

and benchmark analysis. ACM SIGMETRICS Perfor-

mance Evaluation Review, 35(4):62–71.

Slowinska, A. and Bos, H. (2009). Pointless tainting? eval-

uating the practicality of pointer tainting. In Proceed-

ings of the 4th ACM European conference on Com-

puter systems, pages 61–74.

Venkataramani, G., Doudalis, I., Solihin, Y., and Prvulovic,

M. (2008). Flexitaint: A programmable accelerator

for dynamic taint propagation. In 2008 IEEE 14th

International Symposium on High Performance Com-

puter Architecture, pages 173–184. IEEE.

VMware (Accessed Nov. 2022a). VMware ESXi. https:

//www.vmware.com/il/products/esxi-and-esx.html.

VMware (Accessed Nov. 2022b). VMware Work-

station Pro. https://www.vmware.com/products/

workstation-pro.html.

wfeldt (2022). libx86emu. https://github.com/wfeldt/

libx86emu.

Xue, L., Qian, C., Zhou, H., Luo, X., Zhou, Y., Shao, Y.,

and Chan, A. T. (2018). Ndroid: Toward tracking

information ﬂows across multiple android contexts.

IEEE Transactions on Information Forensics and Se-

curity, 14(3):814–828.

Yan, L. K. and Yin, H. (2012). {DroidScope}: Seam-

lessly reconstructing the {OS} and dalvik semantic

views for dynamic android malware analysis. In 21st

USENIX security symposium (USENIX security 12),

pages 569–584.

You, I. and Yim, K. (2010). Malware obfuscation tech-

niques: A brief survey. In 2010 International con-

ference on broadband, wireless computing, communi-

cation and applications, pages 297–300. IEEE.

Zimmer, R. (2009). Hale,“UEFI: From Reset Vector to Op-

erating System,” Chapter 3 of Hardware-Dependent

Software.

ICISSP 2023 - 9th International Conference on Information Systems Security and Privacy

198