Received September 16, 2019, accepted November 7, 2019, date of publication November 14, 2019,

date of current version December 26, 2019.

Digital Object Identifier 10.1109/ACCESS.2019.2953511

Leveraging WebAssembly for Numerical

JavaScript Code Virtualization

SHUAI WANG 1,2, GUIXIN YE1,2, MENG LI1,2 , LU YUAN 1, ZHANYONG TANG 1,2 ,

HUANTING WANG1,2, WEI WANG 1,2, FUWEI WANG 1,2, JIE REN 3,

DINGYI FANG1,2, AND ZHENG WANG 4,5

1School of Computer Science and Technology, Northwest University, Xi’an 710127, China

2Shaanxi International Joint Research Centre for the Battery-Free Internet of Things, Xi’an 710127, China

3School of Computer Science, Shaanxi Normal University, Xi’an 710062, China

4School of Computing, Lancaster University, Lancaster LA1 4YW, U.K.

5School of Computer Science and Technology, Xi’an University of Posts and Telecommunications, Xi’an 710121, China

Corresponding author: Fuwei Wang (wfw@nwu.edu.cn)

This work was supported in part by the NSFC under Grant 61672427 and Grant 61672428, in part by the International Cooperation Project

of Shaanxi Province under Grant 2019KW-009 and Grant 2017KW-008, in part by the Key Research and Development Project of Shaanxi

Province under Grant 2017GY-191, in part by the Shaanxi Science and Technology Innovation Team Support Project under Grant

2018TD-O26, and in part by the Ant Financial through the Ant Financial Science Funds for Security Research.

ABSTRACT Code obfuscation built upon code virtualization technology is one of the viable means

for protecting sensitive algorithms and data against code reverse engineering attacks. Code virtualization

has been successfully applied to programming languages like C, C++, and Java. However, it remains an

outstanding challenge to apply this promising technique to JavaScript, a popular web programming language.

This is primarily due to the open visibility of JavaScript code and the expensive runtime overhead associated

with code virtualization. This paper presents JSPro, a novel code virtualization system for JavaScript.

JSPro is the first JavaScript code obfuscation tool that builds upon the emerging WebAssembly language

standard. It is designed to provide more secure code protection but without incurring a significant runtime

penalty, explicitly targeting numerical JavaScript kernels. We achieve this by first automatically translating

the target JavaScript code into WebAssembly and then performing code obfuscation on the compiled

WebAssembly binary. Our design has two advantages over existing solutions: (1) it increases the code reverse

entering complexity by implementing code obfuscation at a lower binary level and (2) it significantly reduces

the performance impact of code virtualization over the native JavaScript code by using the performance-tuned

WebAssembly language. We evaluate JSPro on a set of numerical JavaScript algorithms widely used in

many applications. To test the performance, we apply JSPro to four mainstream web browsers running on

three distinct mobile devices. Compared to state-of-the-art JavaScript obfuscation tools, JSPro not only

provides stronger protection but also reduces the runtime overhead by at least 15% (up to 38.2%) and the

code size by 28.2% on average.

INDEX TERMS Code obfuscation, javascript, webassembly, security, performance.

I. INTRODUCTION

Unauthorized reverse engineering and modification of code is

a major concern for software vendors [1]–[3]. Such activities

are often associated with malicious behaviors such as cheat-

ing, unauthorized use of software, or bypassing security and

authentication mechanisms.

By making sensitive code hard to be traced and ana-

lyzed, code obfuscation offers a solution for unauthorized

The associate editor coordinating the review of this manuscript and

approving it for publication was Chi-Yuan Chen .

code reverse engineering [4], [5]. In recent years, code vir-

tualization [6], [7] is emerging as a promising method for

implementing code obfuscation. This technique translates

the native instructions into bespoke virtual instructions to

increase the strength of code obfuscation [8], [9]. The idea

behinds code virtualization is that by forcing the attacker

to work on a new, unfamiliar instruction set, one can sig-

nificantly increase the difficulties of launching code reverse

engineering attacks [4].

Despite code virtualization techniques have been success-

fully applied to native program binary [10] and program

VOLUME 7, 2019 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see http://creativecommons.org/licenses/by/4.0/ 182711

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

languages like C [11], C++ [12] and Java [13], it remains

unclear how this promising technology can be used for

JavaScript, a popular programming language for web-based

applications. The challenge mostly comes from two aspects.

First, JavaScript is an interpreted language, and applica-

tions written in JavaScripts are often shipped in the form

of plain source code. As a result, prior works on JavaScript

code obfuscations [14] typically perform at the source code

level, and the obfuscated program will be released again

as JavaScript source code. However, the rich semantics at

the source code level provide much information needed for

reconstructing a simpler yet semantically equivalent code ver-

sion where reserve engineering can be easily performed [15].

This drawback limits the strength of protection a code

obfuscation can provide for JavaScript. Secondly, because

JavaScript code is interpreted and just-in-time compiled for

execution, the additional code associated with code virtual-

ization can lead to significantly runtime overhead [16]. Such

overhead often leads to poor user experience for interactive

and computation-intensive applications. This prevents code

virtualization to be adopted for JavaScript although it just

needs much attention for code protection as other program-

ming languages.

This work aims to unlock the potential of code virtualiza-

tion on JavaScript, and it aims to do so without paying the cost

of significant runtime overhead. Our work is enabled by the

recently proposed WebAssembly standard [17]. WebAssem-

bly is a new type of code in binary instruction format,

and it is widely supported by and built into major web

browsers including Firefox, Chrome, Safari and Microsoft

Edge. Thanks to the ahead-of-time compilation feature [18],

WebAssembly can run at nearly native speed by taking advan-

tages of hardware features that are commonly available on

modern computing devices.

The performance-tuned and ahead-of-time compiled

WebAssembly brings in two potential benefits over prior

methods that solely perform code obfuscation at the

JavaScript source code level. Firstly, WebAssembly is sup-

ported by major web browser vendors. This means that we can

translate the target JavaScript code into WebAssembly to per-

form code obfuscation at the compiled binary. As code obfus-

cation is done at a lower level instead of at the source code,

this increases the difficulty for code analysis [19]. Secondly,

the heavily optimized WebAssembly code can amortize the

overhead brought by code virtualization, resulting in a code

version that has only modest runtime overhead compared

to the vanilla JavaScript implementation. The saving in the

running time is essential for removing the barriers of applying

code virtualization on JavaScript code.

However, translating this high-level idea into a prac-

tical system is non-trivial because of two specific chal-

lenges. Firstly, JavaScript uses JIT compilation to compile the

source code while WebAssembly uses AOT pre-compilation.

Since they work at different layers of the runtime software

stack, we need to have a way to automatically translate the

JavaScript code into WebAssembly and to seemingly switch

between the two different execution modes during runtime.

Secondly, JavaScript is a weakly and dynamically typed lan-

guage, i.e., the type of data and variables can change dynami-

cally during execution time [20]. By contrast, WebAssembly

is a strongly typed language and requires the data type to

be known at compile time. As a result, any code translation

scheme from JavaScript to WebAssembly must be to ensure

the type inferring process is automatic and precise.

This paper presents JSPro, a novel code virtualization

system for JavaScript code. JSPro is the first JavaScript

code obfuscation scheme built upon the recently proposed

WebAssembly standard. It is designed to specifically tar-

get the computation-intensive numerical JavaScript kernels,

which are commonly available in many JavaScript applica-

tions including image processing, cryptography and gam-

ing. When implementing JSPro, we proposed a set of new

methods, analysis and algorithms to overcome the afore-

mentioned challenges for using WebAssembly to protect

JavaScript code. Specifically, We divide the JavaScript code

into computational code and DOM code. The computational

code is virtualized and stored in a WebAssembly file. When

running the protected JavaScript code, the WebAssembly file

is first loaded to provide API functions. Then the DOM code

invokes the WebAssembly API to execute the computational

code. It’s to note that we don’t virtualize the computational

JavaScript code whose parameters contain object type. The

reason is that this kind of code virtualization will increase the

time cost dramatically. Furthermore, we probably need to use

more policies to ensure the translation correctness between

object type operation with no object type operation. When

encountering this case, we apply inline assembly to translate

the code to WebAssembly.

We evaluate JSPro by applying it to 10 widely used

numerical JavaScript kernels on four mainstream web

browsers including Chrome, Firefox, Safari and Microsoft

Edge. Our testing platforms including three distinct mobile

devices where response time is a key constraint. Compared

to state-of-the-art commercial JavaScript obfuscation tools,

JSPro provides stronger code protection, and it achieves this

by delivering at least 15% (up to 38.2%) faster running time

with an average 28.2% reduction in the code size.

The key contribution of this paper is a novel code virtu-

alization system for JavaScript built on WebAssembly. Our

work demonstrates that by carefully exploiting WebAssem-

bly, one can build a code obfuscation scheme that provides

strong code protection for JavaScript without introducing

significant runtime overhead. We hope our work can encour-

age further work in protecting JavaScript applications against

code reverse engineering.

II. BACKGROUND

A. JAVASCRIPT SECURITY AND PERFORMANCE

JavaScript and web applications often suffer from injection-

based attack [21]. At the same time, there is another issue,

the accessibility of the application specific code of the

applications. To prevent piracy or at least make it more

182712 VOLUME 7, 2019

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

FIGURE 1. We show the protection performance results of four types of

obfuscation methods focus on code obfuscation. The optimum result is

that the protected code run less time than native C, and the size is smaller

than the source code. The rectangular area in the figure is our design goal.

difficult, we often use encryption and obfuscation tools to

keep JavaScript code safe [22]. Code encryption usually

encrypts the code in the form of a string and then executing

through the eval function. The main idea of code obfuscation

is to convert the source code into a functionally equivalent

form, but it is difficult to be understood. According to the

purpose, we can category the obfuscation into the following

forms, 1. Layout obfuscation, 2. Name obfuscation 3. Data

obfuscation 4. Control flow obfuscation [23]. As an interpre-

tative language, all these obfuscation methods will seriously

affect the JS running performance. As shown in Figure 1,

the traditional obfuscation algorithm will increase the run-

time and size expansion of the program.

B. WEBASSEMBLY

In modern browsers, like Chrome,Firefox,Edge,

or Safari, the code is interpreted and executed by the

JavaScript engine, which only runs JavaScript. Unfortunately,

JavaScript is not ideal for every task we want to perform.

WebAssembly defines a text format that will be rendered

when developers view the source of a WebAssembly module

with any development tool. It is a binary instruction format

for a stack-based virtual machine. WASM is designed as a

portable target for compilation of high-level languages like

C/C++/Rust so that it could support the deployment of

client and server applications on the web [17]. As mentioned,

obfuscation and encryption of JavaScript source code are easy

to be cracked, so we use WebAssembly to rewrite instruction

for numerical JavaScript protection. Compared to JavaScript

source code, WebAssembly code is more difficult in semantic

understanding. Furthermore, WebAssembly has better perfor-

mance in running time, so we can conclude that JS protection

with WebAssembly can speed up code execution while reduc-

ing the size of the protected code.

III. THE THREAT MODEL

Our work aims to protect JavaScript code against code reverse

engineering attacks. In this work, we assume that the adver-

sary can launch the attack from a malicious host and has

access to sophisticated tools for tracking and analyzing the

program behaviors. This is a reasonable assumption as many

of the JavaScript applications run on a client device (e.g.,

a web browser). Our threat model assumes the attacker has

access to the target JavaScript code and can locate, copy and

FIGURE 2. The Fast Fourier Transform (FFT) function is applied to a

random data set, and which is used to evaluate the performance and size

increasement.

modify the code. We also assume the attacker can intervene

in the execution of the JavaScript host, e.g., a web browser.

This can be achieved by running the JavaScript code in a

modified open-source web browser. We note that to launch

a code reverse engineering attack in our scenario will require

the attacker to understand the logic of the target application

through static or dynamic code analysis.

Protecting JavaScript code from such an environment is

highly challenging as the attacker has access to the code

and an unprotected execution environment. This work aims

to increase the difficulties of tracing and understanding the

target program’s logic.

IV. MOTIVATING EXAMPLES

Generally, the C program not only runs faster than JavaScript

but also has a smaller size. It can be illustrated in Figure 1

that presents the comparison results. We take the C code

in Figure 2as an example. The gray dot line in Figure 1 shows

the run time, and the blue dot line shows the size of this

example. As can be seen, the cost values are all lower than that

of JavaScript execution shown as the histograms. The obfus-

cated code size are almost identical is because the garbage

instructions dominate the obfuscated code size. Since garbage

code does not get executed, it does not affect the running

time; but due to the difference in security strength, we observe

different running time between 2-Js-Online and 3-Decent-

Mess. The combination of these two figures illustrates that

exist obfuscation methods applied to JavaScript protection

VOLUME 7, 2019 182713

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

FIGURE 3. We give an example of a de-obfuscated code snippet. It shows

that the adversary could crack classic JavaScript obfuscation method.

After careful analysis and review of obfuscation data, it appears that the

Name Obfuscation method is used from lines 1to 4, the Control Flow

Flattening method and Junk code method are used from lines 9to 21, the

String Transfer and Split method are used from lines 23 to 26. Finally,

we can find that _0xd210[0] is the encryption key.

would actively expand the code volume and increase running

time consumption.

Take another example in Figure 3, and it shows that the

obfuscation code of the file AES.js have concise param-

eters and variable names, which is difficult to understand.

However, after reconstructing the name, as shown in Figure 3,

we can easily distinguish the position of the encryption key.

Thanks for the code semantics, even for larger, more complex

programs, we also can recover sensitive code elements within

an acceptable timeframe for those JavaScript source level

obfuscation. These obfuscation mechanisms that are running

on JavaScript source code level are ineffective and easily

evaded.

The two limitations posed by de-obfuscation adversaries

motivate us to revisit the research of protection using a

new method. We also expect that this method would race

the run and reduce the code size. Furthermore, it is best

to offer non-source code level protection. To satisfy the

above requirements, we may then set our sights on the

WebAssembly.

V. SYSTEM OVERVIEW

Our virtualization-based approach, as depicted in Figure 4,

is entirely automated. As we know, WebAssembly does not

currently support manipulation of DOM objects in JavaScript.

JSPro separates the code of all non-calculation classes

FIGURE 4. The overview of JSPro system framework. It shows that a

given JavaScript is firstly divided into JDOM type and the calculation type.

Then JSPro aims to translate the calculation type into the virtualization

code. JSpro draw out the interactive DOM and the virtual interpreter

interactive each other using share stream.

named JDOM in target JS code, allowing the separated JDOM

operations and VM interpreter interactions to be implemented

in shared memory so that our approach can reduce the number

of interaction. For a given input JavaScript, the symbolic

execution is used to extract the JDOM interactions. In this

way, a pure numerical application could be easily virtual-

ized. Further, we design virtual instructions as non-separable

atomic operations (similar to assembly instructions), in order

to enable virtual instructions to simulate JavaScript opera-

tions, we will split JavaScript code. After these operations

are encoded and virtualized, the interpreter could start to

perform instructions. However, if the input.js contains

several JDOM operations, the numerical code still needs to

interact with the shared stream.

VI. IMPLEMENTATION DETAILS

In this paper, we implement the virtualization process by

stack virtual machine [24]. If we utilize VM to simulate the

normal execution of the program, it is necessary to build

the structure of the stack and register in the WebAssem-

bly environment. Similar to other virtualization-based code

protection methods, the interpreter uses a loop statement

to implement the scheduling process. As described above,

according to the function of input JavaScript, the code is

divided into the JDOM type and calculation type. JDOM type

contains JavaScript specific functions such as string process-

ing, attributes, and so on. Calculation type includes simple

numerical operations. Our system JSPro does not virtualize

JDOM type code using WebAssembly. As Figure 4shows the

two parts of the code interact by sharing memory.

A. SPLIT, VIRTUALIZE AND ENCODE INSTRUCTIONS

Typical code virtualization constantly utilizes native binary

instructions, which have basic operational characteristics.

Different from common compiled programs, JavaScript

applications are textual code with syntax attributes. Due to

JavaScript does not hold the atomic properties of native oper-

ation instructions, it is difficult to be virtualized comparing to

classic binary code. So how to virtualize the JavaScript code?

The solution is to realize the special split conversion of the

182714 VOLUME 7, 2019

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

FIGURE 5. We take an example of the instruction segmentation and the

process of virtualization. Due to the text attribute of JavaScript,

the program state should be split firstly and then construct the

instruction, which is different from C/C++ type.

target code, destroy the readable syntax attributes, extract the

intermediate code with the characteristics of atomic opera-

tion, and then design the corresponding virtual instructions

and processing functions. Finally, the virtualization opera-

tion is accomplished through instruction encoding. As shown

in Figure 5, we will specify the virtualization process of

JavaScript code with a simple example.

1) SPLIT THE INSTRUCTIONS

As shown in Figure 4Step 1

, we show a simple example

in Figure 5to illustrate why we need to split JavaScript. The

expression “q=a+b” is a simple text, rather than adding

semantics to JavaScript. So this expression first needs to

be altered to an intermediate code sequence, which can be

restored by a set of atomic operations. To achieve this goal,

we extract abstract syntax trees from the input JavaScript

code and split each statement to realize the separation of

operands and operators. Note that in program loop statements

and condition statements, we need to insert branch tags to

indicate which branch to execute or whether to end the loop.

After that, we finally got the atomic instructions (IR) set and

complete instructions split.

2) VIRTUALIZE THE INSTRUCTIONS AND DESIGN THE

HANDLES

To accomplish the virtualization of IR,JSPro offers

three kinds of virtual instructions, Data transfer instruc-

tion, Control transfer instruction and Operation statement

instruction. As shown in Figure 6, data transfer instruc-

tions are designed to transfer variable value to register or

VarList which is contained in VMcontext. As Con-

trol transfer instruction is designed for replacing branch

tags (‘‘ifjmp’’,‘‘elsepart’’ and ‘‘endif’’ in Figure 5)

which is inserted into IR.Operation statement is designed for

mapping symbol of operation.For example, we use ‘‘add’’

to express ‘‘+’’ in Figure 5. Handler is a component for

restoring semantics. We design handler corresponding to the

virtual instruction. For example, for the virtual instruction

‘‘lod_r’’ in Figure 5, we design handler to load variable

value from register. For the virtual instruction ‘‘lod_v’’,

we design handler to load variable value from VarList.

FIGURE 6. The execution process of the protected code, DOM operation

are not virtualized and JSPro separate these codes. And the VM will

interact with DOM using share stream. The number indicates the execution

step sequences.

Algorithm 1 Virtual Interpreter Scheduling Algorithm

1: function DispatchJSVMP

2: InitVMcontext

3: bytecode Fetch(VMdata)

4: while bytecode! = END do

5: HandlerNum Decode(bytecode)

6: if HandlerNum == ret]then

7: return STA.pop()

8: end if

9: DoHandler(HandlerNum)

10: end while

11: return result

3) ENCODE THE INSTRUCTIONS

As shown in Figure 4Step 2

, after completing the virtual-

ization, we design a set of mapping rules to encode the virtual

instructions. To be precise, rules are defined as a type of driver

data like ‘‘03 01’’ in Figure 5that can be used to get and run

instructions. In the encoding process, the virtual instructions

are divided into operation codes and operands to distinguish

different registers or immediate data. Finally, JSpro uses

these bytecodes instead of each virtual instruction, and these

bytecodes will be saved in the VMdata as part of the virtual

interpreter.

B. DESIGN OF VIRTUAL MACHINE PROTECTION BASED

ON WEBASSEMBLY

After splitting the JavaScript statement and claiming a custom

VMdata, as shown in Figure 4step 3

, we need to design

the virtual machine to perform the functions represented by

the VMdata. As shown in Figure 6, the virtual machine inter-

preter of JSPro contains four components: Dispatcher,

VMdata,Handler and VMconext.

When design virtualization protection method, semantics

regularly hid in the bytecode program at runtime, so it is

very important for the virtual interpreter to exactly explain

the semantics and restore the function of the program. Next,

we briefly describe the primary workflow of the virtual

machine.

As shown in Algorithm 1, the browser executes the

target script file, and once the protected numerical script is

VOLUME 7, 2019 182715

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

satisfied, the virtual interpreter entry function will take

over the process and goes into the interpreter’s workflow.

After that, the virtual execution environment is initialized.

VMcontext will be utilized to complete the continuation

of the execution context. After entering the decoding cycle,

the scheduler center fetches bytecode one by one from

VMdata, then decodes it and searches for the corresponding

Handler according to the mapping table. Once achieving

decoding all the bytecode, it returns directly, exits the virtual

interpreter, or returns the value of the stack.

1) VMCONTEXT

The classic binary virtual interpreter run in the OS native

layer, which makes the stack and register could participate in

the computing process. With these characteristics, the inter-

preter only needs a part of memory to map the real local

registers. Our approach implements virtual interpreter logic

of JavaScript code by Clanguage. In other words, we need

to stimulate the OS running environment in the JavaScript

source code level. As Figure 6shows, VMcontext is mainly

composed of three parts, namely Stack, Registers and VarList.

In general, Registers store temporary variables and VarList is

a memory-like pool of variable.

2) VMDATA AND HANDLER

VMdata is a custom bytecode generated based on virtual

instruction that can represent the execution logic of the origi-

nal program. Handler is explanation of a custom VMdata

that can be used to restore the function of the program through

instructions.

We implement the entire virtual machine interpreter in

Clanguage and generate WASM through EMSCRIPTEN

compilation.The design of the Handler is described in

section VI-A.2. According to the virtual mapping relation-

ship, the corresponding Handler is designed to restore the

semantics of bytecode stored in VMdata. An example of the

Handler is shown in Figure 7.

3) DISPATCHER

As shown in Figure 6, the Dispatcher is a key part of

the virtual interpreter. It plays an important role in how to

dispatch the corresponding Handler for execution. First,

the Dispatcher gets the bytecode in VMdata based on

VPC (program counter). Besides, it tries to execute the cor-

responding Handler. Lastly, the process loops until all

bytecode have been explained, the Dispatcher will invoke

the Handler to restore program function based on VMdata.

A simple example of the structure of the Dispatcher can

be found in Figure 7.

4) COMPILING AND CALLING THE VIRTUAL INTERPRETER

As shown in Figure 4part 4

, after finishing the design of

the virtual interpreter, we need to compile it into WebAssem-

bly. Figure 8shows the process of compiling and loading

the virtual machine. Compile the Cfile containing the vir-

tual machine protection program into the WASM file with

FIGURE 7. JSPro gives code examples of Dispatcher and Handler,

which illustrates the fundamental structure.

FIGURE 8. The process of compiling and loading the WebAssembly

module.

EMSCRIPTEN. At the same time, the glue code for call-

ing WASM is also generated. Finally, add the load state of

the glue code, and add the call statement and the param-

eter transfer statement of the virtualization protection pro-

gram in the original file. So the original program can suc-

cessfully invoke the virtualization protection of JavaScript

code.

C. SHARED STREAM FOR DOM INTERACTION

As shown in Figure 4step 5

, for scripts containing DOM

operations, we will keep the DOM operation part in the original

JavaScript, and the calculation part will be extracted and pro-

tected by virtualization. So we need to consider how the DOM

element stored in JavaScript interacts with the calculation part

stored in WASM after virtualization to ensure the correctness

of the program. In this article, we solve this problem by using

shared stream. WebAssembly can apply for a continuous

memory address, we regard it as a shared stream. Specifically,

when the computation in the virtual interpreter needs to be

processed by the DOM element, we call the WebAssembly

API functions so that deliver variables stored in DOM element

to shared stream. Similarly, when the calculated value in the

interpreter needs to be used by the DOM element, the value is

passed to the shared stream, and the DOM element can obtain

the value in the shared stream by calling the corresponding

API.

VII. AN EXAMPLE

In this section, we utilize a short JavaScript code snippet as

an example to illustrate how JSPro virtualizes the original

code and explain how it works, as shown in Figure 6and 9.

182716 VOLUME 7, 2019

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

FIGURE 9. JSPro takes JavaScript code snippet as an example to

illustrate code virtualization and execution process in memory after

protection.

A. JAVASCRIPT CODE VIRTUALIZATION

As mentioned in section VI,JSPro mainly protects the

computation type code, we first extract the calculation part

of the code snippet and then virtualize it. Figure 5shows the

process of virtualization. As we known, JavaScript code will

not be compiled ahead of time, which leads to non-semantics

nature of the source code. Therefore, unlike traditional virtual

protection methods, our method needs to split the instructions

first. The specific virtualization process is as follows. First,

we separate the computational JavaScript code into atomic

operations based on the abstract syntax tree of the JavaScript

code. We then translate the atomic operations to IR for

getting the control flow. Finally, according to the control flow,

we use IR to simulate each atomic operations for achieving

equivalent translation. It’s to note that to ensure the correct-

ness of the code execution after translation, we use JavaScript

to control the execution of the whole program. When running

the virtualized computational JavaScript code, the control

flow will be transformed to the VM which is implemented by

WebAssembly.

B. RUNTIME EXECUTION

Execution of the protected code is illustrated in Figure 6.

As mentioned above, our protect method to neglect the

DOM part of JavaScript, and using virtual interpreter entry

function instead of the calculation part after virtualization.

During implementation, when executing the virtualization

part, the code segment enters the virtual interpreter by call-

ing the virtual interpreter entry function, then transmits the

digital variable to shared stream following step 1

. After

that, following step 2

and 3

, the Dispatcher starts

loading binary codes one by one from VMdata. When the

binary codes representing the Handler number are loaded,

the appropriate Handler is selected for semantic restora-

tion, as shown in step 4

. In the process of semantic

reduction, the storage of intermediate results and the vari-

able transfer between different Handlers are accomplished

through VMcontext as shown in step 5

and 6

. When

the digital variable values received by DOM elements are

needed in the process of scheduling Handler’s computa-

tion, incoming values only can be obtained by accessing

the shared stream through step 7

. After the calculation

is done, the result will be passed to the shared stream for

DOM elements to use, as shown in step 8

and 9

. The

Dispatcher will load all of the bytecodes in VMdata and

restored semantics by loop step 3

. When all the bytecodes

in VMdata are parsed, manually garbage collection of vari-

ables in WebAssembly, and then following step 10

to exit

the virtual interpreter.

VIII. EVALUATION

A. EVALUATION SCENARIOS AND SETUP

JSPro can be evaluated in two aspects: performance and

security. We will analyze its performance on three differ-

ent mobile devices and four different browsers. Table 1

shows the four browsers and the corresponding operating

system and hardware specifications. Table 2summarizes the

specifications of the three mobile devices. In this section,

we select some valid test cases from the research [25]. More-

over, these test cases must follow these principles: 1

Cover

a wide variety of applications. 2

Test cases are mainly

related to numerical calculation. In order to obtain a rela-

tively objective conclusion, we compared several methods

that combined mainstream encryptions and obfuscation tools.

Specifically, we chose four common JavaScript protection

tools for comparison,including: (1) Jsonline,b10, (2)

Decent Mess Up,b8, (3) Js-Obfuscator,b9 and

(4) Obfuscator,b7. The results of the performance tests

are illustrated below in terms of code expansion and time

extension.

B. PERFORMANCE EVALUATION

In this section, we will show the time and space overhead of

the test cases before and after protection.

1) TIME OVERHEAD COMPARISON

To evaluate the performance of five kinds of protec-

tion methods, we experimented with benchmark instances

(selected test cases) on different browsers and different

mobile devices. Before evaluation, each benchmark instance

is firstly protected by JSPro and other four traditional

methods respectively. Then the protected instances and the

original instance run five times at each specific browser

or mobile device. We calculate the average runtime of

five tests as the performance. (1) Experimental results on

different browsers are shown in Figure 10. It shows that

the existing protection methods will lead to significant

decrease in system performance. On the contrary, experimen-

tal results on benchmark instances show that JSPro per-

forms well, in some cases, the performance even better than

VOLUME 7, 2019 182717

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

TABLE 1. Browser, operating system and hardware specs.

TABLE 2. Mobile device and browser specs.

FIGURE 10. This figure shows the performance under different browsers that contain 10 cases. We can see that there are certain differences in

performance of test cases under different browsers. However, traditional protection methods will cause obvious performance loss in different browsers,

while our protection method JSPro will basically not cause performance loss, or even improve performance in some cases.

source code. (2) Further study on mobile devices with limited

resources reveal that the performance of traditional protec-

tion methods is significantly declining, as shown in Fig-

ure 11. However, JSPro’s performance is basically consis-

tent with source code, and even better than pre-virtualization,

resulting in overall performance improvements. In particular,

we test with WebAssembly-enabled browsers like Chrome,

Firefox,Safari and Microsoft Edge four kinds of

browsers. We also choose three kinds of devices including

Vivoxplay6l,Iphone8, and Xiaomi mix2 to evalu-

ate the performance. In different browser performance (exe-

cution time) tests, the best performance improvement is

42.2%, the worst is 8.5%, and the average performance

improvement is 15.7%. In different mobile devices, the best

performance improvement is 80.1%, the worst is 9.3%, and

the average performance improvement is 38.2%.

2) SIZE CHANGE COMPARISON

Figure 12 shows the comparison of size change. As we all

know, classic code obfuscation always increases the pro-

gram size, it is one of the negative effects. Especially for

devices with limited resources, volume expansion may lead

to requested operation to be not performed, or lead to insuf-

ficient storage space in system. For JSPro, the results

are remarkable, and the size of the virtualized code is the

same as the source code, or even smaller. As seen in the

above experiments, under different conditions, we performed

ten sets of experiments on the size increase of the pro-

tected code. The best size decreased by 61.6%, the worst

size decreased by 1%, and the average size decreased

by 28.2%.

C. SECURITY ASSESSMENT

Obfuscation in this work means making the code hard to

understand and debug. By outlining some of the JavaScript

code and compiled them down to WebAssembly, our

approach makes it difficult to understand the program logic.

This is because it is more difficult to track and understand the

low-level compiled machine instructions than doing that for

the high-level JavaScript. By translating the native machine

instructions to bespoke virtual instructions, our approach

forces the adversary to work on an unfamiliar instruction set.

This further increases the difficulty and efforts of understand-

ing and debugging the code. In order to evaluate the security

of our system JSPro against a known attack, we will show

182718 VOLUME 7, 2019

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

FIGURE 11. This diagram shows the performance under different mobile devices that contain 10 cases. We can see that there are some differences in the

performance of test cases under different mobile devices. However, the performance loss of mobile devices with limited resources of traditional

protection methods is very serious, while our protection method JSPro will not cause performance loss, and even can improve performance in some

cases.

FIGURE 12. This diagram shows size change comparison that contain 10 cases.we can see that traditional protection methods will bring volume

expansion, while our protection method JSPro can achieve smaller volume than the original program.

the reverse-engineered results on cracking tools. The specific

test case is a section of the code in ‘‘Cat load’’, as shown

in Figure 13, this code segment is regular and short, and

has rich calculation process, which makes it easier for us

to compare the effect of reverse analysis. We will analyze

the protection results of encryption, obfuscation and JSPro

respectively when they involve reverse cracks.

1) ENCRYPTION TOOL PROTECTION REVERSE ANALYSIS

Figure 14 (a) shows the result of the target protected code

by ToolJS encryption. For an adversary, if he/she wants to

restore the original code, some analysis tools should be first

used to find the most common encryption method. In this

example, the main structure of this encryption method con-

sists of a decryption function and a section of encrypted

string, and the deciphered string is decoded through the ‘‘eval

()’’ function. Therefore, by modifying the ‘‘eval ()’’ in Fig-

ure 14 (a) to ‘‘console.log ()’’, an adversary can get a string of

compressed states, which can be formatted to the final target

code, as shown in Figure 14 (b). It can be seen that the result is

FIGURE 13. We provide a small code snippet demonstrating the attack

experiment, and three kinds of tools will be used to compare one target

against another.

almost the same as source code as shown in Figure 13 exclude

a partial variable name. The main logic and structure of the

code have been completely restored, so it is insecurity and

easy to be cracked.

As the example tell us: Hiding the ‘‘eval ()’’ function’s

body in the protected code maybe stop debugging the

program, if so, the specific decryption method must be

embedded to the protected code, however, it will increase

VOLUME 7, 2019 182719

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

FIGURE 14. Protected code using ToolJS encryption, we show the result

of the reverse analysis in the attack experiment. As we can see, the main

logic and functions are restored.

extra code size. Therefore, encryption is not an appropriate

choice of JavaScript protection methods to defend an actual

attack.

2) REVERSE ANALYSIS OF OBFUSCATING TOOL

PROTECTION

Js-Online is a kind of typical code protection tool, which

uses a variety of obfuscation rules. The following simply

describe the obfuscation process. As Figure 15 (a) shows,

First, Js-Online extracts DOM element, numeric variables

and string variables. After that, split DOM element and string

variables into multiple substrings, then put them into arrays.

Second, the system uses anonymous functions with four

arrays as parameters to shell the original code segment as

well as replace the DOM elements and variables of the original

code by four arrays. Besides, it also applies control flow

flat method, inserts garbage code and so on to transform the

original code.

Next, we will show attack process details. In this part,

we give a cracked example. Just like other evaluate methods,

we also choose a snippet sample to illustrate the crack pro-

cedure, and which helps to ‘‘simplify complex attack tasks’’.

Reverse to the protection, for the obfuscation method name

obfuscation, multivariate, string transfer and split, we can

based on array parameters and array index which is trans-

fer by anonymous functions to reduction DOM element and

string variables.While the control flow obfuscation is more

complex than the previous obfuscation method, the sequence

of execution hidden in the array of parameters, which requires

according to the index of the corresponding parameters and

branches. The garbage code also can be removed by dynamic

debugging and manual analysis, and the restoration of the

structure takes a certain amount of time. Finally, the reverse

FIGURE 15. Show the result of attack experiment aim to protected code

by JS-Online tool. From (a) to (d) are obfuscation rules used by

JS-Online, they will easily be removed because of its semantic

maintenance. After removed these rules, we get the result of

de-obfuscated which is shown in (e).

analysis result can be successfully obtained as shown

in Figure 15 (b).

3) REVERSE ANALYSIS OF JSPRO PROTECTION

For the application after JSPro protection, there is no way

to get the code segment directly after protection. As shown

in Figure 16, the function content of the target program has

been replaced by a function call. This function should be the

entrance of the virtual interpreter. If an adversary wants to

restore the logic of the target code, it first needs to enter

the virtual interpreter through dynamic debugging. However,

the interpreter’s logic has been translated and converted into

WASM module.

In the analysis process, it is found that the browser does

not support debugging WASM modules and can only display

independent function modules, It is difficult to get suffi-

cient information during the dynamic debugging to enter the

follow-up analysis process.

For the traditional binary code virtualization protection,

there is a semantic-based anti obfuscation method, which

extracts program execution sequence through a dynamic

tracking the program, and further simplifies the code struc-

ture to get the final local code sequence [30]–[32] by the

instruction optimization. However, this method does not

apply to JSPro. Firstly, JSPro needs a combination of

182720 VOLUME 7, 2019

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

TABLE 3. Factor assessment of the effect of protection method on reverse analysis.

FIGURE 16. Analyzing JSPro protection application using Chrome

browser. We can see that the protected code is only contain interpreter

entrance,the content of interpreter cannot be debugged and the readable

code disassembled by WASM is difficult to understand.

WASM and JavaScript, and the environment and language

are different, making it difficult for analysts to track all the

execution paths to obtain a unified instruction sequence. Sec-

ondly, in binary code virtualization protection, the target code

and the interpreter is local x86 instructions, while JavaScript

does not have a one-to-one instruction set corresponding to it

as an explanatory language, so there is no mature simplified

rule. Therefore, the reverse analysis can only draw on the

traditional virtualization protection cracking process. Based

on understanding the basic principle and structure of virtual

machine, the method [33] is used based on the virtual exe-

cution feature, tracking and debugging the target program

repeatedly, collecting the Handler sequence and simplify-

ing the anti obfuscation knot which is close to the target code

by manual analysis and reduction. However, which requires

an attacker to have a certain understanding of the core mecha-

nism of code virtualization protection, and the need to devote

a lot of effort to manual analysis of the simplified code, will

greatly increase the difficulty and cost of reverse analysis.

4) CONTRASTIVE RESULTS OF REVERSE ANALYSIS

These above analyses indicate that some related factors have

an important impact on the protection strength anti-reverse

engineer. We will emphasize to analyze the results shown

in Table 3. As we can see, related factor(1), (4), (5),

(8) are mentioned by stochastic optimization of program

obfuscation [23], related factor(2), (9) are mentioned by

the power of obfuscation techniques in malicious JavaScript

code: A Measurement Study [34]. In addition, related fac-

tor(3), (6), (7) are customized by us where factor(3) means

use encryption algorithm encrypts source code, factor(6)

decomposition and the complexity of computing processes

to reduce readability, and factor(7) add code that does not

execute only reduces the readability of the code.

From the table, we can see that the general encryption

protection has clear decryption of structured information, and

the source code can be decrypted directly, and obfuscation

protection will often combine a variety of protection mea-

sures to reform the structure of the code, and increase the

difficulty of reverse analysis. The two kinds of methods are

mainly the changes in the structure based on the original

target code, and the virtualization protection of JSPro is to

transform the target code into a custom bytecode program

without the features of source code variables and control

structures.

IX. DISCUSSIONS AND LIMITATION

A. SCALABILITY AND VERSATILITY

Our system JSPro focus on approaches that reduce pro-

tection code size and strengthen execution efficiency. Using

instruction virtualization, we construct a framework based

on VM to improve security. As a practical matter, our

approach can be extended to the code including DOM oper-

ation, and the DOM operation code could be obfuscated using

the original method. However, in some specific experiment

designs, we also find that JavaScript code segments including

many DOM objects are not suitable for being translated to

WebAssembly. The intuition is that many DOM operations

may involve a lot of interaction operations with WebAssem-

bly, which results in increasing an execution latency. We will

have an example to describe in details in section IX-B.

B. LIMITATION

In the following section, we discuss the limitation of the

system JSPro concerning DOM operation virtualization and

how they can be overcome using the browser’s kernel opti-

mization. As mentioned above, WebAssembly is designed for

accelerated computation, it is not friendly to support object

type. Considering the JavaScript framework, if it contains

many object types, with the protection of our method, per-

formance improvement will not be as expected. We take

DSP,b31 as an example, which is one of the JavaScript

VOLUME 7, 2019 182721

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

FIGURE 17. Performance of DSP with different protection methods under

different browsers.

FIGURE 18. Performance of DSP with different protection methods under

different mobile devices.

frameworks with the most population on GitHub. We choose

two functions named ‘‘dft’’ (Discrete Fourier Transform) and

‘‘fft’’ (Fast Fourier Transformation) from the DSP to eval-

uate the performance of our method. The functions ‘‘dft’’

and ‘‘fft’’ contain a large number of computational code,

which contributes to evaluate the performance of JSPro.

The combination of Figure 17 and 18 shows the performance

changes of DSP using different protection methods under

different browsers and mobile devices, as Figure 17 shows

traditional obfuscation can cause performance decline after

protection while our method can keep performance basically

unchanged or slight improved. In the best case, it can only

improve 4 %, as Figure 18 shows traditional obfuscation can

cause performance decline after protection but our method

has better performance improvement.

However, compared to code without DOM operations men-

tioned above in section VIII-B.1 and VIII-B.2, the perfor-

mance of DSP after JSPro protection does not meet the

requirement. The next step is to optimize further the kernel

of a browser to solve this problem.

X. RELATED WORK

JavaScript is widely used as an important browser lan-

guage. Since the JavaScript transmission is the source code,

the exposure of the source code in the front-end con-

frontation makes the security very fragile, so the protec-

tion of the JavaScript code has been widely concerned by

the academia and the industry. Multiple commercial protec-

tion systems and platforms provide an integrated JavaScript

code protection, for example, JScrambler [36] is a

mature commercial protection tool that provides a variety of

code protection options to compress JavaScript code, data,

string segmentation coding, structure, variable name obfus-

cation and other protection strategies. It also has simple

anti-debug measures to hinder malicious debugging analy-

sis. JavaScript Obfuscator [37] mainly encrypts and

obfuscate JavaScript code, and improves the protection of

JavaScript code by encoding, encrypting and transferring

strings, obfuscating variable names and inserting garbage

code. However, as described earlier, the powerful debugging

capabilities of the browser reduce the cost of anti obfuscation,

and the obfuscation method based on semantic analysis can

also reduce the cost of obfuscation. On the basis of flat control

flow obfuscation and code encryption [38], JShaman [39]

introduces the polymorphic mutation strategy of JavaScript

code. Each call will automatically mutate and prevent the

code from being dynamically debugged and analyzed. But in

our analysis process, the polymorphism is achieved through

the server returning different versions of the obfuscation

script. So the current front-end obfuscation is based on the

source code.

Recently, community has considered using the idea of

code virtualization to protect programs. VMGuards [40] is

a process-level VM-based code protection system. It designs

two new instruction sets to protect the critical code segments

and the host runtime environment where the VM runs in.

[41] presents a multi-stage code obfuscation method by using

improved code virtualization techniques. The key idea of

this method is to iteratively obfuscate a program many times

by using different interpretations, which increases the diffi-

culty of adversaries to analyze the structure of the original

program. DIVILAR [42] is a virtualization-based protec-

tion scheme to enable self-defense of Android apps against

app repackaging. This is achieved by first using a diversified

virtual instruction set to re-encode an Android app and then

using a specialized execution engine to schedule these virtual

instructions for running the protected app. Condroid [43]

proposes a light-weight Android virtualization solution based

on container technology. It can support multiple Android

containers in a single core environment based on multi-

ple dependent virtual machines. Unlike previous VM-based

approaches, we firstly introduce a code virtualization method

for JavaScript built on WebAssembly, and it can effectively

enhance the protection strength with a reasonable cost of

runtime overhead.

Meanwhile, there are several reverse analysis methods

against virtualization protection. Reference [44] put forward

a kind of statically analyzing the combination of interpreter

and bytecode, reducing virtualization protection intensity.

VMAttack [45] is a de-obfuscation tool for virtualization

packed binaries based on automated static and dynamic anal-

ysis. The complexity of the disassembly view is notably

reduced by analyzing the inner working principles of the

VM layer of protected binaries. Reference [46] proposes a

different approach to the problem that focuses on identifying

instructions that affect the observable behavior of the obfus-

cated code.

182722 VOLUME 7, 2019

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

XI. CONCLUSION

This paper has presented JSPro, a novel code virtualization

approach for JavaScript applications. The proposed method is

able to effectively protect JavaScript sensitive algorithms and

data against reverse engineering attacks by adversaries, based

on WebAssembly virtualized binary code. Furthermore, for

computation-intensive JavaScript applications, JSPro can

significantly reduce the running overhead than start-of-the

arts. JSPro was evaluated on three different mobile devices

and four different browsers, and the experimental results

show that the protected JavaScript applications can achieve

the same performance as the original program and better than

the versions which are protected by other commercial obfus-

cation tools. We also evaluate the security of the JavaScript

applications protected by JSPro through manual reverse

analysis. The analysis results present that JSPro provides

stronger protection than traditional JavaScript obfuscation

tools but without paying the cost of significant runtime over-

head. It is to note that like commercial tools, our method

would decrease the performance when a JavaScript code to

be protected has many DOM or interactive operations. This is

also our future work on how to address this problem based on

the browser engine mechanism.

ACKNOWLEDGMENT

(Shuai Wang and Guixin Ye are co-first authors.)

REFERENCES

[1] C. S. Collberg and C. Thomborson, ‘‘Watermarking, tamper-proofing, and

obfuscation—Tools for software protection,’’ IEEE Trans. Softw. Eng.,

vol. 28, no. 8, pp. 735–746, Aug. 2002.

[2] V. van der Veen, E. Göktas, M. Contag, A. Pawoloski, X. Chen, S. Rawat,

H. Bos, T. Holz, E. Athanasopoulos, and C. Giuffrida, ‘‘A tough call:

Mitigating advanced code-reuse attacks at the binary level,’’ in Proc. IEEE

Symp. Secur. Privacy (SP), May 2016, pp. 934–953.

[3] M. G. Kang, S. McCamant, P. Poosankam, and D. Song, ‘‘Dta++:

Dynamic taint analysis with targeted control-flow propagation,’’ in Proc.

Netw. Distrib. Syst. Secur. Symp., Jan. 2011, pp. 1–14.

[4] J. Bringer and H. Chabanne, ‘‘Code reverse engineering problem for iden-

tification codes,’’ IEEE Trans. Inf. Theory, vol. 58, no. 4, pp. 2406–2412,

Apr. 2012.

[5] M. Wu, Y. Zhang, and X. Mi, ‘‘Binary protection using dynamic fine-

grained code hiding and obfuscation,’’ in Proc. 4th Int. Conf. Inf. Netw.

Secur., Dec. 2016, pp. 1–8.

[6] E. Bugnion, S. Devine, M. Rosenblum, J. Sugerman, and E. Y. Wang,

‘‘Bringing virtualization to the x86 architecture with the original VMware

workstation,’’ Acm Trans. Comput. Syst., vol. 30, no. 4, Nov. 2012,

Art. no. 12.

[7] A. Averbuch, M. Kiperberg, and N. Zaidenberg, ‘‘Truly-protect: An effi-

cient VM-based software protection,’’ IEEE Syst. J., vol. 7, no. 3,

pp. 455–466, Sep. 2011.

[8] K. Kuang, Z. Tang, X. Gong, D. Fang, X. Chen, and W. Zheng, ‘‘Enhance

virtual-machine-based code obfuscation security through dynamic byte-

code scheduling,’’ Comput. Secur., vol. 74, pp. 202–220, May 2018.

[9] X. Cheng et al., ‘‘DynOpVm: VM-based software obfuscation with

dynamic opcode mapping,’’ in Proc. Int. Conf. Appl. Cryptogr. Netw. Secur.

Cham, Switzerland: Springer, 2019.

[10] Y. Dong, J. Mao, H. Guan, J. Li, and Y. Chen, ‘‘A virtualization solution

for BYOD with dynamic platform context switching,’’IEEE Micro, vol. 35,

no. 1, pp. 34–43, Jan. 2015.

[11] S. Jansen and A. J. Mcgregor, ‘‘Static virtualization of C source code,’’

Softw.-Pract. Exper., vol. 38, no. 4, pp. 397–416, 2010.

[12] S. Vinco, V. Guarnieri, and F. Fummi, ‘‘Code manipulation for virtual

platform integration,’’ IEEE Trans. Comput., vol. 65, no. 9, pp. 2694–2708,

Sep. 2016.

[13] F. Tip, P. F. Sweeney, and C. Laffra, ‘‘Extracting library-based java appli-

cations,’’ Commun. ACM, vol. 46, no. 8, pp. 35–40, 2003.

[14] Z. Y. Wang and W. M. Wu, ‘‘Technique of javascript code obfuscation

based on control flow tansformations,’’ Appl. Mech. Mater., vols. 519–520,

pp. 391–394, Feb. 2014.

[15] M. Abdelkhalek and A. Shosha, ‘‘JSDES: An automated de-obfuscation

system for malicious JavaScript,’’ in Proc. 12th Int. Conf. Availability, Rel.

Secur., Aug./Sep. 2017, Art. no. 80.

[16] S. Wessel, M. Huber, F. Stumpf, and C. Eckert, ‘‘Improving mobile device

security with operating system-level virtualization,’’ Comput. Secur.,

vol. 52, pp. 207–220, Jul. 2015.

[17] The Web. (2016). WebAssembly.[Online]. Available: https://webassembly.

org

[18] S. Hong, J.-C. Kim, S.-M. Moon, J. W. Shin, J. Lee, H.-S. Oh, and

H.-K. Choi, ‘‘Client ahead-of-time compiler for embedded Java plat-

forms,’’ Softw., Pract. Exper., vol. 39, no. 3, pp. 259–278, 2010.

[19] P. Louridas, ‘‘Static code analysis,’’ IEEE Softw., vol. 23, no. 4, pp. 58–61,

Jul. 2006.

[20] S. Mirshokraie, A. Mesbah, and K. Pattabiraman, ‘‘Guided mutation test-

ing for JavaScript Web applications,’’ IEEE Trans. Softw. Eng., vol. 41,

no. 5, pp. 429–444, May 2015.

[21] A. Barua, M. Zulkernine, and K. Weldemariam, ‘‘Protecting Web browser

extensions from JavaScript injection attacks,’’ in Proc. 18th Int. Conf. Eng.

Complex Comput. Syst., Jul. 2013, pp. 188–197.

[22] C. Curtsinger, B. Livshits, B. Zorn, and C. Seifert, ‘‘ZOZZLE: Fast and

precise in-browser JavaScript malware detection,’’ in Proc. 20th USENIX

Conf. Secur., 2011, p. 3.

[23] H. Liu, C. Sun, Z. Su, Y. Jiang, M. Gu, and J. Sun,‘‘Stochastic optimization

of program obfuscation,’’ in Proc. IEEE/ACM 39th Int. Conf. Softw. Eng.

(ICSE), May 2017, pp. 221–231.

[24] K. Kuang, Z. Tang, X. Gong, D. Fang, X. Chen, T. Xing, G. Ye,

J. Zhang, and Z. Wang, ‘‘Exploiting dynamic scheduling for VM-based

code obfuscation,’’ in Proc. IEEE Trustcom/BigDataSE/ISPA, Aug. 2016,

pp. 489–496.

[25] Kraken. (2017). Kraken Benchmark Suite. [Online]. Available:

http://krakenbenchmark.mozilla.org/

[26] NWU-IRDETO IoT & Info-Sec Joint Lab. (2017). Js-online. [Online].

Available: http://118.89.236.89:60002/login.jsp

[27] BLACKMIAOOL. (2017). Decent Mess Up. [Online]. Available:

http://blackmiaool.com/decent-messup/playground/

[28] Tiago Serafim source code. (2017). Javascript Obfuscator Tool. [Online].

Available: https://javascriptobfuscator.com/

[29] Typecho. (2017). Obfuscator. [Online]. Available: https://obfuscator.io/

[30] B. Yadegari, B. Johannesmeyer, B. Whitely, and S. Debray, ‘‘A generic

approach to automatic deobfuscation of executable code,’’ in Proc. IEEE

Symp. Secur. Privacy, May 2015, pp. 674–691.

[31] Y. Shoshitaishvili, R. Wang, C. Salls, N. Stephens, M. Polino, A. Dutcher,

J. Grosen, S. Feng, C. Hauser, C. Kruegel, and G. Vigna, ‘‘SOK: (State

of) the art of war: Offensive techniques in binary analysis,’’ in Proc. IEEE

Symp. Secur. Privacy (SP), May 2016, pp. 138–157.

[32] B. Yadegari and S. Debray, ‘‘Symbolic execution of obfuscated code,’’

in Proc. 22nd ACM SIGSAC Conf. Comput. Commun. Secur., Oct. 2015,

pp. 732–744.

[33] R. Rolles, ‘‘Unpacking virtualization obfuscators,’’ in Proc. 3rd USENIX

Conf. Offensive Technol., 2009, p. 1.

[34] W. Xu, F. Zhang, and S. Zhu, ‘‘The power of obfuscation techniques in

malicious JavaScript code: A measurement study,’’ in Proc. 7th Int. Conf.

Malicious Unwanted Softw., Oct. 2012, pp. 9–16.

[35] Corbanbrook. (2010). Dsp.js. [Online]. Available: https://github.

com/corbanbrook/dsp.js

[36] P. Fortuna and R. Ribeiro. (2018). Jscrambler, Javascript Application

Security. [Online]. Available: https://jscrambler.com/

[37] CuteSoft Components Inc. (2017). Javascript Obfuscator, Protects

Javascript Code From Reverse Engineering. [Online]. Available:

http://www.javascriptobfuscator.com/

[38] N. Burow, S. A. Carr, J. Nash, P. Larsen, M. Franz, S. Brunthaler, and

M. Payer, ‘‘Control-flow integrity: Precision, security, and performance,’’

Acm Comput. Surv., vol. 50, no. 1, p. 16, 2017.

[39] Shaman Science and Technology. (2013). Jshaman. [Online]. Available:

http://www.jshaman.com/index.html

[40] Z. Tang, M. Li, G. Ye, S. Cao, M. Chen, X. Gong, D. Fang, and Z. Wang,

‘‘VMGuards: A novel virtual machine based code protection system with

VM security as the first class design concern,’’ Appl. Sci., vol. 8, no. 5,

p. 771, 2018.

VOLUME 7, 2019 182723

S. Wang et al.: Leveraging WebAssembly for Numerical JavaScript Code Virtualization

[41] F. Hui, Y. Wu, S. Wang, and H. Yin, ‘‘Multi-stage binary code obfuscation

using improved virtual machine,’’ in Proc. Int. Conf. Inf. Secur., 2011,

pp. 168–181.

[42] W. Zhou, Z. Wang, Y. Zhou, and X. Jiang, ‘‘DIVILAR: Diversifying

intermediate language for anti-repackaging on Android platform,’’ in Proc.

4th ACM Conf. Data Appl. Secur. Privacy, Mar. 2014, pp. 199–210.

[43] W. Chen, L. Xu, G. Li, and Y. Xiang, ‘‘A lightweight virtualization

solution for Android devices,’’ IEEE Trans. Comput., vol. 64, no. 10,

pp. 2741–2751, Oct. 2015.

[44] J. Kinder, ‘‘Towards static analysis of virtualization-obfuscated binaries,’’

in Proc. 19th Work. Conf. Reverse Eng., Oct. 2012, pp. 61–70.

[45] A. Kalysch, J. Götzfried, and T. Müller, ‘‘VMAttack: Deobfuscating

virtualization-based packed binaries,’’ in Proc. 12th Int. Conf. Availability,

Rel. Secur., Aug./Sep. 2017, Art. no. 2.

[46] K. Coogan, G. Lu, and S. Debray, ‘‘Deobfuscation of virtualization-

obfuscated software: A semantics-based approach,’’ in Proc. 18th ACM

Conf. Comput. Commun. Secur., Oct. 2011, pp. 275–284.

SHUAI WANG received the B.E. degree in com-

puter science and technology from the Taiyuan

University of Technology, China, in 2017. He is

currently pursuing the M.S. degree in computer

application technology. His current research inter-

ests include javascript security and deep learning.

GUIXIN YE was born in Tai’an, Shandong, China,

in 1990. He is currently pursuing the Ph.D. degree

in software engineering with Northwest Univer-

sity. His current research interest includes privacy

and software security. He has extensive experience

in authentication and software bug detection.

MENG LI received the B.E. degree in computer

science and Technology from Northwest Univer-

sity, China, in 2017, where she is currently pur-

suing the M.S. degree in computer application

technology. Her current research interests include

wireless sensing and information security.

LU YUAN was born in 1995. She received the

B.S. degree in computer science from Northwest

University, China, in 2017, where she is currently

pursuing the master’s degree in computer science.

Her current research interests include mobile com-

puting and mobile energy efficiency.

ZHANYONG TANG received the Ph.D. degree

in computer software and theory from Northwest

University. He is currently an Associate Professor

with the School of Information Science and Tech-

nology, Northwest University. His current research

interests include network and information security,

software security and protection, localization, and

wireless sensor networks.

HUANTING WANG received the B.E. degree in

computer science and technology from Northwest

University, China, in 2018. He is currently pur-

suing the M.S. degree in computer application

technology. His current research interests include

wireless sensing and information security.

WEI WANG received the B.S. and M.S. degrees in

communication engineering from Xidian Univer-

sity, Xi’an, China, in 2000 and 2004, respectively,

and the Ph.D. degree in information and communi-

cation engineering from Northwestern Polytechni-

cal University, Xi’an, in 2017. Her current research

interests include localization algorithm, the tour

planning of mobile node, and cross technology

communication.

FUWEI WANG was born in Xi’an, Shaanxi,

China, in 1987. He received the Ph.D. degree from

Xidian University, Xi’an, in 2014. He is currently

with Northwest University. His current research

interests include antenna scattering, software secu-

rity, RCS reduction, and metamaterials.

JIE REN was born in 1988. He received the Ph.D.

degree in computer architecture from Northwest

University, China, in 2017. He is currently an

Assistant Professor with the Computer Science

Department, Shaanxi Normal University. His cur-

rent research interests include mobile computing

and performance optimization.

DINGYI FANG received the Ph.D. degree in com-

puter application technology from Northwestern

Polytechnical University, Xi’an, China, in 1983.

His current research interests include mobile com-

puting and distributed computing systems, net-

work and information security, and wireless sensor

networks.

ZHENG WANG received the Ph.D. degree in

computer science from The University of Edin-

burgh, in 2011, under the supervision of Prof.

M. O’Boyle. His current research interests include

parallel compilers, runtime systems, and the appli-

cation of machine learning to tackle the challeng-

ing optimization problems within these areas.

182724 VOLUME 7, 2019