KR101604892B1 - Method and devices for fraud prevention of android-based applications - Google Patents

Abstract

An application upload method for preventing illegal use of an application, an application encryption server corresponding thereto, and an application execution method and a user terminal for the application are disclosed. The method of uploading an app includes a stub application storing step of removing the original executable file from the app, creating a stub app by inserting the stub executable file and storing the stub app in the encryption server, generating an encrypted app by encrypting the original executable file, And a step of uploading the stub application to the app store. A method of executing an application includes the steps of: installing a stub execution file and resource files by downloading a stub application stored in an app store to a user terminal; generating a decryption application by decrypting the encrypted application stored in the user terminal; And overwriting the original executable file with the stub executable file.

Description

[0001] METHOD AND DEVICES FOR FRAUD PREVENTION OF ANDROID-BASED APPLICATIONS [0002]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technique for preventing illegal use of an application, and more particularly, to encryption in an application uploading step performed in an Android environment and decoding technology in a downloading and executing step.

With the recent rapid expansion of smartphones, the smartphone application market, called "app", is also emerging as a huge market. In 2010, the American Dialect Society selected "apps" for the word of the year, and smartphones and apps are rapidly becoming a part of our lives.

Globally, as of March 2012, 750,000 apps (580,000 effective apps) are registered, and domestic smartphone users are estimated to exceed 30,000,000 by March 2012. Of these, iPhone users 4,000,000).

In October 2012, the number of apps used in the Android-based app market surpassed the number of apps available in the iPhone App Store, reaching 700,000. The number of pirated apps registered in the market after illegally duplicating and tampering with apps has increased to about 170,000 at the end of September 2012 compared to 6 times at the end of June 2012.

The problem of app piracy is more serious in the Android operating system than in iOS, which causes serious intellectual property problems with the app. Android is the most popular platform for smartphones, and the hacking attack is also seen as the most.

According to F-Secure, a security firm, 79 percent of malicious code attacks last year were aimed at Android. This was 12.3% p increase from 66.7% in 2011, and the Android attack was only 11.25%

In the case of Apple iPhone, it is possible to use pirated apps only by hacking the iPhone, but for Android-based mobile phones, copying illegal copy apps is also possible. The Android platform is easy to pirate, so you can easily install applications from any source.

On the other hand, as a technique for preventing data from being lost or changed by an illegal method of others when data is transmitted to an application in a general computing device, it is converted into another form so that data can not be easily manipulated, A method of restoring it to its original form has been studied.

This is called encryption and decryption. Encryption schemes are divided into symmetric key cryptography (symmetric key cryptography) and asymmetric key cryptography (asymmetric key cryptography).

In the field of smartphone applications (especially Android-based applications), as has been pointed out earlier, the recent growth in the app market and the damage caused by piracy and use of apps are increasing rapidly. In order to prevent illegal duplication of apps and to reduce damage due to infringement of the copyright of the app, Google's libraries such as License Verification Library (LVL) and SKT's ARM (Application DRM) have been provided. However, Because it is easy to modify and repackage by compilation, it is highly likely that library-level illegal execution blocking technologies will be bypassed.

Such existing anti-piracy technologies are often based on DRM (Digital Rights Management). DRM-based technologies are abused as a means of building monopoly markets by some operators due to the lack of compatibility with other devices.

The reason for the serious copyright problem of Android based application is that it can easily extract APK (Android PacKage) file from the Android terminal to the PC and extracted APK file is relatively easy by the reverse engineering tools of Android It can be decompiled, debugged, and tampered with. In this way, malicious application users can restore the source of the application, bypass the payment authentication process, delete the advertisement, further insert malicious code, and repackage the APK file. The repackaged APK file is put on the market again and sold or it spreads through the web hard.

To improve this, Google encouraged app developers to use ProGuard, a code obfuscation tool. However, this delayed the time it took to reverse the app, but it did not completely block it.

Encryption - based application decompression prevention techniques have been studied steadily, but if the key used for encryption decryption is exposed, the technique can also be disabled. Moreover, since apps purchased through one smartphone are encrypted with the same key, once the key is exposed, all the apps on the smartphone can be decrypted and pirated. Accordingly, an additional key management technology for storing and managing the secret key generated by the server in the smartphone is required.

For this, there is a private key management method using Secure Storage through MTM (Mobile Trusted Module). However, since there is a limitation in application and management method of encryption decryption key, There is also a need for a separate method of managing an app during the creation, installation, and execution of the app.

This is why there is a growing demand for the development and standardization of copyright protection technology to prevent illegal use of the source code of Android-based applications.

It is an object of the present invention to provide a method of encrypting and uploading an app to prevent illegal use of an Android-based app, without uploading important source code.

It is another object of the present invention to provide a method and system for decrypting and decrypting an encrypted application separately managed when the application is downloaded and executed in order to prevent illegal use of the Android-based application, To be changed or replaced with another stub application.

It is still another object of the present invention to provide an application encryption server and a user terminal capable of performing the uploading method and the execution method.

According to one aspect of the present invention, there is provided an app upload method for preventing unauthorized use of an app, the method comprising: an event registering an app in an app store, a stub application saving step of removing the original executable file from the app and generating a stub app by inserting a stub executable file and storing the stub app in the app encryption server; An encrypted application storing step of encrypting the executable file to generate an encrypted app, and storing the encrypted app in the app encrypting server, and a step of uploading the stub app to the app store.

Here, the stub application and the encryption application may be an Android package (APK, Android PacKage) file format.

Here, the stub application can be packaged so that the resource files other than the original executable file are installed.

Here, the app upload method further includes an intent filter adding step of adding an intent filter to the manifest file included in the application before the encrypted application storing step to give an execution flag to the encrypted app And the like.

According to another aspect of the present invention, there is provided an application execution method for preventing an unauthorized use of an application, the event being downloaded from an app store, Installing a stub execution file and resource files by downloading a stub application stored in a store to a user terminal, generating a decryption application by decoding an encrypted application stored in the user terminal as an event triggered by the stub application, , And overwriting the original executable file included in the decryption application with the stub executable file.

Here, the step of generating the decryption application may include the step of, when the encrypted application stored in the user terminal does not exist, the launcher application downloading the encrypted application from the application encryption server and storing the encrypted application in the user terminal Can be performed.

Here, the stub application and the encryption application may be in APK file format.

Here, the method of executing the application may further include a step of backing up the stub application before the overwriting step.

Furthermore, the method of executing an application may further include a step of overwriting the stub executable file included in the backed-up stub application with an event that the execution of the app is terminated as a trigger, to the original executable file.

Here, the method of executing an application may further include a step in which the launcher application transmits an application execution intent to the user terminal after the step of overwriting, and the user terminal determines an application to be executed based on the application execution intent .

Here, the method of executing an application may further include a step of reducing the rights of the other group to the decrypted application after the step of overwriting.

According to another aspect of the present invention, there is provided an application encryption server for preventing an unauthorized use of an application, wherein an event for registering an application in an app store is a trigger, A stub application storage unit for storing a stub application by creating a stub application by removing a file and inserting a stub execution file, an encrypted application storage unit for creating an encrypted application by encrypting the original execution file, and storing the encrypted application, And an app upload unit for uploading the stub app to the app store.

Here, the stub application and the encryption application may be in APK file format.

Here, the stub application may be packaged so that the resource files other than the original executable file are installed.

Here, the application encryption server may further include an intent filter adding unit that adds an intent filter to the manifest file included in the application to give an execution flag to the encrypted application.

According to another aspect of the present invention, there is provided a user terminal for preventing an unauthorized use of an application, comprising: an event receiving an application from an app store as a trigger; a stub application A stub application download unit for downloading the stub execution file and the resource files, an encrypted application download unit for storing the encrypted application in which the application is encrypted, and an event for executing the stub application as a trigger, And a decryption application storage unit for decrypting the encrypted application to generate a decrypted application, and overwriting the original execution file included in the decrypted application with the stub execution file.

Here, if the encrypted application does not exist, the encryption application downloading unit may download and store the encrypted application from the encryption server by the launcher app.

Here, the stub application and the encryption application may be in APK file format.

Here, the user terminal may further comprise a stub application backup unit for backing up the stub application stored in the stub application downloading unit.

Furthermore, the stub application downloading unit can trigger the event that the execution of the application is terminated, and overwrite the stub execution file included in the backed-up stub application with the original execution file.

Here, the user terminal may further include an application execution determining unit that determines an application to be executed based on the tent of the application execution intent transmitted by the launcher application.

Further, the user terminal may further include an appending authority managing unit for reducing and changing the privileges of the other group to the decrypted app.

Using the above-described app upload method and the app encryption server according to the present invention can reduce the possibility of illegal outflow in the process of storing and transmitting an application, and even if an encrypted application is leaked, the decryption mechanism of the user terminal is not leaked The damage can be minimized.

Also, using the above-described method of executing an application and the user terminal according to the present invention, the decrypted application is stored only when it is needed, that is, while the application is running, and when the application is not running, It is possible to drastically reduce the possibility of the decryption application being leaked.

It also has the advantage of not requiring additional skills and resources to store and transfer cryptographic apps, as it can continue to use the first encrypted stored app, creating a decrypted app whenever needed. Furthermore, it overcame the risk of illegal spillage when transmitting and storing the original executable file intact in the Android app.

1 is a flowchart illustrating an application upload method and its detailed steps according to an embodiment of the present invention.
2 is an exemplary diagram illustrating an example of an app upload method according to an embodiment of the present invention.
3 is a flowchart illustrating an application execution method and its detailed steps according to an embodiment of the present invention.
4 is an exemplary diagram illustrating an example of a process of downloading and installing an app from an app store to a user terminal according to an embodiment of the present invention.
5 is an exemplary diagram illustrating an example of a process of downloading a cryptographic application from an app encryption server to a user terminal according to an embodiment of the present invention.
FIG. 6 is an exemplary view illustrating an example of a structure of a directory storing a stub application, an encrypted application, and an optimized DEX file according to an embodiment of the present invention.
7 is an exemplary diagram illustrating an example of a process of decrypting a cryptographic application to generate a decrypted app according to an embodiment of the present invention.
8 is an exemplary diagram for explaining an example of a process of replacing a decrypted application with a stub application according to an embodiment of the present invention.
9 is an exemplary diagram for explaining an example of a process of changing an access right of a decrypted app and an ODEX file and transmitting an app execution intent according to an embodiment of the present invention.
FIG. 10 is an exemplary diagram for explaining an example of a process of replacing a backed-up stub application with a decryption application by detecting an application execution end according to an embodiment of the present invention.
11 is a block diagram for explaining an application encryption server and its components according to an embodiment of the present invention.
12 is an exemplary diagram illustrating a structure of a DEX file, which is an example of a source executable file according to an embodiment of the present invention.
13 is a block diagram illustrating a user terminal and its components 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, the terms used in the present application will be briefly described as follows.

APK (Android Application Package) is a file format used to install and distribute applications and middleware on Google's Android Operating System. That is, the APK file is similar to an MSI (MicroSoft Installer) file in the Windows operating system.

When a program for creating an APK file (for example, sample.apk) is started, all the constituent parts are packaged into one APK file. The APK file contains all of the program's executable code (for example, sample.dex), resources, and manifest files.

The manifest file will be described as follows. There are several software components in an application. To start a specific software component, it is first necessary to know whether the corresponding software component exists in the application. The manifest file has a list of software components existing in the application so that they can be managed as one manifest file.

That is, in software packaging, a distribution list of contents is made into a file, which can be regarded as a manifest file, and simply lists the information of the distributed files.

An intent filter is a means of determining what intents an app component wants to receive. An intent can have an explicit tent and an implicit tent. When an application or computing device sends an explicit tent, the class name is set so it is clear which application to run. However, in the case of an implied tent, an action name is set instead of a class name, and it may not be obvious which application component to run by just the action name. Thus, an app component can have an intent filter, and Android can use an intent filter to determine which app component to deliver an implicit tent.

The following is an example of the process of running an app component using an implicit tent. First, an app component sends an implied tent with an action value of A to Android. Second, Android looks for an app component that has an intent filter with an action value of A. Third, once an app component with an intent filter with the matching action value is found, Android executes it and delivers an implicit tent. If two or more app components are found, Android can ask the user what to do. If none is found, a method of displaying a related message in the user terminal can be used.

A flag is a flag. Sign, or the like, and is an indicator of data to be inspected in order to discriminate whether or not a specific state is established during execution of a program, that is, an indicator attached to data for the purpose of identification or display, 1 bit is used. In-use display, write inhibit display, and interrupt condition occurrence display are used.

The App Store is a bundle of application stores. It contains mobile applications (such as calendar applications, address books, alarms, calculators, games, videos, Internet access, music playback, navigation, (Mobile phone) market where mobile content (software) can be bought and sold freely. It can be seen as an online market for applications that can be installed on smartphones. These include Google's Android app store, an online app store for mobile operators, and the Wholesale App Community (WAC), a wholesale market for apps that all major carriers and manufacturers are participating in.

A stub app is an app that has the ability to remove key executables from the original app and simply install the app's resources. Also called a dummy app.

As used in this application, the term "other group" refers to a group other than the group to which the file or directory owner belongs when managing the permissions of a file or directory on the operating system. For example, in the UNIX family (including Linux), "ls?" You can check the details of directories and files in the current path by using commands (syntax may vary depending on the type of Unix such as Solaris and HP-UX). If you get the results like "-rwxr -r-- 1 sarangir sarangir 658 Jun 22 2012 .zshrc" with the above command, the text of the first 10 digits is related to authority.

That is, the first "-" in the first 10 digits indicates that .zshrc is a regular file, then "rwx" is the permissions of the owner of the .zshrc file to read, write, and execute, then "r--" Is read, and then "r--" means that the authority of the group other than the group to which the owner belongs is read. "r" means read, "w" means write, and "x" means execute. It can be expressed as a number again, where "r" is 4, "w" is 2, and "x" is 1. Therefore, the permission configuration of the .zshrc file is expressed as a number.

The term " event " as used in the present invention includes an occurrence of an operation or an event that a user generates to cause a program to respond. It is typical to press a key on a keyboard or a touchpad on a smartphone. Clicking a mouse button, moving the mouse, and the like. It is also possible to call another specific program while a specific program is terminated or performing a function, and a specific procedure call or function call may be included in the same program.

In other words, the fact that an event becomes a trigger means to cause the start of an action or an event, not to mean that a specific action or event itself is performed. For example, if there is an operation called data transmission, it means to send and receive data link control commands and responses between adjacent nodes in order to exchange identification information and other information between two nodes. It is not.

The mechanism for preventing malicious use of the Android application source code can be represented in the following order as a whole in terms of the application encryption server and the user terminal.

1. System launcher app is built in user terminal.

2. Register the developed app in the app encryption server and app store.

3. Download apps from your device.

4. Added progress on first launch of downloaded app (install original executable).

5. Launch and exit the app.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings. In order to facilitate the understanding of the present invention, the same reference numerals are used for the same constituent elements in the drawings and redundant explanations for the same constituent elements are omitted.

FIG. 1 is a flowchart for explaining an application uploading method and detailed steps according to an embodiment of the present invention. FIG. 2 is an exemplary view for explaining an example of an application uploading method.

Referring to FIGS. 1 and 2, in an application upload method for preventing an unauthorized use of an application, an event for registering an application in the application store 200 becomes a trigger (S110) A stub application storing step (S160) of inserting a stub execution file (S150), creating a stub application (S150), and storing the stub application in an encryption server (S160) An encrypted application storing step (S140) of storing the encrypted application in the encryption server, and a step (S170) of uploading the stub application to the application store (200).

Stub apps and crypto apps can be in Android package file format, and stub apps can be packaged so that the rest of the resource files are installed except for the original executable.

The method of uploading an application may further include an intent filter adding step (S130) of adding an intent filter to the manifest file included in the application before the encrypted application storing step (S140) to give an execution flag to the encrypted app have.

The developer can register the developed application in the app encryption server 100 or the app store 200 (S110). The registration process may be performed mainly through the developer interface provided by the application store 200, but is not limited thereto. That is, registering an application in the application store 200 may have various event types. The developer may use a two-step interface for registering the developed application in the application encryption server 100 and returning the stub application from the encryption server to the application store 200. However, The above two steps may be performed through only one interface through the interface for connecting the application store 200 and the application encryption server 100. [

Although the app encryption server 100 and the application store 200 are logically distinguishable, they may be physically implemented in one device. In the following description, we will explain how to use the above two-level interface for developing an app on the Android operating system.

Referring to FIG. 2, (1) the developer can transmit the APK file of the app created by the developer to the application encryption server 100. (2) The APP encrypting server 100 can copy the APK file of the developer and carry two APK files. ③ You can create a stub APK by removing the original DEX (executable file) file in one APK file and inserting stub DEX file prepared by ④ App-encryption server 100. The stub APK file in which the original DEX file is replaced with the stub DEX can simply generate an app in the user terminal 300 that has the function of installing the app's resources. (5) The stub APK file created by the app encryption server 100 can be returned to the developer.

Ⓐ Modify the manifest file in the other APK file copied in ②. At this time, modification of manifest file is simply adding intent filter for communication with launcher app. Ⓑ Since the stub APK that can install the remaining resources except the original DEX file is created through ④, the resources inside the APK file that finished the operation of ⓐ can be removed. You can encrypt the APK file created through ⓒ. There is no restriction on the type of encryption, but the above mechanism can be modified to add a key management function for each encryption.

The encryption types include a private key method and a public key method. Private Key Encryption is a method of encrypting and decrypting with the same key. It is difficult to maintain security and key management, but it is simple because of its algorithm, its encryption speed is fast, its capacity is small, and it is economical.

That is, since the secret key must be encrypted and decrypted with one secret key, only the parties having secret communication must securely share the key. This method is also called a secret key cryptosystem. DES (Data Encryption Standard), Triple DES and Advanced Encryption Standard (AES), which partially complement the disadvantages of DES, are examples of typical algorithms.

Public Key Encryption consists of a public key and a private key that is used only by the user. Since the public key and secret key are separately managed, key management is easy and both encryption and user authentication are performed at the same time . It is used for digital signature and non-repudiation of electronic documents. However, it has a disadvantage that the algorithm is complicated and slow.

That is, there are two keys for each user, and each user must maintain a public key (a public key) and a private key (a key pair). Representative algorithms include Rivest Shamir Adleman (RSA), and Elliptic Curve Cryptosystem (ECC).

The process of generating the stub APK will be described in more detail as follows.

The stub APK file to be preferentially installed in the user terminal 300 is replaced with a dummy DEX file instead of the actual source code DEX file, and also holds a resource file. Therefore, the role of the stub APK file is to actually install the resources in the user terminal 300 instead of the encrypted APK file to be downloaded subsequently.

When you generate these stub APK files, you can go through the following steps. Unpack the original APK file, remove the DEX file containing the original source code, create a dummy DEX file that does nothing (use the dx tool), APK repackage (including the dummy DEX file) ), Stub APK file signing.

The reason why the stub APK file can be created using the dummy DEX file and installed in the user terminal 300 is that when the application is installed, the DAVIK verifier simply checks whether there is a structural problem of the DEX file, ) And Alder32 checksum values only.

Further, since the source code (DEX file) of the developer is not decompiled or modified in the process of generating the stub APK and the encryption APK for the present invention, there is no probability that an error occurs during the operation of the app due to the above process .

3 is a flowchart illustrating an application execution method and its detailed steps according to an embodiment of the present invention. FIG. 4 shows a process of downloading and installing an application from the application store 200 to the user terminal 300, FIG. 5 shows a process of downloading the encrypted application from the application encryption server 100 to the user terminal 300, 7 shows a process of decrypting a cryptographic application to generate a decrypted app, Fig. 8 shows a process of replacing a decrypted app with a stub app, Fig. 9 shows a process of replacing a decrypted app with a stub app, An example of changing the access right of the decrypted application and the ODEX file and transmitting the application execution intent. 10 is an exemplary diagram for explaining an example of a process of replacing a backed-up stub application with a decryption application by detecting termination of execution of an application.

Referring to FIGS. 3 to 10, in the method of executing an application for preventing illegal use of an application, an event for downloading an application from the application store 200 is triggered (S310) (S315) of downloading the stub application stored in the user terminal 300 (S315), downloading the stub application stored in the user terminal 300 (S315) A step (S335) of decrypting the application to generate a decrypted application (S335), and a step (S345) of overwriting the original execution file included in the decrypted application with the stub execution file.

If the encrypted application stored in the user terminal 300 does not exist in the step S335, the launcher application downloads the encrypted application from the encryption server and stores the encrypted application in the user terminal 300 (S330) It can be done before. Here, stub apps and crypto apps can be in APK file format.

The method of executing an application may further include a step (S340) of backing up a stub application (S340) before a step (S345) of overwriting a source executable file included in a decryption application with a stub executable file. (S365) overwriting the stub executable file included in the backed-up stub application with the original executable file by triggering the termination event (S360).

In addition, after the step S345 of overwriting the original executable file included in the decryption application with the stub executable file, the launcher application transmits an app execution intent to the user terminal 300, and the user terminal 300 ) May further include determining (S350) an app to be executed based on the tent of the app execution intent, and after the overwriting step (S345), reducing the rights of another group to the decrypting app (S355 ). ≪ / RTI >

The launcher application of the system privilege may be built in the user terminal 300 in advance. A launcher app with a system privilege for communication with the encrypted app management and app encryption server 100 may be embedded in the user terminal 300. [ The launcher app can perform a function of decrypting the encrypted application and communicating with the application encryption server 100.

Referring to FIGS. 1 and 2, and referring to FIGS. 3 and 4, the developer can download the stub APK file returned from the application encryption server 100 to a desired market (Google Play Store, SKT TeaStore, etc.) You can register for sale. So in this case, when you buy the app in the market, you actually install the application's resources and buy a stub app that does nothing.

There are additional steps to be performed when the downloaded app is first run. After the downloaded app (stub app) is installed, if you run the app, you need the original APK file with the original DEX inserted, not the stub app with stub DEX inserted. When the downloaded stub application is executed for the first time, the original APK file exists in the application encryption server 100 as a re-packaged encrypted APK file after the resources are removed. Therefore, when the user first launches the application, the launcher application built in the terminal can download the encrypted APK file from the app encryption server 100 and store it in the "/ data / data / launcher" directory. The directory is a directory of system permissions, since it is the private space of the launcher app.

You need to download the encrypted APK file only once, so you do not have to do the above steps to run the next app each time. In addition, since the encrypted APK file is an APK file whose resources are removed, the size of the encrypted APK to download when launching the app for the first time is considerably smaller than that of the original APK file, which causes enough overhead to be accommodated The original app's APK file size is 54MB, and the size of the encrypted APK file for this app was only 4MB, removing the resources.)

However, it may be necessary to perform the above process even if it is not the first time the downloaded app is run. If the encrypted APK file that was once downloaded for various reasons is corrupted or does not exist, you can perform the same process as if you performed the above process during the first execution of the downloaded app. Accordingly, if an event for executing the downloaded stub application occurs, it is necessary to check whether the encrypted APK file is stored in the user terminal 300, whether the encrypted APK file exists in an unfailingly valid state, and the like.

Referring to FIG. 6, the status of a file for each directory for a decryption process can be known at the time of requesting execution of an app. Since the stub app is currently installed in the user terminal 300, the stub APK may exist in the directory "/ data / app" for storing the APK of currently installed apps. There is an ODEX file optimized for stub DEX in "/ data / dalvik-cache" which optimizes and stores DEX file of currently installed apps. Finally, in the "/ data / data / launcher", there may be an encrypted APK downloaded and stored as shown in FIG.

Referring to FIG. 7, the stub APK file backup and the decryption of the encrypted APK file will be described as follows. ① You need to replace the stub APK file in the "/ data / app" directory with the decrypted APK file so that the app will run. You can back up the stub APK file in the "/ data / data / launcher" directory. ② Then the launcher app decrypts the downloaded encrypted APK file in the "/ data / data / launcher" directory and stores it as "decryption APK".

Referring to FIG. 8, a process of replacing the stub APK of "/ data / app " with the decryption APK will be described. ③ Replace stub APK file in "/ data / app" with decrypted APK file of "/ data / data / launcher". All of this can be done because the launcher app is an app owned by the system, and the decryption APK of "/ data / data / launcher" is deleted immediately after step ③.

Referring to FIG. 9, a description will be made of a process of transmitting a decryption APK file and an ODEX file with permission change and app execution intent. ④ Modify the ODEX file permissions of "/ data / dalvik-cache" to 666 because you need to write new ODEX (Optimized DEX) through the decrypted APK file of the newly overwritten "/ data / app" directory. ⑤ Since all preparations for the execution of the app are completed, the launcher app sends the app execution tent to the decryption app. ⑥ Finally, to prevent the decryption APK, which is decrypted while the app is running, from being extracted from the "/ data / app" through the file manager app, the decryption APK file in the "/ data / (others group). For example, you can change from 644 to 640.

The process of terminating the app will now be described with reference to FIG. (1) Through the activity stack monitoring technique, the currently running app is checked in real time by the privilege of the launcher app (system privilege). Through this technique, you can know when the target app is terminated. (2) If it detects that the app is terminated, it can replace the decryption APK in the "/ data / app" directory with the stub APK file that was backed up in "/ data / data / launcher" ③ The authority changed in Fig. 9 can be restored from 640 to 644 again.

Here are some of the features of installing and running apps on the Android operating system using the system privileged launcher app.

When the app is launched, it will not run with the operating system's system privilege or administrator or root privileges, but simply run as application, and sandbox, one of Android OS's security policies, To protect one program from accessing another program area. Therefore, you can not control or monitor other processes by blocking the above Android security policy.

However, according to the security policy of the Android operating system, the present invention can prevent the encrypted application from being downloaded, installed and executed. In other words, it suggests a way to utilize the launcher app so that the crypto app can be downloaded, installed and run by running the stub app. System-authorized launcher apps allow you to monitor, lock, and decrypt protected programs.

Advantages obtained by utilizing the launcher app built in the user terminal 300 include the following. In order to allow the crypto app to be downloaded, installed and launched by running the stub app as above without using the launcher app, you have to modify the Android platform, the OS kernel. That is, using the launcher app does not modify the OS kernel.

This means that the technology can be applied regardless of the version of the Android platform. In addition, if this technology is applied to the terminal manufacturer, it is not necessary to modify the platform and rebuild the terminal.

FIG. 11 is a block diagram for explaining an application encryption server 100 and its components according to an embodiment of the present invention. FIG. 12 is an exemplary diagram illustrating a structure of a DEX file which is an example of a source executable file.

11 to 12, in the Android application encryption server 100 for preventing the unauthorized use of the application, the event that the application is registered in the application store 200 becomes a trigger, A stub application storage unit 110 for storing a stub application by removing a source executable file and inserting a stub executable file, and a stub application storage unit 110 for encrypting the original executable file to generate an encrypted app, An encrypted application storage unit 120 and an app upload unit 130 for uploading the stub application to the application store 200. [

Stub apps and crypto apps can be in APK file format, and stub apps can be packaged so that the rest of the resource files are installed except for the original executable. The application encryption server 100 may further include an intent filter adding unit 140 for adding an intent filter to the manifest file included in the application to give an execution flag to the encrypted application.

The app encryption server 100 and the stub application storage unit 110, the encrypted app storage unit 120, the app upload unit 130 and the intent filter adding unit 140, which are components thereof, As already described in the description of the claims, it is not duplicated.

However, the application encryption server 100 and its constituent elements are logically distinguishable elements, but do not mean that their physical locations are different from each other. That is, for example, the stub application storage unit 110 and the encrypted application storage unit 120 may be physically located at the same physical location, and the application encryption server 100 and the application store 200 may be configured in the same server . The application upload unit 130 or the intent filter adding unit 140 may be located in the application store 200.

Another embodiment of the structure and partial encryption of the DEX file in the Android operating system will be described with reference to FIG. In the present invention, when the encryption technology is applied to the application registered by the developer in the application encryption server 100, the DEX file can be parsed to reduce the overhead so that only the data section containing the important methods in the DEX file can be encrypted . The DEX file has the structure shown in FIG. 12, and the source code can be included in the data section.

13 is a block diagram illustrating a user terminal 300 and its components according to an embodiment of the present invention.

13, in the user terminal 300 that prevents the unauthorized use of the application, the user terminal 300 receives an event that an application is downloaded from the application store 200 as a trigger, A stub application download unit 310 for downloading the stub application and installing the stub execution file and the resource files, an encrypted application download unit 320 for storing the encrypted application in which the application is encrypted, And a decryption application storage unit 330 that decrypts the encrypted application stored in the encrypted application download unit 320 to generate a decrypted application and overwrites the original execution file included in the decrypted application with the stub execution file .

When the stored encrypted application does not exist, the encryption application download unit 320 downloads and stores the encrypted application from the application encryption server 100.

The stub application and the encryption application may be in the APK file format. The user terminal 300 may further include a stub application backup unit 360 for backing up the stub application stored in the stub application download unit 310. Furthermore, the stub application downloading unit 310 can trigger the event that the execution of the application is terminated, and overwrite the stub execution file included in the backed-up stub application with the original execution file.

The user terminal 300 may further include an application execution determining unit 340 that determines an application to be executed based on a tent of the application execution intent transmitted by the launcher application, And an application authority management unit 350 for reducing and changing the authority of the application.

The user terminal 300 and the components of the stub application download unit 310, the encrypted application download unit 320, the decryption application storage unit 330, the application execution decision unit 340, the application authority management unit 350, The application backup unit 360 has not been described in detail because it has already been described in the description of the method claim relating to the corresponding method of executing an application.

However, the user terminal 300 and its constituent elements are logically distinguishable elements, but do not mean that the physical locations are different from each other. That is, for example, each component of the user terminal 300 may be physically located at the same physical location.

Although some aspects have been described in terms of apparatus, it is clear that these aspects represent a description of the corresponding method, wherein the steps of the method correspond to the apparatus. According to certain implementation requirements, embodiments of the invention may be implemented in hardware or software. Embodiments of the present invention may be implemented as program code, a computer program product having program code that is operative for performing one of the methods.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas within the scope of equivalents should be construed as falling within the scope of the present invention.

100: App-encryption server 110: stub application storage unit
120: Encrypted App Storing Unit 130: App Upload Unit
140: Intent filter adding unit 200: App store
300: user terminal 310: stub application downloading unit
320: Encrypted application download unit 330: Decrypted application storage unit
340: App execution decision unit 350: App authority management unit
360: stub app backup unit

Claims (22)

App (app.) In an application upload method for preventing illegal use,
An event registering the app in an app store is triggered and the app removes the original executable file and inserts a stub executable file to create a stub app. A stub application storing step of storing the stub application in an application encryption server;
Encrypting the original executable file to generate an encrypted application, and storing the encrypted application in the application encryption server; And
And uploading the stub app to the app store. The method according to claim 1,
Wherein the stub application and the encryption application are an Android package (APK) file format. The method according to claim 1,
The stub app
And the other resource files except for the original executable file are installed. The method according to claim 1,
Before the encrypted application storage step,
Further comprising an intent filter adding step of adding an intent filter to a manifest file included in the app to give an execution flag to the encrypted app. In an application execution method for preventing illegal use of an application,
Installing a stub executable file and resource files by downloading a stub application stored in the app store to an user terminal as an event for downloading the application from an app store as a trigger;
Generating a decryption application by decrypting the encrypted application stored in the user terminal as an event triggering the stub application; And
And overwriting the original executable file included in the decryption application with the stub executable file. The method of claim 5,
Wherein the step of generating the decryption application comprises:
And a step of downloading the encrypted application from the application encryption server and storing the encrypted application in the user terminal when the encrypted application stored in the user terminal does not exist How to do it. The method of claim 5,
Wherein the stub application and the encryption application are APK file format. The method of claim 5,
Before the overwriting step,
Further comprising the step of backing up the stub application. The method of claim 8,
Further comprising overwriting the stub executable file included in the stub app to the original executable file when an event that execution of the app is terminated becomes a trigger. The method of claim 5,
After the overwriting step,
The launcher application transmits an app execution intent to the user terminal, and the user terminal determines an app to be executed based on the app execution intent. The method of claim 5,
After the overwriting step,
And reducing the rights of another group of the decryption application to the decryption application. An Android app encryption server for preventing the illegal use of an app,
A stub application storage unit for storing the stub application by removing a source executable file from an event of registering the application in the application store as a trigger, inserting a stub executable file to generate a stub application, and storing the stub application;
An encrypted application storage unit for encrypting the original executable file to generate an encrypted application and storing the encrypted application; And
And an app upload unit for uploading the stub app to the app store. The method of claim 12,
Wherein the stub application and the encryption application are APK file format. The method of claim 12,
The stub app
And the resource files except for the source executable file are packaged to be installed. The method of claim 12,
Further comprising an intent filter adding unit for adding an intent filter to the manifest file included in the app to give an execution flag to the encrypted app. A user terminal for preventing illegal use of an application,
A stub application downloading unit for downloading the stub application stored in the app store and installing the stub execution file and the resource files in response to an event that receives the application downloaded from the app store as a trigger; And
An encrypted application download unit for storing an encrypted application encrypted with the application; And
An event for executing the stub application is triggered to generate a decryption application by decrypting the encrypted application stored in the encrypted application downloading unit and to overwrite the original execution file included in the decrypted application with the stub execution file A user terminal comprising an app store. 18. The method of claim 16,
The encrypted-
And when the stored encrypted application does not exist, a launcher app downloads and stores the encrypted application from the application encryption server. 18. The method of claim 16,
Wherein the stub application and the encryption application are in an APK file format. 18. The method of claim 16,
And a stub application backup unit for backing up the stub application stored in the stub application downloading unit. The method of claim 19,
The stub-
Wherein the event that the execution of the application is terminated becomes a trigger, and the stub execution file included in the stub application is overwritten on the original executable file. 18. The method of claim 16,
Further comprising an app execution determining unit that determines an app to be executed based on an app execution intent transmitted by the launcher app. 18. The method of claim 16,
Further comprising: an appending authority managing unit for reducing and changing an authority of another group for the decryption application.

Images