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

Abstract

The invention provides an application security detection method and device, a terminal, a storage medium and a program product. The method belongs to the technical field of application security, and comprises the following steps: under the condition that an identification operation on an application hot update behavior is triggered, performing file verification on a first code file of an 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 application code file being an application code file associated with the application hot update behavior; the file verification is used for verifying whether the first code file is changed or not; when the file verification result indicates that the first code file is changed, determining that the application has an application hot update behavior; and under the condition of determining that the application has the application hot update behavior, performing application security detection on the application. According to the method, application security detection can be carried out on the application in time when the application is subjected to hot update, and the application running security is improved.

Description

Technical Field

[0001] The present application relates to the field of application security technology, and more specifically, to an application security detection method, device, terminal, storage medium and program product in the field of application operation. Background Art

[0002] When an application (APP) fails or the application code resources of the APP need to be updated, the APP developer often uses the application hot update method to update it. In the application hot update method, the application does not need to download and install the package again, and the application patch package can be directly issued. The patch package can be added, replaced or modified directly during the operation of the APP.

[0003] At present, the main application security detection strategies are: when the application is downloaded and installed, the terminal's security detection service performs a security check on the application's installation package; or the user actively triggers the application security detection service to perform a security check on the application; or the security detection service automatically performs a security check on the application at preset time intervals.

[0004] Obviously, application hot update behavior does not fall within the scope of current application security detection strategies, and the security of the application after the application hot update cannot be guaranteed. Summary of the invention

[0005] The present application provides an application security detection method, device, terminal, storage medium and program product. The method can perform application security detection on the application in a timely manner when the application is hot updated, thereby improving the security of application operation.

[0006] In one aspect, a method for detecting application security is provided, the method comprising:

[0007] In the case of triggering an identification operation of an application hot update behavior, performing a file check on a first code file of the application to obtain a file check result, wherein the first code file is an application code file associated with the application hot update behavior, and the file check is used to check whether the first code file is changed;

[0008] When the file verification result indicates that the first code file has been changed, determining that the application has the application hot update behavior;

[0009] When it is determined that the application has the application hot update behavior, an application security detection is performed on the application.

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

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

[0012] a determination module, configured to determine that the application has the application hot update behavior when the file verification result indicates that the first code file has been changed;

[0013] The 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.

[0014] On the one hand, a terminal is provided, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein when the processor executes the computer program, the terminal executes the application security detection method described in any one of the above aspects.

[0015] On the one hand, a computer-readable storage medium is provided, in which instructions are stored. When the instructions are executed on a computer or a processor, the computer or the processor executes the application security detection method described in any one of the above aspects.

[0016] On the one hand, a computer program product is provided, which computer program product or computer program includes a program code, which is stored in a computer-readable storage medium. A processor of a terminal reads the program code from the computer-readable storage medium, and the processor executes the program code, so that the terminal executes the application security detection method described in any one of the above aspects.

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

[0018] The present application provides an application security detection method: when triggering the identification operation of application hot update behavior, the first code file related to the application hot update behavior in the application can be checked, and when the file check result indicates that the first code file has changed, it is determined that the application hot update behavior is detected, and the application hot update is performed on the application. It provides a feasible way to perform application security detection on the application after automatically triggering the execution of application hot update behavior, and can include application hot update behavior in the scope of automatically triggering application security detection, and timely perform application security detection on the application after executing application hot update behavior, so as to ensure the application security of the application operation process. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0020] Figure 1 is a schematic flow chart of an application security detection method provided in an embodiment of the present application;

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

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

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

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

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

[0026] The technical solutions in the present application will be described clearly and in detail below in conjunction with the accompanying drawings. In the description of the embodiments of the present application, "multiple" means two or more than two. The terms "first" and "second" are used for descriptive purposes only and should not be understood as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features.

[0027] When an APP fails or the application code resources of the APP need to be updated, the APP developer often uses the application hot update method to update it. In the application hot update method, the application does not need to download and install the package again, and the application patch package can be directly issued. The patch package can be added, replaced or modified directly during the operation of the APP.

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

[0029] 1. Application hot update

[0030] 1) An APP on the Android terminal (denoted as APP) 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, or by a predefined application key sensitive behavior (such as payment), or according to a predefined detection strategy (regularly or when the device is idle), the security software (denoted as sec_manager) performs security detection on the application software code and its application behavior on the terminal.

[0036] From the above application hot update and security software detection process, it can be seen that the application hot update behavior of APP is not included in the indicator range that triggers security software detection. Some malicious applications can use the application hot update behavior to download malicious application code and run it, thereby endangering the terminal data security.

[0037] In response to the above problems, the present 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 1 is a schematic flow chart of an application security detection method provided in an embodiment of the present application. The present application embodiment takes the method applied 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 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 changed.

[0041] Since application hot update behavior does not require re-downloading and installing the application, it only needs to download the 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 application code files 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 recognition operation of application hot update behavior: when the terminal detects the existence of key behavior, it can automatically trigger the recognition operation of application hot update behavior. The key behavior can be a behavior related to the application hot update behavior, such as detecting the write operation of the dex suffix file, or restarting the activity operation during the application operation, or restarting the entire application operation during the application operation. Optionally, the terminal can also detect the trigger operation of the target application programming interface (Application Programming Interface, API) embedding point, and automatically trigger the recognition operation of the application hot update behavior. The target API is the API that may be called during the application hot update behavior, such as the 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, determine whether the application has an application hot update behavior.

[0044] Since application hot update generally involves modification of dex suffix files, by detecting whether the dex suffix files have changed, it can be used to further detect whether there is application hot update behavior. 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 application hot update behavior.

[0045] Step 103: When it is determined that the application has an application hot update behavior, an application security check is performed on the application.

[0046] In order to perform security checks on the application in time after the application is hot-updated to avoid threats to terminal data from malicious code, in a possible implementation, when the terminal determines that the application has an application hot-updated behavior, the application security check is immediately performed on the application.

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

[0048] Optionally, a security detection strategy corresponding to the application security detection may be pre-configured in the terminal, and the security detection strategy may be used to perform application security detection on the application. Optionally, the security detection strategy may be updated regularly.

[0049] Optionally, after performing application security detection 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 detection result, so that the user can be informed in time 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 the application hot update behavior, the first code file related to the application hot update behavior in the application can be checked, and when the file check result indicates that the first code file has changed, it is determined that the application hot update behavior is detected, and the application hot update is performed on the application. It provides a feasible way to perform application security detection on the application after automatically triggering the execution of the application hot update behavior, and the application hot update behavior can be included in the scope of automatically triggering application security detection, and the application security of the application after the execution of the application hot update behavior can be timely performed.

[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. When verifying the code file with the dex suffix, it is necessary to verify the file hash value and the number of files to determine whether the code file has changed.

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

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

[0054] Step 201, when triggering an identification operation of an application hot update behavior, obtain a file hash value corresponding to a first code file and the number of files corresponding to the first code file.

[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 of obtaining the file hash value: the file content of the first code file can be hashed to output the file hash value corresponding to the first code file. Optionally, the first code file can contain one or more code files. In order to determine whether each first code file has been changed, it is necessary to generate the corresponding file hash value according to 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 quantity of the first code file, it can determine whether the first code file is changed according to the file hash value and the file quantity of the historical records.

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

[0061] Step 202A, obtaining a historical hash value corresponding to the first code file and a historical number corresponding to the first code file, wherein 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 last security check to see if they are consistent. Therefore, in a possible implementation, the terminal will also obtain the file hash value and file quantity recorded during the last application security check on the application, that is, obtain the historical hash value corresponding to the first code file and the historical quantity corresponding to the first code file, and compare 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 it detects that the application has hot update behavior, the terminal can also detect and record the file hash values ​​and file numbers of 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 values ​​and file numbers.

[0064] Step 202B: When 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 does not undergo hot update, the dex suffix file of the application does not change, and the corresponding file hash value and file quantity do not change. Therefore, in a 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 changed.

[0066] Step 202C: when 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] On the contrary, if the application undergoes a hot update, the dex suffix file of the application will change, and the corresponding file hash value or file quantity may also change. In a 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] Exemplarily, if the first code file of the application contains three 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: When 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 of the first code file may also be caused by the change after the application is re-downloaded and installed, and the application installation package of the application is automatically subjected to application security detection when it is re-downloaded and installed, in order to avoid misidentification of application hot update behavior and repeated application security detection of the application. Therefore, in a 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 identification behavior, it is determined that the application has application hot update behavior.

[0071] Step 204: when it is determined that the application has an application hot update behavior, obtain 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.

[0072] When performing application security detection on an application after hot update, it is necessary to perform security detection from two aspects: on the one hand, detecting whether the updated application code contains malicious code or abnormal code; on the other hand, it is also necessary to detect whether the updated application will perform certain malicious behaviors during operation. Correspondingly, in a possible implementation, when it is determined that the application has application hot update behavior, the terminal can first obtain all code files (second code files) of the application after the application hot update behavior is executed, and perform code abnormality check or code malicious check on the second code file.

[0073] Since the hot update process of the application may also affect code files other than those with the suffix dex, 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 suffix dex, jar, so, etc.), 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 may threaten the terminal data security, so as to obtain the code verification result.

[0076] Optionally, when performing code anomaly verification on the second code file, code static analysis functions, malicious code feature 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 code 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 codes may not be detected as malicious, but during the operation of the application, the application code can be executed to cause the application to perform certain malicious behaviors, such as automatically calling user album data without user operation. In order to further improve the operation security of the application, in one possible implementation, when the terminal determines that the code verification result indicates that there is no abnormal code (malicious code) in the second code file, the second application behavior within the target time period after the application hot update behavior is executed can be obtained to perform behavior verification on the second application behavior to determine whether there is malicious application behavior that threatens the terminal data security after the application hot update.

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

[0080] Optionally, when obtaining the second application behavior, the second application behavior under the pre-configured behavior category can also be selected. For example, if the behavior category is payment-related behavior, the second application behavior related to the payment service call behavior is obtained; if the behavior category is positioning-related behavior, the second application behavior related to the positioning service call behavior is obtained; so as to achieve the purpose of behavior verification of the targeted 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 behavior 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 obtaining the second application behavior of the application within the target time period, the second application behavior can be verified to verify whether there is abnormal behavior or malicious behavior during the application operation after the application hot update.

[0084] In this embodiment, the file hash value and the number of files of the first code file are obtained so as to determine whether the first code file has changed from two dimensions, thereby improving the accuracy of determining the change of the first code file; moreover, after determining that the first code file has changed, it is also possible to obtain whether the application has identification behavior related to the application hot update behavior, so as to comprehensively determine whether the application has the application hot update behavior, thereby avoiding the influence of other application installation behaviors that can change the first code file on the accuracy of the determination, thereby improving the accuracy of identifying the application hot update behavior; in addition, when performing application security detection on the application, it is possible not only to detect the code maliciousness from the static code level, but also to detect the application behavior maliciousness from the dynamic application behavior level, and to perform application security detection from multiple angles and layers, thereby further improving the security of application operation.

[0085] In order to trigger application security detection in time, it is necessary to trigger the identification of application hot update behavior in time. Developers analyze the mainstream application hot update methods, extract the key behaviors in the application hot update process, and track the APIs involved in the key behaviors, so that when the APIs with tracking points are called later, the application hot update behavior can be identified in time.

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

[0087] For example, Figure 3 As shown, the method 300 includes:

[0088] Step 301 : In response to a call operation on a target interface, triggering an identification operation on an application hot update behavior, where the target interface is an interface related to the application hot update behavior.

[0089] The target interface is the API interface related to the application hot update behavior. By pre-extracting the key behaviors in the application hot update process and determining the API involved in the key behaviors as the target interface, the API is then tracked through the hook operation, so that the subsequent terminal can determine that the call operation to the target interface is received and trigger the recognition operation of the application hot update behavior when the API with the tracking point is called.

[0090] Exemplarily, if the security software of the terminal performs application security detection on the application, the terminal may trigger the security software after receiving a call operation on the target interface, and the security software may determine whether there is any application hot update behavior.

[0091] For example, the terminal can use the write operation of the dex suffix file, or the restart of the activity during the application running, the restart of the entire application and the change of the dex file at the same time as the hot update identification behavior, and embed 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 comprehensively judge whether the application hot update behavior is recognized based on whether there is an identification behavior and whether the first code file is changed, in a 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 based on the triggered API with a buried point, that is, obtain the first application behavior referred to by the call operation, so as to further determine whether the first application behavior is an identification behavior.

[0094] Step 303: When the identification operation of the hot update behavior of the application 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 may refer to the above embodiment, and will not be described in detail in this embodiment.

[0096] Step 304: When the file verification result indicates that the first code file has been changed and there is an identification behavior in the first application 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 first application behavior contains identification 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 embedding point is called (that is, the target interface is called), it means that the terminal may 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 (the 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, the user's consent is required, a prompt window is displayed accordingly, and with the user's consent, the information is uploaded to the cloud to further ensure the security of the terminal data.

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

[0101] Step 305: When it is determined that the application has an application hot update behavior, an application security check is performed on the application.

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

[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 It 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 it is necessary 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, obtaining software behavior according to 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, obtaining the file hash value and file quantity of the dex file of the APP.

[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, determining whether the dex file of the APP has been 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 (the identification behavior is a key behavior involved in the application hot update process). If the software behavior is an identification behavior, the process proceeds to step 407 to determine whether the APP has an application hot update behavior.

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

[0118] Step 408: Perform code maliciousness detection on the APP.

[0119] After determining that the APP has application hot update behavior, the terminal first obtains all code files of the APP and performs code maliciousness 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 the 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 the number of files are consistent with the historical record value, it is determined that the dex file of the APP has not been changed, but the API with the tracking point 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 point is recorded, and the software behavior and APP code file are uploaded to the cloud for application hot update behavior detection.

[0124] Step 411, record the software behavior indicated by the API with the tracking point, and upload the software behavior and APP code file to the cloud to determine whether there is 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 (remembered 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 occurs, and tracks related APIs.

[0129] For example, operations such as writing to files with a dex suffix, restarting an activity during the running of an application, restarting the entire application with changes in dex files, etc. are used as identification behaviors for application hot updates, and related APIs are 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 existence of a new patch dex file (denoted as dex2).

[0134] 3) APP downloads dex2 and performs the application hot update process. Depending on the specific hot update method, a new dex file (denoted as dex3) is obtained after dex1 and dex2 are merged, or dex2 is saved (at this time, both dex1 and dex2 are saved 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 embedding point to trigger the security software.

[0137] 2) The security software obtains the corresponding software behavior based on the tracking point, 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 there is a change in the dex file, supplemented by identification behavior, the security software will determine whether the APP is hot updated.

[0139] If the dex file has not changed, the pop-up window will be opened with 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 application 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) The security software performs targeted behavioral security detection and logs on the APP within a certain period of time after the APP application is hot updated. The logs can be used for subsequent cloud or manual analysis to identify whether there are any attack behaviors that can evade security detection by the security software.

[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 actively 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 policy.

[0145] 1) Security software regularly pulls new policies from the cloud, or sends policies from the cloud. The policy content includes the identification and judgment method of hot update behavior, as well as the targeted detection strategy of application behavior after hot update, so as to improve the accuracy of judgment on hot update behavior and typical malicious behavior after hot update.

[0146] Figure 5 It 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 used to perform a file verification on a first code file of an application to obtain a file verification result when an identification operation of an application hot update behavior is triggered, 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 is changed;

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

[0150] The security detection module 503 is used to perform 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 used 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] Based on the file hash value and the file quantity, a file verification is performed on the first code file.

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

[0155] Obtaining a historical hash value corresponding to the first code file and a historical number corresponding to the first code file, wherein 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 file quantity matches the historical quantity, determining that the first code file has not been changed;

[0157] When 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 been 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 trigger 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, 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 is used to acquire a second code file of the application when the file verification result indicates that the first code file has not been changed, 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 safety detection module 503 is further used 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 anomaly check is performed on the second code file to obtain a code verification result, wherein the code anomaly check is used to verify whether there is an abnormal code in the application code of the application.

[0171] Optionally, the safety detection module 503 is further used 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 operation 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 the application hot update behavior, the first code file related to the application hot update behavior in the application can be checked, and when the file check result indicates that the first code file has changed, it is determined that the application hot update behavior is detected, and the application hot update is performed on the application. It provides a feasible way to perform application security detection on the application after automatically triggering the execution of the application hot update behavior, and the application hot update behavior can be included in the scope of automatically triggering application security detection, and the application security of the application after the execution of the application hot update behavior can be timely performed.

[0175] Figure 6 It is a structural diagram 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 uses various interfaces and lines to connect various parts of the entire terminal 600, and executes various functions and processes data of the terminal 700 by running or executing instructions, programs, code sets or instruction sets stored in the memory 620, and calling data stored in the memory 620. Optionally, the processor 610 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 710 can integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; and the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 610, but may be implemented separately through 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 storage program area and a storage data area, wherein the storage program 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 deeply developed based on an Android system), an IOS system developed by Apple (including a system deeply developed based on an IOS system) or other systems. The storage data area may also store data (such as a phone book, audio and video data, chat record data) created by the terminal 600 during use.

[0179] In addition, those skilled in the art will appreciate that the structure of the terminal 600 shown in the above figures does not constitute a limitation on the terminal 600, and the terminal may include more or fewer components than shown, or combine certain components, or arrange the components differently. For example, the terminal 600 also includes a radio frequency circuit, a shooting component, a sensor, an audio circuit, a wireless fidelity (WiFi) component, a power supply, a Bluetooth component, and other components, which will not be described in detail here.

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

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

[0182] This embodiment also provides a computer program product including instructions. When the computer program product is executed on a computer or a processor, the computer or the processor executes the above-mentioned related steps to implement any one of the application security detection methods introduced 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 assigned to 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 the present 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 only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, 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 contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. An application security detection method, characterized in that: The method comprises: In the case of triggering an identification operation of an application hot update behavior, performing a file check on a first code file of the application to obtain a file check result, wherein the first code file is an application code file associated with the application hot update behavior, and the file check is used to check whether the first code file is 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, an application security detection is performed on the application.

2. The method according to claim 1, characterized in that The performing file verification on the first code file of the application to obtain a file verification result includes: Obtaining a file hash value corresponding to the first code file and the number of files corresponding to the first code file; Based on the file hash value and the file quantity, a file verification is performed on the first code file.

3. The method according to claim 2, 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 corresponding to the first code file, wherein 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 file quantity matches the historical quantity, determining that the first code file has not been changed; When 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.

4. The method according to any one of claims 1 to 3, 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 been 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.

5. The method according to claim 4, 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 case of triggering an identification operation for the application hot update behavior, 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.

6. The method according to claim 5, 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 has the application hot update behavior.

7. The method according to any one of claims 1 to 3, 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 anomaly check is performed on the second code file to obtain a code verification result, wherein the code anomaly check is used to verify whether there is an abnormal code in the application code of the application.

8. The method according to claim 6, characterized in that The performing application security detection on the application further includes: 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; 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 operation of the application after the application hot update behavior is executed.

9. An application security detection device, characterized in that: The device comprises: A file verification module is used to perform a file verification on a first code file of an application to obtain a file verification result when an identification operation of a hot update behavior of an application is triggered, wherein the first code file is an application code file associated with the hot update behavior of the application, and the file verification is used to verify whether the first code file is changed; a determination module, configured to determine that the application has the application hot update behavior when the file verification result indicates that the first code file has been changed; The 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.

10. 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 as described in any one of claims 1 to 8.

11. 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 8.

12. 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 8 is implemented.

Images