Application tampering verification method, device, electronic device and medium

Abstract

The present application provides an application tampering verification method, apparatus, device and medium, the method comprising: 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; obtaining static signature information of a static SO file in the APK file based on the distribution channel key; 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 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. In addition, by dynamically injecting the SO file to obtain 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.

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] Ensuring app security is crucial during Android app development. Android apps are typically stored in the DEX (Dalvik Executable) format, which is relatively easy to decrypt using decompilation tools, rendering the original Java bytecode readable. This is particularly true for app signature verification, which typically relies on private keys used to generate signatures that prove the app's integrity.

[0003] However, storing private keys directly in Java code is unsafe because once the code is decompiled, the private key is exposed to attackers. Attackers can use the private key to forge signatures or modify the signature verification logic to bypass server verification, compromising the security of the application. Furthermore, if an attacker obtains the private key or signature information for a communication, they can tamper with the communication content or forge requests and responses to steal data or perform other malicious activities. Even if an application's signature verification fails, local functions may still be usable because they do not rely on network communication. An attacker can modify the return value of the verification result, allowing the application to continue using certain local functions even if network verification fails. This increases the security risk of the application by allowing 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 attacks and protect user privacy and data security.

[0005] A first aspect of the present disclosure provides an application tampering verification method, which is applied to a mobile terminal, comprising: 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; obtaining static signature information of a static SO file in the APK file based on the distribution channel key; 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 from running based on the static anti-tampering verification result.

[0006] In an embodiment of the first aspect, the method further includes: receiving a notification of a distribution channel verification failure, 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 mobile terminal device information 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 using the distribution channel key to perform AES decryption on the encrypted signature information fragment to obtain static signature information.

[0010] In an embodiment of the first aspect, after the static anti-tampering verification is successful, it further includes dynamic anti-tampering verification: obtaining dynamic signature information of the APK file when it is running; sending 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; or comparing the static signature information with the dynamic signature information to perform 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, obtaining the dynamic signature information of the 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 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 during runtime.

[0012] A second aspect of the present disclosure discloses an application tampering verification method, which is applied to a server side, comprising: 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 further 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 during 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 during 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] In a fourth aspect, the present disclosure discloses an application tampering verification device, which is arranged on a server side and includes: 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; a 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] In a sixth aspect, the present disclosure discloses a computer-readable storage medium having a computer program stored thereon. When the program is executed by an electronic device, 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 is implemented.

[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 it from being accessed by unauthorized persons.

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

[0023] Because the security of the signature verification mechanism has been 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 development and maintenance processes, and enables applications 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 illustrating a method for verifying application program tampering according to an embodiment of the present disclosure is shown.

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

[0028] Figure 4 A flowchart illustrating a method for verifying application program tampering 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 schematic diagram showing a module of an application tampering verification device according to an embodiment of the present disclosure.

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

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

[0033] The following describes the embodiments of the present invention through specific examples. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments. The details in this specification can also be modified or changed 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 unless they conflict.

[0034] It should be noted that the illustrations provided in the following embodiments are merely schematic illustrations of the basic concept of the present invention. Therefore, the illustrations only show components related to the present invention and are not 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 complex.

[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, an in-vehicle 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 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-mentioned wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile communication (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. The GNSS can include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), Beidou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS) and / or Satellite Based Augmentation System (SBAS).

[0038] The technical solutions in the embodiments of the present invention will be described in detail below with reference to 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 app is launched, it sends a network request to the server, containing the collected channel ID and device information. Network requests are typically encrypted using the HTTPS protocol to ensure data security. Upon receiving the request, the server verifies the validity of the channel ID and device information to confirm that the app was distributed from an authorized channel. If the verification passes, the server deems the app legitimate and can proceed with 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 then verifies the device's authorization status to ensure that the requesting device has permission to access the application's key. If 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 a 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 directly accessed in the SO file without having to obtain it from an external source each time. Applications can access this signature information through a get() method. This is similar to an API, allowing applications to easily obtain signature information without having to understand the internal storage mechanism.

[0048] To enhance security, in some implementations, these static SO files are encrypted using the AES algorithm and then embedded in the APK's lib directory. The encryption process involves reading the static SO file's metadata, locating the signature information segment to be encrypted, reading and saving the signature information segment's contents, encrypting the content using the AES key configured by the distribution channel, and finally writing the encrypted content back into the SO file. By encrypting the static SO file, the signature information remains encrypted even if the file is decompiled, enhancing security.

[0049] Decrypting the above-mentioned encrypted static SO file requires 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, which will perform a series of steps to decrypt the SO file. First, the dynamic linker will find the memory address of the SO file, then read the header information of the static SO file, and find the memory loading address and size of the signature information segment. Next, it will modify the read and write permissions of the memory block where the signature information segment is located, and then use the distribution channel key obtained from the server to decrypt the encrypted signature information segment 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 prevent 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 potential threats from 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 static anti-tampering verification on the APK file.

[0053] Specifically, the mobile terminal first hashes the data in the second network request to generate a unique, fixed-length hash value. The hash value is generated by applying a hash function to the original data and is used to verify data integrity. The mobile terminal then encrypts the generated hash value using static signature information (private key) to generate a digital signature. The mobile terminal then combines the encrypted hash value (digital signature) with the original data to construct a second network request, which typically includes the encrypted hash value, original data, and an application identifier. The mobile terminal then sends the constructed second network request to the server. Upon receiving the second network request from the mobile terminal, the server decrypts the digital signature using the pre-stored application public key. The public key is the key corresponding to the private key and is used to decrypt data encrypted with the private key. The public key is typically stored on the server 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, the static signature information is correct, indicating that the APK file has not been tampered with. If the two hash values do not match, the static signature information is incorrect, indicating that 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, after the server completes the static anti-tampering check on 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 verification result, the mobile terminal decides whether to allow the application to run based on the result. If the verification result shows that the APK file is complete, that is, it has not been tampered with, the application can be started and run normally; on the contrary, if the file is found to have been 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 during runtime.

[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 during runtime.

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

[0061] 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 an SD card). At the Native layer, you can use the 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, read the dynamically pre-stored SO file 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.

[0064] 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.

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

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

[0067] Specifically, the static signature information obtained in step S32 above is generated before the APK file is installed, typically during the development phase, and reflects the initial state of the application. The mobile terminal obtains the dynamic signature information at appropriate times, such as when the application is launched or at specific trigger points, and compares it with the pre-stored static signature information. This comparison involves a complex algorithm designed to detect a match between the two. If the static and dynamic signature information match, the application has not been tampered with; if they do not match, it may mean that the application has been modified.

[0068] 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.

[0069] Specifically, after the dynamic anti-tampering verification of the APK file is completed on the server or locally, the verification result is 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 receiving the verification result, the mobile terminal will decide whether to allow the application to run based on the result. If the verification result indicates that the APK file is intact, that is, has not been tampered with, the application can be launched and run normally; otherwise, if the file is found to have been tampered with, the application will be prohibited from running.

[0070] The dynamic anti-tampering verification in the above embodiment, combined with the dynamic injection of SO files, writes the signature information acquisition code into a pre-stored SO file. This not only effectively prevents criminals from directly modifying the signature verification results, but also ensures 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 runtime environment.

[0071] 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.

[0072] Step S41: receiving 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.

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

[0074] 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.

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

[0076] 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. This key 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.

[0077] 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 the problem and take appropriate countermeasures.

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

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

[0080] Step S45: 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.

[0081] Specifically, after receiving a request containing static signature information, the server uses a 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, meaning that the file has not been tampered with, the server will record this result; if a signature mismatch is found, meaning that the file may have been tampered with, the server will also record this result.

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

[0083] 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 the result, such as allowing the application to run or prompting the user that the application has risks.

[0084] In some implementations, dynamic anti-tampering verification is also included. 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.

[0085] 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 during actual operation; based on the dynamic signature information, the server performs dynamic anti-tampering verification on the APK file to confirm whether the APK file has been tampered with during actual operation; and sends the dynamic anti-tampering verification result to the mobile terminal.

[0086] Specifically, dynamic signature information is generated during the actual operation of the APK file, and it reflects the actual state of the application during runtime. 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 on the server to identify whether the running APK file has shown any signs of tampering. The purpose of dynamic anti-tampering verification is to detect whether the APK file maintains its integrity during installation, startup, and operation, ensuring 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 securely send them to the mobile terminal through the network. This result is crucial for the mobile terminal because it directly determines whether the application can continue to run safely.

[0087] 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.

[0088] In order to better illustrate the technical solution of the present disclosure, a specific example of a mobile application (App) distributed through an official app store is given below, such as Figure 5 As shown, the complete steps of this example are shown.

[0089] Developers use Android Studio to package their apps and embed a unique channel identifier during the packaging process to identify the app's distribution channel. After a user downloads and installs the app, the app automatically collects device information from the mobile terminal, such as the IMEI number and device model, upon startup. The app sends a first network request to the server, including the channel identifier and device information. The server then verifies the distribution channel of the app's APK file. The server verifies that the app is distributed from an authorized channel and sends the verification result to the app.

[0090] 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.

[0091] Based on the distribution channel key, the app obtains the static signature information for the static SO file in the APK file. The app sends a second network request to the server, containing the static signature information. The server then performs a static anti-tampering check on the app's APK file. The server verifies 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.

[0092] 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 of the APK file during operation. The App sends a third network request to the server, which contains the dynamic signature information, and the server performs 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 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.

[0093] It should be noted that the processes or methods represented by the flowcharts of the above embodiments of the present disclosure can be understood as modules, segments, or portions of code that include one or more sets of executable instructions configured to implement specific logical functions or steps of a process. Furthermore, the scope of the preferred embodiments of the present disclosure includes alternative implementations in which functions may be performed in a different order than that shown or discussed, including performing functions substantially simultaneously or in reverse order depending on the functions involved.

[0094] like Figure 6 As shown in the figure, the application tampering verification device 60 provided in the mobile terminal 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 2 ), so it will not be repeated in this embodiment.

[0095] 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:

[0096] The first sending module 61 is 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 the APK file of the application;

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

[0098] The second sending module 64 is configured 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;

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

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

[0101] like Figure 7 As shown in the figure, 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.

[0102] 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:

[0103] The second receiving module 71 is configured 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;

[0104] 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;

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

[0106] The third receiving module 74 is configured 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;

[0107] 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;

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

[0109] It should be noted that Figure 6 、 Figure 7The various functional modules in the embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, they 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 instructions are 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 device. The program instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another computer-readable storage medium.

[0110] and, Figure 6 、 Figure 7 The devices disclosed in the embodiments can be implemented using other module division methods. The device embodiments shown above are merely illustrative. For example, the module division is merely a logical functional division. In actual implementation, other division methods may be used, such as a group of modules or modules that can be combined or dynamically integrated into another system, or some features that can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between devices or modules shown or discussed can be through some interface, and the indirect coupling or communication connection between devices or modules can be electrical or other forms.

[0111] in addition, Figure 6 、 Figure 7 Each functional module and submodule in the embodiments may be dynamically integrated into a single processing component, each module may exist physically independently, or two or more modules may be dynamically integrated into a single component. The aforementioned dynamic components may be implemented in hardware or as software functional modules. If the aforementioned dynamic components are implemented as software functional modules and sold or used as independent products, they may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic disk, or an optical disk, etc.

[0112] like Figure 8 , which shows a structural diagram of an electronic device in an embodiment of the present disclosure.

[0113] The electronic device can execute the computer program instructions to perform the following 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 cloud server / server group, a distributed computing node system, etc. that remotely communicates with a local terminal.

[0114] 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 via the bus 81. The memory 83 can store program instructions. The processor 82 executes the program instructions in the memory 83 to implement the method steps in the previous embodiment, such as Figure 2 、 Figure 4 Any method.

[0115] Bus 81 may be a Peripheral Component Interconnect bus or an Extended Industry Standard Architecture (EISA) bus. Buses can be classified as address buses, data buses, control buses, etc. For ease of illustration, although only one thick line is used in the figure, this does not mean that there is only one bus or only one type of bus.

[0116] In some embodiments, the processor 82 may be implemented as a central processing unit (CPU), a microprocessor unit (MCU), a system on a chip (SoC), or a field programmable gate array (FPGA). The memory 83 may include volatile memory, such as random access memory (RAM), for temporarily storing data while running programs.

[0117] The memory 83 may also include a non-volatile memory (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).

[0118] 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 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 of the following.

[0119] 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.

[0120] 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-transitory 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).

[0121] 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.

[0122] The above embodiments are merely illustrative of the principles and effects of this disclosure and are not intended to limit this disclosure. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of this disclosure. Therefore, all equivalent modifications or alterations made by one of ordinary skill in the art without departing from the spirit and technical concepts disclosed herein shall be covered by the claims of this 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 the 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; receiving a static anti-tampering verification result sent by the server, and prohibiting or allowing the application program from running based on the static anti-tampering verification result; 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 to the static SO file; After the static anti-tampering verification is successful, the dynamic anti-tampering verification is further included: Obtain the dynamic signature information of the APK file during runtime; 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.

2. The application tampering verification method according to claim 1, wherein: Also includes: Receive a notification of a distribution channel verification failure, and prohibit the application from running.

3. The application tampering verification method according to claim 1, wherein: 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 the APK file of the application program includes: Embed a unique channel identifier during 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, wherein: The obtaining of static signature information of the static SO file in the APK file based on the distribution channel key includes: Reading 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; The encrypted signature information fragment is decrypted by AES using the distribution channel key to obtain static signature information.

5. The application tampering verification method according to claim 1, wherein: The method of obtaining the dynamic signature information of the APK file at runtime includes: Use a custom loader to dynamically load SO files pre-existing on the server; Read a pre-stored SO file and access the method stored in the pre-stored SO file; Call the method in the pre-stored SO file to obtain the dynamic signature information of the APK file during runtime.

6. An application tampering verification method, applied to the server side, 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; Performing 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 the distribution channel key to the mobile terminal; receiving a second network request from the mobile terminal, where 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; 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 a 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 during actual operation; Sending a dynamic anti-tampering verification result to the mobile terminal.

7. The application tampering verification method according to claim 6, wherein: Also includes: When the distribution channel verification fails, a distribution channel verification failure notification is sent to the mobile terminal.

8. The application tampering verification method according to claim 6, wherein: 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.

9. An application tampering verification device, provided in a mobile terminal, characterized in that: include: A first sending module is 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 the APK file of the application; A first receiving module, configured to receive a distribution channel key sent by the server; An acquisition module, configured to acquire static signature information of a static SO file in the APK file based on the distribution channel key; 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; A second sending module is configured 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; a first control module, configured to receive a static anti-tampering verification result sent by the server, and prohibit or allow the application program from running based on the static anti-tampering verification result; After the static anti-tampering verification is successful, the following steps are further performed: The second sending module is further configured to obtain dynamic signature information of the APK file when it is running; 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; or compare the static signature information with the dynamic signature information to perform dynamic anti-tampering verification on the APK file; The first control module is further configured to control the application to be allowed to run if the dynamic anti-tampering check result indicates that the APK file has not been tampered with; and to prohibit the application from running if the dynamic anti-tampering check result indicates that the APK file has been tampered with.

10. An application tampering verification device, provided on a server side, characterized in that: include: A second receiving module is configured to receive a first network request from a mobile terminal, where the first network request includes a channel identifier of the APK file and mobile terminal device information; A distribution channel verification module, configured to verify the distribution channel of the APK file based on the channel identifier and the mobile terminal device information; A third sending module is used to send a distribution channel key to the mobile terminal when the distribution channel verification is successful; A third receiving module is configured 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, configured 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; A fourth sending module, configured to send a static verification result to the mobile terminal; The third receiving module is further configured to receive 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 a status of the APK file in actual operation; The static anti-tampering verification module is further used to perform dynamic anti-tampering verification on the APK file based on the dynamic signature information to confirm whether the APK file has been tampered with during actual operation; The fourth sending module is further configured to send a dynamic anti-tampering verification result to the mobile terminal.

11. 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 configured to execute the computer program stored in the memory, so that the electronic device executes the application tampering verification method according to any one of claims 1 to 5 or the application tampering verification method according to any one of claims 6 to 8.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by an electronic device, the application program tampering verification method according to any one of claims 1 to 5 or the application program tampering verification method according to any one of claims 6 to 8 is implemented.

Images