Application tampering verification method and device, electronic equipment and medium

Abstract

The invention provides an application tampering verification method and device, equipment and a medium, and the method comprises the steps: sending a first network request containing a channel identifier and mobile terminal equipment information to a server, so as to enable the server to carry out distribution channel verification on an APK file of an application; receiving a distribution channel key sent by the server; obtaining static signature information of a static SO file in the APK file based on the distribution channel key; a second network request containing the static signature information is sent to the server, so that the server carries out static tamper-proof verification on the APK file; and receiving a static tamper-proof verification result sent by the server, and prohibiting or allowing the application program to run based on the static tamper-proof verification result. In addition, the dynamic signature information during running of the APK file is obtained in a mode of dynamically injecting the SO file, and whether the application program is tampered or not in actual running can be verified in real time.

Description

Technical Field

[0001] The present disclosure relates to the field of information security technology, and in particular to an application tampering verification method, device, electronic device and medium. Background Art

[0002] In the development process of Android applications, ensuring the security of the application is crucial. Since Android applications are usually stored in the DEX (Dalvik Executable) format, this format is relatively easy to be decrypted by decompilation tools, making the original Java bytecode readable. Especially in the signature verification of the application, it usually relies on private keys, which are used to generate signatures to prove the integrity of the application.

[0003] However, it is unsafe to store the private key directly in the JAVA code because once the code is decompiled, the private key is exposed to the attacker. The attacker can use the private key to forge the signature or modify the signature verification logic to bypass the server's verification, thereby compromising the security of the application. In addition, if the private key or signature information of the communication is obtained by the attacker, they can tamper with the communication content, or forge requests and responses to steal data or perform other malicious activities. Even if the signature verification of the application fails, local functions may still be used because these functions do not rely on network communication. An attacker can modify the return value of the verification result so that the application can continue to use certain local functions even if the network verification fails. This increases the security risk of the application because it allows unverified functions to run under unsafe conditions. Summary of the invention

[0004] In view of the shortcomings of the prior art described above, the purpose of the present disclosure is to provide an application tampering verification method, device, electronic device and medium, aiming to reduce the risk of application being attacked and protect user privacy and data security.

[0005] The first aspect of the present disclosure provides an application tampering verification method, which is applied to a mobile terminal, including: sending a first network request containing a channel identifier and the mobile terminal device information to a server, so that the server performs a distribution channel verification on the APK file of the application; receiving a distribution channel key sent by the server; based on the distribution channel key, obtaining static signature information of a static SO file in the APK file; sending a second network request containing the static signature information to the server, so that the server performs a static anti-tampering verification on the APK file; receiving a static anti-tampering verification result sent by the server, and prohibiting or allowing the application to run based on the static anti-tampering verification result.

[0006] In an embodiment of the first aspect, it also includes: receiving a distribution channel verification failure notification, and prohibiting the application from running.

[0007] In an embodiment of the first aspect, the sending of a first network request including a channel identifier and the device information of the mobile terminal to a server so that the server performs distribution channel verification on an APK file of an application includes: embedding a unique channel identifier during the packaging process of the APK file to identify the distribution channel of the application; obtaining the device information of the mobile terminal in response to a startup instruction of the application; and sending a first network request including the channel identifier and the device information to the server so that the server performs distribution channel verification on the APK file of the application.

[0008] In an embodiment of the first aspect, the static SO file is in an encrypted state, and the encryption process includes: reading the metadata of the static SO file to determine the signature information fragment contained therein; performing AES encryption on the signature information fragment; and writing the encrypted signature information fragment back to the static SO file.

[0009] In an embodiment of the first aspect, obtaining the static signature information of the static SO file in the APK file based on the distribution channel key includes: reading the header information of the static SO file based on the memory address of the static SO file; determining the location of the encrypted signature information fragment based on the header information; and performing AES decryption on the encrypted signature information fragment using the distribution channel key to obtain static signature information.

[0010] In an embodiment of the first aspect, after the static anti-tampering verification is successful, it further includes a dynamic anti-tampering verification: obtaining dynamic signature information when the APK file is running; sending a third network request containing the dynamic signature information to the server, so that the server performs a dynamic anti-tampering verification on the APK file; or comparing the static signature information with the dynamic signature information to perform a dynamic anti-tampering verification on the APK file; if the dynamic anti-tampering verification result indicates that the APK file has not been tampered with, allowing the application to run; if the dynamic anti-tampering verification result indicates that the APK file has been tampered with, prohibiting the application from running.

[0011] In an embodiment of the first aspect, the obtaining of dynamic signature information of an APK file during runtime includes: using a custom loader to dynamically load an SO file pre-stored on the server side; reading the pre-stored SO file and accessing a method stored in the pre-stored SO file; and calling the method in the pre-stored SO file to obtain the dynamic signature information of the APK file during runtime.

[0012] The second aspect of the present disclosure discloses an application tampering verification method, which is applied to a server side, including: receiving a first network request from a mobile terminal, the first network request including a channel identifier of an APK file and mobile terminal device information; performing a distribution channel verification on the APK file based on the channel identifier and the mobile terminal device information; when the distribution channel verification is successful, sending a distribution channel key to the mobile terminal; receiving a second network request from the mobile terminal, the second network request including static signature information of a static SO file extracted from the APK file; performing a static anti-tampering verification on the APK file based on the static signature information to confirm whether the APK file has been tampered with; and sending the static anti-tampering verification result to the mobile terminal.

[0013] In an embodiment of the second aspect, it also includes: when the distribution channel verification fails, sending a distribution channel verification failure notification to the mobile terminal.

[0014] In an embodiment of the second aspect, it also includes: dynamically injecting a pre-stored SO file into the mobile terminal, so that the mobile terminal obtains the dynamic signature information of the APK file during runtime through the pre-stored SO file.

[0015] In an embodiment of the second aspect, it also includes: receiving a third network request from the mobile terminal, the third network request including dynamic signature information of the SO file in the APK file; wherein the dynamic signature information is used to indicate the status of the APK file in actual operation; performing dynamic anti-tampering verification on the APK file based on the dynamic signature information to confirm whether the APK file has been tampered with in actual operation; and sending the dynamic anti-tampering verification result to the mobile terminal.

[0016] The third aspect of the present disclosure discloses an application tampering verification device, which is arranged in a mobile terminal, including: a first sending module, used to send a first network request containing a channel identifier and the mobile terminal device information to a server, so that the server performs a distribution channel verification on the APK file of the application; a first receiving module, used to receive a distribution channel key sent by the server; an acquisition module, used to obtain static signature information of a static SO file in the APK file based on the distribution channel key; a second sending module, used to send a second network request containing the static signature information to the server, so that the server performs a static anti-tampering verification on the APK file; a first control module, used to receive the static anti-tampering verification result sent by the server, and based on the static anti-tampering verification result, prohibit or allow the application to run.

[0017] The fourth aspect of the present disclosure discloses an application tampering verification device, which is arranged on the server side, including: a second receiving module, used to receive a first network request from a mobile terminal, the first network request including a channel identifier of an APK file and mobile terminal device information; a distribution channel verification module, used to perform distribution channel verification on the APK file based on the channel identifier and the mobile terminal device information; a third sending module, used to send a distribution channel key to the mobile terminal when the distribution channel verification is successful; the third receiving module, used to receive a second network request from the mobile terminal, the second network request including static signature information of a static SO file obtained from the APK file; a static anti-tampering verification module, used to perform static anti-tampering verification on the APK file based on the static signature information to confirm whether the APK file has been tampered with; and a fourth sending module, used to send the static verification result to the mobile terminal.

[0018] The fifth aspect of the present disclosure discloses an electronic device, comprising: a processor and a memory; wherein the memory is used to store a computer program; the processor is used to execute the computer program stored in the memory, so that the electronic device executes the application tampering verification method described in any one of the first aspect or the application tampering verification method described in any one of the second aspect.

[0019] A sixth aspect of the present disclosure discloses a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the application tampering verification method described in any one of the first aspect or the application tampering verification method described in any one of the second aspect.

[0020] As described above, the present disclosure provides an application tampering verification method, device, electronic device and medium, which have the following beneficial effects:

[0021] The key is stored in an encrypted SO file and is only decrypted when used, which effectively improves the security of the key and prevents the key from being accessed without authorization.

[0022] Writing the code for obtaining signature information in a pre-stored SO file and dynamically injecting the SO file can prevent criminals from directly modifying the verification result of the signature information, thereby ensuring the security of the signature verification mechanism.

[0023] Because the security of the signature verification mechanism is improved, applications can better protect user data and privacy during network communications and prevent data from being accessed or tampered with without authorization.

[0024] By dynamically injecting SO files, the present invention provides flexible functional extensibility, simplifies the development and maintenance process, and enables the application program to more conveniently add or replace functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 Shown is a schematic diagram of a scene of an electronic device in an embodiment of the present disclosure;

[0026] Figure 2 A flowchart of an application tampering verification method in an embodiment of the present disclosure is shown.

[0027] Figure 3 A schematic diagram showing the process of dynamic anti-tampering verification in an embodiment of the present disclosure.

[0028] Figure 4 A flowchart of an application tampering verification method in another embodiment of the present disclosure is shown.

[0029] Figure 5 A schematic diagram showing the complete processing steps of a specific example of the present disclosure.

[0030] Figure 6 A module diagram showing an application tampering verification device in an embodiment of the present disclosure.

[0031] Figure 7 A module diagram showing an application tampering verification device in another embodiment of the present disclosure.

[0032] Figure 8 A schematic diagram of the circuit structure of an electronic device in an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0033] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0034] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0035] The following embodiments of the present invention provide an application tampering verification method, which can be applied to Figure 1The electronic device shown. The electronic device described in the present invention may include a mobile phone 11 with a wireless charging function, a tablet computer 12, a laptop computer 13, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), etc. The embodiment of the present invention does not impose any restrictions on the specific type of the electronic device.

[0036] For example, the electronic device may be a station (STAION, ST) in a WLAN with a wireless charging function, a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA) device, a handheld device with a wireless charging function, a computing device or other processing device, a computer, a laptop computer, a handheld communication device, a handheld computing device, and / or other devices for communicating on a wireless system and a next generation communication system, such as a mobile terminal in a 5G network, a mobile terminal in a future evolved Public Land Mobile Network (PLMN), or a mobile terminal in a future evolved Non-terrestrial Network (NTN).

[0037] For example, the electronic device can communicate with the network and other devices through wireless communication. The above wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobilecommunication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS can include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), Beidou Satellite Navigation System (BDS), Quasi-Zenith Satellite System (QZSS) and / or Satellite Based Augmentation Systems (SBAS).

[0038] The technical solutions in the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0039] like Figure 2 As shown, a flow chart of an application tampering verification method in an embodiment of the first aspect of the present disclosure is shown, which is applied to a mobile terminal and includes steps S21-S25.

[0040] Step S21: sending a first network request including a channel identifier and the mobile terminal device information to a server, so that the server performs a distribution channel verification on the APK file of the application.

[0041] In some embodiments, step S21 specifically includes: embedding a unique channel identifier during the packaging process of the APK file to identify the distribution channel of the application; obtaining device information of the mobile terminal in response to a startup instruction of the application; and sending a first network request containing the channel identifier and the device information to the server, so that the server performs distribution channel verification on the APK file of the application.

[0042] Specifically, during the application development process, the developer will configure a unique channel identifier (such as channel name, channel ID, etc.), which is associated with the distribution channel of the application. The developer uses tools in the Android SDK, such as keytool, to generate a Keystore and embed the channel identifier into the Keystore. When packaging the APK file, the developer will specify the use of this Keystore to sign the APK, thereby embedding the channel identifier in the APK file. After the user downloads and installs the application, the application will automatically perform an initialization process when it starts. During the initialization process, the application will collect device information of the mobile terminal, such as IMEI number, device model, operating system version, etc. This device information helps the server confirm that the application is distributed from an authorized channel and installed on an authorized device.

[0043] After the application is started, it sends a network request to the server, which contains the collected channel identification and device information. Network requests are usually encrypted using the HTTPS protocol to ensure the security of data transmission. After receiving the request, the server verifies the validity of the channel identification and device information to confirm whether the application is distributed from an authorized channel. If the verification passes, the server considers the application to be legitimate and can proceed to the next steps.

[0044] Step S22: Receive the distribution channel key sent by the server.

[0045] Specifically, after receiving the request, the server retrieves the corresponding key from the key management system based on the information sent. The server verifies the authorization status of the device to ensure that the requesting device has the authority to access the key of the application. If the verification is successful, the server encrypts the key and sends it back to the mobile terminal.

[0046] Step S23: Based on the distribution channel key, obtain the static signature information of the static SO file in the APK file.

[0047] Specifically, in the static SO file, the SHA-1 or SHA-256 information of the signing certificate is stored in a string. This storage method allows the signature information to be accessed directly in the SO file without having to obtain it from an external source each time. Through a get() method, the application can access this signature information. This is similar to an API that allows applications to easily obtain signature information without having to understand the internal storage mechanism.

[0048] To improve security, in some implementations, these static SO files are encrypted using the AES encryption algorithm and then embedded in the lib directory of the APK. The encryption process includes: reading the metadata of the static SO file, finding the signature information fragment to be encrypted, reading and saving the content of the signature information fragment, and then encrypting the content using the AES key configured by the distribution channel, and finally writing the encrypted content back to the SO file. By encrypting the static SO, even if the static SO file is decompiled, the signature information is encrypted, which increases security.

[0049] To decrypt the above-mentioned encrypted static SO file, it is necessary to use the distribution channel key in step S22. The specific decryption process is as follows: when the SO file is loaded, a decryption function will be called, and this function will execute a series of steps to decrypt the SO file. First, the dynamic linker will find the memory address of the SO file, and then read the header information of the static SO file to find the memory loading address and size of the signature information fragment. Next, it will modify the read and write permissions of the memory block where the signature information fragment is located, and then use the distribution channel key obtained from the server to decrypt the encrypted signature information fragment data, and finally obtain the static signature information of the static SO file.

[0050] In the above embodiment, the signature information is protected from being leaked by encrypting the static SO file. Even if the static SO file is illegally copied, its content cannot be deciphered without the key, which helps prevent reverse engineering and malware attacks.

[0051] Furthermore, in some embodiments, when the distribution channel verification fails, that is, when the server detects that the channel identifier of the APK file is illegal or the device information does not match the authorized channel, a verification failure notification will be immediately sent to the mobile terminal. This notification usually contains the specific reason for the failure, such as "unauthorized distribution channel" or "device is not authorized". After receiving the verification failure notification, the mobile terminal will block the operation of the APK file according to the designed security policy. At the same time, in order to enhance the user experience, the terminal may provide detailed error information and solutions to guide users on how to safely download and install applications from official channels. This approach effectively prevents the potential threat of malware and protects the security of users' devices.

[0052] Step S24: Send a second network request containing the static signature information to the server, so that the server performs a static anti-tampering check on the APK file.

[0053] Specifically, the mobile terminal first performs hash processing on the data in the second network request to generate a unique and fixed-length hash value, wherein the hash value is generated by the original data through a hash function and is used to verify the integrity of the data. The mobile terminal encrypts the generated hash value using static signature information (private key) to generate a digital signature. The mobile terminal constructs the second network request together with the encrypted hash value (digital signature) and the original data, and the second network request generally includes information such as the encrypted hash value, the original data, and the application identifier. The mobile terminal sends the constructed second network request to the server, and after receiving the second network request sent by the mobile terminal, the server uses the pre-stored application public key to decrypt the digital signature. Among them, the public key is a key corresponding to the private key, which is used to decrypt the data encrypted by the private key. The public key is generally stored on the server side for use when needed. The server compares the decrypted hash value with the hash value of the original data. If the two hash values ​​match, it indicates that the static signature information is correct, that is, the APK file has not been tampered with. If the two hash values ​​do not match, the static signature information is incorrect, that is, the APK file may have been tampered with.

[0054] Step S25: receiving the static anti-tampering verification result sent by the server, and prohibiting or allowing the application to run based on the static anti-tampering verification result.

[0055] Specifically, when the server completes the static anti-tampering check of the APK file, it will send the check result back to the mobile terminal. This result indicates whether the APK file has passed the integrity check, that is, whether the file has been tampered with by a third party. After receiving the check result, the mobile terminal decides whether to allow the application to run based on the result. If the check result shows that the APK file is complete, that is, it has not been tampered with, the application can be started and run normally; conversely, if the file is found to be tampered with, the application will be prohibited from running. The prohibition may include restricting the startup of the application, stopping the running application, or prohibiting access to certain functions of the application. If the application is prohibited from running, the mobile terminal may display a warning message or prompt to the user. The prompt may include an explanation of the reason why the application failed the static anti-tampering check and possible security risks. The prompt may also provide guidance on re-downloading the application, such as guiding the user to download from a formal channel.

[0056] Furthermore, since some functions of the application do not rely on network communication, an attacker can modify the return value of the verification result, so that the application can still continue to use certain local functions when the network verification fails. In order to avoid the above situation and further improve the security of the application, in some embodiments, after the static anti-tampering verification is successful, a dynamic anti-tampering verification is further included, such as Figure 3 As shown, the dynamic anti-tampering verification includes steps S31 to S33:

[0057] Step S31: Obtain the dynamic signature information of the APK file when it is running.

[0058] Specifically, when the application is running, the mobile terminal will obtain the dynamic signature information of the APK file in real time. The dynamic signature information reflects the real-time status of the application during operation and can be used to verify whether the application has been tampered with during actual operation.

[0059] Furthermore, obtaining dynamic signature information includes: using a custom loader to dynamically load a pre-stored SO file on the server; reading the pre-stored SO file and accessing the method stored in the pre-stored SO file; calling the method in the pre-stored SO file to obtain the dynamic signature information of the APK file when it is running.

[0060] Exemplarily, PackageInfo.signingInfo is used to obtain the signature SHA-1 or SHA-256 of the APK. This method can verify the validity of its signature based on the running context of the APK without accessing the original APK file. PackageInfo.signingInfo is an API provided by the Android platform that allows applications to read the signature information of the APK, including the signer's public key, certificate, and SHA-1 or SHA-256 fingerprint.

[0061] In order to load dynamically generated SO files, you need to use a custom loader, such as DexClassLoader at the Java layer or a custom loader at the Native layer. At the Java layer, you can call DexClassLoader through reflection to load SO files stored in external storage (such as SD card); at the Native layer, you can use dlopen() and dlsym() functions to dynamically load SO files. These functions are provided by the operating system and allow applications to load and link shared libraries at runtime.

[0062] Then, the dynamically pre-stored SO file is read to access the methods and data therein. By calling the methods in the pre-stored SO file, the dynamic signature information of the APK actually running can be obtained.

[0063] Next, to verify the dynamic signature information, there are two verification methods: one is network verification, i.e. step S321; the other is local verification, i.e. step S322. Step S321: Send a third network request containing the dynamic signature information to the server, so that the server performs dynamic anti-tampering verification on the APK file.

[0064] Specifically, the mobile terminal sends the acquired dynamic signature information to the server through a secure network request. This request usually uses the HTTPS protocol to ensure the security of data transmission and prevent the data from being intercepted or tampered with during transmission. After receiving the request containing dynamic signature information, the server will use the corresponding algorithm to verify the data. This process may include comparing with pre-stored legal signature information, or verifying the integrity of the data through a certain algorithm. If the verification result shows that the dynamic signature information of the application is consistent with expectations, it means that the application has not been tampered with; otherwise, it means that the application has been tampered with.

[0065] Step S322: Compare the static signature information with the dynamic signature information to perform dynamic anti-tampering verification on the APK file.

[0066] Specifically, the static signature information is obtained in the above step S32. The static signature information is generated before the APK file is installed, usually in the development stage, and it reflects the initial state of the application. The mobile terminal will obtain the dynamic signature information at an appropriate time, such as when the application is started or at a specific trigger point, and compare it with the pre-stored static signature information. The comparison process involves a complex algorithm to detect whether the two match. If the static and dynamic signature information are consistent, it means that the application has not been tampered with; if they are inconsistent, it may mean that the application has been modified.

[0067] Step S33: If the dynamic anti-tampering check result indicates that the APK file has not been tampered with, the application is allowed to run; if the dynamic anti-tampering check result indicates that the APK file has been tampered with, the application is prohibited from running.

[0068] Specifically, after the dynamic anti-tampering check of the APK file is completed on the server side or locally, the check result will be notified to the mobile terminal. This result indicates whether the APK file has passed the integrity check, that is, whether it has been tampered with by a third party. After the mobile terminal receives the check result, it will decide whether to allow the application to run based on the result. If the check result shows that the APK file is complete, that is, it has not been tampered with, the application can be started and run normally; otherwise, if the file is found to be tampered with, the application will be prohibited from running.

[0069] The dynamic anti-tampering verification in the above embodiment, in conjunction with the dynamic injection of SO files, writes the code for obtaining signature information in the pre-stored SO file, which can not only effectively prevent criminals from directly modifying the verification result of the signature information, but also ensure the security of the signature verification mechanism. This technical implementation improves the overall security of the application and provides developers and users with a more secure and reliable application running environment.

[0070] like Figure 4 As shown, a flow chart of an application tampering verification method in an embodiment of the second aspect of the present disclosure is shown, which is applied to the server side and includes steps S41-S46.

[0071] Step S41: receiving a first network request from a mobile terminal, wherein the first network request includes a channel identifier of an APK file and mobile terminal device information.

[0072] Step S42: Based on the channel identifier and the mobile terminal device information, the distribution channel of the APK file is verified.

[0073] Specifically, when the mobile terminal sends the first network request to the server, this request contains the channel identifier of the APK file and the device information of the mobile terminal. This information is key data for identifying the user's installation source and device type. After receiving the request, the server first parses it and extracts the channel identifier and device information to prepare for the subsequent verification process. Based on the received channel identifier and device information, the server performs distribution channel verification. This step is to confirm the legitimacy of the request and ensure that the application is installed through a legitimate channel. During the verification process, the server will query the database or call a third-party service to verify the validity of the channel identifier and the compliance of the device information.

[0074] Step S43: When the distribution channel verification succeeds, the distribution channel key is sent to the mobile terminal.

[0075] Specifically, if the channel verification is successful, that is, it is confirmed that the request comes from a legal and authorized channel, the server will generate a distribution channel key, which is specifically used to decrypt the static SO file in the APK to ensure the integrity and security of the file. The server will send this key back to the mobile terminal.

[0076] Furthermore, if the distribution channel verification fails, a distribution channel verification failure notification is sent to the mobile terminal. The notification sent by the server usually includes the specific reason for the verification failure, such as invalid channel identification or mismatched device information, which helps developers diagnose problems and take corresponding countermeasures.

[0077] Step S44: receiving a second network request from the mobile terminal, wherein the second network request includes static signature information of a static SO file extracted from the APK file.

[0078] Specifically, after the mobile terminal completes the extraction of the signature information of the static SO file in the APK, it will send this information to the server through a second network request. The request will include necessary request header information and request body data, wherein the request body includes the static signature information of the SO file.

[0079] Step S45: Perform static anti-tampering verification on the APK file based on the static signature information to confirm whether the APK file has been tampered with.

[0080] Specifically, after receiving a request containing static signature information, the server will use the corresponding algorithm to verify this data. This involves comparing the received signature information with the original signature information stored on the server to confirm whether the APK file has been illegally modified. If the static signature information verification is successful, that is, the file has not been tampered with, the server will record this result; if the signature does not match, that is, the file may have been tampered with, the server will also record this result.

[0081] Step S46: Send the static anti-tampering verification result to the mobile terminal.

[0082] Specifically, the server sends the verification result back to the mobile terminal. After receiving the verification result, the mobile terminal can adopt different response strategies according to different results, such as allowing the application to run or prompting the user that the application has risks.

[0083] In some implementations, dynamic anti-tampering verification is also performed. First, the server dynamically injects a pre-stored SO file into the mobile terminal, so that the mobile terminal obtains the dynamic signature information of the APK file during runtime through the pre-stored SO file.

[0084] Then, the server receives a third network request from the mobile terminal, the third network request including dynamic signature information obtained through the pre-stored SO file; wherein the dynamic signature information is used to indicate the status of the APK file in actual operation; based on the dynamic signature information, a dynamic anti-tampering check is performed on the APK file to confirm whether the APK file has been tampered with in actual operation; and the dynamic anti-tampering check result is sent to the mobile terminal.

[0085] Specifically, dynamic signature information is generated during the actual operation of the APK file, and it reflects the actual state of the application during operation. This information is usually generated in real time by the application code running on the mobile terminal and sent to the server through a secure network channel. After receiving the dynamic signature information, the server will verify it using a preset security algorithm. This process involves comparing the dynamic signature information with the original signature information or expected signature information stored by the server to identify whether the running APK file has signs of tampering. The purpose of dynamic anti-tampering verification is to detect whether the APK file maintains integrity during installation, startup and operation, and to ensure that the security of the user's device is not threatened by malware. Once the verification is completed, the server will generate the results of the dynamic anti-tampering verification and send them to the mobile terminal securely through the network. This result is crucial for the mobile terminal because it directly determines whether the application can continue to run safely.

[0086] Based on the verification results, the mobile terminal can take appropriate actions, such as allowing the application to continue running or prompting the user that the application may pose a security risk and recommending appropriate measures.

[0087] In order to better illustrate the technical solution of the present disclosure, a specific example of a mobile application (App) distributed through an official application store is listed below, such as Figure 5 The following figure shows the complete steps of this example.

[0088] Developers use Android Studio to package apps and embed a unique channel identifier during the packaging process to identify the app's distribution channel. After users download and install the app, the app automatically collects device information of the mobile terminal, such as IMEI number, device model, etc., when it starts. The app sends a first network request to the server, including the channel identifier and device information, and the server verifies the distribution channel of the app's APK file. The server verifies whether the app is distributed from an authorized channel and sends the verification result to the app.

[0089] If the distribution channel verification passes, the server sends the distribution channel key to the App. The App uses the distribution channel key to decrypt the static SO file to obtain the static signature information.

[0090] Based on the distribution channel key, the App obtains the static signature information of the static SO file in the APK file. The App sends a second network request to the server, which contains the static signature information, and the server performs a static anti-tampering check on the App's APK file. The server confirms whether the App has been tampered with based on the static signature information and sends the verification result to the App. If the verification passes, the App can continue to run; if the verification fails, the App may be prohibited from running.

[0091] After the static anti-tampering verification is successful, the server loads the pre-stored SO file into the APP through a network request, and the App obtains the dynamic signature information when the APK file is running. The App sends a third network request to the server, which contains the dynamic signature information, and the server performs a dynamic anti-tampering verification on the App's APK file. The server confirms whether the App has been tampered with during actual operation based on the dynamic signature information, and sends the verification result to the App. Alternatively, the App compares the static signature information with the dynamic signature to perform a dynamic anti-tampering verification. If the verification passes, the App can continue to run; if the verification fails, the App may be prohibited from running.

[0092] It should be particularly noted that the process or method represented by the flowchart of the above embodiment of the present disclosure can be understood as representing a module, fragment or part of a code including one or more sets of executable instructions configured to implement the steps of a specific logical function or process. And the scope of the preferred embodiment of the present disclosure includes other implementations, in which the functions may not be performed in the order shown or discussed, including performing the functions in a substantially simultaneous manner or in a reverse order according to the functions involved.

[0093] like Figure 6 As shown, the application tampering verification device 60 of the present disclosure is provided in the mobile terminal. It should be noted that the principle and technical implementation of the application tampering verification device can refer to the application tampering verification method embodiment in the previous embodiment (for example Figure 2 ), so it will not be repeated in this embodiment.

[0094] Specifically, the application tampering verification device 60 includes: a first sending module 61, a first receiving module 62, an acquisition module 63, a second sending module 64, and a first control module 65, wherein:

[0095] The first sending module 61 is used to send a first network request including a channel identifier and the mobile terminal device information to a server, so that the server performs a distribution channel verification on the APK file of the application;

[0096] The acquisition module 63 is used to acquire static signature information of the static SO file in the APK file based on the distribution channel key;

[0097] The second sending module 64 is used to send a second network request including the static signature information to the server, so that the server performs a static anti-tampering check on the APK file;

[0098] The first control module 65 is used to receive the static anti-tampering verification result sent by the server, and prohibit or allow the application program to run based on the static anti-tampering verification result.

[0099] The first receiving module 62 is used to receive the distribution channel key sent by the server;

[0100] like Figure 7 As shown, the application tampering verification device 70 provided on the server side of the present disclosure is shown. It should be noted that the principle and technical implementation of the application tampering verification device can refer to the application tampering verification method embodiment in the previous embodiment (for example Figure 4 ), so it will not be repeated in this embodiment.

[0101] Specifically, the application tampering verification device 70 includes: a second receiving module 71, a distribution channel verification module 72, a third sending module 73, a third receiving module 74, a static anti-tampering verification module 75, and a fourth sending module 76, wherein:

[0102] The second receiving module 71 is used to receive a first network request from a mobile terminal, where the first network request includes a channel identifier of an APK file and mobile terminal device information;

[0103] The distribution channel verification module 72 is used to verify the distribution channel of the APK file based on the channel identifier and the mobile terminal device information;

[0104] The third sending module 73 is used to send the distribution channel key to the mobile terminal when the distribution channel verification succeeds; the third receiving module 74 is used to receive the second network request from the mobile terminal,

[0105] The third receiving module 74 is used to receive a second network request from the mobile terminal, where the second network request includes static signature information of a static SO file obtained from the APK file;

[0106] The static anti-tampering verification module 75 is used to perform a static anti-tampering verification on the APK file based on the static signature information to confirm whether the APK file has been tampered with;

[0107] The fourth sending module 76 is used to send the static verification result to the mobile terminal.

[0108] It should be noted that Figure 6 , Figure 7Each functional module in the embodiment can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a program instruction product. The program instruction product includes one or a group of program instructions. When the program instruction is loaded and executed on a computer, the process or function according to the present disclosure is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable devices. The program instruction can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0109] and, Figure 6 , Figure 7 The device disclosed in the embodiment can be implemented by other module division methods. The device embodiments shown above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as a group of modules or modules can be combined or dynamically added to another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or modules can be electrical or other forms.

[0110] in addition, Figure 6 , Figure 7 Each functional module and submodule in the embodiment can be dynamically in a processing component, or each module can exist physically separately, or two or more modules can be dynamically in one component. The above-mentioned dynamic components can be implemented in the form of hardware or in the form of software functional modules. If the above-mentioned dynamic components are implemented in the form of software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. The storage medium can be a read-only memory, a disk or an optical disk, etc.

[0111] like Figure 8 As shown, a schematic diagram of the structure of an electronic device in an embodiment of the present disclosure is shown.

[0112] The electronic device can execute the following steps by running the computer program instructions: Figure 2 or Figure 4 The method in any one of the items. Exemplarily, the electronic device may be a server group / server, a desktop computer, a laptop computer, etc., or a server / server group in the cloud that communicates remotely with a local terminal, a distributed computing node system, etc.

[0113] The electronic device 80 includes a bus 81, a processor 82, and a memory 83. The processor 82 and the memory 83 can communicate with each other through the bus 81. The memory 83 can store program instructions. The processor 82 implements the method steps in the previous embodiment by running the program instructions in the memory 83, such as Figure 2 , Figure 4 Any method.

[0114] The bus 81 may be a peripheral component interconnect standard bus or an extended industry standard architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, although only one thick line is used in the figure, it does not mean that there is only one bus or one type of bus.

[0115] In some embodiments, the processor 82 may be implemented as a central processing unit (CPU), a microprocessing unit (MCU), a system on chip (System On Chip), or a field programmable logic array (FPGA). The memory 83 may include a volatile memory (Volatile Memory) for temporary storage of data when running a program, such as a random access memory (Random Access Memory, RAM).

[0116] The memory 83 may also include a non-volatile memory for data storage, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid-state disk (SSD).

[0117] In some embodiments, the electronic device 80 may further include a communicator 84. The communicator 84 is used to communicate with the outside. In a specific example, the communicator 84 may include one or a group of wired and / or wireless communication circuit modules. For example, the communicator 84 may include one or more of a wired network card, a USB module, a serial interface module, etc. The wireless communication protocols followed by the wireless communication module include: for example, near field wireless communication (NFC) technology, infrared (IR) technology, global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time division code division multiple access (TD-SCDMA), long term evolution (LTE), Bluetooth (BT), global navigation satellite system (GNSS), etc. One or more.

[0118] In an embodiment of the present disclosure, a computer-readable storage medium may be provided, wherein program instructions are stored, and the program instructions are executed by running, for example Figure 2 or Figure 4 An application tampering verification method in an embodiment.

[0119] That is, the method steps in the above embodiments are implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or are implemented as computer code originally stored in a remote recording medium or a non-temporary machine-readable medium downloaded via a network and to be stored in a local recording medium, so that the method represented herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA).

[0120] In summary, the application tampering verification method, device, equipment and medium disclosed in the present invention stores static signature information in an encrypted static SO file. Even when the static SO file is decompiled, the signature information is encrypted, thereby enhancing the security of the static signature information. In addition, by obtaining the dynamic signature information when the APK file is running, it is possible to verify in real time whether the application has been tampered with during actual operation, thereby improving the real-time performance of the dynamic anti-tampering check. If the static anti-tampering check or the dynamic anti-tampering check fails, the operation of the application can be prohibited, thereby preventing the application from being run without authorization, thereby improving the security and reliability of the application.

[0121] The above embodiments are merely illustrative of the principles and effects of the present disclosure, and are not intended to limit the present disclosure. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present disclosure. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed in the present disclosure shall still be covered by the claims of the present disclosure.

Claims

1. An application tampering verification method, applied to a mobile terminal, characterized in that: include: Sending a first network request including a channel identifier and the mobile terminal device information to a server, so that the server performs a distribution channel verification on an APK file of the application; Receiving a distribution channel key sent by the server; Based on the distribution channel key, obtain static signature information of the static SO file in the APK file; Sending a second network request including the static signature information to the server, so that the server performs a static anti-tampering check on the APK file; Receive the static anti-tampering verification result sent by the server, and prohibit or allow the application program to run based on the static anti-tampering verification result.

2. The application tampering verification method according to claim 1, characterized in that: Also includes: A notification of a distribution channel verification failure is received, prohibiting the application from running.

3. The application tampering verification method according to claim 1, characterized in that: The sending of a first network request including a channel identifier and the mobile terminal device information to a server so that the server performs distribution channel verification on an APK file of an application program includes: Embedding a unique channel identifier in the packaging process of the APK file to identify the distribution channel of the application; In response to a startup instruction of the application, acquiring device information of the mobile terminal; A first network request including the channel identifier and the device information is sent to the server, so that the server performs distribution channel verification on the APK file of the application.

4. The application tampering verification method according to claim 1, characterized in that: The static SO file is in an encrypted state, and the encryption process includes: Read the metadata of the static SO file to determine the signature information fragment contained therein; Performing AES encryption on the signature information fragment; Write the encrypted signature information fragment back into the static SO file.

5. The application tampering verification method according to claim 4, characterized in that: The obtaining, based on the distribution channel key, static signature information of the static SO file in the APK file includes: Based on the memory address of the static SO file, read the header information of the static SO file; Based on the header information, determining the location of the encrypted signature information fragment; The encrypted signature information fragment is decrypted by AES using the distribution channel key to obtain static signature information.

6. The application tampering verification method according to claim 1, characterized in that: After the static anti-tampering verification is successful, a dynamic anti-tampering verification is further included: Obtaining dynamic signature information of the APK file when it is running; Sending a third network request including the dynamic signature information to the server, so that the server performs a dynamic anti-tampering check on the APK file; or comparing the static signature information with the dynamic signature information to perform a dynamic anti-tampering check on the APK file; If the dynamic anti-tampering check result indicates that the APK file has not been tampered with, the application is allowed to run; if the dynamic anti-tampering check result indicates that the APK file has been tampered with, the application is prohibited from running.

7. The application tampering verification method according to claim 6, characterized in that: The step of obtaining the dynamic signature information of the APK file when it is running includes: Use a custom loader to dynamically load SO files pre-existing on the server side; Read a pre-stored SO file and access the method stored in the pre-stored SO file; The method in the pre-stored SO file is called to obtain the dynamic signature information of the APK file when it is running.

8. An application tampering verification method, applied to a server, characterized in that: include: Receiving a first network request from a mobile terminal, wherein the first network request includes a channel identifier of an APK file and mobile terminal device information; Based on the channel identifier and the mobile terminal device information, verify the distribution channel of the APK file; When the distribution channel verification succeeds, sending the distribution channel key to the mobile terminal; Receiving a second network request from the mobile terminal, wherein the second network request includes static signature information of a static SO file extracted from the APK file; Performing static anti-tampering verification on the APK file based on the static signature information to confirm whether the APK file has been tampered with; Sending a static anti-tampering verification result to the mobile terminal.

9. The application tampering verification method according to claim 8, characterized in that: Also includes: When the distribution channel verification fails, a distribution channel verification failure notification is sent to the mobile terminal.

10. The application tampering verification method according to claim 8, characterized in that: include: A pre-stored SO file is dynamically injected into the mobile terminal, so that the mobile terminal obtains the dynamic signature information of the APK file during runtime through the pre-stored SO file.

11. The application tampering verification method according to claim 8, characterized in that: Also includes: Receiving a third network request from the mobile terminal, wherein the third network request includes dynamic signature information of the SO file in the APK file; wherein the dynamic signature information is used to indicate a state of the APK file in actual operation; Performing a dynamic anti-tampering check on the APK file based on the dynamic signature information to confirm whether the APK file has been tampered with during actual operation; Sending a dynamic anti-tampering verification result to the mobile terminal.

12. An application tampering verification device, arranged in a mobile terminal, characterized in that: include: A first sending module, configured to send a first network request including a channel identifier and the mobile terminal device information to a server, so that the server performs a distribution channel verification on an APK file of an application program; A first receiving module, used for receiving a distribution channel key sent by the server; An acquisition module, used for acquiring static signature information of a static SO file in the APK file based on the distribution channel key; A second sending module, used for sending a second network request including the static signature information to the server, so that the server performs a static anti-tampering check on the APK file; The first control module is used to receive the static anti-tampering verification result sent by the server, and prohibit or allow the application program to run based on the static anti-tampering verification result.

13. An application tampering verification device, arranged on a server side, characterized in that: include: A second receiving module is used to receive a first network request from a mobile terminal, where the first network request includes a channel identifier of an APK file and mobile terminal device information; A distribution channel verification module, used to verify the distribution channel of the APK file based on the channel identifier and the mobile terminal device information; A third sending module, configured to send a distribution channel key to the mobile terminal when the distribution channel verification succeeds; A third receiving module is used to receive a second network request from the mobile terminal, where the second network request includes static signature information of a static SO file obtained from the APK file; A static anti-tampering verification module, used to perform a static anti-tampering verification on the APK file based on the static signature information to confirm whether the APK file has been tampered with; The fourth sending module is used to send the static verification result to the mobile terminal.

14. An electronic device, characterized in that: The electronic device comprises: Processor and memory; Wherein, the memory is used to store computer programs; The processor is used to execute the computer program stored in the memory so that the electronic device executes the application tampering verification method described in any one of claims 1 to 7 or the application tampering verification method described in any one of claims 8-11.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by an electronic device, the program implements the application tampering verification method described in any one of claims 1 to 7 or the application tampering verification method described in any one of claims 8 to 11.

Images