System and method for code obfuscation of application

Provided is a method and system for code obfuscation of an application. A method configured as a computer may include receiving an application program package that includes an intermediate language (IL) code generated by compiling code for an application including a plurality of classes and a plurality of methods as a dex file over a network, selecting a protection target class or a protection target method from among the plurality of classes and the plurality of methods, encrypting the selected protection target class or the selected protection target method by retrieving and encrypting an IL code corresponding to the selected protection target class or the selected protection target method from the dex file, and adding decryption information for decrypting the encrypted protection target class or the encrypted protection target method to a secure module that is further included in the application program package.

BACKGROUND

Field

One or more example embodiments relate to a system, apparatus, non-transitory computer readable medium, and/or method for code obfuscation of an application.

Description of Related Art

An intermediate language or InterLanguage (IL) refers to a language that goes through an intermediate stage of a process of generating a target language program by translating a source language program using a compiler. For example, if a machine language program is generated by converting a high-level language program to an assembly language, and then by assembling the assembly language into machine language code (e.g., machine code, or machine readable code), the assembly language may be considered the intermediate language.

According to the related art, an IL conversion apparatus and method for a mobile platform includes a C/C++ compiler configured to convert a mobile platform source code developed with a C or C++ language to an IL code required at an interpreter of a mobile communication terminal, and an IL assembler configured to convert the IL code to a format executed at the interpreter of the mobile communication terminal.

However, code of an application that goes through conversion to the IL is vulnerable to decompiling due to one or more characteristics of the code (e.g., code characteristics). For example, code of an application written in a programming language, such as Java, needs to go through conversion (e.g., compilation or interpretation, etc.) into an IL, and thus, the intermediate code is vulnerable to decompiling. Accordingly, important code is easily exposed and is also vulnerable to code manipulation. As a more specific example, code written in Java is generally compiled to a file with an extension “.class” for each class of the application. On Android, code written in Java is compiled to a dex file including a header and data, such as “classes.dex”. Here, the dex file is bytecode that is a binary code compiled from an IL code in which a Java code is compiled. Once a Java program is converted into bytecode, the bytecode may be transmitted as a compiled format of the Java program over a network and executed by a Java virtual machine.

Files that have been compiled in a form of an IL code may be provided, for example, from a server to an electronic device and may be executed on a virtual machine supported by the electronic device. Accordingly, the electronic device may acquire and correct (e.g., manipulate, change, modify, etc.) the original code by decompiling the compiled files based on a characteristic of an IL and may compile again (e.g., recompile) the corrected code to the files that are compiled in the form of IL codes. Accordingly, the application may be forged.

SUMMARY

One or more example embodiments provide a system, apparatus, non-transitory computer readable medium, and/or method that may prevent forgery of an application through decompiling by selecting and encrypting code corresponding to a primary class and method from among codes of the application and by decrypting the encrypted code in a runtime.

According to an aspect of at least one example embodiment, there is provided a method executed using at least one computer, the method including receiving, using at least one processor, an application program package over a network, the application program package including intermediate language (IL) code generated by compiling code for an application as a dex file, the application including a plurality of classes and a plurality of methods, selecting, using the at least one processor, at least one protection target class or at least one protection target method from the plurality of classes and the plurality of methods, encrypting, using the at least one processor, the selected protection target class or the selected protection target method, the encrypting including retrieving and encrypting IL code corresponding to the selected protection target class or the selected protection target method from the dex file, and adding, using the at least one processor, decryption information to a secure module that is further included in the application program package, the decryption information for decrypting the encrypted protection target class or the encrypted protection target method.

The receiving may include receiving selection information for designating a class or a method over the network, and the selecting may include selecting the class or the method designated using the received selection information as the protection target class or the protection target method.

The selecting may include retrieving a class or a method corresponding to a desired function of the application from among the plurality of classes and the plurality of methods, and selecting the retrieved class or the retrieved method as the protection target class or the protection target method.

The desired function may include at least one of a billing function at a service provided through the application, an authentication function at the service, and a communication function with a server providing the service.

The dex file may include a header that stores a number indicating a total number of classes included in the plurality of classes, and an offset of a class table, each of the classes of the plurality of classes may include an address offset of a method table with respect to a method included in each of the classes of the plurality of classes, and the encrypting may include retrieving IL code corresponding to the protection target class using the class table, or retrieving IL code corresponding to the protection target method using the method table.

The method may also include selecting, using the at least one processor, the decryption information based on a runtime scheme at an electronic device on which the application program package is to be installed, and the adding may include adding the decryption information to the secure module of the application program package, or generating a plurality of different application program packages using difference pieces of decryption information each corresponding to a plurality of runtime schemes, and adding each of the different pieces of decryption information to a corresponding secure module of the generated plurality of different application program packages.

The decryption information may include information associated with an address offset of the encrypted IL code, a size of the encrypted IL code, and a key used for encryption for a case in which an electronic device executes the application using Dalvik runtime.

The encrypted protection target method may be decrypted at the electronic device by loading the encrypted IL code included in the dex file to a memory of the electronic device, locating the encrypted protection target method in the encrypted IL code based on the address offset of the encrypted IL code included in a dex header of the dex file, decrypting code corresponding to a size of the encrypted IL code corresponding to the encrypted protection target method using the key, and overwriting the decrypted code on the dex header.

The decryption information may include the dex file, and the dex file may include (1) a class including the encrypted protection target method or a class index of the encrypted protection target method, (2) a method index of the encrypted protection target method, and (3) the protection target class or the protection target method for a case in which an electronic device executes the application using Android runtime (ART).

The encrypted protection target method may be decrypted at the electronic device by compiling the dex file included in the decryption information using a converter, by acquiring a native code of the protection target class or the protection target method, by retrieving the encrypted IL code using the class index and the method index from a header of the dex file loaded to a memory of the electronic device, and by overwriting a native code corresponding to the encrypted IL code among the acquired native codes on the retrieved encrypted IL code.

The method may further include updating a cyclic redundancy check (CRC) and a hash value of the dex file changed in response to encrypting the IL code.

The method may further include transmitting, to an electronic device, the application program package in which the IL code is encrypted and the decryption information is added in response to a request from the electronic device over the network.

According to an aspect of at least one example embodiment, there is provided a method executed using at least one computer, the method including receiving, using at least one processor, from a server over a network, an application program package that includes intermediate language (IL) code generated by compiling code for an application as a dex file and decryption information included in a secure module, the IL code including a plurality of classes and a plurality of methods and in which at least a portion of the IL code is encrypted, and the decrypted information is for decrypting the encrypted IL code, decrypting, using the at least one processor, the encrypted IL code using the decryption information or by replacing the encrypted IL code with an IL code included in the decryption information, and executing the decrypted IL code based on a runtime scheme applicable during an execution process of the application, wherein the encrypted IL code is generated by encrypting an IL code of a protection target class or a protection target method selected at the server from among the plurality of classes and the plurality of methods of the application.

According to an aspect of at least one example embodiment, there is provided a system of at least one server including one or more processors. Each of the one or more processors is configured to execute computer readable instructions to, receive an application program package over a network, the application program package including intermediate language (IL) code generated by compiling code for an application as a dex file, the application including a plurality of classes and a plurality of methods, select at least one protection target class or at least one protection target method from the plurality of classes and the plurality of methods, encrypt the selected protection target class or the selected protection target method, the encrypting including retrieving and encrypting IL code corresponding to the selected protection target class or the selected protection target method from the dex file, and add decryption information to a secure module that is further included in the application program package, the decryption information for decrypting the encrypted protection target class or the encrypted protection target method.

According to at least one example embodiment, it is possible to reduce and/or prevent forgery of an application through decompiling by selecting and encrypting code corresponding to a primary class and method from among codes of the application and by decrypting the encrypted code at runtime.

It should be noted that these figures are intended to illustrate the general characteristics of methods and/or structure utilized in certain example embodiments and to supplement the written description provided below. These drawings are not, however, to scale and may not precisely reflect the precise structural or performance characteristics of any given embodiment, and should not be interpreted as defining or limiting the range of values or properties encompassed by example embodiments.

DETAILED DESCRIPTION

A support system according to example embodiments may be configured through an electronic device and/or a serve to be described in the following, and a support method according to example embodiments may be performed by the electronic device or the server. For example, the electronic device may perform the support method for the electronic device under control of an application executed on the electronic device. A computer program, such as the application, may be stored in a non-transitory computer-readable storage medium to perform the support method in conjunction with the electronic device. As another example, the server that provides a messaging service and manages a social network between users through the messaging service may perform the support method.

FIG. 1is a diagram illustrating an example of a network environment according to at least one example embodiment. Referring toFIG. 1, the network environment includes a plurality of electronic devices110,120,130, and140, a plurality of servers150and160, and a network170, but is not limited thereto.FIG. 1is provided as an example only and thus, a number of electronic devices and/or a number of servers are not limited thereto.

Each of the plurality of electronic devices110,120,130, and140may be a fixed terminal or a mobile terminal configured as a computing system. For example, the plurality of electronic devices110,120,130, and140may be a smartphone, a mobile phone, a personal navigation device, a computer, a laptop computer, a digital broadcasting terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), a tablet personal computer (PC), a gaming console, a wearable device, an Internet of Things (IOT) device, a virtual reality device, an augmented reality device, and the like. For example, the electronic device110may communicate with other electronic devices120,130, and/or140, and/or the servers150and/or160over the network170in a wired communication manner and/or in a wireless communication manner.

The communication scheme is not particularly limited and may include a communication method that uses a near field communication between devices as well as a communication method using a communication network, for example, a mobile communication network, the wired Internet, the wireless Internet, a broadcasting network, a satellite network, etc., which may be included in the network170. For example, the network170may include at least one of network topologies that include networks, for example, a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), a broadband network (BBN), the Internet, and the like. Also, the network170may include at least one of network topologies that include a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or hierarchical network, and the like. However, it is only an example and the example embodiments are not limited thereto.

Each of the servers150and160may be configured as an apparatus or a plurality of apparatuses that provides instructions, codes, files, contents, services, and the like through communication with the plurality of electronic devices110,120,130, and/or140over the network170.

For example, the server150may provide a file for installing an application to the electronic device110connected through the network170. In this case, the electronic device110may install the application using the provided file. Also, the electronic device110may access the server160under control of at least one program, for example, browser or the installed application, or an operating system (OS) included in the electronic device110, and may use a service or content provided from the server160. For example, when the electronic device110transmits a service request message to the server160through the network170under control of the application, the server160may transmit code corresponding to the service request message to the electronic device110and the electronic device110may provide content to a user by configuring and displaying a screen according to the code under control of the application.

FIG. 2is a block diagram illustrating an example of a configuration of an electronic device and a server according to at least one example embodiment.FIG. 2illustrates a configuration of the electronic device110as an example for a single electronic device and illustrates a configuration of the server150as an example for a single server, however the example embodiments are not limited thereto.

Referring toFIG. 2, the electronic device110may include a memory211, a processor212, a communication module213, and an input/output (I/O) interface214, and the server150may include a memory221, at least one processor222, a communication module223, and/or an I/O interface224, but is not limited thereto. The memory211,221may include a permanent mass storage device, such as random access memory (RAM), read only memory (ROM), a disk drive, a solid state drive, a flash memory, etc., as a non-transitory computer-readable storage medium. Also, an OS and at least one program code, for example, code for a browser installed and executed on the electronic device110or the application, etc., may be stored in the memory211,221. Such software components may be loaded from another non-transitory computer-readable storage medium separate from the memory211,221using a drive mechanism. The other non-transitory computer-readable storage medium may include, for example, a floppy drive, a disk, a tape, a DVD/CD-ROM drive, a memory card, etc. According to other example embodiments, software components may be loaded to the memory211,221through the communication module213,223, instead of, or in addition to, the non-transitory computer-readable storage medium. For example, at least one program may be loaded to the memory211,221based on a program, for example, the application, installed by files provided over the network170from developers or a file distribution system, for example, the server150, which provides an installation file of the application.

The at least one processor212,222may be configured to process computer-readable instructions of a computer program by performing basic arithmetic operations, logic operations, and I/O operations. According to at least one example embodiment, the processor212,222may be a single processor, a multi-core processor, a multi-processor system, a distributed processing system, a cloud computing system, etc. The computer-readable instructions may be provided from the memory211,221and/or the communication module213,223to the at least one processor212,222. For example, the at least one processor212,222may be configured to execute received instructions in response to the program code stored in the storage device, such as the memory211,222.

The communication module213,223may provide a function for communication between the electronic device110and the server150over the network170, and may provide a function for communication between the electronic device110and/or the server150and another electronic device, for example, the electronic device120or another server, for example, the server160. For example, the processor212of the electronic device110may transfer a request, for example, a streaming service request for the content, created based on a program code stored in the storage device such as the memory211, to the server150over the network170under control of the communication module213. Inversely, a control signal, an instruction, content, a file, etc., provided under control of the processor222of the server150may be received at the electronic device110through the communication module213of the electronic device110by going through the communication module223and the network170. For example, a control signal, an instruction, content, a file, etc., of the server150received through the communication module213may be transferred to the processor212or the memory211, and content, a file, etc., may be stored in a storage medium further includable in the electronic device110.

The I/O interface214,224may be a device used for interface with an I/O device215. For example, an input device may include a keyboard, a mouse, a microphone, a camera, etc., and an output device may include a device, such as a display, for displaying a communication session of the application. As another example, the I/O interface214may be a device for interface with an apparatus in which an input function and an output function are integrated into a single function, such as a touch screen. In detail, when processing instructions of the computer program loaded to the memory211, the processor212of the electronic device110may display a service screen configured using data provided from the server150or the electronic device120, or may display content on a display through the I/O interface214.

According to other example embodiments, the electronic device110and the server150may include a greater or lesser number of components than a number of components shown inFIG. 2. However, there is no need to clearly illustrate many components according to the related art. For example, the electronic device110may include at least a portion of the I/O device215, or may further include other components, for example, a transceiver, a global positioning system (GPS) module, a camera, a microphone, a variety of sensors, a database, and the like.

FIG. 3illustrates an example of a format of a dex file including classes and methods according to at least one example embodiment,FIG. 4illustrates an example of displaying classes and methods selected as protection targets from among classes and methods included in a dex file according to at least one example embodiment, andFIG. 5illustrates an example of displaying encryption of classes and methods selected as protection targets according to at least one example embodiment.

Referring toFIG. 3, a dex file300may include N classes and n methods for each class, but the example embodiments are not limited thereto. For example, while the example embodiments refer to the Java programming language and/or elements of the Android operating system, the example embodiments are not limited thereto and may be implemented using other programming languages, such as Basic, C, C++, C #, Objective C, Python, Perl, Lisp, Javascript, Fortran, COBOL, HDL, SQL, etc., and/or operating systems/runtime execution environments, such as iOS, Windows, MacOS, Linux, Unix, etc. Referring back toFIG. 3, each of N and n denotes a natural number. AlthoughFIG. 3illustrates an example in which n methods are includes for each class, a number of methods includable for each class may vary for each class. The dex file300may be included in an Android application package (APK) developed by developers and may be transmitted and registered to a system, such as the server150, for code protection. For example, the server150may provide an APK registration service to users, for example, users desiring to register the APK, such as a developer, through, for example, a webpage, an application, etc. In detail, a user interface capable of registering the APK may be provided to a user that accesses a webpage provided from the server150using the electronic device120, through the webpage.

Here, the server150may extract the dex file300, such as a ‘classes.dex’ file from the APK uploaded through the webpage and may select a class and/or a method to be protected.

A dex file400ofFIG. 4shows a protection target class, a non-protection target class, a protection target method, and a non-protection target method in the dex file300ofFIG. 3, however the example embodiments are not limited thereto. InFIG. 4, the protection target class and/or the protection target method is not actually generated. For clarity of description,FIG. 4illustrates an example in which corresponding classes and/or methods are selected as protection targets. Although a class (and/or metaclasses, superclass, subclass, objects, templates, constructors, databases, etc.) is a protection target, all of the methods (and/or functions, subroutines, instances, structures, data structures, tables, etc.) included in the class may not be a protection target. In other words, one or more methods, or a subset of methods, included in a protection target class may be a protection target(s). For example, refer to class 1 and class N. That is, an actual protection target may be a method unit. As another example, if a class is a protection target, all or some of the methods included in the class may be configured to be selected as protection targets.

The protection target class and/or the protection target method may be selected based on an input from a user. For example, a webpage provided to the user may include a user interface that allows the user to input or select a class and/or a method to be protected. Once information associated with the class or the method to be protected is input through the webpage, the server150may verify the class and/or the method to be protected as shown in the dex file400. Information input from the user may be a prefix of the class and/or the method, a class domain, and/or a name of the class or the method.

According to another example embodiment, the server150may directly select a class and/or a method of a desired and/or preset function. For example, the server150may retrieve and select a class and/or methods corresponding to a billing function at a service provided to users through the application, an authentication function at the service, a communication function with a server, for example, the server160, providing the service, and the like. To this end, the server150may verify a list of classes or methods through a function, such as an API call for a developer system, may retrieve a class or a method from the list of classes or methods, and may select the class or the method as a protection target class and/or a protection target method.

As described above, the dex file400may include compiled bytecode, for example, IL code, and the server150may retrieve bytecode corresponding to the selected class and method. For example, a total number of classes and an offset (e.g., an address offset) of a class table may be stored in a header of the dex file400, and an offset of a method table may be stored in each class. Accordingly, the server150may retrieve a desired bytecode in order of a class, a method, and/or a bytecode using the class table and the method table to retrieve a specific bytecode from the dex file400.

A dex file500ofFIG. 5is an example in which methods selected as protection targets in the dex file400ofFIG. 4are encrypted. Once bytecodes of selected methods are obfuscated through encryption, information (hereinafter, ‘decryption information’) for decrypting the encrypted bytecodes may be added to the APK. For example, decryption information may be recorded in a native module, for example, a secure module that is written with extension “.so” and included in the APK with an execution code and distributed. The decryption information may vary based on a runtime scheme, for example, Dalvik runtime and Android runtime (ART), Objective C, Java Virtual Machine, etc., on an electronic device, for example, the electronic device110, on which the application is executed. Since a plurality of methods may be encrypted, decryption information may be recorded in a form of an array for each method that is a protection target, but the example embodiments are not limited thereto.

For example, in Android, a dex file may be executed at Dalvik runtime on a Dalvik machine, for example, virtual machine, or an OAT file may be executed at ART on an ART machine. The Dalvik machine converts an application code to a native machine language code and executes code through a just-in-time (JIT) compilation of going through the conversion procedure every time the user executes the application (e.g., compiling and/or interpreting classes and/or methods, etc., of the application that are called and/or used by the application into machine code at run-time, etc.). The ART machine may convert the dex file to the OAT file using a converter called ‘dex2oat’ and may execute the converted OAT file. That is, when installing the application, the ART machine converts the application to a native application and installs the converted native application through an ahead of-time (AOT) compilation (e.g., compiling all of the classes and/or methods, etc., of the application into machine code prior to run-time and/or execution, etc.). Accordingly, in the case of using the ART, a new virtual machine, for example, the aforementioned Dalvik machine, may be generated every time the application is executed and an execution time of an interpreted code may be removed. Accordingly, a different piece of decryption information may need to be transferred based on a different runtime scheme. In this case, decryption information for two runtime schemes may be recorded in the native module so that the APK provided from the server150may be executed using the two runtime schemes. An APK for Dalvik runtime and an APK for ART may be separately generated and an appropriate APK may be transmitted based on a corresponding electronic device.

Initially, decryption information for the Dalvik runtime may include an offset of a bytecode corresponding to a protection target method (substantially, an offset of an encrypted bytecode), a size (bytes) of the corresponding bytecode, a size (bytes) of the encrypted bytecode, and/or a key used for encryption, but is not limited thereto.

Also, decryption information for the ART may include a class index (information regarding which class and/or identifying the class) including the protection target method (e.g., encrypted method) and a method index (information regarding which method in a corresponding class and/or identifying a method of the class) of the corresponding protection target method. A dex file including a protection target class and a protection target method before encryption may be recorded in the native module.

In addition, since a cyclic redundancy check (CRC) and/or a hash value of the dex file that were previously computed using the original application are changed due to encryption of the method, the server150may recalculate the changed CRC and/or hash value using the encrypted code and may update the CRC and/or the hash value of the dex file.

The APK that includes the dex file in which the protection target method is encrypted may be transmitted to and installed on an electronic device, for example, the electronic device110.

For example, on the Dalvik runtime, the electronic device may retrieve a dex header by parsing an odex header from the dex file, for example, ‘classes.dex’, loaded to the memory using, for example, a JNI_Onload function. Here, the dex file loaded to the memory may be an odex file present in a Dalvik-cache, and most bytecodes excluding bytecodes of a portion of classes are interpreted at a point in time at which a corresponding code is actually executed (e.g., at run-time), but the example embodiments are not limited thereto. In this case, the electronic device may decrypt data followed by the dex header based on the decryption information. For example, the electronic device may decrypt encrypted bytecodes by decrypting a size of a corresponding encrypted bytecode from an offset of a corresponding method using a key recorded on the native module based on decryption information recorded on the native module in a form of an array, etc., for each protection target method, and by overwriting the decrypted bytecode at a corresponding location.

Also, on the ART, the electronic device may secure native codes of the protection target class and the protection target method by executing a ‘dex2oat’ instruction, that is, an instruction for converting codes of the protection target class and the protection target method to native codes, by using, as a factor, the dex file recorded on the native module. For example, the dex file may include the protection target class and the protection target method before encryption, but is not limited thereto. As described above, on the ART, code of an application may be converted to a native code through an AOT compilation and thereby installed when installing the application, but is not limited thereto. On the ART, the electronic device may retrieve the dex file, for example, ‘classes.dex’, loaded to the memory using the JNI_Onload function. Here, since the dex file loaded to the memory substantially has an OAT file format, code may not be acquired using a general scheme, for example, a scheme using a dlopen function, etc. Accordingly, the electronic device may retrieve an OAT header and may retrieve, from the OAT header, a desired native code through a method index and class index included in decryption information. For example, the OAT header may be retrieved using an address (indicating an OAT header) of an OAT data symbol (oatdata symbol) and an address of an OAT execution symbol (oatexec symbol) acquired using a function, for example, a dlsym function, etc., of returning an address of a desired function. The electronic device may process decryption by overwriting the native codes of the protection target class and the protection target method on the native codes retrieved through the method index and the class index included in the decryption information. In detail, the electronic device may retrieve an OAT class that is represented by the OAT header and at the same time, corresponds to the class index and may retrieve the native code corresponding to the method index from the OAT class.

The Dalvik runtime and the ART are identical in that an encrypted code is decrypted at runtime and different in that an application is installed through a nativization process (a nativization process through compilation using a converter, such as dex2oat, etc.) of an original code on the ART. That is, a scheme of retrieving an encrypted code on the ART differs from that on the Dalvik runtime.

FIG. 6illustrates an example of a process of retrieving an encrypted native code on ART according to at least one example embodiment. Referring toFIG. 6, Classes.dex610may represent a dex file included in an application program package provided to an electronic device. As described above, for example, on the ART, code included in the dex file may be converted to a native code using a converter, such as dex2oat, when installing an application. The dex file loaded to a memory of the electronic device may be, for example, substantially in an Elf share object (extension “.so”) format, and may include an ELF header (Elf Header)621as shown in Classes.dex620. Also, as described above, a format of the dex file may be converted to an OAT file format and may include an OAT header (Oat Header)622. Also, the Classes.dex620may include a dex file meta header (Dex File Meta Header)623and Classes.dex624. The Classes.dex624may correspond to the Classes.dex610that is the dex file before conversion. The Dex File Meta Header623may include meta information associated with the Classes.dex624. The Oat Header622provides information capable of retrieving a desired OAT class (OatClass)625through a class index. Also, the OatClass625provides information (OatMethodOffset)626capable of retrieving code corresponding to a desired method from a native code627through a method index. As described above, the electronic device may acquire a normal native code by converting a dex file (including codes of a protection target class and a protection target method(s) before encryption) included in decryption information using a converter. In this case, the electronic device may decrypt the encrypted protection target method by retrieving code corresponding to the encrypted protection target method from the native code627and by replacing the retrieved code with the normal native code.

FIG. 7is a block diagram illustrating an example of components includable in at least one processor of a server according to at least one example embodiment, andFIG. 8is a flowchart illustrating an example of a method performed by a server according to at least one example embodiment. Referring toFIG. 7, the at least one processor222of the server150may include a reception controller710, a selection controller720, an encryption controller730, and/or an addition controller740, etc., and may selectively further include an update controller750and/or a transmission controller760, but the example embodiments are not limited thereto. Components of the at least one processor222may control the server150to perform operations810through860included in the method ofFIG. 8, and may be configured to operate through at least one program code and an OS included in the memory221to perform the above control. Operations850and860may be selectively included in the method ofFIG. 8depending on example embodiments.

In operation810, the server150may receive an application program package that includes an IL code generated by compiling code for an application including a plurality of classes and a plurality of methods as a dex file over a network. For example, a dex file that includes a bytecode as an IL code generated by compiling code written in Java may be included in the application program package, but the example embodiments are not limited thereto. The reception controller710may control the server150to perform operation810.

Here, the server150may be a system that receives and protects an application program package for a developed application. The server150may be a system of a developer of an application, may be a system of a third party that receives and protects the application program package from the developer, may be a file distribution system that receives the application program package of the developer and distributes the received application program package to users, etc.

In operation820, the server150may select a protection target class or a protection target method from among the plurality of classes and the plurality of methods. The selection controller720may control the server150to perform operation820. The protection target class and/or the protection target method may be selected based on information input from a user, for example, the developer of the application, and/or may be selected by the server150.

According to at least one example embodiment, the server150may further receive selection information for designating a class and/or a method over the network. In this case, the server150may select the class and/or the method designated using the selection information as the protection target class and/or the protection target method.

According to another example embodiment, in operation820, the server150may select a class and/or a method corresponding to a desired and/or preset function of the application from among the plurality of classes and the plurality of methods and may select the retrieved class or the retrieved method as the protection target class and/or the protection target method. For example, the server150may automatically select, as the protection target class and/or the protection target method, a class and/or a method corresponding to at least one of a billing function at a service provided through the application, an authentication function at the service, and/or a communication function with a server, for example, the server160, providing the service, etc., but the example embodiments are not limited thereto. In other words, the server150may analyze the code and select desired functions (e.g., classes, methods, API, code, etc.) directed towards system critical, confidential, financially sensitive, privacy-related, etc., software functions of the code for protection from hackers, snoopers, or the like.

In operation830, the server150may encrypt the selected protection target class and/or the selected protection target method by retrieving and encrypting an IL code corresponding to the selected protection target class and/or the selected protection target method from the dex file. The encryption controller730may control the server150to perform operation830.

For example, the dex file may include a header that stores a number of the plurality of classes (e.g., a count of how many classes are included in the plurality of classes and/or a quantity of the total number of classes, etc.) and an offset (e.g., an address offset, a memory offset, etc.) of a class table, and each of the plurality of classes may include an offset of a method table with respect to a method included in each of the plurality of classes. In this case, the server150may retrieve an IL code corresponding to the protection target class using the class table or retrieve an IL code corresponding to the protection target method using the method table, and may encrypt the retrieved IL code.

In operation840, the server150may add decryption information for decrypting the encrypted protection target class and/or the encrypted protection target method to a secure module that is further included in the application program package. The addition controller740may control the server150to perform operation840.

A different piece of decryption information may be used based on a runtime scheme of an electronic device on which the application program package is to be installed. To this end, in operation840, the server150may add the different piece of decryption information to the secure module of the application program package, or may generate a plurality of different application program packages each in which the difference piece of decryption information is added to the secure module. For example, the server150may add all of decryption information for Dalvik runtime and decryption information for ART to the secure module, but the example embodiments are not limited thereto. As another example, the server150may generate an application program package in which decryption information for the Dalvik runtime is added to the secure module and an application program package in which decryption information for the ART is added to the secure module.

According to at least one example embodiment, the decryption information may include information associated with an offset of the encrypted IL code, a size of the encrypted IL code, and a key used for encryption for a case in which an electronic device executes the application using the Dalvik runtime. In this case, the encrypted protection target method may be decrypted at the electronic device by decrypting code corresponding to a size of the encrypted IL code from the offset of the encrypted IL code from a dex header of the dex file loaded to a memory of the electronic device using the key and by overwriting the decrypted code on the dex header.

According to another example embodiment, the decryption information may include the dex file including (1) a class including the encrypted protection target method and/or a class index of the encrypted protection target method, (2) a method index of the encrypted protection target method, and/or (3) the protection target class (class before encryption) and/or the protection target method (method before encryption) for a case in which the electronic device executes the ART, but the example embodiments are not limited thereto. In this case, the encrypted protection target method may be decrypted at the electronic device by compiling the dex file included as the decryption information using a converter, by acquiring a native code of the protection target class (class before encryption) and/or the protection target method (method before encryption), by retrieving an encrypted IL code using the class index and the method index from a header of the dex file loaded to a memory of the electronic device, and/or by overwriting a native code corresponding to the encrypted IL code among the acquired native codes on the retrieved encrypted IL code.

In operation850, the server150may update a CRC and/or a hash value (e.g., a file integrity or verification check, etc.) of the dex file changed in response to encrypting the IL code. The update controller750may control the server150to perform operation850. If the dex file of the application program package initially transmitted to the server150includes the CRC and/or the hash value, the CRC and/or the hash value need to be updated in response to encryption of the IL code. Accordingly, the server150may calculate a CRC and/or a hash value of the changed dex file and may update the same.

In operation860, the server150may transmit, to the electronic device, the application program package in which the IL code is encrypted and the decryption information is added in response to a request from the electronic device over the network. The transmission controller760may control the server150to perform operation860. If the server150is a file distribution system that distributes the APK to the user, the server150may perform operation860. If the server150is a separate system for protecting the APK, the server150may provide the protected APK to the file distribution system and/or may retransmit the protected APK to the user, for example, the developer, etc.

FIG. 9is a block diagram illustrating an example of components includable in at least one processor of an electronic device according to at least one example embodiment, andFIG. 10is a flowchart illustrating an example of a method performed by an electronic device according to at least one example embodiment. Referring toFIG. 9, the at least one processor212of the electronic device110may include a reception controller910and/or an execution controller920, but is not limited thereto. Components of the at least one processor212may control the electronic device110to perform operations1010and1020included in the method ofFIG. 10, and may be configured to operate through at least one program code and an OS included in the memory211. Here, the at least one program code may be a portion of code included in an application program package received by the electronic device110in operation1010to process operation1020.

Referring toFIG. 10, in operation1010, the electronic device110may receive, from the server150over a network, an application program package that includes an IL code generated by compiling code for an application including a plurality of classes and a plurality of methods as a dex file, and in which at least a portion of the IL code is encrypted, and decryption information for decrypting the encrypted IL code is included in a secure module. The reception controller910may control the electronic device110to perform operation1010. Also, the encrypted IL code may be generated by encrypting an IL code of a protection target class and/or a protection target method selected at the server150from among the plurality of classes and the plurality of methods.

In operation1020, the electronic device110may decrypt the encrypted IL code using the decryption information and/or may replace the encrypted IL code with an IL code included in the decryption information, and may execute the IL code based on a runtime scheme applicable during an execution process of the application. The execution controller920may control the electronic device110to perform operation1020.

As described above, the decryption information may include information associated with an offset of the encrypted IL code, a size of the encrypted IL code, and/or a key used for encryption, etc., for Dalvik runtime. In this case, in operation1020, when the Dalvik runtime proceeds, the electronic device110may decrypt the protection target method by decrypting code corresponding to a size of the encrypted IL code from the offset of the encrypted IL code from a dex header of the dex file loaded to a memory using the key and by overwriting the decrypted code on the dex header.

Also, the decryption information may include the dex file including (1) a class including the encrypted protection target method and/or a class index of the encrypted protection target method, (2) a method index of the encrypted protection target method, and/or (3) the protection target class or the protection target method for ART, etc. In this case, in operation1020, when the ART proceeds, the electronic device110may decrypt the protection target method by compiling the dex file included as the decryption information using a converter, by acquiring a native code of the protection target class or the protection target method, by retrieving the encrypted IL code using the class index and the method index from a header of the dex file loaded to the memory, and/or by overwriting a native code corresponding to the encrypted IL code among the acquired native codes on the retrieved encrypted IL code.

A detailed description is made above and thus, a further description is omitted here.

According to some example embodiments, it is possible to reduce and/prevent forgery of an application through decompiling by selecting and encrypting code corresponding to a primary class and/or method from among codes of the application and by decrypting the encrypted code at runtime.