Server-based code obfuscation scheme for APK tamper detection

Transcription

1 SECURITY AND COMMUNICATION NETWORKS Security Comm. Networks 2016; 9: Published online 10 March 2014 in Wiley Online Library (wileyonlinelibrary.com)..936 SPECIAL ISSUE PAPER Server-based code obfuscation scheme for APK tamper detection Yuxue Piao, Jin-Hyuk Jung and Jeong Hyun Yi* School of Computer Science and Engineering, Soongsil University, Seoul, Korea ABSTRACT It is easy to decompile Android applications (or apps) owing to the structural characteristics of the app building process, but this ease makes them quite vulnerable to forgery or modification attacks. In particular, users may suffer direct financial loss if this vulnerability is exploited in security-critical private and business applications, such as online banking. One of the solutions to these problems is a code obfuscation technique. In this regard, DexGuard, which is based on ProGuard, which is integrated into the Android software development kit build system, has recently been introduced. Although DexGuard protects Android applications more effectively, an attacker is still able to analyze the hex code of a Dalvix Executable file. To resolve this weakness, we begin by analyzing the DexGuard tool from both a static and dynamic point of view. Our analysis reveals that DexGuard has some weaknesses. In this paper, we propose an obfuscation technique based on a client/server model with one-time secret key delivery using short message service or network protocol. The main concept is to store the core execute class file through obfuscation on the server, so when a program needs to execute core routines, it must request these routines from the server. In this way, we can protect Android apps from reverse engineering. Copyright 2014 John Wiley & Sons, Ltd. KEYWORDS APK tamper detection; repackaging attack; code obfuscation; reverse engineering *Correspondence Jeong Hyun Yi, School of Computer Science and Engineering, Soongsil University, Seoul, Korea. jhyi@ssu.ac.kr 1. INTRODUCTION As a relative latecomer to the smartphone market, one of the top priorities of Android-based smartphones is openness. Accordingly, the Android market the key market in which applications are distributed is also run in an open manner. Anyone can register as an application developer, self-sign developed applications, and register an application without having to go through a complicated procedure. This kind of open policy in which anyone can publish applications on the market has one fundamental weakness: applications containing malicious code can be published just as easily. In addition, Android applications can be easily decompiled owing to their structural characteristics [1], in which applications are developed using Java and are self-signed so that applications modified in this way can be repackaged [2]. In this current situation that has this inherent vulnerability, an increasing number of Android-based financial service applications, including banking applications or mobile wallets [3], are finding their way into users hands. One of the solutions to these problems is a code obfuscation technique. Obfuscation is used to make reverse engineering of source code or machine code more difficult. It is used to transform a code into a form that is functionally identical to the original form but is much more difficult to understand. ProGuard [4] is a renaming identifiers obfuscator that is integrated into the Android software development kit. It takes care of only the renaming identifiers obfuscation [5], and using this method, the original opcodes remain unchanged. DexGuard [6], which is based on ProGuard, has more recently been introduced. It supports control flow randomization [7] and class encryption in addition to renaming identifiers obfuscation, hides sensitive APIs, and provides string encryption. Although DexGuard protects Android applications more effectively than ProGuard, an attacker is still able to analyze the hex code of a Dalvik Executable (DEX) [8] file. We thus begin by analyzing the DexGuard tool from both a static and dynamic point of view. Our analysis reveals that DexGuard has some weaknesses. Accordingly, we propose a new obfuscation and protection scheme for APK [9] that DexGuard is unable to support. The proposed obfuscation is based on a client/server model with one-time secret key delivery using short message service (SMS) or network protocol. We remove the core classes and tamper detection routine to server in order to protect them more effectively. This paper is organized as follows. Section 2 outlines the research that has already been performed in the area Copyright 2014 John Wiley & Sons, Ltd. 457

2 Server-based code obfuscation scheme for APK tamper detection Y. Piao, J.-H. Jung and J. H. Yi of obfuscation, paying particular attention to the main obfuscation technique that is applied to Java or Android applications and obfuscation tools, and in this part describes in detail the various features of an Android application. This includes the DEX file format and DEX opcodes. Section 3 discusses DexGuard weakness through reverse engineering the obfuscated APKs. In Section 4, we introduce our proposed scheme, which is based on serverbased obfuscation. Finally, in Section 5, we offer a number of suggestions about our proposed obfuscation scheme, and Section 6 summarizes our conclusions. 2. RELATED WORK There has been a lot of research into code obfuscation in recent decades. Most of this research has addressed native code obfuscation in order to protect Executable and Linkable Format files or Portable Executable files. Today, as Java-based applications have grown increasingly popular, issues related to managing code obfuscation have become a major subject of research. In Java, five major obfuscation features are applied in practice: renaming identifiers obfuscation, control flow randomization, string encryption, application programming interface (API) hiding, and class encryption. On the basis of these obfuscation features, a number of commercial obfuscation software products have added a tamper detection feature as an extra layer of protection. Figure 1 shows the classification of Java obfuscation technique. Renaming identifiers obfuscation involves replacing the original names of the classes, fields, and methods with meaningless words. Because Java is an object-oriented language, the names of the classes, fields, and methods contain meaningful information about the software s architecture. By replacing these names with meaningless names, it takes more time to reverse the application architecture. The aim of control flow randomization is to mislead the decompiler into adding some junk bytecode or using an opaque predicate [10]. This technique is used for protecting the logic of the method and variables. String encryption is a kind of encryption of the string constant in a Java application. After applying this technique, the original string constant is changed into encrypted data. When the application uses the string constant, it will invoke the decryption method that was added by the obfuscator. API hiding is used to prevent a static analysis from discovering the core API uses. To achieve this goal, in Java, the reflection mechanism is used. As a result, the obfuscator encrypts every descriptor. The mechanism for encrypting an entire class is referred to as class encryption. When an application uses the original classes, it decrypts these classes first and loads them into a virtual machine memory pool. Strictly, tamper detection is not kind of obfuscation. But there are some obfuscation tools that support tamper detection as protection mechanism. A number of Java code obfuscation tools have been introduced recently. For this study, we selected the most popular tools, namely ProGuard, DexGuard, and Allatori [11], and compared their key characteristics. Table I shows a comparison of the key features of these obfuscation tools. As can be seen in the table, ProGuard supports only the renaming identifiers technique, but it is open source, which is why it is widely used. DexGuard and Allatori, on the other hand, support a number of other features. We analyze the features of DexGuard in more detail in Section 3. In order to obfuscate or deobfuscate APK, we need to understand the concept of DEX format and bytecode for Dalvik virtual machine (DVM). A DEX file is an executable file for DVM that has a more compact structure than a class file. Figure 2 shows the overall layout of a DEX file. Every section except the header, data, and link_data sections contains an offset value. Further, in the data section, all the detailed data are stored for data compaction. Figure 1. Classification of Java obfuscation technique. 458 Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd.

3 Y. Piao, J.-H. Jung and J. H. Yi Server-based code obfuscation scheme for APK tamper detection Table I. Comparison of obfuscation tool features. ProGuard DexGuard Allatori Renaming identifiers Yes Yes Yes Control flow randomization No Yes Yes String encryption No Yes Yes API hiding No Yes No Class encryption No Yes No Tamper detection No Yes No API, application programming interface. Opcodes are stored in the class_def section, which defines the class information. In a Dalvik bytecode specification, every instruction has its own format, so we must calculate the boundary for each instruction. When reading the bytecode of instructions, we choose the first single byte and look it up in the instruction manual. Figure 3 shows how to translate binary codes into mnemonics. In this sample, 0x12 represents const/4, which means that it assigns a 4-bit value to the first operand virtual register. It also indicates that we need to read one more byte. The next byte is 0x00, which means that the instruction assigns a value of 0x0 to the virtual register zero. Let us then look at the next group of opcode and operand. The next first byte is 0x35, which represents the if-ge mnemonic. We thus need to read three more bytes to obtain the entire meaning. 3. THE WEAKNESS OF DEXGUARD Figure 2. Overall layout of Dalvix Executable file. The header section contains the magic number for the DEX file that is used for file type identification. In addition, it contains the checksum field, which can detect file corruption, and the signature field, which uniquely identifies files. The string_ids section has the offset of the string value used by the application. The type_ids section lists the descriptor for the method or class. The proto_ids section contains the prototype for the method, but the opcodes of the method are in the class_ids section. The field_ids section describes the information of the fields, which are defined in classes or are used in classes or methods. The method_ids section has the name of the method and the class to which the method belongs. The class_defs section has the details of the class, such as the field, method, and the opcodes of the method. We are also able to read the binary code for the bytecode using the DEX file format, because disassembly is more correct than decompiling. Many reverse engineers use the smali/backsmali tool [12], which is an assembler/disassembler tool that converts a binary DEX file into an instruction mnemonic defined by a Dalvik bytecode [13]. DexGuard manipulates a DEX file to obfuscate it. To do so, it changes two major parts of the file. One part is a constant pool that contains the string_ids, type_ids, proto_ids, field_ids, and method_ids sections, and the other part is the class area, which contains the Dalvik opcode. By default, DexGuard uses a renaming dictionary in which the characters exist in a unicode set but are semantically meaningless in human languages. These kinds of unicode sets cannot be displayed well in a typical system because most of the font sets do not implement the useless fonts defined in unicode sets. Before analyzing or forging the APK, the attacker must find the proper unicode font to display the result correctly. We can rename entire classes again to deobfuscate the renaming obfuscation using dex2jar [14]. The string_ids typically contains the descriptors for the class, the field, and the method. However, all the original Figure 3. Bytecode to mnemonic translation. Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd. 459

4 Server-based code obfuscation scheme for APK tamper detection Y. Piao, J.-H. Jung and J. H. Yi descriptors have disappeared because the hiding of the sensitive API functions. To hide these important descriptors, DexGuard uses a reflection API in order to replace the typical Java programming methodology. When using reflection, the descriptor of the API changes to strings, so that hiding an API feature produces a kind of string encryption. DexGuard adds a descriptor decryption method for the encrypted descriptor. Before the routines reference the class or invoke the method, the descriptor decryption method is invoked. In addition, data from the encrypted descriptors are stored in an array, which is a feature for hiding sensitive APIs. After decrypting the descriptors, the reflected bytecodes added by DexGuard are invoked in order to load and run the proper classes. Thus far, we have explained the mechanism for hiding sensitive APIs. Because of the reflection API identity, an obfuscated DEX file must have certain kinds of reflection API descriptors in the data section. String encryption is similar to hiding sensitive APIs. DexGuard encrypts the string data and adds a decryption method for the strings. Every time the program uses a string, it invokes this decryption method for strings. At this point, we can inject the print instruction after invoking the string decryption method. In response, the decrypted strings are displayed on the console and are used by the application. Using the same method, we can also discover the hidden API descriptors. A more important feature is class encryption. Figure 4 shows how DexGuard encrypts a class. When applying this feature, DexGuard generates another class using a class decryption method we refer to as a package class. The entire program references the encrypted class through the package class. Although DexGuard provides a good solution to protecting APK against repacking attacks, we still find that it has some weaknesses. For example, certain debugging opcodes can be injected into an obfuscated DEX file. From our investigation, we found that DexGuard uses the data encryption standard (DES) algorithm [15] to encrypt the class using a secret key that is discovered in the decryption routine. In a new version, we found DexGuard changes the DES algorithm to advanced encryption standard algorithm. Figure 5 shows DexGuard how to encrypt the SecretClass and the application how to decrypt the encrypted class. At first reverse engineering, we found one secret key named Array_9c0 (every application has different name), initial vector named Array_9c8, and two encrypted binary data Array_9d0 and Array_b44, which existed in byte array in DEX file. When the obfuscated APK executes, the decryption method for encrypted class will run first. It uses secret key 1 named Array_9c8 and initial vector to decrypt the first array data Array_9d0. After Array_9d0 is decrypted, a new zip file format data will be created. Because of the first data array starts PK magic number and end with PK. This zip file contains a new classes.dex, we decompile the new Dex file using baksmali. There is one class that contains another secret key 2 and initial vector 2 for encrypted data Array_b44. So, we use secret key 2 and initial vector 2 to decrypt Array_b44. We found the disassembled smali code logic is the same as original source code logic. To increase the complexity of its obfuscation method, DexGuard adds control flow randomization to each obfuscation mechanism. For example, the errors occur, when decompiling the decryption method for encrypted classes. After analysis, it was found that the reason for the error phenomenon is that DexGuard reorders a number of opcodes, a process that has no effect on the logic and that adds some opaque predicates to the method. Finally, DexGuard supports tamper detection. When a programmer develops his or her own applications, he or she simply calls the tamper detection API to ensure the integrity of the Android application. With this protective mechanism, when a DEX file is modified by an attacker, the tamper attack routine finds out that the entire application has changed and directs the application to run an alert instead of running the original routines. Figure 6 shows the original tamper detection routine and how it can be bypassed. A brief description of this process is as follows. First, the tamper detection routine checks the entire DEX file and returns a value. Opcode if-nez indicates whether the return value is non-zero, which means that the APK cannot run properly. We therefore add a fake zero value using the instruction const/4 p1, 0x0 in the code section in order to trick the entire application. As we can see, the attacker can remove the bytecodes of the tamper detection or can skip the tamper detection routine and remake a fake application [16]. DexGuard delivers many obfuscation features. In any case, we can restore the original string by invoking the Figure 4. DexGuard class encryption concept. 460 Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd.

5 Y. Piao, J.-H. Jung and J. H. Yi Server-based code obfuscation scheme for APK tamper detection Figure 5. DexGuard encryption mechanism. decrypt string method. We can also gain access to the hidden API by injecting the print descriptor opcodes. In addition, we can also analyze and find the encrypted classes. The most difficult parts of the process are removing the opaque predicates or understanding the reordered opcodes. Therefore, an attacker may be able to reproduce a fake application. This possibility can make it possible for mission-critical applications such as banking apps to be attacked. For this reason, we need a more effective and improved obfuscation and protection mechanism to protect such Android applications. 4. PROPOSED SCHEME In this paper, we propose a server-based obfuscation scheme to protect the encrypted classes and the tamper detection routine more securely. The main idea is to move the tamper detection routine and the encrypted core class onto the server side and to deploy the decryption key from the server for the encrypted classes [17]. Figure 7 shows the conceptual architecture of the proposed scheme. The original APK program is divided into two parts. One is a subroutine, and the other is a core routine stored on the server. Both routines are obfuscated using typical obfuscation methods such as renaming identifiers obfuscation, control flow randomization, and string obfuscation; the core routine adds tamper detection routines. As a first step, we divide the original DEX files. For this purpose, we employ the ASMDEX library [18], which is a kind of framework that supports the direct manipulation of a DEX file at the bytecode level. In practice, this kind of division is performed by separating the string_ids, type_ids, proto_ids, field_ids, method_ids, class_defs, and data sections. After separating these sections, the data structure elements in each section must be rearranged. In addition, every time the binary code of the DEX file is changed, we must recalculate the values of the checksum field and the signature field in the header section. Figure 8 shows the process of dividing the original DEX file. In the second step, we can optionally apply the typical obfuscation mechanism cited in Section 2. Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd. 461

6 Server-based code obfuscation scheme for APK tamper detection Y. Piao, J.-H. Jung and J. H. Yi Figure 6. Bypassing the tamper detection routine. Figure 7. Overall concept of the proposed scheme. 462 Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd.

7 Y. Piao, J.-H. Jung and J. H. Yi Server-based code obfuscation scheme for APK tamper detection Figure 8. Dalvix Executable file division process. In the third step, we repackage the stub DEX file into the APK file that will be deployed on the client s phone. At the same time, the core DEX file is stored on the server along with the client s DEX file signature value. We use the DES algorithm to encrypt the core DEX file and deploy the key from the server each time. In the third step, we also develop the server-side program so it is coordinated with the obfuscation tool. The serverside program runs as follows. When a client executes a program, the client requests the core routine. Next, the server sends the encrypted core routine, which contains a number of classes and the tamper detection routine. The core routines are delivered via any network protocols built in smartphones; for example, the hypertext transfer protocol. Simultaneously, the server sends a secret key to the user s mobile phone using an SMS or Internet protocol. In this paper, we simply choose hypertext transfer protocol to transfer core DEX and secret key. The delivered secret key is used to encrypt/decrypt the core routine each time. We will later describe how a random secret key is generated every time. After decrypting the core DEX file at the client side, it must be loaded by the client s DVM. In Java, there is a reflection API that can help load the classes dynamically during the runtime. The mechanism of this process is similar to the hidden API mechanism mentioned in Section 3. Figure 9 shows the loading process for the core classes. Unlike in Java virtual machine, in DVM, we must use the dalvik.system.dexfile API in order to load the core classes dynamically. We prewrite the Java code in the client stub using a reflection API with predefined descriptor strings. Finally, the subclient loads the decrypted core routine in a DVM and executes the tamper detection process. Once the integrity of the client DEX file is confirmed, the core Figure 9. Core class loading process. routine starts to run the main process. Figure 10 shows the architecture of the proposed obfuscation system. Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd. 463

8 Server-based code obfuscation scheme for APK tamper detection Y. Piao, J.-H. Jung and J. H. Yi Figure 10. Architecture of the proposed obfuscation system. The key for encrypting the core classes can be generated by any random number generator every time. In this study, though, we employ a hash chain mechanism [19] based on one-time password generation. We choose a random string, which is used to calculate the hash value. Using this hash value, we recalculate the hash of the previous hash. Let us suppose that we perform this kind of calculation n times. That is, h k ðpþ :¼ hh ð k 1 ðpþþ; 0 < k < n; where h 0 ðpþ ¼ hp ð Þ We use each of the hash values in the reverse order of the hash calculation as a secret key to encrypt thecoredexfile, except for the last hash value h n (P), where P is a master secret and h n (P) is installed as an integrity checking value in smartphones. For example, h n-i (P) is selected as i-th secret key, denoted by SK i ;Thatis,SK i = h n-i (P). Suppose the core class management server will encrypt the core class with SK i and then send it to the smartphone at the client side. At the client side, when the protected application receives SK i through SMS channel, the stub routine applies the hash function i times on SK i in order to verify Table II. Notations. Notations ID A SK i BDEX EDEX Sig V DEX, Dalvix Executable. Description Identifier of application i-th secret key Original DEX Encrypted DEX Signature for client DEX Return value for validation Figure 11. Proposed obfuscation procedure. 464 Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd.

9 Y. Piao, J.-H. Jung and J. H. Yi Server-based code obfuscation scheme for APK tamper detection its integrity by comparing h i (SK i ) with the preinstalled h n (P). If the both values are identical, then the client uses the received secret key SK i to decrypt the core DEX file. On successive occasions, the secret key that the client receives is changed every time without generating a random number. After successfully decrypting and loading the core classes, the core routine executes the overall the tamper detection routine. It opens the DEX of the current APK and reads the signature bytes in the header section of the DEX. At the same time, the tamper detection routine requests the stored signature value via the network and compares the two values in order to determine whether it has been modified. Table II lists the notations used in this section. Figure 11 shows the tamper detection procedure of the proposed obfuscation scheme. Send(ID A ) means sending an identification of application for request the core routines. On the server side, if the ID A is legitimate, then the server generates a secret key and encrypts the core DEX file. As a response to the client, RES(EDEX, SK) indicates response the client with encrypt DEX and secret key as parameters. After the client receives the encrypt core DEX and secret key, the decrypt routine runs. Next, the client loads core DEX file into Dalvik virtual machine and executes the tamper detection that is located in core classes. Send (Sig) shows the signature for client DEX sent by tamper detection routine. The core class management server determines if the client s signature is correct and then it will return the confirmation value. 5. DISCUSSION All the typical obfuscation methods we mentioned in Section 2 can be directly applied to our proposed system. In any case, the complete logic of the program remains with the client. An attacker may be able to analyze a hex code of an executable file and determine how it is structured. If, however, the complete logic of the program is divided and stored in different locations, the attacker must calculate all possible locations and combine all the pieces of information. After an attacker successfully combines all the information that remains obfuscated by typical obfuscation methods, the attacker must then analyze the obfuscated program. We also move the tamper detection routine from the client to the server-side management routines. This mechanism protects the tamper detection routine from being bypassed. There is network communication in our proposed scheme, so the attacker may attack core DEX management system by SYN flooding attacks. This problem is out of our discussion in this paper, but we can develop additional security mechanism such as detection of SYN flooding [20]. We change the deployment of the secret key for class encryption. DexGuard carries out class encryption and stores the secret key in an opcode. An attacker can find out the secret key and decrypt the encrypted classes. For this reason, we store the secret key on the server and deploy the key through an SMS channel or network protocol during runtime. Each time the secret key is changed, its timeliness and newness are guaranteed, making it more secure. We said the secret key will be delivered through SMS or network. The two methods all have pros and cons. In Figure 12. Difference between DexGuard and the proposed scheme. Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd. 465

10 Server-based code obfuscation scheme for APK tamper detection Y. Piao, J.-H. Jung and J. H. Yi practical, if we choose SMS way, the user must input the secret key for execution. This mechanism reduces usability but prevents man-in-middle attack. On the other hand, the server deploys the secret key via network protocol, so the client will run the loading core DEX process silently without interrupt users. This mechanism increase usability, but the attacker may analyze the secret key on network. Our proposed scheme obfuscates applications by storing them in two different spaces. This kind of mechanism costs the attacker attempt reverse engineering at least twice, because the attacker must analyze the stub routines to figure out how the program runs. After that, the attacker must reanalyze the core routines that are sent by server. Figure 12 shows structural difference between DexGuard and the proposed scheme. In practical, the core class management server can use cloud computing [21] to reduce maintenance cost. Another concern is about calculating hash value algorithm for secret key. One of good algorithm is an improved fast and secure hash algorithm [22]. If the protected application is focused on security, we can use bank one time password (OTP) system module [23] to deploy secret key. The limitation of our proposed scheme is as follows. The client must access the network, so it may cost user s communication fee. 6. CONCLUSION Decompiler/disassembler technology is powerful, so a protection mechanism for APK modification attacks must be developed. Code obfuscation and protection can be applied to the Android platform in order to hinder reverse engineering and protect against such repackaging attacks. We investigated the well-known obfuscation tool DexGuard and discovered that it had a design weakness that makes it possible for the secret key for the encryption class to be discovered in the bytecode itself, along with the decryption module. In response to this discovery, we proposed a serverbased code obfuscation scheme. We showed that moving the tamper detection routines to the server side offered a more effective guarantee of the integrity of the APK. In addition, a scheme that involves storing the core class on the server side prevents an attacker from analyzing the main routine. In conclusion, it is expected that the proposed APK obfuscation and protection scheme will provide a much more competitive approach than is provided by existing obfuscation tools, such as DexGuard, specifically with regard to tamper detection of APK files. ACKNOWLEDGEMENTS This research was supported in part by the Ministry of Science, ICT & Future Planning, Korea, under the Information Technology Research Center support program (NIPA-2013-H ) supervised by the National IT Industry Promotion Agency, and in part by the National Research Foundation of Korea funded by the Ministry of Education (NRF-2013R1A1A ). REFERENCES 1. Enck W, Octeau D, McDaniel P, Chaudhuri S. A study of Android application security. USENIX Security Symposium, Jung JH, Kim JY, Lee HC, Yi JH. Repackaging attack on Android banking applications and its countermeasures. Journal of Wireless Personal Communication 2013; 73: Ma G, Yi JH. Design and Implementation of smart channel establishment schemes for mobile wallet services. Advanced Science Letters 2012; 9: ProGuard. (Accessed December 2012). 5. Cimato S, De Santis A, Ferraro Petrillo U. Overcoming the obfuscation of Java programs by identifier renaming. The Journal of Systems and Software 2005; 78: DexGuard. (Accessed December 2012). 7. Hou TW, Chen HY, Tsai MH. Three control flow obfuscation methods for Java software. IEE Proceedings-Software 2006; 153: Dex. dex-format.html (Accessed December 2012). 9. APK Collberg C, Thomborson C, Low D. Manufacturing cheep, resilient, and stealthy opaque constructs. ACM Symposium on Principles of Programming Languages, 1998; Allotori. (Accessed December 2012). 12. Smali/baksmali. (Accessed December 2012). 13. Dalvik bytecode. (Accessed December 2012). 14. Dex2jar. (Accessed December 2012). 15. Stallings W. Cryptography and Network Security. Pearson Education: Upper Saddle River, NJ, USA, Piao YX, Jung JH, Yi JH. Deobfuscation analysis of DexGuard code obfuscation tool. The International Conference on Computer Applications and Information Processing Technology, 2013; Yi JH, Piao YX, Jung JH, Choi EH, Cho SH. File server, file transfer method thereof and file 466 Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd.

11 Y. Piao, J.-H. Jung and J. H. Yi Server-based code obfuscation scheme for APK tamper detection tamperproof system. Patent App. No.: KR , ASMDEX Lamport L. Password authentication with insecure communication. Communications of the ACM 1981; 24(11): Wang SG, Sun QB, Zou H, Yang FC. Detecting SYN flooding attacks based on traffic prediction.security and Communication Networks 2012; 5(10): Pan Y, Zhang J. Parallel programming on cloudcomputing platforms challenges and solutions. Journal of Convergence 2012; 3(4): Agarwal S, Rungta A, Padmavathy R, Shankar M, Rajan N. An improved fast and secure hash algorithm. Journal of Information Processing Systems 2012; 8(1): Tsai C, Chen C, Zhuang D. Trusted M-banking verification scheme based on a combination of OTP and biometrics. Journal of Convergence 2012; 3(3): Security Comm. Networks 2016; 9: Copyright 2014 John Wiley & Sons, Ltd. 467