comparative analysis of mobile app reverse engineering...

Comparative Analysis of Mobile App Reverse EngineeringMethods on Dalvik and ART

Geonbae Na, Jongsu Lim, Kyoungmin Kim, and Jeong Hyun Yi∗

Soongsil University, Seoul, 06978, Korea{nagb, jongsu253, mseckkm, jhyi}@ssu.ac.kr

Abstract

The runtime system for the Android platform has changed to ART. ART differs from previouslyused Dalvik in that it is to be a runtime environment for the application’s machine code. As a re-sult, ART does not execute Dalvik bytecode through an interpreter but executes the machine codeitself, leading to high performance and many other benefits. This change in runtime system alsohas many implications for mobile security. While we can anticipate with certainty the resurgence ofmodified malicious activity or malicious applications previously used with Dalvik or the emergenceof completely new structures of malicious techniques, we can no longer ascertain the feasibility ofthe analysis techniques and analysis tools used against these malicious applications that operated inDalvik. To combat future potential malicious techniques for ART, we must first have a clear under-standing of ART and, with this foundation, to effectively and accurately utilize the correct analysistechnique. Thus, this paper serves to introduce an analysis on the operating method and architectureof ART and, based on this information, address the executable feasibility of the analysis techniquesin ART. Furthermore, we present the test results of running these analysis tools and techniques inART.

Keywords: Android runtime, reverse engineering, dynamic analysis

1 Introduction

The Android platform has been using Dalvik Virtual Machine (Dalvik) as the runtime environment but,due to limitations in performance from of its structural characteristic of using a virtual machine and othercomplex factors such as hardware resource performance improvement, has begun to use a new runtimeenvironment called ART (Android runtime) instead of Dalvik starting from Version 5.0. The architectureof Dalvik uses the interpreter method to run the application based on Dalvik bytecode while ART uses thecompiler method to run the application using machine code obtained through ahead-of-time complicationof the Dalvik bytecode.

We are at a point where, following this change in runtime environment, a preliminary examinationof the new needs and limitations of the existing android application analysis techniques and tools isneeded. As of now, because versions 4.1-4.3 (Jellybean) and 4.4 (Kitkat), which use Dalvik, take upover 50% of the Android platform, the existing dynamic analysis tools used in Dalvik can be usedfor reverse engineering. However, in the soon to be upgraded versions 5.x (Lollipop) and version 6.0(Marshmallow), most of the applications are run in ART.

As a result, there may be cases in the future where vulnerabilities or the structural characteristicsin ART can be manipulated so that a code runs as normal code in Dalvik but as malicious code inART. In this case, it will prove difficult to use as is the dynamic analysis tools based on QEMU (QuickEmulator)[7] which heavily relies on Dalvik for code analysis.

Journal of Internet Services and Information Security (JISIS), volume: 6, number: 3 (August 2016), pp. 27-39∗Corresponding author: School of Software, Soongsil University, Seoul, 06978, Korea, Tel: +82-2-828-7360

27

Analysis of Mobile App Reverse Enginnering Methods Na, Lim, Kim, and Yi

Since its advent, Android has been the main target of continuous malicious behavior such as privilegeescalation attack[13], information leakage[16], rootkit[11], etc. Furthemore, the number of maliciouscode targeting Androids will not soon diminish, and with the runtime system currently changing, thereis the possibility of a resurgence of mobile malicious applications that had been previously weededout in addition to the emergence of malicious applications with new techniques. It is most likely thatdevelopers of malicious applications will discover and abuse vulnerabilities in the new runtime systemand bypass the existing application analysis tools that are suited for Dalvik to induce false positives andfalse negatives.

In response, to address ahead of time mobile malicious code that is soon to appear, this paper sets outto examine the operational method and architecture of ART through source code analysis. We analyzeand confirm through running experiments whether the various static and dynamic analysis schemes usedin Dalvik can effectively run in the ART environment. Furthermore, we introduce the latest ART basedmalicious code analysis techniques and tools.

This paper is organized as follows. In Section 2, we analyze the architecture of the ART systemand, in Sections 3 and 4, we explain each of the existing static analysis techniques and dynamic analysistechniques and the feasibility of using these technique in ART. Section 5 presents the experiment resultsof running static and dynamic analysis in the ART environment. Lastly, we make our conclusion inSection 6.

2 Android Runtime

In this section, we examine the ART based operating structure that has been applied since Androidversion 4.4 (KitKat) and compare it to Dalvik to analyze the differences in-between. While ART wasexperimentally applied to Android version 4.4 (KitKat), under that version the default runtime systemwas still Dalvik, and ART could be selected as the runtime system as an option for the developer. After-wards, starting from Android version 5.0 (Lollipop), Dalvik was completely gone, and ART began to beused as the default runtime system.

Figure 1: Comparison on installation and run methods of Android applications

With the change in runtime system, the biggest changes in application installation and execution

28


times are shown in Figure 1. In the case of Dalvik, the DEX file in the distributed APK was optimizedusing the dexopt tool and the ODEX file generated, while for ART, the DEX file is compiled using thedex2oat tool and the OAT file is generated. The ODEX file is the actual executable file with Dalvik and,while almost identical to the original DEX file, is partially optimized so that opcode is partly changed.On the other hand, the OAT file in ART is a file in ELF format, completely different from the originalDEX file, and includes the machine code generated through the compilation process.

2.1 Dex File Format

Because the format of the input file for both Dalvik and ART is DEX, in this section we provide a briefoverview of the DEX file structure. The DEX file is composed of many various sections, as shown inFigure 2.

Figure 2: DEX File Format

The header section contains the overall information of the DEX file while the strings ids sectioncontains all the file’s strings. All the information regarding type is included in the type ids section,and all the information regarding prototype is in the proto ids section. Information regarding the field,method, and class is in the field ids, method ids, class defs sections respectively. Lastly, the datasection, the constant pool of the java class file compiled by javac, contains information such as the stringor method name.

2.2 OAT File Format

The OAT file, a file compiled through AOT (Ahead-of-Time) compilation, is an execution file that re-places the ODEX file for Dalvik.

In the case of ART, while an application is being installed, it goes through the AOT compilation pro-cess where the DEX file is converted into the OAT file using dex2oat within the device. More precisely,the file generated using dex2oat is not the OAT file itself but the ELF formatted file that includes the

29


Figure 3: OAT File Format

compiled OAT file[9]. This file, shown in the left side of Figure 3, is comprised of ELF Header, and theoatdata and oatexec sections[14][15], while the three symbols oatdata, oatexec, oatlastword exist inthe dynamic symbol table while each points to the beginning of the oatdata section, the beginning ofthe oatexec section, and the end of the oatexec section respectively (See Figure 4).

Figure 4: Dynamic Symbol Table

OatHeader: The OAT file, made of the oatdata section and oatexec section, has its own header. OatHeadercontains the magic value, file version information, OatHeader’s alder-32 checksum, DEX filecount, instruction set, and the offset information of the oatexec section. The oatexec sectionincludes the machine code compiled based on the Dalvik bytecode.The OAT file version for Android 6.0 (Marshmallow) is Version 064 and for Android 5.1 (Lol-lipop MR1) is Version 045. With no more portable mode from Android 6.0 onward, there havealso been changes in OatHeader. As can be seen in Figure 5, there are fields relating to portablemode in the current Version 045 such as portable imt conflict trampoline offset andportable resolution trampoline offset, while in Version 064 the corresponding field iscompletely gone.

In addition, we can identify the command used to generate the corresponding OAT file usingkey value store, the last field of OatHeader. Figure 6 shows the content of key value store

from extracting the OAT file of the test application installed in Android 5.1. --zip-location

represents APK file’s path while --oat-location represents the location of where the OAT file

30


Figure 5: OatHeader Structure Comparison

generated through the compilation process will be placed. Next, --instruction-set is an optionthat indicates to compile instructions as a specific instruction set. The basic value is arm, butarm64, mips, mips64, x86, and x86 64 are also supported. However, depending on the Androidversion, sometimes only part of the enumerated instruction set is supported.

Figure 6: Example of dex2oat command line

OatDexFile: Right after OatHeader is one or more OatDexFiles – as many as the number of DEXfiles there are in oatdata. The number of DEX files in the OAT file can be known using thedex file count field in the aforementioned OatHeader.OatDexFile is comprised of brief information regarding the DEX file and includes the path,CRC32 checksum, and offset of the DEX file as well as the OatClass offset for the DEX filein array form (See Figure 7).

Figure 7: OatDexFile Structure

DEX File: One or more DEX file may exist between OatDexFile and OatClass, as in Figure 8. Ifan application is installed, the classes.dex file is included in the oatdata section of the OAT filein the APK file. While generally only one DEX file exists, for boot.oat files including Androidframeworks such as core-libart.jar, framework.jar, etc., many DEX files exist and, as explained

31


before, there are as many OatDexFiles containing information regarding DEX files as there areDEX files.

Figure 8: DEX File in oatdata section

OatClass: After the DEX file, there is one or more OatClass, the total number being however asmany DEX file classes there are. In the DEX file header, there is a class defs size field thatrepresents the number of classes contained in the DEX file, which also indicates the number ofOatClass.OatClass contains general information regarding the class and method of the application. Alongwith information on whether the class and method were both compiled error free during the com-pilation process or whether only a part of the method was compiled, there is also information onthe type and member method of the class. The member method information is managed in arrayform using methods pointer field. Each element of the array, in OatMethod form, is made ofinformation directly related to the machine code such as the actually AOT compiled machine codeof the method and the method header.

2.3 Compilation Methods

With Dalvik, JIT (Just-in-time) compilation was used. JIT compilation is a method of improving theapplication’s execution performance by dynamically compiling the Dalvik bytecode into machine codeevery time the application is run. JIT with Androids, to minimize the resulting overhead from the ma-chine code compilation process, does not compile the application’s entire Dalvik bytecode but compilesinto machine code a uniform number of parts that are repeatedly executed.

On the other hand, ART uses AOT (Ahead-of-time) compilation to compile the Dalvik bytecode intomachine code in advance when the application is installed. While JIT compilation compiles only partsof the application into machine code, AOT compilation targets the entire application for compilation.

As the abovementioned process occurs during installation of an application, there are drawbacks inhaving a longer installation time than the current time as well as in needing a greater amount of storagespace. However, compared to the early mobile devices with limited internal storage capacity, most oftoday’s mobile devices support sufficient storage capacity, so the issue of storage space is no longer

32


counted as a drawback. Rather, because the machine code is compiled in advance, the machine code nolonger needs to be dynamically generated every time the application runs, resulting in greater memoryefficiency and longer battery life as well as better run performance.

2.4 File Analysis Tools

The DEX file, compared to the OAT file, relatively has more information on file structure. Even for-mally, the DEX file structure is disclosed, and a number of analysis and research materials have beencollected over the years. As a result, the various existing tools explained in Section 3 (eg., apktool[1],baksmali[2], etc.) can be used to analyze the DEX file. Even if a tool does not exist, it is possible torun an analysis up to a certain point by solely using information on the structure of DEX file.

On the other hand, the OAT file, carrying limited information compared to DEX file, can be analyzedusing Android’s basic system utility oatdump. The main function of oatdump is to process the contentin OAT file format and to provide it in a format that is discernable to the user. oatdump largely providesinformation on OatHeader and OatClasses. Because the OatHeader, as explained before, includesinformation regarding the OAT file version, instruction set, machine code start position, checksum, com-mands and options used when generating the OAT file, etc., we can determine general information re-garding the OAT file by dumping OatHeader information. Containing important information such asbytecode and machine code, mapping table, etc. through the compiled information of each class and themethods within each class, OatClasses can be considered the focus of core analysis. However, becauseoatdump simply dumps all of the OAT file’s content, if the file size gets bigger, the dumped contentbecomes so large that analysis becomes somewhat difficult. Furthermore, with information regardingthe entire DEX file structure, excluding Dalvik bytecode, not separately provided, analysis from variousangles can become complicated.

oatdump++[6], modified and enhanced from oatdump, provides a greater variety of functions thandoes the current oatdump such as class list extraction, method list extraction, filtered classes dump,filtered methods dump, DEX file extraction, etc. While oatdump++ is based on oatdump but offeredseparately, because the main functions of oatdump++ are currently merged in AOSP (Android OpenSource Project), the various functions provided by oatdump++ can be used starting from Android 6.0.Comparison of Dalvik and ART can be summerized as Table 1.

Dalvik ARTFile Format DEX OAT + DEXCompilation Method JIT AOTFile Analysis Tool apktool, baksmali, etc oatdump(oatdump++)

Table 1: Comparison of Dalvik and ART

3 Static Analysis

Static analysis refers to analysis of the application without running the application using the application’ssource code or object code. This section investigates whether the static analysis methods used in Dalvikcan also be applied in the ART environment.

3.1 Analysis Tools

Android static analysis tools can be grouped into diassemblers and decompilers and, depending onwhether they support analysis of Dalvik bytecode and machine code, can be organized as Table 2.

33


Disassemblers Description Bytecode Machine codeApktool Disassembles Dalvik bytecode into Smali code Yes No

Dedexer[3] ” Yes NoOatdump OAT file dump Yes Yes

Oatdump++ Provides additional functions than Oatdump Yes YesIDA Disassembles Dalvik bytecode and machine code Yes Yes

Decompilers Description Bytecode Machine codeDex2jar & jad Reconstruct Dalvik bytecode into Java source code Yes No

JEB Provicdes automated decompilation function Yes No

Table 2: Static Analysis Tools for Android

Using analysis tools that targeted the DEX file, the analysis methods can be applied on the DEX fileincluded in the OAT file or the DEX file in the distributed APK. To analyze the new OAT file structureand machine code, oatdump or GDB can be used.

As analysis tools for OAT files, as explained in Section 2.4, there is oatdump and oatdump++. Fun-damentally they provide the disassemble function for Dalvik bytecode and machine code and additionallyprovide information of the OAT file format, thus supporting analysis of OAT file.

Another static analysis tool besides those two is commercial software IDA. In the case of IDA, itprovides the disassemble function for both machine code and Dalvik bytecode. When the input is anOAT file, IDA provides a disassemble function for machine code regardless of the Dalvik bytecodelocated in the oatdata section within the OAT file while if the input is an APK file, IDA disassemblesthe DEX file within the APK file. Thus, while IDA provides disassemble functions for both machinecode and Dalvik bytecode, with one input, it cannot identify the two code formats simultaneously. Toanalyze both machine code and Dalvik bytecode, it needs both the APK (or DEX) file and OAT file.

3.2 Applicability on ART

For Android applications, the smali code obtained using apktool or baksmali or the java code restoredusing dex2jar becomes the target of static analysis. In the Dalvik environment, the main static analysismethod was to, after either extracting the APK file from the application or downloading it, to disassem-ble the DEX file (classes.dex) in the APK file using the apktool, while simultaneously decoding theresources to analyze not only the application’s code[12] but the various elements of the application’s ar-chitecture. This kind of method is also still effective in the current ART environment due to the followingreason.

Figure 9 has taken Figure 1, which showed the change during the installation and execution of theapplication, and has focused on the differences during the time of nd the run stage, there are no differ-ences in distribution. In ART as well, the application that the developer finally distributesdistribution.While Dalvik and ART have quite stark differences during the installation stage of the application ontothe device a is still distributed in the APK file format, and users install them onto their devices from avariety of markets and websites. Because application developers and users, regardless of the type of run-time system, are utilizing the familiar, existing mechanism, due to the nature of static analysis where theactual execution of the application is unnecessary, existing methods and tools can be applied for analysisin the ART environment as well.

34


Figure 9: Difference between Dalvik and ART in application distribution

4 Dynamic Analysis

Dynamic analysis is the analysis of the application’s operational behavior by running the application.In this section, we examine whether the existing Dalvik-based dynamic analysis methods for Androidapplications are applicable in the ART environment.

4.1 Analysis Tools

The main dynamic analysis tools that have been used are shown in Table 3.

Name Description Bytecode Machine codeNetBeans Provides Dalvik bytecode debugging function Yes No

GDB Provides machine code debugging function No YesIDA Provides Dalvik bytecode & machine code debugging function Yes Yes

DroidScope[5] Provides real-time Dalvik bytecode extraction function Yes No

Table 3: Dynamic Analysis Tools for Android

4.2 Applicability on ART

One of the reasons for continuing to leave the entire Dalvik bytecode into the OAT file despite havinggenerated the machine code based on the Dalvik bytecode during application installation in the ARTenvironment can be understood by relating it to dynamic debugging.

When an ART-based Android application is generally run, it is made to run using the compiledmachine code, while in the case of methods with events such as break point or watch configured inan environment in the process of debugging, it is made to reset the method’s entry point so that theapplication is run using Dalvik bytecode. This structure would run in Dalvik-based dynamic debuggingenvironments for Androids using JDWP (Java Debug Wire Protocol) which, we surmise, was to maintainthe system structure as is. Consequently, dynamic analysis of an application in ART or the usage ofexisting JDWP-based debugging tools should be possible.

35


5 Experiments

5.1 Static Analysis

Static analysis experiments show that the new runtime system and the previous existing system run withthe same exact mechanism with no mentionable difference. The steps for static analysis are delineatedbelow[10].

First, the application’s APK file is extracted (or downloaded). While there are slight differences inthe APK file pathway according to the Android version, they are similar overall.

Second, obtain the smali code or Java code using the prepared in advance diassembler and decom-piler. Excluding cases where a separate protection mechanism is applied to the application, the majorityof the tools will allow the analyzer to obtain the code in any form he or she wants. Using the obtainedcode as the basis, the analysis can now begin in earnest as shown in Figure 10.

The two steps mentioned above are applicable in both Dalvik and ART, the reason being that, duringdistribution time, the executable file format is the same DEX file within the APK file for both.

Figure 10: Disassembled output using IDA: machine code (Left) and Dalvik bytecode (Right)

5.2 Dynamic Analysis

NetBeans provides dynamic debugging for Dalvik bytecode, while GDB provides dynamic debuggingfor machine code. Operating through JDWP, Netbeans was usable in Dalvik, which allows JDWP. Be-cause, fundamentally, the method is executed based on machine code in ART and ART also allowsJDWP, we tested for whether, when debugging, the method would be once again executed using Dalvikbytecode. We modified the OAT file so that the Dalvik bytecode and machine code of a method thatoutputs the log would each output a different string, as seen in Figure 11.

Figure 11: Modified bytecode and machine code example

While the string “Say Good-Bye” is output until the method’s events are triggered using dynamicdebugging tools such as Netbeans or IDA, we were able to confirm that the string “Say Hello” wasoutput when a debugging event is configured. Judging from the code shown in the tool as well as the

36


string “Say Hello” as seen in Figure 12, we could see that it was Dalvik bytecode rather than method’smachine code that functioned as the basis of dynamic debugging.

Figure 12: Dalvik bytecode dynamic debugging using Netbeans in ART environment

Thus, in the case of dynamic debugging methods using JDWP, the debugging function is providedby forcibly changing the entry point of the method in ART, while with using GDB on the other hand, theactually executed machine code of the method is able to be debugged as shown in Figure 13.

Figure 13: Dynamic debugging of machine code using GDB

Because this experiment forcibly constructed Dalvik bytecode and machine code, it showed the dif-ferences in results when debugging while, generally, the Dalvik bytecode and machine code of OAT filesare only different in form and will generate the same results. In addition, QEMU based dynamic analysistools such as DroidScope, Andrubis, DroidBox[4], Taintdroid[8] provide functions such as extractingDalvik instruction as well, they all having a strong dependency on Dalvik.

6 Conclusion

In this paper, to smoothly deal with the new malicious applications soon to appear due to the Androidplatform’s new change in runtime system, we analyze the main changes in the runtime system and in-troduce related static analysis methods and dynamic analysis methods. We were able to confirm that,with the exception of dynamic analysis tools that use the QEMU emulator, which heavily depends onDalvik, most of the existing analysis tools and methods were still effective with the change in runtimesystem. The fact that the existing analysis tools are effective also means that the current various analysis

37


prevention methods are also effective. However, in the future, we predict that malicious applications thatabuse the vulnerabilities in ART or take advantage of its structural characteristic and such will gradu-ally emerge. Thus, with the appearance of new malicious code in the future, the ART system structureanalysis results presented in this paper will help contribute toward effective analysis of the maliciouscode.

AcknowledgmentsThis research was supported by the Global Research Laboratory (GRL) program through the NationalResearch Foundation of Korea (NRF) funded by the Ministry of Science, ICT, and Future Planning(NRF-2014K1A1A2043029).

References[1] Apktool. http://ibotpeaches.github.io/Apktool [Online; Accessed on August 5, 2016].[2] Baksmali. https://github.com/JesusFreke/smali [Online; Accessed on August 5, 2016].[3] Dedexer. http://dedexer.sourceforge.net/ [Online; Accessed on August 5, 2016].[4] Droidbox. https://github.com/pjlantz/droidbox/ [Online; Accessed on August 5, 2016].[5] Droidscope. https://github.com/sycurelab/DECAF/ [Online; Accessed on August 5, 2016].[6] Oatdump++. https://github.com/anestisb/oatdump_plus/ [Online; Accessed on August 5, 2016].[7] Qemu. http://wiki.qemu.org/ [Online; Accessed on August 5, 2016].[8] Taintdroid. http://www.appanalysis.org/ [Online; Accessed on August 5, 2016].[9] M. Backes, O. Schranz, and P. von Styp-Rekowsky. Poster: Towards compiler-assisted taint tracking on the

android runtime (art). In Proc. of the 22nd ACM SIGSAC Conference on Computer and CommunicationsSecurity (CCS’15), Denver, Colorado, US, pages 1629–1631. ACM, October 2015.

[10] J.-H. Jung, J. Y. Kim, H.-C. Lee, and J. H. Yi. Repackaging attack on android banking applications and itscountermeasures. Wireless Personal Communications (WPC), 73(4):1421–1437, December 2013.

[11] S. Kim, J. Park, K. Lee, I. You, and K. Yim. A brief survey on rootkit techniques in malicious codes. Journalof Internet Services and Information Security (JISIS), 2(3/4):134–147, November 2012.

[12] S. W. Park and J. H. Yi. Multiple device login attacks and countermeasures of mobile voip apps on android.Journal of Internet Services and Information Security (JISIS), 4(4):115–126, November 2014.

[13] Y. Park, C. Lee, J. Kim, S.-J. Cho, and J. Choi. An android security extension to protect personal informationagainst illegal accesses and privilege escalation attacks. Journal of Internet Services and Information Security(JISIS), 2(3/4):29–42, November 2012.

[14] P. Sabanal. State of the art exploring the new android kitkat runtime. Hack In TheBox Security Conference, 2014. https://www.corelan.be/index.php/2014/05/29/

hitb2014ams-day-1-state-of-the-art-exploring-the-new-android-kitkat-runtime/

?output=pdf [Online; Accessed on August 5, 2016].[15] P. Sabanal. Hiding behind art. Black Hat, 2015. https://www.blackhat.com/docs/asia-15/

materials/asia-15-Sabanal-Hiding-Behind-ART-wp.pdf [Online; Accessed on August 5, 2016].[16] S. Sakamoto, K. Okuda, R. Nakatsuka, and T. Yamauchi. Droidtrack: Tracking and visualizing informa-

tion diffusion for preventing information leakage on android. Journal of Internet Services and InformationSecurity (JISIS), 4(2):55–69, May 2014.

——————————————————————————

38

http://ibotpeaches.github.io/Apktool

https://github.com/JesusFreke/smali

http://dedexer.sourceforge.net/

https://github.com/pjlantz/droidbox/

https://github.com/sycurelab/DECAF/

https://github.com/anestisb/oatdump_plus/

http://wiki.qemu.org/

http://www.appanalysis.org/

https://www.corelan.be/index.php/2014/05/29/hitb2014ams-day-1-state-of-the-art-exploring-the-new-android-kitkat-runtime/?output=pdf



https://www.blackhat.com/docs/asia-15/materials/asia-15-Sabanal-Hiding-Behind-ART-wp.pdf

https://www.blackhat.com/docs/asia-15/materials/asia-15-Sabanal-Hiding-Behind-ART-wp.pdf


Author Biography

Geonbae Na received the B.S. degree in Computer Science and Engineering and theM.S. degree in Software Convergence from Soongsil University, Seoul, Korea, in2014 and 2016, respectively. His research interests include mobile application secu-rity, mobile platform security and Reverse Engineering.

Jongsu Lim received the B.S. degree in Computer Science and Engineering fromSoongsil University, Seoul, Korea, in 2016. Currently he is taking a master’s coursein Software Convergence from Graduate School of Soongsil University. His researchinterests include mobile application security, mobile platform security and ReverseEngineering.

Kyoungmin Kim received the B.S. degree in Computer Science and Engineeringfrom Soongsil University, Seoul, Korea, in 2016. Currently he is taking a master’scourse in Software Convergence from Graduate School of Soongsil University. Hisresearch interests include mobile application security, mobile platform security andReverse Engineering.

Jeong Hyun Yi is an Associate Professor in the School of Software and a Director ofMobile Security Research Center at Soongsil University, Seoul, Korea. He receivedthe B.S. and M.S. degrees in computer science from Soongsil University, Seoul, Ko-rea, in 1993 and 1995, respectively, and the Ph.D. degree in information and com-puter science from the University of California, Irvine, in 2005. He was a PrincipalResearcher at Samsung Advanced Institute of Technology, Korea, from 2005 to 2008,and a member of research staff at Electronics and Telecommunications Research In-

stitute (ETRI), Korea, from 1995 to 2001. Between 2000 and 2001, he was a guest researcher at NationalInstitute of Standards and Technology (NIST), Maryland, U.S. His research interests include mobilesecurity and privacy, IoT security, and applied cryptography.

39

comparative analysis of mobile app reverse engineering...

Documents