KR101734663B1 - Method for preventing reverse engineering of android application and apparatus for performing the method - Google Patents

Abstract

A method and apparatus for preventing reverse engineering by supporting encryption and decryption of an executable file by applying an entry point conversion technique in the execution of an Android application is disclosed. A method for preventing reverse engineering of an Android application includes extracting and encrypting an executable file of the Android application; And packaging the Android application so that it includes a stub file that decrypts the encrypted executable file and the encrypted executable file, wherein the stub file is an executable file encrypted based on an entry point conversion technique Decrypted and executed. Therefore, it is possible to effectively prevent the static reverse engineering attack of the Android package by applying the entry point conversion technique to the stub file.

Description

TECHNICAL FIELD [0001] The present invention relates to a method for preventing reverse engineering of an Android application, and a device for performing the reverse application.

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to protection of an Android application, and more particularly, to a method and apparatus for preventing reverse engineering by supporting encryption and decryption of an executable file by applying a conversion technique in execution of an Android application.

Conventionally, in order to prevent static reverse engineering of the Android application, a technique of encrypting a DEX file having source code in an application package and decrypting it after execution is used.

More specifically, a decompression prevention code is added to the source code to generate a DEX file or a form of an application package file (zip file) to encrypt the application. Thereafter, an application package combining the DEX file generated by modifying the application source code and the decryption module of the executable file type is generated, and the decryption module is executed first when the application is executed, or a separate launcher Launcher) or service to decrypt the application before execution, or modify the Android framework or kernel to decrypt and use the encrypted application.

In this case, for encryption or decryption key management, a private key is used through index information of a plurality of classes and methods included in the DEX file, an encryption key is inserted into the application package, or encryption Key, or using a cryptographic algorithm that does not require a separate key, such as XOR.

The above-described conventional techniques can efficiently protect conventional static reverse engineering attacks such as obfuscation and insertion of dummy codes. However, in order to encrypt an Android application, an encryption algorithm that is vulnerable to attack such as XOR is used, Or the decryption key is managed in an unsecured manner, there is a problem that the effect of preventing the static reverse engineering through the encryption can not be efficiently used.

Also, in order to execute an encrypted Android application, the prior art has previously installed a Launcher that executes a separate system service or an application that executes an encrypted Android application in the Android framework or service terminal, There is a limit to the versatility and portability of Android smartphones, which are rapidly developing in various ways, because the application execution code in the Android framework needs to be modified, and the DEX file or source code of the Android application must be arbitrarily changed .

It is an object of the present invention to provide a method for preventing reverse engineering of an Android application based on an entry point conversion technique.

Another object of the present invention is to provide an apparatus for preventing reverse engineering of an Android application based on an entry point conversion technique.

According to an aspect of the present invention, there is provided a method of preventing reverse engineering of an Android application, the method comprising: extracting and encrypting an executable file of an Android application; And packaging the Android application so that it includes a stub file that decrypts the encrypted executable file and the encrypted executable file, wherein the stub file is an executable file encrypted based on an entry point conversion technique Decrypted and executed.

Here, the method for preventing reverse engineering of the Android application may be performed in a developer terminal for developing an Android application or a distribution server for distributing an Android application.

Here, the stub file may be set to be executed first when executing the Android application.

Here, the stub file may be executed first regardless of whether an activity, a service, a content provider, and a broadcast receiver are executed.

Here, the stub file can be executed first according to the setting of the Android manifest file.

Here, the stub file can be set such that the execution flow change according to the entry point conversion for the original executable file generated by decoding the encrypted executable file is performed.

Here, the execution flow change can be performed in the Android runtime according to the setting of the stub file.

Here, the execution flow change can be performed by initializing the entry point component of the original executable file to be used in the Android runtime.

Here, the executable file may be a Classes.dex file.

According to another aspect of the present invention, there is provided a method for preventing reverse engineering of an Android application, the method comprising: receiving an Android application packaged to include an encrypted executable file and a stub file for decrypting the encrypted executable file; Wow; And decrypting the encrypted executable file using a stub file included in the packaged Android application, wherein the stub file is a program for decrypting the encrypted executable file based on an entry point conversion technique do.

Here, the method for preventing reverse engineering of the Android application may be performed in a user terminal executing the Android application.

According to another aspect of the present invention, there is provided an apparatus for preventing reverse engineering of an Android application, the apparatus including: an extraction unit for extracting and encrypting an executable file of an Android application, the stub file is used to decrypt and execute the encrypted executable file based on the entry point conversion technique.

According to another aspect of the present invention, there is provided an apparatus for preventing reverse engineering of an Android application, the apparatus comprising: an Android application that is packaged to include an encrypted executable file and a stub file for decrypting the encrypted executable file; And decrypts the encrypted executable file using the stub file included in the packaged Android application. The stub file controls the encrypted executable file to be decrypted and executed based on the entry point conversion technique .

According to another aspect of the present invention, there is provided a computer readable recording medium storing a computer program for performing a method of preventing reverse engineering of an Android application.

The method and apparatus for preventing reverse engineering of the Android application according to the present invention can effectively prevent the static reverse engineering attack of the Android package by applying the entry point conversion technique to the stub file.

In addition, the embodiment of the present invention has an advantage that a starter app of an administrator authority is not separately needed for decoding and dynamic loading through the stub DEX.

In addition, the embodiment of the present invention can be applied even when an entry point to an application does not start from an activity, and there is no need to set and install the system level separately.

1 is a conceptual diagram for explaining a method of preventing reverse engineering of an Android application according to an embodiment of the present invention.
2 is a flowchart illustrating a method of packaging an Android application based on an entry point conversion technique to prevent reverse engineering according to an embodiment of the present invention.
3 is a flowchart illustrating a method of executing an Android application based on an entry point conversion technique to prevent reverse engineering according to an embodiment of the present invention.
4 is an exemplary diagram illustrating a method for executing an Android application based on an entry point conversion technique to prevent reverse engineering according to an embodiment of the present invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention. Like reference numerals are used for like elements in describing each drawing.

The terms first, second, A, B, etc. may be used to describe various elements, but the elements should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. And / or < / RTI > includes any combination of a plurality of related listed items or any of a plurality of related listed items.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between.

The terminology used in this application is used only to describe a specific embodiment and is not intended to limit the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In the present application, the terms "comprises" or "having" and the like are used to specify that there is a feature, a number, a step, an operation, an element, a component or a combination thereof described in the specification, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are to be interpreted as either ideal or overly formal in the sense of the present application Do not.

First, basic terms for explaining the present invention will be described as follows.

One Android application consists of a set of several components. A component can be classified as an activity, a service, a content provider, and a broadcast receiver.

Activity is a component that handles UI functions in Android application. In general, an activity defines a single screen.

Service is a component operating in the background. The service is connected to another component through bind, and other components can use the function provided by the connected service through the object named binder. A service has a local service that can be accessed only by the same application and a remote service that can be accessed by another application (another process).

A content provider is a component that functions to share data used by an application in various applications. In general, one application can not directly access the data store of another application. However, if an application provides data using a content provider, other applications can access the data through a content resolver.

A broadcast receiver is a component that receives intents sent to multiple applications. Unlike an activity or service, this component exists for a short period of time. Generally, a broadcast intent can be received and processed before it can be destroyed.

The application component inherits the classes of the components (Activity, Service, Content Provider, and Broadcast Receiver) defined by the Android API on the actual implementation and overrides the methods that are executed according to the life cycle of the component and the methods ). ≪ / RTI >

An Android application accesses another application's resources by executing another application itself, binding a remote service defined in another application, passing a command through a content resolver, or receiving a broadcast delivered by another application. This is defined as communication between components. Intent and intent filters are used to exchange information between components except content providers.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

1 is a conceptual diagram for explaining a method of preventing reverse engineering of an Android application according to an embodiment of the present invention.

Referring to FIG. 1, the prevention of reverse application of the Android application according to the embodiment of the present invention can be explained by interlocking between the developer terminal 10, the market server 20, and the user terminal 30.

The Android application (or app) generated through the developer terminal 10 may be provided to the user terminal 30 through the market server 20. That is, the Android application created in the developer terminal 10 is registered in the market server 20, and the Android application registered in the market server 20 can be downloaded to the user terminal 30. At this time, Android applications can be distributed by encrypting executable code to protect against reverse engineering attacks.

For example, the developer terminal 10 or the market server 20 can extract and encrypt an executable file of the Android application. In addition, the developer terminal 10 or the market server 20 can package the Android application so as to include a stub file for decrypting the encrypted executable file and the encrypted executable file. Here, the executable file means a DEX file, and the stub file can mean a stub DEX file.

More specifically, in order to prevent forgery and falsification of an application, an encryption technique for an executable file can be provided. In order to protect the executable code of the application from reverse engineering attack, it is possible to encrypt and distribute only the classes.dex file, which is an executable file, and then to stub, which decrypts the encrypted executable file for normal execution and dynamically loads, Method can be applied.

Particularly, according to the embodiment of the present invention, even when an application element is defined in the AndroidManifest.xml, an entry point transformation technique capable of dynamically loading and decrypting an encrypted executable file by first executing a stub file Can be applied. That is, the stub file according to the embodiment of the present invention can be set to decrypt and execute the encrypted executable file based on the entry point conversion technique. Here, an Application element can mean an Application class.

The user terminal 30 can download the packaged Android application with the stub file. Also, the user terminal 30 can perform dynamic loading in which the encrypted execution file is decrypted based on the stub file, and the execution flow is changed to the decrypted original executable file.

The user terminal 30 may be a desktop computer, a laptop computer, a tablet PC, a wireless phone, a mobile phone, a smart phone, A smart watch, a smart glass, an e-book reader, a portable multimedia player (PMP), a portable game machine, a navigation device, a digital camera, a digital multimedia broadcasting (DMB) A digital audio recorder, a digital audio player, a digital picture recorder, a digital picture player, a digital video recorder, a digital video player, a digital video player, or the like.

2 is a flowchart illustrating a method of packaging an Android application based on an entry point conversion technique to prevent reverse engineering according to an embodiment of the present invention.

Referring to FIG. 2, a method for preventing reverse engineering of an Android application according to an embodiment of the present invention includes: extracting and encrypting an executable file of an Android application (S210); (S220) packaging the Android application so as to include a stub file for decrypting the encrypted executable file and the encrypted executable file; And transmitting the packaged Android application (S230).

2 is a diagram for explaining a method for creating and transmitting a packaged Android application and may be performed in the developer terminal 10 or the distribution server (for example, the market server 20) described in FIG.

The Android application contains additional information such as executable files as well as various images and multimedia, so that when encrypting the entire application package, the encryption and decryption performance is degraded. Therefore, according to the embodiment of the present invention, the executable file of the Android application can be extracted and encrypted. Also, for efficient and safe encryption and decryption key management, the encryption key and the encryption key can be generated based on the feature point so as to uniquely identify the application.

More specifically, the DEX file, which is an executable file of the Android application, is extracted from the package and encrypted (S210), and the Android application may be packaged so that the encrypted DEX file and the stub DEX are included in the package (S220).

Here, the stub file can be set to control that the encrypted executable file is decrypted and executed based on the entry point conversion technique. That is, the stub file enables the stub DEX to decrypt the encrypted DEX file when the executable of the encrypted application is executed, and to change the execution flow to the original executable file using the pre-entry conversion method.

In addition, the stub file can be set to be executed first when executed for an Android application. That is, the stub file can be executed first according to the settings of the Android manifest file. For example, a stub file may be executed first, whichever component is executed, such as an activity, a service, a content provider, and a broadcast receiver.

In particular, according to the embodiment of the present invention, even when an application element is defined in the AndroidManifest.xml, reverse engineering can be effectively prevented through application of the entry point conversion technique.

More specifically, the general application execution sequence is the same as "Runtime -> (Optional) Application element -> Start component". In other words, defining application element in AndroidManifest.xml is an optional issue, but if you define Application element in AndroidManifest.xml, you can effectively decode the packaged Android application including encrypted executable file using stub file and execute There is a problem. Here, an Application element can mean an Application class.

Accordingly, the application execution sequence according to the embodiment of the present invention is executed in the order of "Runtime -> stub application element (addition of entry point conversion function) -> (Optional) original application element - &Quot; Start component ".

Thus, the stub file according to the embodiment of the present invention can be set such that execution flow change according to entry point conversion for the original executable file generated by decoding the encrypted executable file is performed. That is, execution flow changes can be performed in the Android runtime, depending on the stub file's configuration. For example, changing the execution flow can be done by initializing the entry point component of the original executable to be used in the Android runtime.

For example, for an application that does not apply the reverse engineering attack prevention technique, the DEX file in the app package can be extracted, encrypted based on the bus mark, and added with the stub DEX. Therefore, even if reverse engineering attack is performed, DEX file of original application is encrypted, and reverse engineering attack is impossible because there is no bus mark information of original application. Here, the bus mark may mean unique identification information of an application or an executable file.

According to an embodiment of the present invention, the Android application is packaged such that an executable file of the Android application is extracted and encrypted, and a stub file for decrypting the encrypted executable file and the encrypted executable file is included, May provide an apparatus for preventing reverse engineering of an Android application, which controls to decrypt and execute the encrypted executable file based on an entry point conversion technique, 1 to the developer terminal 10 or the market server 20 described above.

Therefore, according to the embodiment of the present invention, the reverse engineering attack prevention technique can be applied regardless of the version of the Android platform. That is, it is possible to effectively prevent the static reverse engineering attack of the Android package without having to modify and rebuild the platform.

Furthermore, according to embodiments of the present invention, reverse engineering can generate stub files in a more difficult form. For example, you can create a stub file in a native language written in C, rather than a Dex file written in java.

FIG. 3 is a flowchart illustrating a method of executing an Android application based on an entry point conversion technique to prevent reverse engineering according to an embodiment of the present invention. FIG. 4 is a flowchart illustrating a method for preventing reverse engineering according to an embodiment of the present invention. FIG. 5 is an exemplary diagram illustrating a method of executing an Android application based on an entry point conversion technique.

Referring to FIG. 3, a method for preventing reverse engineering of an Android application according to an exemplary embodiment of the present invention includes receiving an Android application packaged to include an encrypted executable file and a stub file for decrypting the encrypted executable file (S310); And decrypting the encrypted executable file using the stub file included in the packaged android application (S320).

Also, a method of preventing reverse engineering of an Android application according to an embodiment of the present invention includes: performing an execution flow change through an entry point conversion for an original executable file generated by decoding an encrypted executable file (S330); And executing the original executable file according to the changed execution flow (S340).

FIG. 3 illustrates a method of executing an Android application based on an entry point conversion technique to prevent reverse engineering, and may be performed in the user terminal 30 described above with reference to FIG.

3, a secure encryption technique can be applied without arbitrarily modifying the DEX file of the original application in various Android environments through the entry point conversion technique when decrypting the encrypted executable file.

To do this, the stub file is executed first when the packaged app is executed. That is, the stub file can be set to be executed first when it is executed for an Android application. For example, a stub file may be executed first, whichever component, such as Activity, Service, Content Provider, and Broadcast Receiver, is executed, And load the original executable into memory.

Referring to FIGS. 3 and 4, the stub file may be executed first by the Android runtime according to the setting of the Android manifest file (S410).

After that, the entry point component of the original executable file to be used in the Android runtime is identified, and a new entry point component to be used is created and initialized (S420). Then, an entry point conversion technique is applied to the Android runtime, (S430).

Therefore, the stub file in which the execution flow change according to the entry point conversion for the original executable file generated by decrypting the encrypted executable file is set to perform the execution flow change at the Android runtime. For example, changing the execution flow can be done by initializing the entry point component of the original executable to be used in the Android runtime.

For example, you could add code like "This -> parent -> application = OrigApplication ()" to your stub file to load and run the original executable in memory.

According to another aspect of the present invention, there is provided a method for receiving an Android application packaged to include an encrypted executable file and a stub file for decrypting the encrypted executable file, using a stub file included in the packaged Android application And the stub file decrypts the encrypted executable file based on an entry point conversion technique so that the encrypted executable file is decrypted and executed. And such a device may be mounted to the user terminal 30 described above in Fig.

Furthermore, the operation of the anti-reverse engineering method of the Android application according to the embodiment of the present invention can be implemented as a computer-readable program or code on a computer-readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. The computer-readable recording medium may also be distributed and distributed in a networked computer system so that a computer-readable program or code can be stored and executed in a distributed manner.

Computer readable media can include hardware devices that are specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Program instructions may include machine language code such as those produced by a compiler, as well as high-level language code that may be executed by a computer using an interpreter or the like. The hardware device may be configured to operate with at least one software module to perform the binary mixed model based beam demarcation data analysis method of the present embodiment, and vice versa.

The method and apparatus for preventing reverse engineering of the Android application according to the embodiment of the present invention can effectively prevent the static reverse engineering attack of the Android package by applying the entry point conversion technique to the stub file.

In addition, the embodiment of the present invention has an advantage that a starter app of an administrator authority is not separately needed for decoding and dynamic loading through the stub DEX.

In addition, the embodiment of the present invention can be applied even when an entry point to an application does not start from an activity, and it is possible to minimize separate setting and installation at the system level.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the present invention as defined by the following claims It can be understood that

10: Developer terminal 20: Market server
30: User terminal

Claims (20)

A method for preventing reverse engineering of an Android application executed on a developer terminal or a distribution server,
Extracting and encrypting an executable file of the Android application; And
And packaging the Android application so that the encrypted executable file and the stub file for decrypting the encrypted executable file are included,
In the stub file,
And controlling the decrypted executable file to be decrypted and executed based on an entry point conversion technique.
How to prevent reverse engineering of Android applications. delete The method according to claim 1,
In the stub file,
And is set to be executed first in execution for the Android application.
How to prevent reverse engineering of Android applications. The method of claim 3,
In the stub file,
Is executed first, whichever component is executed, such as an activity, a service, a content provider, and a broadcast receiver.
How to prevent reverse engineering of Android applications. The method of claim 3,
In the stub file,
Characterized in that it is executed first according to the setting of the Android manifest file,
How to prevent reverse engineering of Android applications. The method according to claim 1,
In the stub file,
And an execution flow change according to an entry point conversion for an original executable file generated by decoding the encrypted executable file is performed.
How to prevent reverse engineering of Android applications. The method of claim 6,
The execution flow change includes:
And is executed in the Android runtime according to the setting of the stub file.
How to prevent reverse engineering of Android applications. The method of claim 7,
The execution flow change includes:
And initializing an entry point component of the original executable file for use in the Android runtime.
How to prevent reverse engineering of Android applications. The method according to claim 1,
The executable file includes:
Classes.dex file,
How to prevent reverse engineering of Android applications. A method for preventing backtracking of an Android application executed in a user terminal,
Receiving an packaged Android application including an encrypted executable file and a stub file for decrypting the encrypted executable file; And
Decrypting the encrypted executable file using the stub file included in the packaged Android application,
In the stub file,
And controlling the decrypted executable file to be decrypted and executed based on an entry point conversion technique.
How to prevent reverse engineering of Android applications. delete The method of claim 10,
In the stub file,
And is set to be executed first in execution for the Android application.
How to prevent reverse engineering of Android applications. The method of claim 12,
In the stub file,
Is executed first, whichever component is executed, such as an activity, a service, a content provider, and a broadcast receiver.
How to prevent reverse engineering of Android applications. The method of claim 12,
In the stub file,
Characterized in that it is executed first according to the setting of the Android manifest file,
How to prevent reverse engineering of Android applications. The method of claim 10,
In the stub file,
And an execution flow change according to an entry point conversion for an original executable file generated by decoding the encrypted executable file is performed.
How to prevent reverse engineering of Android applications. 16. The method of claim 15,
The execution flow change includes:
And is executed in the Android runtime according to the setting of the stub file.
How to prevent reverse engineering of Android applications. 18. The method of claim 16,
The execution flow change includes:
And initializing an entry point component of the original executable file for use in the Android runtime.
How to prevent reverse engineering of Android applications. The method comprising the steps of: extracting and encrypting an executable file of the Android application, and packaging the Android application so that the encrypted executable file and the stub file for decrypting the encrypted executable file are included,
In the stub file,
And controlling the decrypted executable file to be decrypted and executed based on an entry point conversion technique.
A device to prevent reverse engineering of Android applications. Receiving the packaged Android application so as to include an encrypted executable file and a stub file for decrypting the encrypted executable file and decrypting the encrypted executable file using the stub file included in the packaged Android application However,
In the stub file,
And controlling the decrypted executable file to be decrypted and executed based on an entry point conversion technique.
A device to prevent reverse engineering of Android applications. A computer program for performing any one of the methods according to claims 1 and 3 to 9 when being executed on a computer.

Images