WO2016119548A1 - 防软件反编译的方法、防反编译软件启动的方法和装置 - Google Patents

防软件反编译的方法、防反编译软件启动的方法和装置 Download PDF

Info

Publication number
WO2016119548A1
WO2016119548A1 PCT/CN2015/098978 CN2015098978W WO2016119548A1 WO 2016119548 A1 WO2016119548 A1 WO 2016119548A1 CN 2015098978 W CN2015098978 W CN 2015098978W WO 2016119548 A1 WO2016119548 A1 WO 2016119548A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
file
nativeactivity
main interface
signature information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2015/098978
Other languages
English (en)
French (fr)
Inventor
王国涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co Ltd
Original Assignee
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Qihoo Technology Co Ltd, Qizhi Software Beijing Co Ltd filed Critical Beijing Qihoo Technology Co Ltd
Publication of WO2016119548A1 publication Critical patent/WO2016119548A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation

Definitions

  • the present invention relates to the field of computer technology, and in particular, to a method for preventing software decompilation, a device for preventing software decompilation, a method for starting anti-decompilation software, and a device for starting anti-decompilation software.
  • the Android platform has developed rapidly and has gradually become the most popular operating system for mobile terminals. Compared with other terminal operating systems, the open Android system provides more functional interfaces for application developers. These functional interfaces improve the system's Scalability.
  • the present invention has been made in order to provide an apparatus for preventing software decompilation and a corresponding method for preventing software decompilation that overcome the above problems or at least partially solve the above problems.
  • a method for preventing software decompilation comprising:
  • the entry activity in the configuration file is declared as a nativeActivity
  • An execution file for the nativeActivity is configured by using a JAVA local call interface, where an execution file for the nativeActivity is used, after the execution file for the nativeActivity is loaded, before the main interface of the application is started.
  • the application performs signature verification, and if the application's signature verification fails, the application is exited.
  • the present invention also discloses a method for starting anti-decompilation software, comprising:
  • the application After loading the execution file for the nativeActivity, the application is signature verified before the main interface of the application is completed, and if the signature verification of the application fails, the application is exited.
  • the present invention also discloses an apparatus for preventing software decompilation, comprising:
  • An entry declaration module suitable for a configuration file of an application of the Android system, declaring an entry activity in the configuration file as a nativeActivity
  • a main interface verification building module configured to build an execution file for the nativeActivity through a JAVA local call interface; wherein an execution file for the nativeActivity is used after the execution file for the nativeActivity is loaded, The application is signed and verified before the main interface of the application is completed. If the signature verification of the application does not pass, the application is exited.
  • the present invention also discloses an apparatus for preventing anti-compilation software startup, including:
  • a configuration file reading module configured to read a nativeActivity declared in a configuration file of the application when the application of the Android system is started;
  • the main interface loading module is adapted to invoke a JAVA local calling interface by using a nativeActivity declared in the configuration file to load an execution file for the nativeActivity;
  • a main interface signature verification module configured to perform signature verification on the application before the main interface of the application is completed after loading the execution file for the nativeActivity, and if the signature verification of the application fails, Exit the app.
  • the present invention also discloses a computer program comprising computer readable code that, when run on the computer readable code terminal device, causes the server to perform the method of preventing software decompilation as described in any of the foregoing. Further, a computer readable medium is disclosed in which a package is stored A computer program comprising computer readable code for the above method of preventing software decompilation.
  • the present invention also discloses a computer program comprising computer readable code, when run on the computer readable code terminal device, causing the server to perform the method of booting the anti-compilation software described in any of the foregoing. Further, a computer readable medium is disclosed in which a computer program comprising computer readable code of the above described method of anti-compilation software startup is stored.
  • a method for preventing software decompilation according to the present invention may be used in the application of the Android system, in the configuration file Manifest file of the application, the entry activity in the configuration file is declared as a nativeActivity, and then through JNI (Java Native An execution file for the nativeActivity, where the execution file for the nativeActivity is used to start the main interface of the application after the execution file for the nativeActivity is loaded.
  • JNI Java Native An execution file for the nativeActivity, where the execution file for the nativeActivity is used to start the main interface of the application after the execution file for the nativeActivity is loaded.
  • the application is previously checked for signature, and if the signature verification of the application does not pass, the application is exited. Since the execution file for the nativeActivity is built by JNI (Java Native Interface), it can construct the above logic in the android_main function by using C++ implementation, and the application cannot be passed due to the decompiled application.
  • the application can not be started, thereby solving the problem that the application of the Android system is easy to be decompiled due to various logics of constructing the application by using the java, resulting in a lot of useless functions for the user, which is not harmful, and For the developer of the application, this method damages the developer's rights and interests, and avoids the application changes to add other logic to the application, avoiding the interference of unauthenticated information to the user, and protecting the application developer's The beneficial effects of equity.
  • FIG. 1 is a flow chart showing a method for preventing software decompilation according to an embodiment of the present invention
  • FIG. 1A illustrates an overall startup logic of an app according to an embodiment of the present invention
  • FIG. 2 is a schematic flowchart diagram of a method for preventing anti-compilation software startup according to an embodiment of the present invention
  • 2A is a schematic flow chart of a method for starting anti-decompilation software according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of an apparatus for preventing anti-compilation software startup according to an embodiment of the present invention
  • FIG. 4 is a schematic structural diagram of an apparatus for preventing anti-compilation software startup according to an embodiment of the present invention
  • Figure 5 shows schematically a block diagram of a terminal device for carrying out the method according to the invention
  • Figure 6 shows schematically a storage unit for holding or carrying program code implementing the method according to the invention
  • FIG. 1 it is a schematic flowchart of a method for preventing software decompilation according to the present invention, which may specifically include:
  • Step 110 for the configuration file of the application of the Android system, declare the entry activity in the configuration file as a nativeActivity
  • the Manifest file is named Java package for the application.
  • the name of the package as a unique identifier for an application.
  • the activities, services, broadcast receivers, content providers, and application components of the components of the application are declared in the Manifest file.
  • the class named in the Manifest file implements each component.
  • the Manifest file determines which processes will host the application components. (4) The Manifest file states that the application must have permission to access the protected API (Application Program Interface) section and interact with other applications. (5) The Manifest file also states that other processes need to interact with the components of the application. (6) The minimum level required for the Android API application announced in the Manifest file. A series of functions.
  • the entry activity that is, the class that declares the application main interface to start.
  • the entry activity in the Manifest file is declared as a nativeActivity.
  • Step 120 Build an execution file for the nativeActivity by using a JAVA local call interface.
  • the execution file for the nativeActivity is used to start on the main interface of the application after the execution file for the nativeActivity is loaded.
  • the application is signed and verified before completion, and if the application's signature verification fails, the application is exited.
  • JNI is the Java Native Interface, the java native interface, which is the java native interface. It provides several API implementations for communication with Java and other languages (C&C++).
  • execution file is also used to draw logic related to the main interface, and logic for starting the corresponding function after the verification is passed.
  • the execution file is used to perform signature verification on the application before the execution of the main interface of the application is completed after the execution of the execution file of the nativeActivity, including:
  • Sub-step 121 after loading the execution file for the nativeActivity, executing an Android main interface function, and performing signature verification on the application before the main interface of the application is completed by the main interface function.
  • FIG. 1A The overall logic of the startup of the main interface applied in the embodiment of the present invention is as shown in FIG. 1A:
  • any APP in the Android system starts, it will load the Manifest file, and then the entry activity to draw the main interface.
  • the Manifest file is loaded, and the nativeActivity declaration is read therefrom, so that the local method can be called through the JNI interface, and the execution file of the local application main function android_main is loaded through the JNI interface.
  • the android_main is executed in the embodiment of the present invention.
  • call engine_init_display to initialize the resources needed to draw the main interface.
  • the UI item drawing function engine_term_display is executed in the frame.
  • engine_term_display to draw the specific UI interface in the framework.
  • the present invention unifies the above steps A14-A16 to construct an execution file, such as a so file, according to the JNI specification.
  • an execution file such as a so file
  • the Android main interface function android_main is executed in step A13, before the main interface is drawn, the signature verification logic of the application main interface is added, and the signature verification logic is controlled by android_main.
  • performing signature verification on the application before the main interface of the application is completed including:
  • Sub-step 1211 in the main interface function, calling the natve method to apply for a piece of memory in a specified position in the system memory, and storing the preset first signature information;
  • Sub-step 1212 obtaining second signature information of the current application, determining whether the first signature information and the second signature information match; if the first signature information does not match the second signature information, determining a signature school of the application The test will not pass.
  • the natve method is added to the logic controlled by the android_main, and the natve method performs a request for a piece of memory in a specified location in the system memory, and stores the preset first signature information. Then, after decompiling the APP, after repackaging, the signature information stored in the memory that may be requested at the specified location is changed.
  • the android_main controls the subsequent verification logic
  • the second signature information of the currently started application is first acquired, and the first signature information in the memory block of the specified location that is built when the developer completes the development is matched. If the first signature information does not match the second signature information, it is determined that the signature verification of the application does not pass, and the drawing main interface is exited, so that the APP cannot be entered. If the first signature information matches the second signature information, it is determined that the signature verification of the application passes, and the main interface can be drawn, and the slave can enter the APP.
  • the decompiled APP may not apply for a memory block at a specified location at all.
  • the signature information is read from the memory block at the specified location. No signature information was read from the specified location and the check did not pass.
  • the first signature information is a first MD5 value in an initial state of application
  • the second signature information is a second MD5 value when the application is started.
  • the first signature information is that after the developer develops the APP, the MD5 value (Message Digest Algorithm 5) is calculated for a certain file A of the APP, and the MD5 value is the first value. MD5 value.
  • the client downloads the APP from a certain path, such as a third-party platform after installation, the file A of the APP at the current startup is calculated to calculate the MD5 value, and the MD5 value calculated at the startup is the second MD5 value. . Then if the APP is After decompilation, the contents of file A are different and their MD5 values are different.
  • the first signature information is a first certificate file in an initial state of the application
  • the second signature information is a second certificate file when the application is started.
  • the first signature information is a certificate file of a file content delivered by the developer after the development of the APP
  • the certificate file is a first certificate file.
  • the APP startup logic is modified. Even after the APP is decompiled, since the local method is called through the JNI interface, and the local method can be built as a SO file through C++, the decompilation is very difficult and basically cannot be reversed. Compilation, then even if the modifier decompiles the general logic of the entire APP, it will change the signature of the APP. If the APP after decompilation is started, it cannot pass the verification logic in the execution file of the above nativeActivity. , the main interface of the APP cannot be started, and the APP cannot be used, and neither the user nor the developer will be harmed by the change of the APP content.
  • the executing the executable file for the nativeActivity through the JAVA local calling interface includes:
  • Sub-step 122 constructing a SO file for the nativeActivity
  • the execution file of the build of the present invention may be a so file.
  • the so file can be understood as a dynamic link library, which can be compiled by C++.
  • the SO file is configured to perform signature verification on the application before the execution of the main interface of the application is completed after the execution of the execution file for the nativeActivity, if the signature verification of the application is not Pass, then exit the app. That is, through the so file, in the logic for drawing the main interface, the signature verification is performed on the application, and if the signature verification of the application does not pass, the application is exited, and the drawing of the main interface is ended, if the application After the signature verification is passed, the main interface is drawn.
  • the entry activity in the configuration file is declared as a nativeActivity, and then through JNI (Java Native Interface, An execution file for the nativeActivity is configured, where an execution file for the nativeActivity is used, after the execution file of the nativeActivity is loaded, before the main interface of the application is started.
  • JNI Java Native Interface
  • An execution file for the nativeActivity is configured, where an execution file for the nativeActivity is used, after the execution file of the nativeActivity is loaded, before the main interface of the application is started.
  • the application performs signature verification, and if the application's signature verification fails, the application is exited. Since the execution file for the nativeActivity is built by JNI (Java Native Interface), it can implement the above logic in the android_main function by using C++, and the application that is decompiled cannot be passed because the signature cannot pass.
  • the application can't be started, which solves the problem that the application of the Android system is easy to be decompiled due to various logics of building applications by using java, which leads to many useless functions for the user, which is not harmful, and for the application.
  • this method damages the developer's rights and interests, and avoids the application changes to add other logic to the application, avoiding the interference of unauthenticated information to users, and protecting the rights of application developers. Beneficial effect.
  • the following describes the startup process of the APP in the second embodiment.
  • FIG. 2 it is a schematic flowchart of a method for starting an anti-decompile software according to the present invention, which may specifically include:
  • Step 210 when the application of the Android system is started, reading the nativeActivity declared in the configuration file of the application;
  • the Manifest file is named Java package for the application.
  • the name of the package as a unique identifier for an application.
  • the activities, services, broadcast receivers, content providers, and application components of the components of the application are declared in the Manifest file.
  • the Manifest file determines which processes will host the application components. (4) The Manifest file states that the application must have permission to access the protected API (Application Program Interface) section and interact with other applications. (5) The Manifest file also states that other processes need to interact with the components of the application. (6) The minimum level required for the Android API application announced in the Manifest file. A series of functions.
  • one is declared as an entry activity, and the embodiment of the present invention declares the entry activity as a nativeActivity. Then, after step 210 of the embodiment of the present invention, the nativeActivity statement in the aforementioned Manifest file needs to be read.
  • Step 220 Call the JAVA local calling interface by using the nativeActivity declared in the configuration file, and load an execution file for the nativeActivity.
  • an execution file for the nativeActivity is first constructed, and the logic of the execution file includes, after the execution of the execution file for the nativeActivity, before the startup of the application's main interface is completed.
  • the application performs signature verification. If the signature verification of the application fails, the application is exited. If the signature verification of the application passes, the main interface is started and the APP is entered.
  • the JNI interface is called to load the executable file for the nativeActivity.
  • Step 230 After loading the execution file for the nativeActivity, perform signature verification on the application before the main interface of the application is completed, and exit the application if the signature verification of the application fails.
  • the app signature verification logic may be executed, that is, the application is signed and verified before the main interface of the application is completed, and if the signature verification of the application fails, the application is exited if the application is After the signature verification is passed, the main interface is drawn and the app is entered.
  • performing signature verification on the application before the main interface of the application is completed includes:
  • Sub-step 231 after the execution file for the nativeActivity is loaded, execute the security
  • the master interface function performs signature verification on the application before the main interface of the application is completed by the main interface function.
  • FIG. 1A The overall logic of the startup of the main interface applied in the embodiment of the present invention is as shown in FIG. 1A:
  • any APP in the Android system starts, it will load the Manifest file, and then the entry activity to draw the main interface.
  • the Manifest file is loaded, and the nativeActivity declaration is read therefrom, so that the local method can be called through the JNI interface, and the execution file of the local application main function android_main is loaded through the JNI interface.
  • the android_main is executed in the embodiment of the present invention.
  • call engine_init_display to initialize the resources needed to draw the main interface.
  • the UI item drawing function engine_term_display is executed in the frame.
  • engine_term_display to draw the specific UI interface in the framework.
  • the present invention unifies the above steps A14-A16 to construct an execution file, such as a so file, according to the JNI specification.
  • an execution file such as a so file
  • the Android main interface function android_main is executed in step A13, before the main interface is drawn, the signature verification logic of the application main interface is added, and the signature verification logic is controlled by android_main.
  • performing signature verification on the application before the main interface of the application is completed including:
  • Sub-step 2211 in the main interface function, calling the natve method to apply for a piece of memory in a specified position in the system memory, and storing the preset first signature information;
  • Sub-step 2212 Acquire second signature information of the current application, determine whether the first signature information and the second signature information match; if the first signature information does not match the second signature information, determine a signature school of the application. The test will not pass.
  • the natve method is added to the logic controlled by the android_main, and the natve method performs a request for a piece of memory in a specified location in the system memory, and stores the preset first signature information. Then, after decompiling the APP, after repackaging, the signature information stored in the memory that may be requested at the specified location is changed.
  • the android_main controls the subsequent verification logic
  • the second signature information of the currently started application is first acquired, and the first signature information in the memory block of the specified location that is built when the developer completes the development is matched. If the first signature information does not match the second signature information, it is determined that the signature verification of the application does not pass, and the drawing main interface is exited, so that the APP cannot be entered. If the first signature information matches the second signature information, it is determined that the signature verification of the application passes, and the main interface can be drawn, and the slave can enter the APP.
  • the decompiled APP may not apply for a memory block at a specified location at all.
  • the signature information is read from the memory block at the specified location. No signature information was read from the specified location and the check did not pass.
  • the first signature information is a first MD5 value in an initial state of application
  • the second signature information is a second MD5 value when the application is started.
  • the first signature information is that after the developer develops the APP, the MD5 value (Message Digest Algorithm 5) is calculated for a certain file A of the APP, and the MD5 value is the first value. MD5 value.
  • the client downloads the APP from a certain path, such as a third-party platform after installation, the file A of the APP at the current startup is calculated to calculate the MD5 value, and the MD5 value calculated at the startup is the second MD5 value. . Then, if the content of file A is different after the APP is decompiled, its MD5 value is also different.
  • the first signature information is a first certificate file in an initial state of the application
  • the second signature information is a second certificate file when the application is started.
  • the first signature information is after the developer completes the development of the APP, A certificate file of a file content issued by the APP, the certificate file being a first certificate file.
  • the client downloads the APP from a certain path, such as a third-party platform, after the installation, the digital certificate of the APP at the current startup is obtained when starting, and the certificate file at the startup is the second certificate file. Then, if the APP is decompiled, the file content of the APP is different, and the value of the certificate file is different.
  • the APP startup logic is modified. Even after the APP is decompiled, since the local method is called through the JNI interface, and the local method can be built as a SO file through C++, the decompilation is very difficult and basically cannot be reversed. Compilation, then even if the modifier decompiles the general logic of the entire APP, it will change the signature of the APP. If the APP after decompilation is started, it cannot pass the verification logic in the execution file of the above nativeActivity. , the main interface of the APP cannot be started, and the APP cannot be used, and neither the user nor the developer will be harmed by the change of the APP content.
  • the executing the executable file for the nativeActivity through the JAVA local calling interface includes:
  • Sub-step 232 constructing a SO file for the nativeActivity
  • the execution file of the build of the present invention may be a so file.
  • the so file can be understood as a dynamic link library, which can be compiled by C++.
  • adding a signature verification to the application in the logic for drawing the main interface, adding a signature verification to the application, if the signature verification of the application does not pass, exiting the application, ending the drawing of the main interface, if the application After the signature verification is passed, the main interface is drawn.
  • FIG. 2A a specific example of an app launching according to Embodiment 3 of the present invention is shown.
  • Step S210 reading the nativeActivity of the Manifest file
  • Step S220 loading the SO file by calling the JNI interface through the nativeActivity
  • Step S230 executing android_main
  • Step S240 saving the first signature information in the specified memory block
  • Step S250 Acquire second signature information of the currently launched application.
  • Step S260 matching the first signature information with the second signature information; if the first signature information matches the second signature information, proceeding to step 270; if the first signature information does not match the second signature information, proceeding to step 280 ;
  • step 270 the application is launched.
  • step 280 the application is exited and the startup process is ended.
  • the nativeActivity declaration is read from the configuration file to invoke the JAVA local calling interface to load the execution file for the nativeActivity; thus, after loading the execution file for the nativeActivity, The application is signature verified before the main interface of the application is completed, and if the signature verification of the application fails, the application is exited. Since the execution file for the nativeActivity is built by JNI (Java Native Interface), it can construct the above logic in the android_main function by using C++ implementation, and the application cannot be passed due to the decompiled application.
  • JNI Java Native Interface
  • the application can not be started, thereby solving the problem that the application of the Android system is easy to be decompiled due to various logics of constructing the application by using the java, resulting in a lot of useless functions for the user, which is not harmful, and For the developer of the application, this method damages the developer's rights and interests, and avoids the application changes to add other logic to the application, avoiding the interference of unauthenticated information to the user, and protecting the application developer's The beneficial effects of equity.
  • FIG. 3 it is a schematic structural diagram of an apparatus for preventing software decompilation according to the present invention, which may specifically include:
  • the entry declaration module 310 is adapted to declare an entry activity in the configuration file as a nativeActivity for a configuration file of an application of the Android system;
  • the main interface verification construction module 320 is configured to construct an execution file for the nativeActivity through a JAVA local call interface, where an execution file for the nativeActivity is used after the execution file for the nativeActivity is loaded, The application is signature verified before the main interface of the application is started, and if the signature verification of the application fails, the application is exited.
  • the execution file is used to perform signature verification on the application before the execution of the main interface of the application is completed after the execution of the execution file of the nativeActivity, including:
  • an Android main interface function is executed, and the application is signature verified by the main interface function before the main interface of the application is completed.
  • the signature verification of the application is performed before the startup of the main interface of the application is completed by using the main interface function, including:
  • the natve method is called to apply for a piece of memory at a specified location in the system memory, and the preset first signature information is stored;
  • the first signature information is a first MD5 value in an initial state of application
  • the second signature information is a second MD5 value when the application is started.
  • the first signature information is a first certificate file in an initial state of the application
  • the second signature information is a second certificate file when the application is started.
  • the executing the executable file for the nativeActivity through the JAVA local calling interface includes:
  • FIG. 4 it is a schematic structural diagram of an apparatus for preventing software decompilation according to the present invention, which may specifically include:
  • the configuration file reading module 410 is adapted to read the nativeActivity declared in the configuration file of the application when the application of the Android system is started;
  • the main interface loading module 420 is adapted to invoke a JAVA local calling interface to load an execution file for the nativeActivity by using a nativeActivity declared in the configuration file.
  • the main interface signature verification module 430 is adapted to perform signature verification on the application before the main interface of the application is completed after loading the execution file for the nativeActivity, and if the signature verification of the application fails, Then exit the app.
  • the main interface signature verification module includes:
  • a main interface function execution module configured to execute an Android main interface function after the execution file for the nativeActivity is loaded, and use the main interface function to sign the application before the main interface of the application is completed check.
  • the main interface function execution module comprises:
  • the signature information storage module is adapted to apply for a piece of memory in a specified location in the system memory by the natve method after the loading of the execution file of the nativeActivity, and store the preset first signature information;
  • the signature information verification module is configured to obtain the second signature information of the current application, determine whether the first signature information and the second signature information match, and if the first signature information does not match the second signature information, determine the application. The signature verification did not pass.
  • the first signature information is an MD5 value in an initial state of application
  • the second signature information is an MD5 value at the time of application startup.
  • the first signature information is a first certificate file in an initial state of the application
  • the second signature information is a second certificate file when the application is started.
  • the main interface loading module includes:
  • the SO file loading module is adapted to invoke a local calling interface to load the SO file for the nativeActivity.
  • the various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof.
  • a microprocessor or digital signal processor may be used in practice to implement some or all of the components of the anti-software decompiler device, anti-decompiler software boot device, in accordance with an embodiment of the present invention.
  • DSP digital signal processor
  • the invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein.
  • Such a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
  • FIG. 5 illustrates a terminal device, such as a mobile terminal, that can implement anti-software decompilation in accordance with the present invention, which terminal device conventionally includes a processor 510 and calculations in the form of memory 520 Machine program product or computer readable medium.
  • the memory 520 may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read Only Memory), an EPROM, a hard disk, or a ROM.
  • Memory 520 has a memory space 530 for program code 531 for performing any of the method steps described above.
  • storage space 530 for program code may include various program code 531 for implementing various steps in the above methods, respectively.
  • the program code can be read from or written to one or more computer program products.
  • These computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards or floppy disks.
  • Such computer program products are typically portable or fixed storage units as described with reference to FIG.
  • the storage unit may have a storage section, a storage space, and the like arranged similarly to the storage 520 in the terminal device of FIG.
  • the program code can be compressed, for example, in an appropriate form.
  • the storage unit comprises computer readable code 531 'is a code readable by a processor, such as 510, which when executed by the terminal device causes the terminal device to perform each of the methods described above step.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)

Abstract

本发明公开了一种防软件反编译的方法、防反编译软件启动的方法和装置，涉及计算机技术领域。所述防软件反编译的方法包括：针对安卓系统的应用的配置文件，将所述配置文件中的入口activity声明为nativeActivity；通过JAVA本地调用接口构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。本发明取得了可避免应用更改在应用中添加其他逻辑，避免了未经验证的信息对用户的干扰，保护的应用开发者的权益的有益效果。

Description

防软件反编译的方法、防反编译软件启动的方法和装置 技术领域
本发明涉及计算机技术领域，具体涉及一种防软件反编译的方法、一种防软件反编译的装置、一种防反编译软件启动的方法和一种防反编译软件启动的装置。
背景技术
安卓平台发展迅速，已经逐渐成为了移动终端的最普及的操作系统，与其他终端操作系统相比，开放式的安卓系统为应用开发者提供了更多的功能接口，这些功能接口提高了系统的可扩展性。
目前安卓系统的应用的构建都采用java，而java编译得到的文件很容易被反编译。因此存在应用更改者通过非法拷贝、逆向工程、反编译等手段来添加其自己的逻辑，比如在应用中加入自己广告等内容，对于用户来说多了很多无用的功能，存在不小危害，并且对于应用的开发者来说，该种方式损害了开发者的权益。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种防软件反编译的装置和相应的一种防软件反编译的方法。
依据本发明的一个方面，提供了本发明公开了一种防软件反编译的方法，包括：
针对安卓系统的应用的配置文件，将所述配置文件中的入口activity声明为nativeActivity；
通过JAVA本地调用接口构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
依据本发明的另外一个发明，本发明还公开了一种防反编译软件启动的方法，包括：
在安卓系统的应用启动时，读取所述应用的配置文件中声明的nativeActivity；
通过所述配置文件中声明的nativeActivity，调用JAVA本地调用接口，加载针对所述nativeActivity的执行文件；
在加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
依据本发明的另外一个方面，本发明还公开了一种防软件反编译的装置，包括：
入口声明模块，适于针对安卓系统的应用的配置文件，将所述配置文件中的入口activity声明为nativeActivity；
主界面验证构建模块，适于通过JAVA本地调用接口构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
依据本发明的另外一个方面，本发明还公开了一种防反编译软件启动的装置，包括：
配置文件读取模块，适于在安卓系统的应用启动时，读取所述应用的配置文件中声明的nativeActivity；
主界面加载模块，适于通过所述配置文件中声明的nativeActivity，调用JAVA本地调用接口，加载针对所述nativeActivity的执行文件；
主界面签名验证模块，适于在加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
本发明还公开了一种计算机程序，包括计算机可读代码，当所述计算机可读代码终端设备上运行时，导致所述服务器执行前述的任一个所述的防软件反编译的方法。进一步的，还公开了一种计算机可读介质，其中存储了包 括上述防软件反编译的方法的计算机可读代码的计算机程序。
本发明还公开了一种计算机程序，包括计算机可读代码，当所述计算机可读代码终端设备上运行时，导致所述服务器执行前述的任一个所述的防反编译软件启动的方法。进一步的，还公开了一种计算机可读介质，其中存储了包括上述防反编译软件启动的方法的计算机可读代码的计算机程序。
根据本发明的一种防软件反编译的方法可以在安卓系统的应用的，在所述应用的配置文件Manifest文件中，将所述配置文件中的入口activity声明为nativeActivity，然后通过JNI(Java Native Interface，JAVA本地调用接口)构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。由于通过JNI(Java Native Interface，JAVA本地调用接口)构建针对所述nativeActivity的执行文件，其可以通过采用C++实现进行构建android_main函数中的上述逻辑，那么对被反编译的应用，由于签名不能通过，可以使应用无法启动，由此解决了由安卓系统的应用由于采用java构建应用的各种逻辑而导致应用容易被反编译，导致对于用户来说多了很多无用的功能，存在不小危害，并且对于应用的开发者来说，该种方式损害了开发者的权益问题，取得了可避免应用更改在应用中添加其他逻辑，避免了未经验证的信息对用户的干扰，保护的应用开发者的权益的有益效果。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其Manifest文件中目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符 号表示相同的部件。在附图中：
图1示出了根据本发明一个实施例的一种防软件反编译的方法的流程示意图；
图1A示出了根据本发明一个实施例的app整体启动逻辑；
图2示出了根据本发明一个实施例的一种防反编译软件启动的方法的流程示意图；
图2A示出了根据本发明一个实施例具体的一种防反编译软件启动的方法的流程示意图；
图3示出了根据本发明一个实施例的一种防反编译软件启动的装置的结构示意图；
图4示出了根据本发明一个实施例的一种防反编译软件启动的装置的结构示意图；
图5示意性地示出了用于执行根据本发明的方法的终端设备的框图；以及
图6示意性地示出了用于保持或者携带实现根据本发明的方法的程序代码的存储单元；
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
实施例一
参照图1，其示出了本发明的一种防软件反编译的方法的流程示意图，具体可以包括：
步骤110，针对安卓系统的应用的配置文件，将所述配置文件中的入口activity声明为nativeActivity；
在安卓(Android)系统的APP(APPlication，应用)启动时，必然首先加载其配置文件Manifest文件。因为每个安卓应用程序必须有一个Manifest文件配置文件，在其根目录res下。Manifest文件在简单的Android系统的应用提出了重要的信息，信息系统必须具备之前，Manifest文件中可以运行任何应用程序的代码。除其他事项外，清单中执行下列操作：(1)Manifest文件命名为应用程序的Java包。包的名称作为一个应用程序的唯一标识符；(2)Manifest文件中声明了应用程序的组件的活动、服务、广播接收机、内容提供商、应用程序组成。Manifest文件中命名的类，实现每个组件。这些声明让Android系统知道的组件是什么和在什么条件下，他们可以启用。(3)Manifest文件中决定哪些进程将主机应用程序组件。(4)Manifest文件中声明，应用程序必须有权限才能访问受保护的API(APPlication Program Interface，应用程序编程接口)部分，并与其他应用程序进行交互。(5)Manifest文件中还声明，其他进程需要以与应用程序的组件交互的权限。(6)Manifest文件中宣布的Android API的应用程序需要的最低水平。等等一系列功能。
在上述一系列功能中，有一个声明为入口activity，即声明应用主界面启动的类。在本发明实施例中，Manifest文件中的入口activity声明为nativeActivity。
步骤120，通过JAVA本地调用接口构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
然后通过jni实现nativeActivity的逻辑，即通过JNI口构建针对所述nativeActivity的执行文件。JNI是Java Native Interface，java本地接口，也就是java本地接口，它提供了若干的API实现了和Java和其他语言(C&C++)的通信。
当然所述执行文件还用于绘制主界面相关的逻辑，以及校验通过后，启动相应功能的逻辑。
优选地，所述执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
子步骤121，在所述针对所述nativeActivity的执行文件加载后，执行安卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验。
在本发明实施例中应用的主界面的启动的整体逻辑如图1A：
A11，加载Manifest文件中的nativeActivity。
A12，调用Android Jni接口；
安卓系统中任何一个APP启动时，都会去加载Manifest文件，然后其中的入口activity，以绘制主界面。但是在本发明实施例中加载Manifest文件，从中读取nativeActivity声明，从而可以通过JNI接口去调用本地方法，加载通过JNI接口加载本地应用主函数android_main的执行文件。
A13，执行应用主函数android_main；
在本发明实施例中执行android_main。
A14，执行主界面初始化函数engine_init_display；
然后会根据上述执行文件调用engine_init_display对绘制主界面需要的资源进行初始化。
A15，执行框架绘制函数engine_draw_frame；
然后执行engine_draw_frame绘制主界面的框架。
A16，在frame中执行UI条目绘制函数engine_term_display。
然后执行engine_term_display绘制框架中的具体UI界面。
本发明将上述的步骤A14-A16统一以JNI规定构建一个执行文件，比如so文件，那么应用读取到Manifest文件中的nativeActivity后，需要首先读取与nativeActivity对应的本地so文件去绘制主界面的activity。那么本发明则可在步骤A13执行安卓主界面函数android_main之后，主界面绘制之前，加入应用主界面的签名校验逻辑，由android_main控制所述签名校验逻辑。
优选地，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
子步骤1211，在主界面函数中，调用natve方法在系统内存中指定位置申请一块内存，存放预置的第一签名信息；
子步骤1212，获取当前应用的第二签名信息，判断所述第一签名信息与第二签名信息是否匹配；所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过。
前述签名校验逻辑中，在android_main控制的逻辑中加入natve方法，由natve方法执行在在系统内存中指定位置申请一块内存，存放预置的第一签名信息。那么果反编译过APP，重新打包后，其可能在指定位置申请的内存中存放的签名信息被更改。
那么在android_main控制后续验证逻辑时，首先获取当前启动的应用的第二签名信息，与开发者开发完成时构建的存在指定位置的内存块中第一签名信息进行匹配。如果所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过，退出绘制主界面，从而不能进入APP。如果所述第一签名信息与第二签名信息匹配，则确定所述应用的签名校验通过，可以绘制主界面，从能进入APP。
当然在本发明实施例中，经过反编译的APP，其还可能根本就不在指定位置申请内存块，本发明实施例android_main控制后续验证逻辑时，则从指定位置的内存块读取签名信息，如果没有从指定位置读取到任何签名信息，也认为校验没有通过。
优选地，所述第一签名信息为应用初始状态下的第一MD5值，所述第二签名信息为应用启动时的第二MD5值。
在本发明实施例中，第一签名信息为开发者把APP开发完成后，对APP的某个文件A计算MD5值(Message-Digest Algorithm 5，信息摘要算法5)，，该MD5值为第一MD5值。当客户端从某个途径，比如第三方平台下载所述APP，进行安装后，启动时则会计算当前启动时的APP的文件A计算MD5值，该启动时计算的MD5值为第二MD5值。那么如果APP被 反编译后，文件A的内容不同，其MD5值也不同。
优选地，所述第一签名信息为所述应用初始状态下的第一证书文件，所述第二签名信息为所述应用启动时的第二证书文件。
在本发明实施例中，第一签名信息为开发者把APP开发完成后，对APP的下发的一个文件内容的证书文件，该证书文件为第一证书文件。当客户端从某个途径，比如第三方平台下载所述APP，进行安装后，启动时则会获取当前启动时的APP的数字证书，该启动时的该证书文件为第二证书文件。那么如果APP被反编译后，APP的文件内容不同，其证书文件值也不同。
那么如此对APP的启动逻辑进行了修改，即使该APP被反编译之后，由于是通过JNI接口调用的本地方法，而本地方法可以通过C++构建为SO文件，反编译难度巨大，基本上无法被反编译，那么即使有修改者对整个APP的大致逻辑进行了反编译，也会改变APP的签名，那么对于被反编译之后的APP，如果启动，其不能通过上述nativeActivity的执行文件中的校验逻辑，则无法启动APP的主界面，也就无法使用APP，对用户和开发者来说均不会由于APP内容改变而受到危害。
优选地，所述通过JAVA本地调用接口构建针对所述nativeActivity的执行文件包括：
子步骤122，构建针对所述nativeActivity的SO文件；。
本发明的构建的执行文件可为so文件。so文件可以理解为动态链接库，可以由C++编译出来。所述所述SO文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。即通过所述so文件，在绘制主界面的逻辑中，加入对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用，结束主界面的绘制，如果所述应用的签名校验通过，则绘制主界面。
本发明实施例在所述应用的配置文件Manifest文件中，将所述配置文件中的入口activity声明为nativeActivity，然后通过JNI(Java Native Interface， JAVA本地调用接口)构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。由于通过JNI(Java Native Interface，JAVA本地调用接口)构建针对所述nativeActivity的执行文件，其可以通过采用C++实现android_main函数中的上述逻辑，那么对被反编译的应用，由于签名不能通过，可以使应用无法启动，由此解决了由安卓系统的应用由于采用java构建应用的各种逻辑而导致应用容易被反编译，导致对于用户来说多了很多无用的功能，存在不小危害，并且对于应用的开发者来说，该种方式损害了开发者的权益问题，取得了可避免应用更改在应用中添加其他逻辑，避免了未经验证的信息对用户的干扰，保护的应用开发者的权益的有益效果。
实施例二
相对实施例一的APP构建过程，下面在实施例二对应介绍APP的启动过程。
参照图2，其示出了本发明的一种防反编译软件启动的方法的流程示意图，具体可以包括：
步骤210，在安卓系统的应用启动时，读取所述应用的配置文件中声明的nativeActivity；
在安卓(Android)系统的APP(APPlication，应用)启动时，必然首先加载其配置文件Manifest文件。因为每个安卓应用程序必须有一个Manifest文件配置文件，在其根目录res下。Manifest文件在简单的Android系统的应用提出了重要的信息，信息系统必须具备之前，Manifest文件中可以运行任何应用程序的代码。除其他事项外，清单中执行下列操作：(1)Manifest文件命名为应用程序的Java包。包的名称作为一个应用程序的唯一标识符；(2)Manifest文件中声明了应用程序的组件的活动、服务、广播接收机、内容提供商、应用程序组成。Manifest文件中命名的类，实现每个组 件。这些声明让Android系统知道的组件是什么和在什么条件下，他们可以启用。(3)Manifest文件中决定哪些进程将主机应用程序组件。(4)Manifest文件中声明，应用程序必须有权限才能访问受保护的API(APPlication Program Interface，应用程序编程接口)部分，并与其他应用程序进行交互。(5)Manifest文件中还声明，其他进程需要以与应用程序的组件交互的权限。(6)Manifest文件中宣布的Android API的应用程序需要的最低水平。等等一系列功能。
在上述一系列功能中，有一个声明为入口activity，本发明实施例将该入口activity声明为nativeActivity。那么本发明实施例步骤210后，需要读取前述Manifest文件中的这个nativeActivity声明。
步骤220，通过所述配置文件中声明的nativeActivity，调用JAVA本地调用接口，加载针对所述nativeActivity的执行文件；
在本发明实施例中，首先会构建针对所述nativeActivity的执行文件，该执行文件的逻辑包括在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用；如果所述应用的签名校验通过，则启动主界面，进入APP。
然后即通过nativeActivity声明可知道其调用的为本地方法，那么则调用JNI接口，去加载针对所述nativeActivity的执行文件。
步骤230，在加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
然后则可执行app签名校验逻辑，即在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用，如果所述应用的签名校验通过，则绘制主界面，进入app。
优选地，加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验包括：
子步骤231，在所述针对所述nativeActivity的执行文件加载后，执行安 卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验。
在本发明实施例中应用的主界面的启动的整体逻辑如图1A：
A11，加载Manifest文件中的nativeActivity。
A12，调用Android Jni接口；
安卓系统中任何一个APP启动时，都会去加载Manifest文件，然后其中的入口activity，以绘制主界面。但是在本发明实施例中加载Manifest文件，从中读取nativeActivity声明，从而可以通过JNI接口去调用本地方法，加载通过JNI接口加载本地应用主函数android_main的执行文件。
A13，执行应用主函数android_main；
在本发明实施例中执行android_main。
A14，执行主界面初始化函数engine_init_display；
然后会根据上述执行文件调用engine_init_display对绘制主界面需要的资源进行初始化。
A15，执行框架绘制函数engine_draw_frame；
然后执行engine_draw_frame绘制主界面的框架。
A16，在frame中执行UI条目绘制函数engine_term_display。
然后执行engine_term_display绘制框架中的具体UI界面。
本发明将上述的步骤A14-A16统一以JNI规定构建一个执行文件，比如so文件，那么应用读取到Manifest文件中的nativeActivity后，需要首先读取与nativeActivity对应的本地so文件去绘制主界面的activity。那么本发明则可在步骤A13执行安卓主界面函数android_main之后，主界面绘制之前，加入应用主界面的签名校验逻辑，由android_main控制所述签名校验逻辑。
优选地，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
子步骤2211，在主界面函数中，调用natve方法在系统内存中指定位置申请一块内存，存放预置的第一签名信息；
子步骤2212，获取当前应用的第二签名信息，判断所述第一签名信息与第二签名信息是否匹配；所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过。
前述签名校验逻辑中，在android_main控制的逻辑中加入natve方法，由natve方法执行在在系统内存中指定位置申请一块内存，存放预置的第一签名信息。那么果反编译过APP，重新打包后，其可能在指定位置申请的内存中存放的签名信息被更改。
那么在android_main控制后续验证逻辑时，首先获取当前启动的应用的第二签名信息，与开发者开发完成时构建的存在指定位置的内存块中第一签名信息进行匹配。如果所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过，退出绘制主界面，从而不能进入APP。如果所述第一签名信息与第二签名信息匹配，则确定所述应用的签名校验通过，可以绘制主界面，从能进入APP。
当然在本发明实施例中，经过反编译的APP，其还可能根本就不在指定位置申请内存块，本发明实施例android_main控制后续验证逻辑时，则从指定位置的内存块读取签名信息，如果没有从指定位置读取到任何签名信息，也认为校验没有通过。
优选地，所述第一签名信息为应用初始状态下的第一MD5值，所述第二签名信息为应用启动时的第二MD5值。
在本发明实施例中，第一签名信息为开发者把APP开发完成后，对APP的某个文件A计算MD5值(Message-Digest Algorithm 5，信息摘要算法5)，，该MD5值为第一MD5值。当客户端从某个途径，比如第三方平台下载所述APP，进行安装后，启动时则会计算当前启动时的APP的文件A计算MD5值，该启动时计算的MD5值为第二MD5值。那么如果APP被反编译后，文件A的内容不同，其MD5值也不同。
优选地，所述第一签名信息为所述应用初始状态下的第一证书文件，所述第二签名信息为所述应用启动时的第二证书文件。
在本发明实施例中，第一签名信息为开发者把APP开发完成后，对 APP的下发的一个文件内容的证书文件，该证书文件为第一证书文件。当客户端从某个途径，比如第三方平台下载所述APP，进行安装后，启动时则会获取当前启动时的APP的数字证书，该启动时的该证书文件为第二证书文件。那么如果APP被反编译后，APP的文件内容不同，其证书文件值也不同。
那么如此对APP的启动逻辑进行了修改，即使该APP被反编译之后，由于是通过JNI接口调用的本地方法，而本地方法可以通过C++构建为SO文件，反编译难度巨大，基本上无法被反编译，那么即使有修改者对整个APP的大致逻辑进行了反编译，也会改变APP的签名，那么对于被反编译之后的APP，如果启动，其不能通过上述nativeActivity的执行文件中的校验逻辑，则无法启动APP的主界面，也就无法使用APP，对用户和开发者来说均不会由于APP内容改变而受到危害。
优选地，所述通过JAVA本地调用接口构建针对所述nativeActivity的执行文件包括：
子步骤232，构建针对所述nativeActivity的SO文件；。
本发明的构建的执行文件可为so文件。so文件可以理解为动态链接库，可以由C++编译出来。在所述执行文件中，在绘制主界面的逻辑中，加入对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用，结束主界面的绘制，如果所述应用的签名校验通过，则绘制主界面。
参照图2A，其示出了本发明实施例三的一种app启动的具体示例。
步骤S210，读取Manifest文件的nativeActivity；
步骤S220，通过nativeActivity，以调用JNI接口加载SO文件；
步骤S230，执行android_main；
步骤S240，在指定内存块中保存第一签名信息；
步骤S250，获取当前启动应用的第二签名信息；
步骤S260，将第一签名信息与第二签名信息进行匹配；如果第一签名信息与第二签名信息匹配，则进入步骤270；如果第一签名信息与第二签名信息不匹配，则进入步骤280；
步骤270，启动应用。
步骤280，退出应用，结束启动过程。
本发明实施例在安卓系统的应用启动时，从其配置文件中读取nativeActivity声明，以调用JAVA本地调用接口，加载针对所述nativeActivity的执行文件；从而在加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。由于通过JNI(Java Native Interface，JAVA本地调用接口)构建针对所述nativeActivity的执行文件，其可以通过采用C++实现进行构建android_main函数中的上述逻辑，那么对被反编译的应用，由于签名不能通过，可以使应用无法启动，由此解决了由安卓系统的应用由于采用java构建应用的各种逻辑而导致应用容易被反编译，导致对于用户来说多了很多无用的功能，存在不小危害，并且对于应用的开发者来说，该种方式损害了开发者的权益问题，取得了可避免应用更改在应用中添加其他逻辑，避免了未经验证的信息对用户的干扰，保护的应用开发者的权益的有益效果。
实施例三
参照图3，其示出了本发明一种防软件反编译的装置的结构示意图，具体可以包括：
入口声明模块310，适于针对安卓系统的应用的配置文件，将所述配置文件中的入口activity声明为nativeActivity；
主界面验证构建模块320，适于通过JAVA本地调用接口构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
优选地，所述执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
在所述针对所述nativeActivity的执行文件加载后，执行安卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验。
优选地，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
在主界面函数中，调用natve方法在系统内存中指定位置申请一块内存，存放预置的第一签名信息；
获取当前应用的第二签名信息，判断所述第一签名信息与第二签名信息是否匹配；所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过。
优选地，所述第一签名信息为应用初始状态下的第一MD5值，所述第二签名信息为应用启动时的第二MD5值。
优选地，所述第一签名信息为所述应用初始状态下的第一证书文件，所述第二签名信息为所述应用启动时的第二证书文件。
优选地，所述通过JAVA本地调用接口构建针对所述nativeActivity的执行文件包括：
构建针对所述nativeActivity的SO文件；。
实施例四
参照图4，其示出了本发明一种防软件反编译的装置的结构示意图，具体可以包括：
配置文件读取模块410，适于在安卓系统的应用启动时，读取所述应用的配置文件中声明的nativeActivity；
主界面加载模块420，适于通过所述配置文件中声明的nativeActivity，调用JAVA本地调用接口，加载针对所述nativeActivity的执行文件；
主界面签名验证模块430，适于在加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
优选地，所述主界面签名验证模块包括：
主界面函数执行模块，适于在所述针对所述nativeActivity的执行文件加载后，执行安卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验。
优选地，所述主界面函数执行模块包括：
签名信息存放模块，适于针对所述nativeActivity的执行文件在加载后，通过natve方法在系统内存中指定位置申请一块内存，存放预置的第一签名信息；
签名信息验证模块，适于获取当前应用的第二签名信息，判断所述第一签名信息与第二签名信息是否匹配；所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过。
优选地，所述第一签名信息为应用初始状态下的MD5值，所述第二签名信息为应用启动时的MD5值。
优选地，所述第一签名信息为所述应用初始状态下的第一证书文件，所述第二签名信息为所述应用启动时的第二证书文件。
优选地，所述主界面加载模块包括：
SO文件加载模块，适于调用本地调用接口，加载针对所述nativeActivity的SO文件。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的防软件反编译设备、防反编译软件启动设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
例如，图5示出了可以实现根据本发明的防软件反编译的终端设备，例如移动终端，该终端设备传统上包括处理器510和以存储器520形式的计算 机程序产品或者计算机可读介质。存储器520可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储器520具有用于执行上述方法中的任何方法步骤的程序代码531的存储空间530。例如，用于程序代码的存储空间530可以包括分别用于实现上面的方法中的各种步骤的各个程序代码531。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为如参考图6所述的便携式或者固定存储单元。该存储单元可以具有与图5的终端设备中的存储器520类似布置的存储段、存储空间等。程序代码可以例如以适当形式进行压缩。通常，存储单元包括计算机可读代码531’，即可以由例如诸如510之类的处理器读取的代码，这些代码当由终端设备运行时，导致该终端设备执行上面所描述的方法中的各个步骤。
当然，本发明实施例的防反编译软件启动的终端设备的结构和相应的计算机程序产品分别与图5、图6类似，在此不再赘叙。
本文中所称的“一个实施例”、“实施例”或者“一个或者多个实施例”意味着，结合实施例描述的特定特征、结构或者特性包括在本发明的至少一个实施例中。此外，请注意，这里“在一个实施例中”的词语例子不一定全指同一个实施例。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的 计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
此外，还应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (28)

  1. 一种防软件反编译的方法，包括：
    针对安卓系统的应用的配置文件，将所述配置文件中的入口activity声明为nativeActivity；
    通过JAVA本地调用接口构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
  2. 如权利要求1所述的方法，其特征在于，所述执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
    在所述针对所述nativeActivity的执行文件加载后，执行安卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验。
  3. 如权利要求1所述的方法，其特征在于，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
    在主界面函数中，调用natve方法在系统内存中指定位置申请一块内存，存放预置的第一签名信息；
    获取当前应用的第二签名信息，判断所述第一签名信息与第二签名信息是否匹配；所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过。
  4. 如权利要求3所述的方法，其特征在于，所述第一签名信息为应用初始状态下的第一MD5值，所述第二签名信息为应用启动时的第二MD5值。
  5. 如权利要求3所述的方法，其特征在于，所述第一签名信息为所述应用初始状态下的第一证书文件，所述第二签名信息为所述应用启动时的第二证书文件。
  6. 如权利要求1所述的方法，其特征在于，所述通过JAVA本地调用接口构建针对所述nativeActivity的执行文件包括：
    构建针对所述nativeActivity的SO文件；所述SO文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
  7. 一种防反编译软件启动的方法，包括：
    在安卓系统的应用启动时，读取所述应用的配置文件中声明的nativeActivity；
    通过所述配置文件中声明的nativeActivity，调用JAVA本地调用接口，加载针对所述nativeActivity的执行文件；
    在加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
  8. 如权利要求7所述的方法，其特征在于，加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验包括：
    在所述针对所述nativeActivity的执行文件加载后，执行安卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验。
  9. 如权利要求8所述的方法，其特征在于，执行安卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验包括：
    在主界面函数中，调用natve方法在系统内存中指定位置申请一块内存，存放预置的第一签名信息；
    获取当前应用的第二签名信息，判断所述第一签名信息与第二签名信息是否匹配；所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过。
  10. 如权利要求9所述的方法，其特征在于，所述第一签名信息为应用初始状态下的第一MD5值，所述第二签名信息为应用启动时的第二MD5 值。
  11. 如权利要求9所述的方法，其特征在于，所述第一签名信息为所述应用初始状态下的第一证书文件，所述第二签名信息为所述应用启动时的第二证书文件。
  12. 如权利要求7所述的方法，其特征在于，所述调用JAVA本地调用接口，加载针对所述nativeActivity的执行文件包括：
    调用本地调用接口，加载针对所述nativeActivity的SO文件；所述SO文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
  13. 一种防软件反编译的装置，包括：
    入口声明模块，适于针对安卓系统的应用的配置文件，将所述配置文件中的入口activity声明为nativeActivity；
    主界面验证构建模块，适于通过JAVA本地调用接口构建针对所述nativeActivity的执行文件；其中，针对所述nativeActivity的执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
  14. 如权利要求13所述的装置，其特征在于，所述执行文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
    在所述针对所述nativeActivity的执行文件加载后，执行安卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验。
  15. 如权利要求14所述的装置，其特征在于，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验，包括：
    在主界面函数中，调用natve方法在系统内存中指定位置申请一块内存，存放预置的第一签名信息；
    获取当前应用的第二签名信息，判断所述第一签名信息与第二签名信息是否匹配；所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过。
  16. 如权利要求15所述的装置，其特征在于，所述第一签名信息为应用初始状态下的第一MD5值，所述第二签名信息为应用启动时的第二MD5值。
  17. 如权利要求15所述的装置，其特征在于，所述第一签名信息为所述应用初始状态下的第一证书文件，所述第二签名信息为所述应用启动时的第二证书文件。
  18. 如权利要求13所述的装置，其特征在于，所述通过JAVA本地调用接口构建针对所述nativeActivity的执行文件包括：
    构建针对所述nativeActivity的SO文件；所述SO文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
  19. 一种防反编译软件启动的装置，包括：
    配置文件读取模块，适于在安卓系统的应用启动时，读取所述应用的配置文件中声明的nativeActivity；
    主界面加载模块，适于通过所述配置文件中声明的nativeActivity，调用JAVA本地调用接口，加载针对所述nativeActivity的执行文件；
    主界面签名验证模块，适于在加载针对所述nativeActivity的执行文件后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
  20. 如权利要求19所述的装置，其特征在于，所述主界面签名验证模块包括：
    主界面函数执行模块，适于在所述针对所述nativeActivity的执行文件加载后，执行安卓主界面函数，通过所述主界面函数，在所述应用的主界面启动完成之前对所述应用进行签名校验。
  21. 如权利要求20所述的装置，其特征在于，所述主界面函数执行模块包括：
    签名信息存放模块，适于针对所述nativeActivity的执行文件在加载后，通过natve方法在系统内存中指定位置申请一块内存，存放预置的第一签名信息；
    签名信息验证模块，适于获取当前应用的第二签名信息，判断所述第一签名信息与第二签名信息是否匹配；所述第一签名信息与第二签名信息不匹配，则确定所述应用的签名校验不通过。
  22. 如权利要求21所述的装置，其特征在于，所述第一签名信息为应用初始状态下的MD5值，所述第二签名信息为应用启动时的MD5值。
  23. 如权利要求21所述的装置，其特征在于，所述第一签名信息为所述应用初始状态下的第一证书文件，所述第二签名信息为所述应用启动时的第二证书文件。
  24. 如权利要求19所述的装置，其特征在于，所述主界面加载模块包括：
    SO文件加载模块，适于调用本地调用接口，加载针对所述nativeActivity的SO文件；所述SO文件用于，在所述针对所述nativeActivity的执行文件加载后，在所述应用的主界面启动完成之前对所述应用进行签名校验，如果所述应用的签名校验不通过，则退出应用。
  25. 一种计算机程序，包括计算机可读代码，当所述计算机可读代码终端设备上运行时，导致所述服务器执行根据权利要求1-6中的任一个所述的防软件反编译的方法。
  26. 一种计算机可读介质，其中存储了如权利要求25所述的计算机程序。
  27. 一种计算机程序，包括计算机可读代码，当所述计算机可读代码终端设备上运行时，导致所述服务器执行根据权利要求7-12中的任一个所述的防反编译软件启动的方法。
  28. 一种计算机可读介质，其中存储了如权利要求27所述的计算机程序。
PCT/CN2015/098978 2015-01-27 2015-12-25 防软件反编译的方法、防反编译软件启动的方法和装置 Ceased WO2016119548A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510041209.7A CN104615933B (zh) 2015-01-27 2015-01-27 防软件反编译的方法、防反编译软件启动的方法和装置
CN201510041209.7 2015-01-27

Publications (1)

Publication Number Publication Date
WO2016119548A1 true WO2016119548A1 (zh) 2016-08-04

Family

ID=53150372

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/098978 Ceased WO2016119548A1 (zh) 2015-01-27 2015-12-25 防软件反编译的方法、防反编译软件启动的方法和装置

Country Status (2)

Country Link
CN (1) CN104615933B (zh)
WO (1) WO2016119548A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110275710A (zh) * 2019-06-10 2019-09-24 天翼电子商务有限公司 一种Java本地接口一致性检查方法及系统、存储介质及终端
CN114237614A (zh) * 2021-12-14 2022-03-25 北京奇艺世纪科技有限公司 应用程序的处理方法、装置、电子设备和存储介质
CN114265598A (zh) * 2021-12-22 2022-04-01 深圳市智微智能软件开发有限公司 基于Android的签名白名单方法、系统、终端及存储介质

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104615933B (zh) * 2015-01-27 2018-08-17 北京奇虎科技有限公司 防软件反编译的方法、防反编译软件启动的方法和装置
CN105844150A (zh) * 2016-03-23 2016-08-10 青岛海信传媒网络技术有限公司 一种应用程序的数据保护方法和装置
CN106022098A (zh) * 2016-05-10 2016-10-12 青岛海信传媒网络技术有限公司 一种应用程序的签名验证方法和装置
CN107766701B (zh) * 2016-08-19 2021-01-26 北京京东尚科信息技术有限公司 电子设备、动态库文件保护方法及装置
CN106843853B (zh) * 2016-12-28 2020-09-08 北京五八信息技术有限公司 保护用户信息的方法和装置
CN109271758B (zh) * 2018-08-24 2021-04-20 阿里巴巴（中国）有限公司 防止So文件被盗用的方法、设备、装置及服务器

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103544046A (zh) * 2013-10-25 2014-01-29 苏州通付盾信息技术有限公司 一种移动应用的软件加固方法
CN104021321A (zh) * 2014-06-17 2014-09-03 北京奇虎科技有限公司 软件安装包的加固保护方法和装置
CN104615933A (zh) * 2015-01-27 2015-05-13 北京奇虎科技有限公司 防软件反编译的方法、防反编译软件启动的方法和装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102831342B (zh) * 2012-07-28 2016-01-06 北京深思数盾科技有限公司 一种提高安卓系统中应用程序保护强度的方法
CN103679029A (zh) * 2013-12-11 2014-03-26 北京奇虎科技有限公司 一种修复山寨应用程序的方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103544046A (zh) * 2013-10-25 2014-01-29 苏州通付盾信息技术有限公司 一种移动应用的软件加固方法
CN104021321A (zh) * 2014-06-17 2014-09-03 北京奇虎科技有限公司 软件安装包的加固保护方法和装置
CN104615933A (zh) * 2015-01-27 2015-05-13 北京奇虎科技有限公司 防软件反编译的方法、防反编译软件启动的方法和装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110275710A (zh) * 2019-06-10 2019-09-24 天翼电子商务有限公司 一种Java本地接口一致性检查方法及系统、存储介质及终端
CN110275710B (zh) * 2019-06-10 2023-07-14 天翼电子商务有限公司 一种Java本地接口一致性检查方法及系统、存储介质及终端
CN114237614A (zh) * 2021-12-14 2022-03-25 北京奇艺世纪科技有限公司 应用程序的处理方法、装置、电子设备和存储介质
CN114265598A (zh) * 2021-12-22 2022-04-01 深圳市智微智能软件开发有限公司 基于Android的签名白名单方法、系统、终端及存储介质

Also Published As

Publication number Publication date
CN104615933B (zh) 2018-08-17
CN104615933A (zh) 2015-05-13

Similar Documents

Publication Publication Date Title
US9536080B2 (en) Method for validating dynamically loaded libraries using team identifiers
CN104615933B (zh) 防软件反编译的方法、防反编译软件启动的方法和装置
CN104008340B (zh) 病毒查杀方法及装置
CN107451474B (zh) 用于终端的软件漏洞修复方法和装置
US10713028B2 (en) On-demand installer for resource packages
US9513937B2 (en) Method and client for using an embedded ActiveX plug-in in a browser
CN106971098B (zh) 一种防重打包的方法及其装置
US10846101B2 (en) Method and system for starting up application
CN105786538B (zh) 基于安卓系统的软件升级方法和装置
US9189300B2 (en) Dynamic service discovery
US20140337824A1 (en) Out-of-band framework libraries within applications
CN104484585A (zh) 一种应用程序安装包的处理方法、装置及移动设备
CN108229148B (zh) 一种基于Android虚拟机的沙箱脱壳方法及系统
JP2019502197A (ja) ランタイム生成コードにおける悪意のあるコードの検出のためのシステムおよび方法
CN106560830A (zh) 一种Linux嵌入式系统中的安全防护方法及系统
CN112698867B (zh) 注解信息的动态修改方法、装置、电子设备及介质
CN113391874A (zh) 一种虚拟机检测对抗方法、装置、电子设备及存储介质
CN107943544B (zh) 一种内核补丁的加载方法及装置
US9842018B2 (en) Method of verifying integrity of program using hash
US10606611B2 (en) Techniques for performing dynamic linking
CN114489698A (zh) 应用程序安装方法和装置
CN106203087B (zh) 注入防护方法、系统、终端以及存储介质
CN113157337A (zh) 应用程序启动方法、装置、终端设备及存储介质
CN112543104A (zh) 应用程序打包方法、装置、电子设备及存储介质
CN109408073B (zh) 一种Android非侵入式应用重打包方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15879746

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15879746

Country of ref document: EP

Kind code of ref document: A1