Intelligent Automation And Soft Computing, 2019

Copyright © 2019, TSI® Press

Vol. 25, no.1, 143 –15 3

Protecting Android applications with multiple DEX files against Static

Reverse Engineering Attacks

Kyeonghwan Lim1, Nak Young Kim1, Younsik Jeong1, Seong-je Cho1,

Sangchul Han2, and Minkyu Park2
1Dankook University, Yongin-si, Gyeonggi-do 16890 Korea

{limkh120, iuasdofil, jeongyousik, sjcho}@dankook.ac.kr

2Konkuk University, Chungju-si, Chungbuk-do 27478 Korea

{schan, minkyup}@kku.ac.kr

ABSTRACT
The Android application package (APK) uses the DEX format as an executable
file format. Since DEX files are in Java bytecode format, you can easily get Java
source code using static reverse engineering tools. This feature makes it easy
to steal Android applications. Tools such as ijiami, liapp, alibaba, etc. can be
used to protect applications from static reverse engineering attacks. These tools
typically save encrypted classes.dex in the APK file, and then decrypt and load
dynamically when the application starts. However, these tools do not protect
multidex Android applications. A multidex Android application is an APK that
contains multiple DEX files, mostly used in a large-scale application. We
propose a method to protect multidex Android applications from static reverse
engineering attacks. The proposed method encrypts multiple DEX files and
stores them in an APK file. When an APK is launched, encrypted DEX files are
decrypted and loaded dynamically. Experiment results show that the proposed
method can effectively protect multidex APKs.

KEY WORDS: Reverse engineering, Android, Multidex, Packing, Dynamic code loading

transform the source code into a form that is very

1 INTRODUCTION complicated and difficult to understand.
AS the use of mobile devices such as smart phones Meanwhile, some tools such as ijiami, liapp and
and smart watches increases, the number of Android alibaba protect Android applications using code
applications is also growing. As of 2016, the number encryption and dynamic code loading (Yang et al.,
of Android applications exceeded 2 million 2015; Yu, 2014). These tools encrypt a DEX (Dalvik
(AppBrain, 2016). Most Android applications are Executable) file, move the encrypted DEX file to
being developed using the Java language. Java source another directory, and place a stub DEX file in the
codes are compiled into bytecodes and executed on a APK root directory. When the application is executed,
virtual machine. Unfortunately, by reverse engineering the stub DEX decrypts the encrypted DEX and
these bytecodes, one can easily get Java codes and dynamically loads it. However, we found the fact that
Android applications are exposed to code theft. these tools have a weakness: these tools do not protect
Developing methods to prevent unauthorized use of multidex applications, which have multiple DEX files
code is an important research topic. in its APK. Since one DEX file cannot have more than
Many developers apply obfuscation techniques to 65,536 methods, large applications should be
prevent exposure of application codes. Obfuscation implemented in a multidex form. The above tools do
techniques include identifier mangling, string not work properly for multidex applications and
obfuscation, and dead or irrelevant code insertion. encrypts only a single DEX file.
However, these obfuscation techniques do not We propose a dynamic code loading method for
completely protect the source code. Their goal is to protecting Android applications against static reverse
engineering. This proposed method is based on the

CONTACT Minkyu Park [email protected]

© 2019 TSI® Press
2 LIM, KIM, ET. Al.

Multidex library. The Multidex library is a library remaining classes, fields, and methods. Each of these
developed by Google to load more than one DEX files steps is optional. For instance, ProGuard can be used
in Dalvik Virtual Machine (DVM). The proposed to obfuscate the APK file only.
method encrypts / decrypts and dynamically loads In (Schulz, 2012), the authors proposed several
multiple DEX files. Since the encrypted DEX files are obfuscation techniques and dynamic code loading
decrypted only when the application is executed, it is technique. In the dynamic code loading technique
difficult to statically reverse-engineer the DEX files. there are two components: an encrypted DEX file and
Experimental results show that the proposed method a decryption stub (stub DEX). The original DEX file is
can effectively protect multidex APKs. encrypted and stored at somewhere in the APK. When
We have recently proposed a protection scheme for the application is launched, the decryption stub
multidexing-based Android applications (Kim, Shim, decrypts the encrypted DEX file and loads it into
Cho, Park, & Han, 2016). In (Kim, Shim, Cho, Park, Dalvik Virtual Machine (DVM) to execute.
& Han, 2016), the stub DEX is a weak point. Since the In (Ghosh, Tandan, & Lahre, 2013), the authors
stub DEX was implemented in Java language, it is added few more logic on Android source code to make
vulnerable to reverse engineering attacks. If an it more complex to understand. They exploit try-catch
attacker reverse-engineers and tampers the stub DEX, blocks to change the control flow at runtime. They
he/she can obtain the decrypted original DEX files. In exchanged the role of try-catch blocks. They put
this paper, we extend the previous version as follows. business logic into catch block and dummy code,
First, we propose stub DEX integrity verification as a meaningless loop, and senseless if-else condition into
native library. This library is called by a stub DEX, try block. Also, they put one line of code that always
and checks if the stub DEX is tampered. If so, the cause exception at runtime. Reverse engineers try to
library terminates the application immediately in order understand the try block but it has meaningless code.
to prevent further dynamic reverse engineer attacks. This makes understanding code more complex.
Second, we support multiple architectures. Since the In (Xu, Zhang, Sun, Lin, & Mao, 2015), the
decryption and integrity verification are implemented authors presented a technique that can detect debug
as a native library, the library is implemented for 7 state and debug environment by detecting debugging-
types of architectures including armeabi-v7a and related processes and emulator specific features. On
armeabi. the basis of the results, they proposed some solutions
The remainder of this paper is organized as to prevent Android applications being decompiled and
follows. Section 2 discusses background knowledge cracked. Taking advantage of these methods, they
and related studies. In Section 3, we propose a mostly eliminate the feasibility of the secondary
multidex-library based dynamic code loading scheme. packaging for Android software.
Section 4 shows the experimental and analytical In (Sun, Cuadros, & Beznosov, 2015), the authors
results. Finally, we concluded in Section 5. evaluate rooting detection techniques. They found
many techniques used by apps to detect rooted
2 BACKGROUND AND RELATED WORKS devices, but all rooting detection methods studied can
be evaded. They concluded that Android OS can only
2.1 Anti-Reverse Engineering Techniques provide a reliable rooting detection method. OS also
REVERSE engineering is a process of analyzing a implements rooting detection logic in the trusted
program to identify and represent its components, components, such as integrity-protected kernels or
structure and/or behavior. Reverse engineering can be external trusted execution environments.
used to understand how a program works and design a Lim et al. (Lim et al., 2016) proposed an anti-
new program by improving the technology of the dynamic reverse engineering scheme for Android
existing program. Meanwhile, reserve engineering also applications on real smart phones, where its stub DEX
can be used to hack or tamper a program for illegal tries to detect dynamic reverse engineering attacks.
benefits. Especially Android applications are exposed Especially they focus on call stack-based evasion
to such software theft, because most Android attack (API hooking) detection. If the stub DEX does
applications are written in Java programming language not detect any dynamic reverse engineering attack it
and their Java source codes can be easily obtained loads the original DEX file dynamically.
using reverse engineering. Kim et al. (Kim, Shim, Cho, Park, & Han, 2016)
There are many studies on protecting Android proposed a technique for protecting multiple DEX
applications against reverse engineering attacks. Pro- Android applications. The technique is similar to
Guard (Android, 2016e) can shrink, optimize, Schulz’s one in the sense that the original DEX files
obfuscate, and pre-verify Java class files. The are encrypted and the stub DEX decrypts/loads them
ProGuard reduces APK file size by removing unused dynamically. However, Kim’s technique supports
classes, fields, methods, and attributes. It optimizes the multiple DEX Android applications.
bytecode of the methods. The obfuscation step uses In (Na, Lim, Kim & Yi 2016), the authors
short meaningless names to change the names of the summarized the difference of attacks to DEX files and
 INTELLIGENT AUTOMATION AND SOFT COMPUTING 3

OAT files. DEX is for Dalvik Virtual Machine and Table 1. 19 Multidex APK
OAT for ART environment. The authors explored
static and dynamic analysis technique for DEX and APK name
OAT files on Android 4.0 (KitKat). Note that, in our com.snapchat.android-1.apk
work, we tried to prevent static attacks for DEX files, com.infraware.office.link-1.apk
but not for OAT files. com.toxic.apps.chrome-1.apk
com.myfitnesspal.android-1.apk
2.2 Multidex APK
com.twitter.android-1.apk
Most Android application package (APK) is the file
format for packages for distribution and installation of com.zhiliaoapp.musically-1.apk
applications on Android platform. An APK file jp.naver.line.android-1.apk
contains manifest files, architecture-dependent native com.skype.raider-1.apk
codes, resources, DEX files, etc. In most APKs, there mobi.byss.instaweather.watchface-1.apk
is one DEX file, classes.dex, which is loaded and com.undertap.watchlivetv-1.apk
executed on DVM. Android application developers com.talkatone.android-1.apk
usually write Java source programs and compile them com.estrongs.android.pop-1.apk
all together with third-party libraries into a DEX file.
net.zedge.android-1.apk
One problem in the build process is that the
air.com.officemax.magicmirror.ElfYourSelf-1.apk
number of referred methods in a single DEX file is
limited to 65,536 (= 216), including user-defined com.mcentric.mcclient.FCBWorld-1.apk
methods, third-party library methods and framework com.viber.voip-1.apk
methods (Android, 2016b). This is because invoke-* kik.android-1.apk
Dalvik instruction takes a 16-bit argument which com.fitbit.FitbitMobile-1.apk
represents the reference index of the target method.
com.pinterest-1.apk
Thus, if the number of methods in classes.dex exceeds
65,536, the build process fails. To remedy this
problem, developers shrink codes using tools such as
ProGuard and/or adopt lightweight libraries (Reznik, 2.3 Analysis of Android Packers
2014). A tool that counts the referred methods is also An Android packer is a tool that protects Android
used (Parparita, 2014). applications by encrypting, decrypting and
To get around this limitation, Android provides dynamically loading classes.dex (Yang et al., 2015;
multidex library. With this library an APK file can Yu, 2014). In this section, we analyze three Android
contain multiple DEX files without changing the DEX packer services, ijiami, liapp, and alibaba, to explore
file format. The multidex library is available in build whether they can protect multidex APKs. All these
tools 21.1.1 or later (Android, 2016f). When packers deploy Application class for dynamic code
developers build an APK, they switch on the multidex loading. “Application class is a base class for
support option in Android Studio or Eclipse. In maintaining global application state” (Android,
multidex APKs, the names of DEX files are 2016a). When an APK is packed, Application class (or
classes.dex, classes2.dex, and so forth. If classes.dex its subclass) is replaced with each packer’s custom
in a multidex APK is decompiled using dex2jar and class to control the execution flow. Thereby, the name
jd-gui (Java Decompiler, 2008), attribute of <application> element in
android.support.multidex package is found. We AndroidManifest.xml is modified to their custom
collected and decompiled popular 40 Android class’ name. When a packed application is launched,
applications from Google Play. We found out that 22 its custom class is executed first. It decrypts the
(55 %) APKs among them are multidex APKs. The encrypted DEX file, and then loads the decrypted
Table 1 lists 19 apps among them, which the proposed DEX file dynamically using DexClassLoader class.
method is successfully applied to. We investigate whether each packer can protect
multiple DEX files from static reverse engineering.
First we pack com.twitter.android-1.apk using the
three packers. We unzip the original APK and the
packed APK, respectively, to obtain classes.dex. Then
we decompile each classes.dex using dex2jar (Pan, B)
and gd-gui (Java decompiler) to obtain Java source
codes, and examine their code trees. As shown in
Figure 1, the code trees are different from each other.
We can find the name of the custom class for each
packer. Figure 1 implies that the three packers can
protect classes.dex from static reverse engineering.
4 LIM, KIM, ET. Al.

Now we examine the code trees of the decompiled describe how DexProtector protects multiple DEX
classes2.dex. As shown in Figure 2, the code trees of files. Meanwhile, DexGurard’s documentations do not
the packed APKs are identical to the original APK. mention multidex support.
Furthermore, some decompiled codes are the same as
the original ones. Figure 2 implies that the three 2.4 Overview of Multidex Library
Android packers do not protect classes2.dex at all Dalvik loads classes.dex using the constructor of
from static reverse engineering. the DexFile class. The DexFile constructor loads only
classes.dex in APK file (Android, 2016c). Google
does not modify the Dalvik to provide the
functionality to load multiple DEX files from an APK
file. This is because the Android users may not update
the OS or the vendors may not support these
modifications. Instead, Google offers a Multidex
library (Android, 2016g) that enable Android to load
multiple DEX files from your APK. The Multidex
library is built into classes.dex and executed to load
the rest of the DEX files when the application runs.
The name attribute of the <application> element in
AndroidManifest.xml must be set to
MultiDexApplication class or a user-defined subclass
of MultiDexApplication.
Figure 3 shows the execution flow of the Multidex
library. The MultiDex.install method calls the
MultiDexExtractgor.load method which extracts DEX
files (classes*.dex) from the APK’s root directory,
compresses and saves them as classes*.dex.zip in the
/data/data/package/code_cache/secondary-dexes
directory, and returns an array containing the full
Figure 1. Code tree of decompiled classes.dex. paths of classes*.dex.zip. Then MultiDex.install
passes the array to the installSecondaryDexes method
which invokes a build-platform-specific install
method. The install method invokes in turn the
makeDexElements method of the DexPathList class
using API reflection (Android, 2016d). The
makeDexElement method allows additional DEX files
such as classes2.dex, classes3.dex, etc. to be loaded.
Finally, more than one DEX files are loaded and the
application runs normally.

Figure 3. Execution Flow of Multidex APK.

Figure 2. Code tree of decompiled classes2.dex.

3 PROPOSED METHOD
There are commercial packers such as OUR anti-static reverse engineering method for
DexProtector and DexGuard. Since these tools do not multidex Android applications is embedded in
provide a free or trial version, we could not examine applications. Figure 4 shows the overview of the
whether they can protect multidex APKs. According proposed method. Our method consists of several
to DexProtector’s documentations, DexProtector techniques. In Java layer, DEX file substitution,
supports multidex APKs. However, they do not dynamic code loading for multidex APK and entry
point change are implemented. In native C layer, DEX
 INTELLIGENT AUTOMATION AND SOFT COMPUTING 5

file decryption and stub DEX integrity verification are 3.1 Verifying Integrity of Stub DEX
implemented. When a packed APK is launched in a In our proposed method, since stub DEX must be
user device, these techniques are performed in the executed first in the application, we need to set the
following order: (1) stub DEX integrity verification, value of the name attribute of the <application>
(2) DEX file decryption, (3) dynamic code loading for element in the AndroidManifest.xml file to the
multidex APK, (4) entry point change, (5) the original package name of stub DEX.
DEX execution. To begin with, the stub DEX must verify its own
integrity. Because stub DEX is implemented in Java
language, it is vulnerable to reverse engineering attack
compared with C implementation of Android native
library layer. Unless the integrity of stub DEX is
verified, the following problems may occur. Attackers
can prevent normal execution of applications by
modifying the decryption codes of the stub DEX. The
stub DEX calls an Android native function to decrypt
the encrypted original executable code. If the codes
that call the functions of this native layer are deleted,
the original app code will not be decrypted and the
Figure 4. Overview of Proposed Method. app will not run normally.
To make matters worse, if you modulates codes
Figure 5 shows the structure of an APK that decrypt the original DEX file and load it into
before/after packing using our method. In Figure 5(b), memory, attackers may get the original code. He can
gray boxes represent modified files. The original DEX also tamper with this part to load and run malware.
files are encrypted during packing and stored as Therefore, it is necessary to verify the integrity of the
encrypted_classes.dex, encrypted_classes2.dex, and so stub DEX itself. Upon passing the verification
on. Instead of the original classes.dex, a stub DEX file, process, multidex decryption and dynamic loading are
named as classes.dex, is added to the packed APK. performed.
The stub DEX implements the Java layer; it calls Integrity verification is performed as follows.
native codes, loads the decrypted DEX and changes When a server applies the proposed scheme, it obtains
the entry point to the DEX. The name attribute of the SHA1 hash value for a stub DEX file, encodes the
<application> element in AndroidManifest.xml is obtained SHA1 hash value into Base64 string, and
changed to the package name of the stub DEX so that stores it in libstub.so. Then, when the developer signs
the stub DEX can be executed first. The native C layer the application, the server stores the Base64 string of
is implemented as libStub.so file, which is loaded on SHA1 of the stub DEX in the signature-related file
memory at the start of execution. By invoking MANIFEST.MF and distributes afterwards. The
functions in libStub.so, the stub DEX verifies the MANIFEST.MF file exists in the META-INF
integrity of itself and decrypts encrypted_classes*.dex directory and stores information on all files in the
file. APK package except the files in META-INF
directory. Information include the file path and the
Base64 encoded string of SHA1 hash value of each
file. When the application is executed, libstub.so is
loaded and Base64 string of stub DEX stored in
libstub.so is compared with the Base64 string stored in
MANIFEST.MF.

3.2 Multidex Library based Dynamic Code

Loading
This section proposes a dynamic code loading
technique based on multidex library. As explained in
Section 2.4, multidex library is executed first when an
application starts. In our technique, all DEX files in
the root directory in an APK file are encrypted using
AES (Advanced Encryption Standard) and moved to
Figure 5. Structure of APK files before/after Packing. asset directory. When the application is executed, a
stub DEX file (named as classes.dex) located in the
root directory is executed first. It decrypts the
encrypted DEX files and dynamically loads them. The
AES decryption is implemented as JNI codes and the
6 LIM, KIM, ET. Al.

codes are stored as libStub.so in directory lib. Figure 5 application such as ClassLoader, ActivityThread and
shows the structure of APK files that are repackaged ApplicationInfo. The original DEX can execute
using our method. normally by using this object. (3) Invoke
We implement the stub DEX by modifying makeApplication() which in turn invokes onCreate()
multidex library. We name the modified library as of the initial activity of the application.
com.dynamic.loading. If we use the original name
android.support.multidex in the stub DEX, we 3.4 Multiple Architecture Support
encounter a pre-verification error because Dalvik tries Google provides a number of Application Binary
to verify and load android.support.multidex twice; in Interfaces (ABIs) that allow Android handsets to be
the stub DEX and the original classes.dex. We can manufactured using a variety of CPUs (Wikipedia,
find it out using logcat. 2016). ABI is a low-level binary interface used
Our library extracts and decrypts the encrypted between the application and the operating system or
DEX files (named as encrypted_classes.dex, application and its library, or finally the components
encrypted_classes2.dex, ...) from directory assets of the application.
instead of simply extracting classes*.dex. The process The ABI is distinguished from the API
is as follows. (Application Programming Interface). The API is used
at the source code level, and the ABI is used at the
1. A user launches an application. binary code level. These ABIs can be cross-compiled
2. Stub DEX (classes.dex) is loaded and executed on using NDK, and currently there are seven kinds of
Dalvik. ABIs supported. A detailed description of each ABI
3. It verifies the integrity of itself by invoking can be found on the Google developer site (Google,
libStub.so through JNI. 2016).
4. It extracts encrypted_classes*.dex (AES-encrypted Since the proposed method adds a native library
DEX files) in assets into that is responsible for integrity verification of the stub
/data/data/package/code_cache/secondary-dexes DEX file itself and decryption of the original DEX
directory. files, it must support various architectures as
5. It decrypts the encrypted_classes*.dex files by mentioned above. Therefore, the proposed method
invoking libStub.so through JNI. inserts the corresponding native library for each
6. It compresses the decrypted files in the ZIP format. architecture supported. Among them the most
7. It loads the compressed files on Dalvik. commonly used ABIs are armeabi-v7a and armeabi.
8. It deletes the compressed files
4 EXPERIMENTAL RESULTS
IN this section, we verify that the proposed method
can protect multidex applications against reverse
engineering and measure performance overhead of the
method by carrying out experiments. Our experiments
are conducted on Google Nexus 7 using the multidex
applications listed in Table 1. The specifications of
Google Nexus 7 are shown in Table 2.

Table 2. Specification of Google Nexus 7

Operating System Android 4.3(Jelly Bean)

Figure 6. Execution Flow of Multidex Library based Dynamic Kernel Version 3.4.0-g6537a16
Code Loading. CPU 1.51 GHz quad-core Krait 300
Memory 2GB DDR3L RAM
Storage 16 GB
3.3 Changing Entry Point & Executing the
original DEX 4.1 Static Reverse Engineering Attack Test
In order that the application may execute normally, For the experiment, we pack a sample original
the stub DEX needs to configure the execution application using our proposed method and create its
environments as if the original DEX were executing packed version, that is, the packed application. We
(Lim, Jeong, Lim, et al., 2016). The last task of the then reverse engineer the packed version using
stub DEX is to change the entry point to a proper baksmali and dex2jar tools (Tumbleson & Wisniewski,
method of the loaded DEX. The process is as follows. 2010; Freke, 2009; Pan, 2014). We can analyze
(1) The original DEX files are already loaded on classes.dex of the packed version. It contains only the
Dalvik. (2) Fill the fields of loadedapk object with the classes of the stub DEX file introduced by our
information of the original application. The loadedapk proposed method and does not contain the classes of in
object maintains the information of the current the original application. Next, we examine the
 INTELLIGENT AUTOMATION AND SOFT COMPUTING 7

encrypted_classes*.dex files (shortly named as Enc*) five major components: integrity verification time,
in the packed version. Their contents are shown in decryption time, compression time, the execution time
Figure 7. It is impossible to identify any original DEX of the DexOpt program and changing entry point time.
file from the encrypted_classes*.dex files because We analyze the major components of the processing
none of them has DEX file header “dex\n035\0” time in detail and show the results in Figure 8. And
(Freke, 2009). Therefore, we verify that our proposed Table 3 lists the number and size of the
method can protect Android applications against static encrypted_classes*.dex files contained in each packed
reverse engineering attacks. application. DexOpt is a system-internal program that
is used to produce optimized DEX files. DexOpt
loads, verifies and optimizes DEX files. It performs
these tasks in favor of Dalvik VM to avoid allocating
some resources to Dalvik. Instead, those resources are
allocated to DexOpt and it frees the resources on
completion of the tasks. The app with the proposed
scheme will run stub DEX first. The original
classes*.dex files are then executed through a
changing entry point technique. The Android system
will perform bytecode optimization to run the original
DEX file. The time it takes to optimize is DexOpt time.
DexOpt is usually invoked once when the original
applications as well as their packed versions are
executed at the first time. The run time of the DexOpt
is short in case of the execution of the original
Figure 7. Contents of Enc* files of the packed application,
com.twitter.android-1.apk.
application because the corresponding symbol
information can be obtained directly, while the run
4.2 Dynamic Code Loading Overhead time of the DexOpt is very long in case of the
AT the beginning of an application execution, the execution of the packed version because the
procedure for the dynamic code loading technique is corresponding symbol information cannot be obtained
described in Section 3.2. In case of the packed directly. From the message of the logcat tool, our
application with our proposed method, the dynamic guess is that APK repackaging of our method have
code loading is performed after verifying the integrity caused the mapping information of the symbols to be
of the stub DEX. During the dynamic code loading, broken. As the result of the repackaging, the symbol
our method decrypts the encrypted_classes*.dex files information and method overriding should be
and compresses the decrypted files one by one to the recovered during the unpacking and dynamic loading
ZIP format. Then, the compressed files are the codes of the packed application.
dynamically loaded on Dalvik using DexPathList In Figure 8, we can see that the time for verifying
shown in Figure 3. Therefore, we measure the stub DEX integrity is almost steady. However, the
performance overhead of our method as follows. time for decryption and compression is increased in
First, we calculate the processing time for proportion to the size and number of
dynamically loading code of an original application encrypted_classes*.dex files. During the execution of
and its packed version with our proposed method, the packed applications, the DexOpt program is
respectively. By repeating the calculation ten times, invoked. The invocation to the DexOpt is an
we measure the average processing time. Figure 8 additional overhead incurred by the proposed method.
shows the average processing times side by side which Among the sample applications used in our
are spent for dynamically loading the codes of the experiments, the com.infraware.office.link-1.apk
original applications and their packet versions. The includes four encrypted_classes*.dex files and
system.currentTimeMillis () method, which returns the requires the largest time, 19.66 seconds, for integrity
current time, is used to measure the total time taken verification, decryption, compression and the
for dynamic loading, integrity verification, decryption invocation of the DexOpt. On the one hand, the
time, compression time, DexOpt, and changing entry mobi.byss.instaweather.watchface-1.apk includes two
point time. To measure the processing time of each encrypted_classes*.dex files and requires the smallest
element, the time difference was calculated by placing time, 6.80 seconds, for integrity verification,
the method at the start and end. For dynamic code decryption, compression and the invocation of the
loading, the packed applications with our method DexOpt.
takes more time than their original ones ranging from
minimally 1.46 times to maximally 5.9 times.
The processing time for dynamically loading the
codes of the packed applications can be broken into
8 LIM, KIM, ET. Al.

Table 3. The number of the encrypted DEX files and their size We collected 22 multidex apps from the Google
APK name # of Encrypted Encrypted Dex Play. The proposed method is successfully applied to
(its extension is .apk) DEX files file size(MB) 19 of them. Table 3 shows these 19 applications with
com.snapchat.android-1 4 23.00 their number of DEX and size. We cannot apply the
proposed method to three apps because of verifying
com.infraware.office.link 4 29.60 self-integrity and repacking. If an app verifies its
-1
com.toxic.apps.chrome-1 3
integrity itself, our modification to the app cannot pass
15.03
this integrity verification. Such cases are
com.myfitnesspal.androi 3 20.70 com.supo.security-1.apk and com.qihoo.security-1.apk.
d-1 In case of com.tencent.mm-1.apk, we cannot repack
com.twitter.android-1 3 18.10 the app because the version of apktool is incompatible
com.zhiliaoapp.musicall 3 17.70 with the app.
y-1 We assume that AES keys are managed properly
jp.naver.line.android-1 3 22.80 and safely, and that AES is secure. Since our
technique encrypts/decrypts the DEX files using AES,
com.skype.raider-1 2 11.80
its application protection capability against static
mobi.byss.instaweather. 2 9.04 reverse engineering depends on the security of AES,
watchface-1 which is beyond the scope of this paper. Our technique
com.undertap.watchlivet 2 11.60 can protect applications against all static reverse
v-1
engineering attacks as long as the assumption holds.
com.talkatone.android-1 2 10.90
com.estrongs.android.po 2 15.20 5 CONCLUSION AND FUTURE WORK
p-1
WE propose a method to protect multidex Android
net.zedge.android-1 2 11.80
applications against static reverse engineering. The
air.com.officemax.magic 2 11.50 proposed method encrypts the DEX files of APK
mirror.ElfYourSelf-1 using the AES encryption and adds a stub DEX
com.mcentric.mcclient.F 2 16.00 instead of the original classes*.dex file. When the
CBWorld-1 application starts, Verify the integrity of the Stub Dex
com.viber.voip-1 2 14.10 and stub DEX decrypts and dynamically loads the
kik.android-1 2 14.60 encrypted DEX file. We modified Google’s multidex
library to implement stub DEX. Experiments also
com.fitbit.FitbitMobile-1 2 15.20 show that applications implemented using the
com.pinterest-1 2 12.60 proposed technique are difficult to reverse-engineer
using well-known tools such as dex2jar and baksmali.
Compared to other existing packers, the proposed
4.3 Discussion method is more effective for multi DEX files.
LIAPP, ijiami, alibaba, etc. are representative tools A disadvantage of the proposed method is time
for preventing static reverse engineering attacks. overhead. According to the experimental result, when
These tools usually encrypt and save classes.dex in the the applications packed by the proposed method are
Android app in a similar way to the proposed executed, it takes more time from minimally 1.46
technique. The encrypted classes.dex file is decrypted times to maximally 5.9 times than the execution time
and loaded when the app launches. However, these of their original Android applications. The additional
tools only support apps with a single DEX file, and we overhead is mainly caused by the slow execution of
showed that you cannot defend all classes.dex files if the DexOpt program during decryption and dynamic
more than one classes.dex file exists in Section 2.3. loading the codes of the packed applications.

Table 4. Comparison of app protection tools with respect to 5.1 Acknowledgment

functionality THIS work was supported by the MSIP, Korea,
The under the ITRC support program (IITP-2016-R0992-
Liapp ijiami Alibaba
packer packer packer
proposed 16-1012) supervised by the IITP. This research was
method also supported by Basic Science Research Program
static
static static static reverse through the National Research Foundation of Korea
What it
can
reverse reverse reverse engineerin (NRF) funded by the Ministry of Science, ICT and
prevent
engineerin engineerin engineerin g attacks Future Planning (No. 2015R1A2A1A15053738)
g attacks g attacks g attacks and
tempering
Support
multide X X X O
x
Figure 8. The major components of the processing time for dynamic code loading in case of packed application with the proposed method.
INTELLIGENT AUTOMATION AND SOFT COMPUTING 9
10 LIM, KIM, ET. Al.

M. Parparita, (2014). dex-method-counts,

6 REFERENCES https://github.com/mihaip/dex-method-counts.
Android. (2016a). Application. T. Reznik, (2014). Android and the dex 64k methods
http://developer.android.com/reference/android/a limit-contentful, https://www.contentful
pp/Application.html. .com/blog/2014/10/30/android-and-the-dex-64k-
Android. (2016b). Configure apps with over 64k methods-limit/.
methods. http://developer.android.com/ P. Schulz, (2012). Code protection in Android, Tech.
studio/build/multidex.html. Rep. No. 110. Rheinische Friedrich-Wilhelms-
Android. (2016c). Dexfile. Universitat Bonn.
http://developer.android.com/reference/dalvik/sys S. T. Sun, A. Cuadros and K. Beznosov, (2015).
tem/ DexFile.html. Android rooting: Methods, detection, and
Android. (2016d). Package java.lang.reflect. evasion, Proceedings of the 5th annual acm ccs
http://developer.android.com/reference/java/ workshop on security and privacy in smartphones
lang/reflect/package-summary.html. and mobile devices, 3–14.
Android. (2016e). ProGuard. C. Tumbleson, and R. Wisniewski, (2010). Apktool,
http://developer.android.com/tools/help/proguard http://ibotpeaches.github.io/Apktool/.
.html. Wikipedia. (2016). Abi,
Android. (2016f). SDK build tools release notes. https://en.wikipedia.org/wiki/Application binary
http://developer.android.com/tools/revisions/buil interface.
d-tools.html. J. Xu, L, Zhang, Y. Sun, D. Lin, and Y. Mao, (2015).
Android. (2016g). Support library features. Toward a secure android software protection
http://developer.android.com/tools/support- system, Proc. of 2015 IEEE international
library/features.html. conference on Computer and information
AppBrain. (2016). Number of android applications. technology; ubiquitous computing and
http://www.appbrain.com/stats/number-of- communications; dependable, autonomic and
android-apps. secure computing; pervasive intelligence and
J. Freke, (2009). baksmali. computing, 2068–2074.
https://github.com/JesusFreke/smali. W. Yang, Y. Zhang, J. Li, J. Shu, B. Li, W. Hu, and
S. Ghosh, S. R. Tandan, and K. Lahre, (2013, June). D. Gu, (2015). Appspear: Bytecode decrypting
Shielding android application against reverse and dex reassembling for packed android
engineering, International Journal of Engineering malware, Proc. of the 18th international
Research and Technology, 2(6), 2635–2643. symposium on research in attacks, intrusions and
Google Inc. (2016). Abi, defenses (raid’15), kyoto, japan, 9404, 359–381.
https://developer.android.com/ndk/guides/abis.ht R. Yu, (2014). Android packers: facing the challenges,
ml?hl=en building solutions, Proc. of the 24th virus bulletin
Java decompiler. (2008). http://jd.benow.ca/. international conference (vb’14), Seattle,
N. Y. Kim, J. Shim, S. Cho, M. Park, and S. Han, Washington, USA, 266–275
(2016). Android application protection against G. Na, J. Lim, K. Kim, and J. Yi, (2016). Comparative
static reverse engineering based on multidexing, Analysis of Mobile App Reverse Engineering
The 2016 International Symposium on Mobile Methods on Dalvik and ART, 2016 Journal of
Internet Security (MobiSec 2016), July 2016, Internet Services and Information Security
Taichung, Taiwan, Journal of Internet Services (JISIS), 6(3), 54–64.
and Information Security (JISIS), 6(4), 54–64.
K. Lim, Y. Jeong, S. Cho, M. Park, and S. Han, 7 NOTES ON CONTRIBUTORS
(2016). An android application protec¬tion K. Lim received the B.E. degree
scheme against dynamic reverse engineering in Dept. of Software Science from
attacks, Journal of Wireless Mobile Networks, Dankook University, Korea, in
Ubiquitous Computing, and Dependable 2015 and the M.E. degree in
Applications (JoWUA), 7(3), 40–52. computer science and engineering
K. Lim, Y. Jeong, J. Lim, S. Cho, H. Shim, and S. from Dankook University, Korea,
Cho, (2016). Encrypting executable codes and in 2016. He is currently a Ph.D.
changing entry point of them for preventing student in Computer Science and
android apps against reverse engineering, Proc. of Engineering at Dankook University, Korea. His
the 26th joint conference on communications and research interests include computer system security,
information (jcci’16), sokcho, korea. 26, 0244– mobile security.
0245.
B. Pan, (2014). dex2jar,
https://sourceforge.net/projects/dex2jar/.
 INTELLIGENT AUTOMATION AND SOFT COMPUTING 11

N. Y. Kim received the B.E. S. Han received his B.S. degree

degree in Dept. of Software from in Computer Science from
Dankook University in 2015 and Yonsei University in 1998. He
the M.E. degree in computer received his M.E. and Ph.D.
science and engineering from degrees in Computer Engineering
Dankook University, Korea, in from Seoul National University
2016. He is currently a researcher in 2000 and 2007, respectively.
in Inetcop laboratory, Korea. His He is now an associate professor
research interests include computer system security, in the Department of Computer
mobile security, and software protection. Engineering at Konkuk University. His research
interests include real-time scheduling, software
Y. Jeong received the B.E. degree protection, and computer security.
in computer engineering from
Dankook University, Korea, in M. Park received the B.E., M.E.,
2012 and the M.E. degree in and Ph.D. degree in Computer
computer science and engineering Engineering from Seoul National
from t-he Dankook University, University in 1991, 1993, and
Korea, in 2013. He is a Ph.D. 2005, respectively. He is now a
student in Computer science and professor in Konkuk University,
engineering at the Dankook Rep. of Korea. His research
University. His current research interests include interests include operating
computer security and mobile security. systems, real-time scheduling,
embedded software, computer system security, and
S. Cho received the B.E., the HCI. He has authored and co-authored several journals
M.E. and the Ph.D. in Computer and conference papers.
Engineering from Seoul National
University in 1989, 1991 and
1996 respectively. He joined the
faculty of Dankook University,
Korea in 1997. He was a visiting
scholar at Department of EECS,
University of California, Irvine,
USA in 2001, and at Department of Electrical and
Computer Engineering, University of Cincinnati, USA
in 2009 respectively. He is a Professor in Department
of Computer Science and Engineering (Graduate
school) and Department of Software Science
(Undergraduate school), Dankook University, Korea.
His current research interests include computer
security, smartphone security, operating systems, and
software protection.