Application security detection method and device, terminal, storage medium and program product

Abstract

The application provides an application security detection method and device, a terminal, a storage medium and a program product. It belongs to the technical field of application security. The method comprises the following steps: in the case of triggering the identification operation of the application hot updating behavior, performing file checking on the first code file of the application to obtain a file checking result, the first code file being an application code file associated with the application hot updating behavior, the file checking being used to check whether the first code file has changed; in the case that the file checking result indicates that the first code file has changed, determining that the application has the application hot updating behavior; and in the case that it is determined that the application has the application hot updating behavior, performing application security detection on the application. The method can timely perform application security detection on the application during application hot updating, thereby improving the security of application running.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of application security technology, and more particularly, to an application security detection method and device in the field of application running, a terminal, a storage medium and a program product. BACKGROUND

[0002] When an application (APP) fails or needs to update the application code resource of the APP, the developer of the APP often uses an application hot update method to update. In the application hot update method, the application does not need to download and install a package again, and a patch package can be directly issued, and the APP can directly add, replace or modify the patch package during the running process.

[0003] Currently, the main application security detection strategy is that the security detection service of a terminal performs security detection on the installation package of an application during application download and installation, or a user actively triggers the application security detection service to perform security detection on the application, or the security detection service automatically performs security detection on the application every preset time period.

[0004] Obviously, the application hot update behavior is not within the scope of the current application security detection strategy, and the security of the application after the application hot update cannot be guaranteed. SUMMARY

[0005] The present application provides an application security detection method, device, terminal, storage medium and program product, which can perform application security detection on an application in time when the application is hot updated, and improve the security of application running.

[0006] In one aspect, an application security detection method is provided, and the method comprises:

[0007] In a case where an identification operation of an application hot update behavior is triggered, performing file verification on a first code file of the application to obtain a file verification result, the first code file being an application code file associated with the application hot update behavior, and the file verification being used to verify whether the first code file has changed;

[0008] In a case where the file verification result indicates that the first code file has changed, determining that the application has the application hot update behavior;

[0009] In a case where it is determined that the application has the application hot update behavior, performing application security detection on the application.

[0010] In one aspect, an application security detection device is provided, and the device comprises:

[0011] The file checking module is configured to, in response to triggering the identification operation of the application hot update behavior, perform file checking on a first code file of the application to obtain a file checking result, the first code file being an application code file associated with the application hot update behavior, and the file checking being configured to check whether the first code file has been changed;

[0012] The determining module is configured to, in response to the file checking result indicating that the first code file has been changed, determine that the application has the application hot update behavior.

[0013] The security detection module is configured to, in response to determining that the application has the application hot update behavior, perform application security detection on the application.

[0014] In one aspect, a terminal is provided, and the terminal includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to cause the terminal to perform the application security detection method in any one of the above aspects.

[0015] In one aspect, a computer-readable storage medium is provided, and the computer-readable storage medium stores instructions, when the instructions are run on a computer or a processor, the computer or the processor performs the application security detection method in any one of the above aspects.

[0016] In one aspect, a computer program product is provided, and the computer program product or the computer program includes program code stored in a computer-readable storage medium, and a processor of a terminal reads the program code from the computer-readable storage medium, and the processor executes the program code to cause the terminal to perform the application security detection method in any one of the above aspects.

[0017] The technical solution provided by the embodiments of the present application can bring the following beneficial effects:

[0018] The present application provides an application security detection method: in response to triggering the identification operation of the application hot update behavior, the first code file related to the application hot update behavior in the application can be checked, and in response to the file checking result indicating that the first code file has been changed, it is determined that the application hot update behavior is detected, and the application hot update is performed on the application. The application security detection of the application after the automatic triggering of the application hot update behavior is provided, and the application hot update behavior is included in the automatic triggering of the application security detection. The application security detection of the application after the application hot update behavior is performed is performed in time, and the application security of the application running process is ensured. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0020] Figure 1 is a schematic flowchart of an application security detection method provided by an embodiment of the present application;

[0021] Figure 2 is a schematic flowchart of another application security detection method provided by an embodiment of the present application;

[0022] Figure 3 is a schematic flowchart of another application security detection method provided by an embodiment of the present application;

[0023] Figure 4 is a schematic flowchart of another application security detection method provided by an embodiment of the present application;

[0024] Figure 5 is a structural schematic diagram of an application security detection device provided by an embodiment of the present application;

[0025] Figure 6 is a structural schematic diagram of a terminal provided by an embodiment of the present application. DETAILED DESCRIPTION

[0026] The technical solutions in the present application will be described in detail below with reference to the drawings. In the description of the embodiments of the present application, "multiple" means two or more than two. The terms "first" and "second" are only for the purpose of description, and cannot be understood as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features.

[0027] When the APP fails or needs to update the application code resource of the APP, the developer of the APP often uses the application hot update method for updating. In the application hot update method, the application does not need to be re-downloaded and installed, and the application patch package can be directly issued, and the APP can directly add, replace or modify the patch package during the running process.

[0028] The existing application hot update and detection process of the Android terminal is as follows:

[0029] I. Application hot update

[0030] 1) An app (denoted as APP) on the Android terminal starts running and loads and executes the corresponding dex file (denoted as dex1).

[0031] 2) The APP remotely connects to its backend server and detects in real time whether there is a new patch dex file.

[0032] 3) When a new patch file (denoted as dex2) is detected, the APP downloads dex2 and performs the application hot update process.

[0033] During the application hot update process, the APP merges the dex1 file and the dex2 file according to the specific hot update method to obtain a new dex3 file; or, the APP directly saves the dex2 file. At this time, the dex1 file and the dex2 file are saved in the APP sandbox directory at the same time.

[0034] 2. Security software execution detection

[0035] 1) When triggered by the user, by predefined key sensitive application behaviors (such as payment), or according to predefined detection policies (periodically or when the device is idle), the security software (denoted as sec_manager) performs security checks on the application software code and its application behaviors on the terminal.

[0036] The above application hot update and security software detection process shows that app hot update behavior is not included in the indicators that trigger security software detection. Some malicious applications can use application hot update behavior to download malicious application code and run it, thereby endangering terminal data security.

[0037] To address the above issues, this application provides an application security detection method that can identify application hot update behavior and, when it is determined that an application has application hot update behavior, promptly trigger application security detection on the application to ensure the security of application operation.

[0038] Figure 1 This is a schematic flow chart of an application security detection method provided in an embodiment of the present application. This embodiment of the present application takes the application of the method to a terminal as an example for explanation.

[0039] like Figure 1 As shown, the method 100 includes:

[0040] Step 101, when triggering the identification operation of the application hot update behavior, perform file verification on the first code file of the application to obtain a file verification result. The first code file is the application code file associated with the application hot update behavior, and the file verification is used to verify whether the first code file has changed.

[0041] Since application hot update behavior does not require re-downloading and installing the application, it only requires downloading a patch package to modify, add or replace the application's dex file, etc., so the general application hot update behavior is often completed without the user's perception. In order to be able to perceive the application hot update behavior in a timely manner, and thus perform application security detection on it in a timely manner. The embodiment of the present application provides a method for performing file verification on the application code file to detect whether the application has application hot update behavior. In one possible implementation, when the identification operation of the application hot update behavior is triggered, the terminal can obtain the first code file associated with the application hot update behavior in the application, and perform file verification on the first code file to verify whether the first code file has changed.

[0042] Among them, the triggering scenario of the identification operation of the application hot update behavior: it can be that when the terminal detects the existence of a key behavior, it automatically triggers the identification operation of the application hot update behavior. The key behavior can be a behavior related to the application hot update behavior, such as detecting a write operation to a dex suffix file, or restarting an activity operation during the application operation, or restarting the entire application operation during the application operation. Optionally, the terminal can also detect a triggering operation on a target application programming interface (Application Programming Interface, API) and automatically trigger the identification operation of the application hot update behavior. The target API is an API that may be called during the application hot update behavior, such as an API that needs to be called when writing a dex file. Optionally, the application security detection can also be automatically triggered at predetermined intervals.

[0043] Step 102: When the file verification result indicates that the first code file has been changed, it is determined that the application has an application hot update behavior.

[0044] Since application hot updates generally involve modifications to the dex suffix file, detecting whether the dex suffix file has changed can be used to further detect whether an application hot update has occurred. Therefore, in one possible implementation, when the terminal determines that the file verification result indicates that the first code file has changed, it can be determined that the application may have undergone an application hot update.

[0045] Step 103: If it is determined that the application has the application hot update behavior, perform application security detection on the application.

[0046] In order to promptly perform security checks on applications after hot updates to prevent threats to terminal data from malicious code, in one possible implementation, when the terminal determines that an application has been hot updated, it immediately performs application security checks on the application.

[0047] Optionally, when performing application security testing on an application, security testing may be performed on the changed dex suffix file, or on all code files of the application.

[0048] Optionally, a security detection policy corresponding to the application security detection can be pre-configured in the terminal, and the application security detection can be performed on the application using the security detection policy. Optionally, the security detection policy can be updated regularly.

[0049] Optionally, after performing an application security check on the application, the terminal may display a notification message, which may inform the user of the application hot update behavior and the application security check result, so that the user can subsequently promptly learn that the application has been hot updated.

[0050] In summary, the present application provides an application security detection method: when triggering the identification operation of application hot update behavior, a file verification can be performed on the first code file in the application related to the application hot update behavior, and when the file verification result indicates that there is a change in the first code file, it is determined that the application hot update behavior has been detected, and the application hot update is performed on the application. This provides a feasible method for automatically triggering the application hot update behavior to perform application security detection, and can include the application hot update behavior in the scope of automatically triggering application security detection, and promptly perform application security detection on the application after the application hot update behavior is executed, thereby ensuring the application security of the application operation process.

[0051] Due to differences in application hot update methods, for example, after downloading a new dex2 file, it may be merged with the dex1 file to generate a dex3 file, or the dex2 file may be saved directly. Therefore, when verifying code files with the dex suffix, it is necessary to verify both the file hash value and the file count to determine whether the code files have changed.

[0052] Figure 2 This is a schematic flow chart of another application security detection method provided in an embodiment of the present application. This embodiment of the present application takes the application of this method to a terminal as an example for explanation.

[0053] For example, Figure 2 As shown, the method 200 includes:

[0054] Step 201 : When an identification operation of an application hot update behavior is triggered, a file hash value corresponding to a first code file and a file quantity corresponding to the first code file are obtained.

[0055] In order to improve the accuracy of file verification, in one possible implementation, when the terminal triggers an identification operation for an application hot update behavior, a file verification is performed on the first code file of the application to obtain a file verification result. The first code file is an application code file associated with the application hot update behavior. The file verification is used to verify whether the first code file has changed. The file hash value corresponding to the first code file and the file number of the first code file can be obtained, so that the first code file can be subsequently verified from two dimensions: the file hash value and the file number.

[0056] Regarding the method for obtaining a file hash value: a hash operation can be performed on the file content of the first code file to output a file hash value corresponding to the first code file. Optionally, the first code file may include one or more code files. In order to determine whether each first code file has been changed, it is necessary to generate a corresponding file hash value based on the file content of each first code file.

[0057] Exemplarily, if the first code file includes a dex1 file, a dex2 file, and a dex3 file, the generated file hash values ​​include: a hash value 1 corresponding to the dex1 file, a hash value 2 corresponding to the dex2 file, and a hash value 3 corresponding to the dex3 file.

[0058] Step 202: Perform file verification on the first code file based on the file hash value and the file quantity.

[0059] Furthermore, after the terminal obtains the file hash value and the file number of the first code file, it can determine whether the first code file has been changed based on the file hash value and the file number in the historical records.

[0060] Optionally, step 202 may further include steps 202A to 202C.

[0061] Step 202A: Obtain a historical hash value corresponding to the first code file and a historical number corresponding to the first code file. The historical hash value and the historical number are the file hash value and the file number recorded during the last application security detection process for the application.

[0062] In order to verify whether the first code file has been changed, it is necessary to compare the current first code file with the first code file recorded during the previous security check to see if they are consistent. Therefore, in one possible implementation, the terminal also obtains the file hash value and file quantity recorded during the previous application security check on the application, that is, obtains the historical hash value corresponding to the first code file and the historical quantity corresponding to the first code file, and compares them with the currently obtained file hash value and file quantity to determine whether the first code file has been changed.

[0063] Optionally, in addition to performing application security detection on the application when detecting that the application has application hot update behavior, the terminal can also detect and record the file hash value and file number of the dex files of all applications on the terminal at predetermined intervals, so that it can subsequently verify whether the first code file has changed based on the recorded file hash value and file number.

[0064] Step 202B: If the historical hash value matches the file hash value and the file quantity matches the historical quantity, it is determined that the first code file has not been changed.

[0065] If the application has not been hot-updated, the application's dex suffix file will not change, and the corresponding file hash value and file quantity will not change. Therefore, in one possible implementation, when the terminal determines that the historical hash value of the first code file matches the file hash value, and the file quantity matches the historical quantity, it is determined that the first code file of the application has not been changed.

[0066] Step 202C: If the historical hash value does not match the file hash value, and / or the historical quantity does not match the file quantity, it is determined that the first code file has been changed.

[0067] Conversely, if the application undergoes a hot update, the application's dex suffix file will change, and the corresponding file hash value or file quantity may also change. In a corresponding possible implementation, when the terminal determines that the historical hash value of the first code file does not match the file hash value, or the number of files of the first code file does not match the historical number, or the historical hash value of the first code file does not match the file hash value, and the number of files of the first code file does not match the historical number, it is determined that the first code file has changed.

[0068] For example, if the first code file of the application contains 3 dex files (the number of files is 3): dex1 file, dex2 file, and dex3 file, the generated file hash values ​​include: the file hash value corresponding to the dex1 file: fae0, the file hash value corresponding to the dex2 file: b27c, and the file hash value corresponding to the dex3 file: 451c; and the number of files recorded in the last application security detection process of the application is also 3 (the historical number is 3), and the file hash values ​​include: the file hash value corresponding to the dex1 file: 7e8c, the file hash value corresponding to the dex2 file: b27c, and the file hash value corresponding to the dex3 file: 4e53; among them, the number of files of the first code file has not changed, but the file hash values ​​of the dex1 file and the dex3 file have changed, and it is determined that the first code file has changed.

[0069] Step 203: If the file verification result indicates that the first code file has been changed and there is an identification behavior, it is determined that the application has an application hot update behavior, and the identification behavior is an application behavior involved in the process of executing the application hot update behavior.

[0070] Since the change to the first code file may also be caused by the application being re-downloaded and installed, and the application installation package of the application is automatically subjected to application security checks during re-download and installation, in order to avoid misidentification of application hot update behavior and repeated application security checks on the application, in one possible implementation, after the terminal determines that the file verification result indicates that the first code file has changed, it is necessary to further determine whether there is an application behavior (identification behavior) involved in the process of executing the application hot update behavior. If the application has an identification behavior, it is determined that the application has an application hot update behavior.

[0071] Step 204 : When it is determined that the application has an application hot update behavior, a second code file of the application after the application hot update behavior is executed is obtained, where the second code file is all code files of the application.

[0072] When performing application security testing on an application after a hot update, security testing needs to be conducted from two aspects: first, detecting whether the updated application code contains malicious or abnormal code; and second, detecting whether the updated application performs certain malicious behaviors during operation. Accordingly, in one possible implementation, if it is determined that an application has been hot updated, the terminal can first obtain all code files (second code files) of the application after the hot update has been executed, and perform code anomaly verification or code malicious verification on the second code files.

[0073] Since the hot update process of an application may also affect code files other than those with the dex suffix, in order to perform a more comprehensive cloud application security check on the application, the terminal needs to obtain all code files of the updated application (for example, those with the dex, jar, so, etc. suffixes), and then perform local security checks on all code files to determine whether there is malicious code in the updated application code.

[0074] Step 205: Perform code anomaly verification on the second code file to obtain a code verification result. The code anomaly verification is used to verify whether there is an abnormal code in the application code of the application.

[0075] After obtaining all the code files (second code files) after the application hot update, the terminal can perform code anomaly verification on the second code file to verify whether there is abnormal code in the application code of the application. The abnormal code in application security detection mainly refers to malicious code, that is, application code that will threaten the terminal data security, in order to obtain the code verification result.

[0076] Optionally, when performing code anomaly verification on the second code file, a code static analysis function, malicious code characteristic values, etc. can be used to perform code anomaly verification on the second code file. Optionally, the terminal can also periodically pull updated code anomaly verification strategies from the cloud or server to improve the accuracy of identifying malicious or abnormal code.

[0077] Step 206 : When the code verification result indicates that there is no abnormal code in the second code file, obtain a second application behavior within a target time period after the application hot update behavior is executed.

[0078] Some application code may not be detectably malicious, but during application operation, the application code can be executed, causing the application to perform certain malicious behaviors, such as automatically accessing user album data without user intervention. To further improve the operational security of the application, one possible implementation is to obtain a second application behavior within a target time period after the application hot update behavior is executed, and perform a behavior verification on the second application behavior to determine whether there is any malicious application behavior that threatens the terminal data security after the application hot update.

[0079] The target time period can be configured by the detection policy of the application security detection. For example, the target time period can be within a day, or within a week, or the target time period can be N days of application behavior randomly selected within a month. This embodiment does not constitute a limitation to this.

[0080] Optionally, when obtaining the second application behavior, you can also select the second application behavior under a pre-configured behavior category based on the behavior category. For example, if the behavior category is payment-related, you can obtain the second application behavior related to the payment service call behavior; if the behavior category is positioning-related, you can obtain the second application behavior related to the positioning service call behavior, so as to achieve the purpose of targeted behavior verification of the second application behavior.

[0081] Optionally, if the code verification result indicates that there is abnormal code in the second code file, the terminal can immediately remind the user that the application has a security risk, and there is no need to perform subsequent behavioral verification of the application behavior to avoid threats to terminal data during application operation.

[0082] Step 207: Perform behavior verification on the second application behavior to obtain a behavior verification result. The behavior verification is used to verify whether there is abnormal behavior during the application operation after the application hot update behavior is executed.

[0083] After the second application behavior of the application in the target time period is acquired, the second application behavior can be behaviorally verified to verify whether abnormal behavior or malicious behavior exists in the application running process after the application hot update.

[0084] In this embodiment, the file hash value and the file quantity of the first code file are acquired to determine whether the first code file is changed from two dimensions, so as to improve the accuracy of the first code file change determination. Moreover, after it is determined that the first code file is changed, whether the application has an identification behavior related to the application hot update behavior can be acquired to comprehensively determine whether the application has the application hot update behavior, so as to avoid the influence of the application installation behavior of other changeable first code files on the determination accuracy and improve the accuracy of identifying the application hot update behavior. In addition, when the application security detection is performed on the application, not only the code maliciousness detection can be performed on the application from the static code level, but also the application behavior maliciousness detection can be performed on the application from the dynamic application behavior level, so that the application security is detected from multiple angles and multiple levels, and the security of the application running is further improved.

[0085] In order to timely trigger the application security detection, the identification operation of the application hot update behavior needs to be timely triggered. The developer analyzes the mainstream application hot update mode, extracts the key behavior in the application hot update process, and buries the API related to the key behavior, so that the application hot update behavior can be identified in time when the API with the buried point is called subsequently.

[0086] Figure 3 FIG. 3 is a schematic flowchart of another application security detection method provided by an embodiment of the present application. The embodiment of the present application takes the method applied to a terminal as an example for description.

[0087] For example, as shown in FIG. 3, the method 300 includes the following steps. Figure 3

[0088] Step 301, in response to a calling operation on a target interface, an identification operation of an application hot update behavior is triggered, and the target interface is an interface related to the application hot update behavior.

[0089] The target interface is an API interface related to the application hot update behavior. The key behavior in the application hot update process is extracted in advance, and the API related to the key behavior is determined as the target interface. Then, the API is buried through the hook operation, so that the terminal can determine that the calling operation on the target interface is received and trigger the identification operation of the application hot update behavior when the API with the buried point is called subsequently.

[0090] ​For example, if the terminal's security software performs application security detection on the application, the terminal may trigger the security software after receiving a call operation to the target interface, and the security software may determine whether there is an application hot update behavior.

[0091] For example, the terminal can use the writing operation of the dex suffix file, or the restart of the activity during the application running, the restart of the entire application and the simultaneous change of the dex file as the hot update identification behavior, and track the relevant API for subsequent triggering of security software.

[0092] Step 302: When the identification operation of the application hot update behavior is triggered, obtain the first application behavior indicated by the calling operation.

[0093] Since it is necessary to subsequently comprehensively determine whether the application hot update behavior is recognized based on whether the identification behavior exists and whether the first code file has been changed, in one possible implementation, after triggering the identification operation of the application hot update behavior, the terminal will also obtain the first application behavior executed by triggering the API with the embedded point, that is, obtain the first application behavior referred to by the call operation, to further determine whether the first application behavior is the identification behavior.

[0094] Step 303: When the identification operation of the application hot update behavior is triggered, a file verification is performed on the first code file of the application to obtain a file verification result.

[0095] The implementation of step 303 can refer to the above embodiment, and will not be described in detail in this embodiment.

[0096] Step 304: If the file verification result indicates that the first code file has been changed and the first application behavior contains an identification behavior, it is determined that the application has an application hot update behavior.

[0097] Furthermore, when the terminal obtains the first application behavior indicated by the calling operation, it compares it with the pre-configured identification behavior. If the identification behavior exists in the first application behavior and the file verification result indicates that the first code file has changed, it is determined that the application may have application hot update behavior, and application security detection needs to be performed on the application.

[0098] Optionally, if the first code file has not changed, but the API with the embedded point is called (that is, the target interface is called), it means that the terminal may have application hot update behavior, or may not have application hot update behavior. In order to further improve the accuracy of judging application hot update behavior, in one possible implementation, the terminal can record the first application behavior, and upload information such as the first application behavior and all code files of the application (second code file) to the cloud, which will analyze and determine whether there is application hot update behavior. If there is application hot update behavior, the feedback result will be sent to the terminal. When the terminal receives the judgment result fed back by the cloud, and the judgment result indicates that there is application hot update behavior, it is also necessary to perform application security detection on the application.

[0099] Optionally, before uploading the first application behavior and all code files to the cloud, user consent is required, a corresponding prompt window is displayed, and with user consent, the information is uploaded to the cloud to further ensure the security of terminal data.

[0100] Optionally, an application hot update detection strategy can be deployed locally on the terminal. If the file verification result indicates that the first code file has not been changed, but the target API has been called, the entire application code file (the second code file) can be obtained and, based on the second code file and the first application behavior, analyzed to determine whether the application has experienced an application hot update. After determining that the application has experienced an application hot update, an application security check is performed on the application.

[0101] Step 305: If it is determined that the application has the application hot update behavior, perform application security detection on the application.

[0102] The implementation of step 305 can refer to the above embodiment, and will not be described in detail in this embodiment.

[0103] In this embodiment, by monitoring the call status of the target interface with the embedded point to determine whether to trigger the identification operation of the application hot update behavior, the triggering operation of the application hot update behavior can be triggered in time, and then the application hot update behavior can be identified in time, thereby improving the timeliness of application security detection in the application hot update scenario.

[0104] Figure 4 This is a schematic flowchart of another application security detection method provided in an embodiment of the present application.

[0105] The method includes:

[0106] Step 401: Whether to trigger the API with tracking points.

[0107] The API with a tracking point is an API related to the application hot update behavior. The terminal determines whether to trigger the recognition operation of the application hot update behavior by detecting whether the API with a tracking point is called. If the API with a tracking point is triggered, step 402 can be executed.

[0108] Step 402: Obtain software behavior based on the triggered API with tracking points.

[0109] The terminal obtains the software behavior executed by the triggered API with tracking points, so as to subsequently determine whether the software behavior is an identification behavior related to application hot update.

[0110] Step 403: Obtain the file hash value and file quantity of the APP's dex file.

[0111] At the same time, the terminal will also obtain the file hash value and file number of the dex file suffix related to the hot update of the application in the APP, and check whether it is consistent with the historical record to determine whether the dex file has changed.

[0112] Step 404: Check whether the file hash value and the file quantity are consistent with the historical record results.

[0113] If it is determined that both the file hash value and the file quantity are consistent with the historical record results, proceed to step 410; if it is determined that at least one of the file hash value or the file quantity is inconsistent with the historical record results, proceed to step 405 to determine if the dex file of the APP has changed.

[0114] Step 405: Determine whether the dex file of the APP has changed.

[0115] Step 406: Whether the software behavior is an identification behavior.

[0116] After determining that the dex file of the APP has changed, it is possible to further determine whether the software behavior is an identification behavior (identification behavior is a key behavior involved in the application hot update process). If the software behavior is an identification behavior, step 407 can be entered to determine whether the APP has an application hot update behavior.

[0117] Step 407: Determine whether an application hot update behavior of the APP is detected.

[0118] Step 408: Detect malicious code on the APP.

[0119] After determining that the APP has hot update behavior, the terminal first obtains all code files of the APP and performs code malicious detection on all code files.

[0120] Step 409: perform attack behavior detection on the application behavior of the APP.

[0121] Furthermore, the terminal can also obtain application behavior within a certain period of time after the application hot update, and perform attack behavior detection on the application behavior of the APP to determine whether there is malicious application behavior.

[0122] Step 410: Determine whether the dex file of the APP has not been changed.

[0123] When the file hash value and file quantity are consistent with the historical record value, it is determined that the APP's dex file has not changed, but the API with tracking is triggered. In order to further identify whether there is application hot update behavior, the software behavior indicated by the API that triggers the tracking is recorded, and the software behavior and APP code file are uploaded to the cloud for application hot update behavior detection.

[0124] Step 411 records the software behavior indicated by the triggering API with tracking points, and uploads the software behavior and APP code files to the cloud to determine whether there is a hot update behavior.

[0125] If the cloud feedback result indicates that there is an application hot update behavior, then continue to execute steps 407 to 408. Perform application security detection on the application.

[0126] Taking the application hot update to update the APP dex file as an example, applying the application security detection method shown in the above embodiment, the application security detection process of the APP can be summarized as follows:

[0127] 1. Security software (can be recorded as: sec_manager) tracks and monitors the status of APP dex files.

[0128] 1) Based on the analysis of mainstream application hot update methods, the security software extracts key behaviors in the application hot update process as identification behaviors to determine whether an application hot update has occurred, and tracks related APIs.

[0129] For example, operations such as writing to files with the dex suffix, restarting an activity during application execution, restarting the entire application with simultaneous changes to the dex file can be used as identification behaviors for application hot updates, and related APIs can be tracked for subsequent triggering of security software.

[0130] 2) The security software regularly detects and records the dex file hash values ​​and number of dex files of all application software on the maintenance terminal.

[0131] 2. Apply hot updates.

[0132] 1) The APP on the terminal starts running and loads the corresponding dex file (denoted as dex1).

[0133] 2) The app remotely connects to its server and detects the presence of a new patch dex file (denoted as dex2).

[0134] 3) The app downloads dex2 and performs a hot update. Depending on the hot update method, a new dex file (denoted as dex3) is obtained by merging dex1 and dex2, or dex2 is saved (both dex1 and dex2 are now stored in the app sandbox directory).

[0135] 3. Security software performs detection.

[0136] 1) During the hot update process of the APP, the hot update identification behavior will call the relevant API with the embedded point, triggering the security software.

[0137] 2) The security software obtains the corresponding software behavior based on the tracking points, and then detects the hash value of the app's dex file and the number of dex files, and compares them with the previously recorded results to determine whether the dex file has changed.

[0138] If the dex file changes, supplemented by identification behavior, the security software will determine that the APP is hot updated.

[0139] If the dex file has not changed, the pop-up window will be displayed to obtain the user's consent, and the tracking behavior, APP code file and other information will be recorded and reported to the server. The cloud will analyze and determine whether hot update behavior has occurred, and feedback the judgment result to the security software.

[0140] 3) When determining that an APP has been hot-updated, the security software performs local security checks on the updated APP code files (including dex, jar, so, etc.) or uploads them to the cloud for analysis to determine the maliciousness of the hot-updated code.

[0141] 4) Security software performs targeted behavioral security checks and logs for a certain period of time after an app is hot-updated. Logs can be used for subsequent cloud-based or manual analysis to identify any attacks that could evade security software detection.

[0142] 5) After the application is hot-updated, the security software will promptly notify the user of the application's hot-update behavior and detection results, and prompt the user to actively trigger security detection later.

[0143] 6) When triggered by the user, or by predefined application key sensitive behaviors (such as payment), or triggered according to predefined detection policies (regularly or when the device is idle), the security software performs security detection on the application software code and its application behavior on the terminal.

[0144] 4. Update security software policies.

[0145] 1) Security software regularly pulls new policies from the cloud or issues policies from the cloud. These policies include methods for identifying and judging hot-update behavior, as well as targeted detection strategies for application behavior after hot-updates, to improve the accuracy of identifying hot-update behavior and typical malicious behavior after hot-updates.

[0146] Figure 5 This is a structural diagram of an application security detection device provided in an embodiment of the present application.

[0147] For example, Figure 5 As shown, the device 500 includes:

[0148] A file verification module 501 is configured to, when an operation of identifying an application hot update behavior is triggered, perform a file verification on a first code file of the application to obtain a file verification result, wherein the first code file is an application code file associated with the application hot update behavior, and the file verification is used to verify whether the first code file has been changed;

[0149] A determination module 502 is configured to determine whether the application has the application hot update behavior if the file verification result indicates that the first code file has been changed;

[0150] The security detection module 503 is configured to perform an application security detection on the application when it is determined that the application has the application hot update behavior.

[0151] Optionally, the file verification module 501 is further configured to:

[0152] Obtaining a file hash value corresponding to the first code file and the number of files corresponding to the first code file;

[0153] Perform file verification on the first code file based on the file hash value and the file quantity.

[0154] Optionally, the file verification module 501 is further configured to:

[0155] Obtaining a historical hash value corresponding to the first code file and a historical number of files corresponding to the first code file, where the historical hash value and the historical number are the file hash value and the file number recorded during the last application security detection process for the application;

[0156] If the historical hash value matches the file hash value, and the number of files matches the historical number, determining that the first code file has not been changed;

[0157] If the historical hash value does not match the file hash value, and / or the historical quantity does not match the file quantity, it is determined that the first code file has been changed.

[0158] Optionally, the determining module 502 is further configured to:

[0159] When the file verification result indicates that the first code file has changed and there is an identification behavior, it is determined that the application has the application hot update behavior, and the identification behavior is the application behavior involved in the process of executing the application hot update behavior.

[0160] Optionally, the device further comprises:

[0161] a triggering module, configured to trigger an identification operation of the application hot update behavior in response to a call operation on a target interface, wherein the target interface is an interface related to the application hot update behavior;

[0162] A first acquisition module is configured to acquire the first application behavior indicated by the calling operation when an identification operation of the application hot update behavior is triggered;

[0163] The determining module 502 is further configured to:

[0164] When the file verification result indicates that the first code file has been changed and the identification behavior exists in the first application behavior, it is determined that the application has the application hot update behavior.

[0165] Optionally, the device further comprises:

[0166] a second acquisition module, configured to acquire, if the file verification result indicates that the first code file has not been changed, a second code file of the application, where the second code file is all code files of the application;

[0167] An analysis module is used to analyze whether the application has the application hot update behavior based on the second code file and the first application behavior.

[0168] Optionally, the security detection module 503 is further configured to:

[0169] Obtaining a second code file of the application after the application hot update behavior is executed, where the second code file is all code files of the application;

[0170] A code abnormality check is performed on the second code file to obtain a code verification result, wherein the code abnormality check is used to verify whether there is abnormal code in the application code of the application.

[0171] Optionally, the security detection module 503 is further configured to:

[0172] When the code verification result indicates that the abnormal code does not exist in the second code file, obtaining a second application behavior within a target time period after the application hot update behavior is executed;

[0173] A behavior check is performed on the second application behavior to obtain a behavior check result, wherein the behavior check is used to check whether there is abnormal behavior during the running of the application after the application hot update behavior is executed.

[0174] In summary, the present application provides an application security detection method: when triggering the identification operation of application hot update behavior, a file verification can be performed on the first code file in the application related to the application hot update behavior, and when the file verification result indicates that there is a change in the first code file, it is determined that the application hot update behavior has been detected, and the application hot update is performed on the application. This provides a feasible method for automatically triggering the application hot update behavior to perform application security detection, and can include the application hot update behavior in the scope of automatically triggering application security detection, and promptly perform application security detection on the application after the application hot update behavior is executed, thereby ensuring the application security of the application operation process.

[0175] Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of the present application.

[0176] For example, Figure 6 As shown, the terminal 600 in the present application may include one or more of the following components: a processor 610 and a memory 620 .

[0177] The processor 610 may include one or more processing cores. The processor 610 utilizes various interfaces and circuits to connect various components within the terminal 600. It executes instructions, programs, code sets, or instruction sets stored in the memory 620, as well as accesses data stored in the memory 620, to perform various functions and process data for the terminal 700. Optionally, the processor 610 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 710 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing content displayed on the display; and the modem handles wireless communications. It is understood that the modem may not be integrated into the processor 610 and may be implemented separately via a baseband chip.

[0178] The memory 620 may include a random access memory (RAM) or a read-only memory (ROM). Optionally, the memory 720 includes a non-transitory computer-readable storage medium. The memory 620 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 620 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc. The operating system may be an Android system (including a system developed based on the depth of the Android system), an iOS system developed by Apple (including a system developed based on the depth of the iOS system), or other systems. The data storage area may also store data (such as a phone book, audio and video data, chat history data), etc., created by the terminal 600 during use.

[0179] In addition, those skilled in the art will appreciate that the structure of terminal 600 shown in the above figures does not limit terminal 600. The terminal may include more or fewer components than shown, or may combine certain components, or arrange the components differently. For example, terminal 600 also includes RF circuits, camera components, sensors, audio circuits, Wireless Fidelity (WiFi) components, power supplies, Bluetooth components, and other components, which will not be described in detail here.

[0180] The terminal provided in the embodiments of the present application can specifically be a chip, component or module, and the terminal may include a connected processor and memory; wherein the memory is used to store instructions, and when the terminal is running, the processor can call and execute instructions to enable the chip to execute any one of the application security detection methods introduced above.

[0181] This embodiment provides a computer-readable storage medium, which stores instructions. When the instructions are executed on a computer or a processor, the computer or processor executes any one of the application security detection methods described above.

[0182] This embodiment further provides a computer program product comprising instructions. When the computer program product is run on a computer or a processor, the computer or processor is caused to execute the above-mentioned related steps to implement any of the application security detection methods described above.

[0183] Among them, the terminal, computer-readable storage medium, computer program product or chip containing instructions provided in this embodiment are all used to execute the corresponding application security detection method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.

[0184] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0185] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, 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, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0186] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. An application security detection method, characterized in that: The method comprises: In a case where an operation of identifying an application hot update behavior is triggered, performing a file verification on a first code file of the application to obtain a file verification result, where the first code file is an application code file associated with the application hot update behavior, and the file verification is used to verify whether the first code file has been changed; When the file verification result indicates that the first code file has been changed, determining that the application has the application hot update behavior; When it is determined that the application has the application hot update behavior, performing application security detection on the application; The performing of file verification on the first code file of the application to obtain a file verification result includes: Obtain a file hash value corresponding to the first code file and the number of files corresponding to the first code file; and perform file verification on the first code file based on the file hash value and the number of files.

2. The method according to claim 1, characterized in that The performing file verification on the first code file based on the file hash value and the file quantity includes: Obtaining a historical hash value corresponding to the first code file and a historical number of files corresponding to the first code file, where the historical hash value and the historical number are the file hash value and the file number recorded during the last application security detection process for the application; If the historical hash value matches the file hash value, and the number of files matches the historical number, determining that the first code file has not been changed; If the historical hash value does not match the file hash value, and / or the historical quantity does not match the file quantity, it is determined that the first code file has been changed.

3. The method according to claim 1 or 2, characterized in that When the file verification result indicates that the first code file has been changed, determining that the application has the application hot update behavior includes: When the file verification result indicates that the first code file has changed and there is an identification behavior, it is determined that the application has the application hot update behavior, and the identification behavior is the application behavior involved in the process of executing the application hot update behavior.

4. The method according to claim 3, characterized in that The method further comprises: In response to a call operation on a target interface, triggering an identification operation on the application hot update behavior, wherein the target interface is an interface related to the application hot update behavior; In a case where an identification operation for the application hot update behavior is triggered, obtaining a first application behavior indicated by the calling operation; When the file verification result indicates that the first code file has been changed and there is an identification behavior, determining that the application has the application hot update behavior includes: When the file verification result indicates that the first code file has been changed and the identification behavior exists in the first application behavior, it is determined that the application has the application hot update behavior.

5. The method according to claim 4, characterized in that The method further comprises: If the file verification result indicates that the first code file has not been changed, obtaining a second code file of the application, where the second code file is all code files of the application; Based on the second code file and the first application behavior, the application is analyzed to determine whether the application hot update behavior exists.

6. The method according to claim 1 or 2, characterized in that The performing application security detection on the application includes: Obtaining a second code file of the application after the application hot update behavior is executed, where the second code file is all code files of the application; A code abnormality check is performed on the second code file to obtain a code verification result, wherein the code abnormality check is used to verify whether there is abnormal code in the application code of the application.

7. The method according to claim 5, characterized in that The performing application security detection on the application further includes: When the code verification result indicates that no abnormal code exists in the second code file, obtaining a second application behavior within a target time period after the application hot update behavior is executed; A behavior check is performed on the second application behavior to obtain a behavior check result, wherein the behavior check is used to check whether there is abnormal behavior during the running of the application after the application hot update behavior is executed.

8. An application security detection device, characterized in that: The device comprises: a file verification module configured to, when triggering an operation to identify an application hot update behavior, perform a file verification on a first code file of the application to obtain a file verification result, wherein the first code file is an application code file associated with the application hot update behavior, and the file verification is used to verify whether the first code file has been changed; a determination module, configured to determine whether the application has the application hot update behavior if the file verification result indicates that the first code file has been changed; A security detection module is used to perform application security detection on the application when it is determined that the application has the application hot update behavior; The file verification module is further configured to obtain a file hash value corresponding to the first code file and the number of files corresponding to the first code file; and perform file verification on the first code file based on the file hash value and the number of files.

9. A terminal, characterized in that: The terminal includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the terminal executes the application security detection method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, and when the instructions are executed on a computer or a processor, the computer or the processor executes the application security detection method according to any one of claims 1 to 7.

11. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the application security detection method according to any one of claims 1 to 7 is implemented.

Images