CN119494096A - Application security detection method, device, terminal, storage medium and program product - Google Patents
Application security detection method, device, terminal, storage medium and program product Download PDFInfo
- Publication number
- CN119494096A CN119494096A CN202311023367.0A CN202311023367A CN119494096A CN 119494096 A CN119494096 A CN 119494096A CN 202311023367 A CN202311023367 A CN 202311023367A CN 119494096 A CN119494096 A CN 119494096A
- Authority
- CN
- China
- Prior art keywords
- application
- file
- behavior
- code
- hot update
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/562—Static detection
- G06F21/563—Static detection by source code analysis
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Stored Programmes (AREA)
Abstract
本申请提供了一种应用安全检测方法、装置、终端、存储介质及程序产品。属于应用安全技术领域，该方法包括：在触发对应用热更新行为的识别操作的情况下，对应用的第一代码文件进行文件校验，得到文件校验结果，第一代码文件是与应用热更新行为关联的应用代码文件，文件校验用于校验第一代码文件是否发生变更；在文件校验结果指示第一代码文件发生变更的情况下，确定应用存在应用热更新行为；在确定应用存在应用热更新行为的情况下，对应用进行应用安全检测。该方法能够在应用热更新时及时对应用进行应用安全检测，提高应用运行的安全性。
The present application provides an application security detection method, device, terminal, storage medium and program product. It belongs to the field of application security technology. The method includes: when triggering the identification operation of the application hot update behavior, performing file verification on the first code file of the application to obtain the 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; when the file verification result indicates that the first code file has changed, it is determined that the application has application hot update behavior; when it is determined that the application has application hot update behavior, application security detection is performed on the application. 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.
Description
Technical Field
The present application relates to the field of application security technologies, and more particularly, to an application security detection method, apparatus, terminal, storage medium, and program product in the field of application operation.
Background
When an Application (APP) fails, or an APP code resource needs to be updated, a developer of the APP often updates the APP by using an Application hot update method. Under the application hot update mode, the application can directly issue the application patch package without re-downloading and installing the package, and the APP can directly add, replace or modify the patch package in the running process.
At present, the main application security detection strategy is that the security detection service of the terminal carries out security detection on an installation package of the application when the application is downloaded and installed, or the user actively triggers the application security detection service to carry out security detection on the application, or the security detection service automatically carries out security detection on the application in preset time intervals.
Obviously, the application hot update behavior does not belong to the current application safety detection policy category, and the safety of the application after the application hot update cannot be ensured.
Disclosure of Invention
The application provides an application security detection method, an application security detection device, a terminal, a storage medium and a program product.
In one aspect, an application security detection method is provided, the method comprising:
Under the condition of triggering the identification operation of the application hot update behavior, performing file verification on a first code file of an 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 for verifying whether the first code file is changed or not;
determining that the application has the application hot update behavior under the condition that the file verification result indicates that the first code file is changed;
and carrying out application security detection on the application under the condition that the application is determined to have the application hot update behavior.
In one aspect, there is provided an application security detection apparatus, the apparatus comprising:
The file verification module is used for carrying out file verification on a first code file of an application under the condition of triggering the identification operation of the application hot update behavior 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 for verifying whether the first code file is changed or not;
the determining module is used for determining that the application has the application hot update behavior under the condition that the file verification result indicates that the first code file is changed;
And the security detection module is used for carrying out application security detection on the application under the condition that the application is determined to have the application hot update behavior.
In one aspect, a terminal is provided, the terminal including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, causes the terminal to execute the application security detection method according to any one of the above aspects.
In one aspect, a computer readable storage medium is provided, in which instructions are stored which, when run on a computer or processor, cause the computer or processor to perform the application security detection method of any of the above aspects.
In one aspect, a computer program product is provided, the computer program product or computer program comprising a program code, the program code being stored in a computer readable storage medium, a processor of a terminal reading the program code from the computer readable storage medium, the processor executing the program code such that the terminal performs the application security detection method according to any one of the above aspects.
The technical scheme provided by the embodiment of the application can bring the following beneficial effects:
The application provides an application security detection method, which can carry out file verification on a first code file related to application hot update behavior in application under the condition of triggering identification operation of the application hot update behavior, and can determine that the application hot update behavior is detected and carry out application hot update on the application under the condition that a file verification result indicates that the first code file has change. The method provides a feasible way for automatically triggering the application after executing the application hot update behavior to perform application safety detection, can bring the application hot update behavior into the range of automatically triggering the application safety detection, and timely performs the application safety detection on the application after executing the application hot update behavior, thereby ensuring the application safety in the application running process.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic flow chart of an application security detection method provided by an embodiment of the present application;
FIG. 2 is a schematic flow chart of another method for applying security detection provided by an embodiment of the present application;
FIG. 3 is a schematic flow chart of another method for applying security detection provided by an embodiment of the present application;
FIG. 4 is a schematic flow chart of another method for applying security detection provided by an embodiment of the present application;
fig. 5 is a schematic structural diagram of an application security detection device according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a terminal according to an embodiment of the present application.
Detailed Description
The technical scheme of the application will be clearly and thoroughly described below with reference to the accompanying drawings. Wherein in the description of embodiments of the application, "a plurality" means two or more than two. The terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as implying or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature.
When an APP fails or an APP application code resource needs to be updated, a developer of the APP often updates the APP by using an application hot update mode. Under the application hot update mode, the application can directly issue the application patch package without re-downloading and installing the package, and the APP can directly add, replace or modify the patch package in the running process.
The existing application hot updating and detecting process of the Android terminal is outlined as follows:
1. Application hot update
1) And (3) starting running of a certain APP (marked as APP) on the Android terminal, and loading and executing a corresponding dex file (marked as dex 1).
2) The APP is remotely connected with a background server, and detects whether a new patch dex file exists or not in real time.
3) When a new patch file (denoted as dex 2) is detected, the APP downloads dex2 and performs an application hot update procedure.
In the process of applying hot update, the APP combines the dex1 file and the dex2 file according to a specific hot update mode to obtain a new dex3 file, or directly stores the dex2 file, and simultaneously stores the dex1 file and the dex2 file under an APP sandbox directory.
2. Secure software execution detection
1) The security software (denoted as sec _ manager) performs security detection of the application software code on the terminal and its application behavior, either triggered actively by the user, or by predefined application critical sensitive actions (e.g. payment), or triggered according to predefined detection policies (periodically, or when the device is idle).
From the above application hot update and security software detection process, the application hot update behavior of APP is not included in the index range triggering the security software detection. Some malicious applications can download malicious application codes and run by means of application hot update behaviors, so that the terminal data security is compromised.
Aiming at the problems, the application provides an application security detection mode which can identify application hot update behaviors and timely trigger application security detection of the application when the application hot update behaviors are determined to exist in the application so as to ensure the running security of the application.
Fig. 1 is a schematic flow chart of a security detection method according to an embodiment of the present application. The embodiment of the application is described by taking the application of the method to the terminal as an example.
As shown in fig. 1, the method 100 includes:
step 101, under the condition of triggering the identification operation of the application hot update behavior, performing file verification on the 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 for verifying whether the first code file is changed or not.
Since the application hot update behavior does not need to re-download and install the application, only the patch package needs to be downloaded to modify, add or replace the dex file of the application, etc., the general application hot update behavior is often completed without perception of the user. The application security detection is performed on the application hot update behavior in time so that it can be perceived in time. The embodiment of the application provides a mode for checking the application code file to detect whether the application has application hot update behavior. In a possible implementation manner, under the condition that the identification operation of the application hot update behavior is triggered, the terminal can acquire a 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 is changed.
The triggering scenario of the identification operation of the application hot update behavior may be that the terminal automatically triggers the identification operation of the application hot update behavior when detecting that a key behavior exists, where the key behavior may be a behavior related to the application hot update behavior, for example, detecting a write operation to a dex suffix file, or that a restart activity operation occurs during an application running period, or that a restart of the entire application operation occurs during the application running period, etc. Optionally, the terminal may detect a trigger operation on a buried point of a target application programming interface (Application Programming Interface, API), and automatically trigger an identification operation on an application hot update behavior, where the target API is an API that may be called during the application hot update behavior, for example, an API that needs to be called when writing a dex file. Alternatively, the application security detection may be triggered automatically at predetermined intervals.
Step 102, determining that the application has application hot update behavior when the file verification result indicates that the first code file is changed.
Since application hot updates typically involve modification of the dex suffix file, it can be used to further detect whether application hot update behavior exists by detecting whether the dex suffix file has changed. Thus, in one possible implementation, when the terminal determines that the file verification result indicates that the first code file is changed, it may be determined that the application may have application hot update behavior.
Step 103, in the case that it is determined that the application has application hot update behavior, application security detection is performed on the application.
In order to be able to detect the security of the application in time after the application is hot updated, the threat of malicious code to the terminal data is avoided. In a possible implementation manner, when the terminal determines that the application has application hot update behavior, application security detection is performed on the application immediately.
Optionally, when security detection is applied to the application, security detection may be performed on the changed dex suffix file, or security detection may be performed on all code files of the application.
Optionally, a security detection policy corresponding to the application security detection may be preconfigured in the terminal, and the application security detection may be performed on the application by using the security detection policy. Alternatively, the security detection policy may be updated regularly.
Optionally, after application security detection is performed on the application, the terminal may display a notification message, where the notification message may notify the user that there is an application hot update behavior and an application security detection result, so that it may be known in time that the application has been updated by the application.
In summary, the application provides an application security detection method, which can perform file verification on a first code file related to an application hot update behavior in an application under the condition of triggering an identification operation of the application hot update behavior, and determine that the application hot update behavior is detected and perform application hot update on the application under the condition that a file verification result indicates that the first code file has a change. The method provides a feasible way for automatically triggering the application after executing the application hot update behavior to perform application safety detection, can bring the application hot update behavior into the range of automatically triggering the application safety detection, and timely performs the application safety detection on the application after executing the application hot update behavior, thereby ensuring the application safety in the application running process.
Because of the difference in the application of the hot update method, for example, after downloading a new dex2 file, the new dex2 file may be combined with a dex1 file to generate a dex3 file, or the dex2 file may be directly saved. When the code file of the dex suffix is subjected to file verification, the file hash value and the number of files need to be verified to determine whether the code file is changed or not.
Fig. 2 is a schematic flow chart of another method for applying security detection according to an embodiment of the present application. The embodiment of the application is described by taking the application of the method to the terminal as an example.
Illustratively, as shown in FIG. 2, the method 200 includes:
Step 201, under the condition of triggering the identification operation of the application hot update behavior, obtaining a file hash value corresponding to the first code file and the number of files corresponding to the first code file.
In order to improve accuracy of file verification, in a possible implementation manner, when a terminal triggers an identification operation for an application hot update behavior, file verification is performed on a first code file of an application to obtain a file verification result, where the first code file is an application code file associated with the application hot update behavior, file verification is used to verify whether the first code file is changed, a file hash value corresponding to the first code file and a number of files of the first code file may be obtained, so that file verification may be performed on the first code file from two dimensions, namely the file hash value and the number of files.
For the file hash value obtaining mode, hash operation can be carried out on the file content of the first code file so as to output the file hash value corresponding to the first code file. Optionally, the first code file may include 1 or more code files, and in order to determine whether each first code file is changed, a corresponding file hash value needs to be generated according to the file content of each first code file.
For example, if the first code file includes a dex1 file, a dex2 file, and a dex3 file, the generated file hash value includes 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.
Step 202, performing file verification on the first code file based on the file hash value and the number of files.
Further, after the terminal obtains the file hash value and the number of files of the first code file, whether the first code file is changed or not can be judged according to the file hash value and the number of files of the history record.
Optionally, the step 202 may further include steps 202A to 202C.
Step 202A, a history hash value corresponding to the first code file and a history number corresponding to the first code file are obtained, where the history hash value and the history number are a file hash value and a file number recorded in the last application security detection process for the application.
In order to check whether the first code file is changed, it is necessary to compare whether the current first code file is identical to the first code file recorded at the last security detection. Therefore, in one possible implementation manner, the terminal may further obtain the file hash value and the number of files recorded in the application security detection process of the application last time, that is, obtain the historical hash value corresponding to the first code file and the historical number corresponding to the first code file, so as to compare the obtained file hash value and the number of files with each other to determine whether the first code file is changed.
Optionally, the terminal may detect and record, at intervals of a predetermined time, a file hash value and the number of dex files of all applications on the terminal, in addition to performing application security detection on the applications when detecting that the applications have application hot update behaviors, so that whether the first code file is changed or not may be checked based on the recorded file hash value and the number of files.
In step 202B, when the historical hash value matches the file hash value and the number of files matches the historical number, it is determined that the first code file has not been changed.
If the application does not generate the application hot update, the applied dex suffix file is not changed, and the corresponding file hash value and the number of files are not changed. Thus, in one possible implementation, when the terminal determines that the historical hash value of the first code file matches the file hash value and that the number of files matches the historical number, it is determined that the applied first code file has not been changed.
In step 202C, it is determined that the first code file has been changed if the historical hash value does not match the file hash value and/or if the number of histories does not match the number of files.
Conversely, if the application is updated by the application hot, the dex suffix file of the application may change, and the corresponding file hash value or number of files may also change. In a corresponding possible implementation manner, 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 is changed.
For example, if the first code file includes 3 dex files (the number of files is 3): dex1 file, dex2 file, and dex3 file, the generated file hash values include a file hash value corresponding to the dex1 file: fae0, a file hash value corresponding to the dex2 file: b27c, and a file hash value corresponding to the dex3 file: 451c, and the number of files recorded in the last application security detection process for the application is also 3 (the number of files is 3), the file hash values include a file hash value corresponding to the dex1 file: 7e8c, a file hash value corresponding to the dex2 file: b27c, and a file hash value corresponding to the dex3 file: 4e53, where the number of files of the first code file is not changed, but the file hash values of the dex1 file and the dex3 file are changed, and it is determined that the first code file is changed.
In step 203, when the file verification result indicates that the first code file is 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 executing the application hot update behavior.
Since the first code file is changed after the application is downloaded again and installed, the application security detection is automatically performed on the application installation package of the application during the downloading again and the installation again. Then application security detection is repeated for the application in order to avoid misidentification of application hot update behavior. Therefore, in one possible implementation manner, after the terminal determines that the file verification result indicates that the first code file is changed, it is further required to determine whether there is an application behavior (identification behavior) involved in executing the application hot update behavior, and if the application has the identification behavior, it is determined that the application has the application hot update behavior.
In step 204, in the case that it is determined that the application has the application hot update behavior, a second code file of the application after the execution of the application hot update behavior is obtained, where the second code file is all code files of the application.
When application security detection is performed on an application after application hot update, security detection needs to be performed from two aspects, namely, whether malicious code or abnormal code exists in the updated application code is detected, and whether some malicious behaviors can be executed by the updated application during operation is detected. In a possible implementation manner, in the case that it is determined that the application has the application hot update behavior, the terminal may first obtain all code files (second code files) of the application after the execution of the application hot update behavior, and perform code anomaly verification or code malicious verification on the second code files.
Since the code files except the dex file with suffix may be affected in the application hot update process, in order to more comprehensively detect the cloud application security of the application, the terminal needs to obtain all the code files (for example, dex, jar, so with suffix) of the updated application, and further perform local security detection on all the code files to determine whether malicious codes exist in the updated application code.
And 205, performing code exception checking on the second code file to obtain a code check result, wherein the code exception checking is used for checking whether an exception code exists in application codes of the application.
After all the code files (second code files) after the application hot update are obtained, the terminal can perform code exception checking on the second code files to check whether the application codes of the application have exception codes, and the exception codes in the application safety detection mainly refer to malicious codes, namely the application codes which threaten the data safety of the terminal, so as to obtain code checking results.
Alternatively, when the code exception checking is performed on the second code file, the code exception checking may be performed on the second code file using a code static analysis function, a malicious code feature value, or the like. Optionally, the terminal may also regularly pull the updated code anomaly verification policy from the cloud or the server, so as to improve the accuracy of identifying malicious codes or anomaly codes.
And step 206, acquiring a second application behavior in a target time period after the execution of the application hot update behavior under the condition that the code verification result indicates that the abnormal code does not exist in the second code file.
Some application code may not detect maliciousness, but may be run during application running to cause the application to perform some malicious behavior, such as automatically invoking user album data without user action. In order to further improve the running security of the application, in a possible implementation manner, when the terminal determines that the code verification result indicates that no abnormal code (malicious code) exists in the second code file, a second application behavior in a target period of time after the execution of the application hot update behavior may be obtained, so as to perform behavior verification on the second application behavior, so as to determine whether a malicious application behavior that threatens the data security of the terminal exists after the application hot update.
Wherein the target time period may be configured by a detection policy that applies 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 an application behavior that randomly selects N days within one month. The present embodiment is not limited thereto.
Optionally, when the second application behavior is acquired, the second application behavior under the behavior category may be selected according to a pre-configured behavior category. For example, if the behavior class is a payment class behavior, a second application behavior related to the payment service calling behavior is obtained, and if the behavior class is a positioning class behavior, a second application behavior related to the positioning service calling behavior is obtained, so that the purpose of behavior verification of the targeted second application behavior is achieved.
Optionally, if the code verification result indicates that the second code file has an abnormal code, the terminal can immediately remind the user that the application has a security risk, and no subsequent behavior verification of the application behavior is required to be executed, so as to avoid threatening the terminal data in the application running process.
Step 207, performing behavior verification on the second application behavior to obtain a behavior verification result, where the behavior verification is used to verify whether an abnormal behavior exists in the application running process after the application hot update behavior is executed.
After the second application behavior of the application in the target time period is obtained, the second application behavior can be subjected to behavior verification to verify whether abnormal behavior or malicious behavior exists in the application running process after the application is thermally updated.
In the embodiment, the file hash value and the file number of the first code file are acquired so as to judge whether the first code file is changed or not from two dimensions, so that the accuracy of judging the change of the first code file is improved, after the first code file is confirmed to be changed, whether the application has the identification behavior related to the application hot update behavior or not can be obtained, so that the influence of the application installation behavior of other changeable first code files on the judging accuracy is comprehensively confirmed, the accuracy of identifying the application hot update behavior is improved, and in addition, when the application safety is detected, the application safety can be detected from a static code layer, the application behavior is detected from a dynamic application behavior layer, the application safety is detected from multiple-angle multilayer faces, and the safety of the application operation is further improved.
In order to trigger the application security detection in time, the identification operation of the application hot update behavior is required to be triggered in time correspondingly. The developer analyzes the main stream application hot update mode, extracts key behaviors in the application hot update process, buries the API related to the key behaviors, and can identify the application hot update behaviors in time when the subsequent API with the buries is called.
Fig. 3 is a schematic flow chart of another method for applying security detection according to an embodiment of the present application. The embodiment of the application is described by taking the application of the method to the terminal as an example.
Illustratively, as shown in FIG. 3, the method 300 includes:
In step 301, in response to a call operation to 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.
Wherein the target interface is an API interface related to application hot update behavior. The method comprises the steps of extracting key behaviors in the application hot updating process in advance, determining an API (application program interface) related to the key behaviors as a target interface, burying points for the API through hook operation, and enabling a subsequent terminal to determine that a calling operation for the target interface is received and trigger an identification operation for the application hot updating behaviors when the API with the burying points is called.
For example, if the security software of the terminal performs application security detection on the application, after receiving a call operation on the target interface, the terminal may trigger the security software, and determine whether there is an application hot update behavior by the security software.
For example, the terminal may take a write operation on the dex suffix file, or a behavior of restarting activity during an application running period, restarting the entire application, and simultaneously, taking a dex file change as a hot update identification behavior, and embed a point on the related API for subsequent triggering of security software.
Step 302, under the condition that an identification operation of the application hot update behavior is triggered, a first application behavior indicated by a calling operation is obtained.
Whether the application hot update behavior is identified is comprehensively judged according to whether the identification behavior exists or not and whether the first code file is changed or not. Therefore, in one possible implementation manner, after the identification operation of the application hot update behavior is triggered, the terminal further obtains, according to the triggered API with the embedded point, a first application behavior executed by triggering the API, that is, obtains a first application behavior referred to by the calling operation, so as to further determine whether the first application behavior is the identification behavior.
Step 303, under the condition of triggering the identification operation of the application hot update behavior, performing file verification on the first code file of the application to obtain a file verification result.
The implementation of step 303 may refer to the above embodiments, which are not described herein.
Step 304, determining that the application has application hot update behavior when the file verification result indicates that the first code file is changed and the first application behavior has identification behavior.
Further, after the terminal acquires the first application behavior indicated by the calling operation, comparing the first application behavior with the preset identification behavior, and if the identification behavior exists in the first application behavior and the file verification result indicates that the first code file is changed, determining that the application may have application hot update behavior, and needing to perform application security detection on the application.
Alternatively, if the first code file is unchanged, but the API with the embedded point is called (i.e., the target interface is called), it indicates that the terminal may or may not have application hot update behavior. In order to further improve the accuracy of judging the application hot update behavior, in one possible implementation manner, the terminal may record the first application behavior, upload information such as the first application behavior and all code files (second code files) of the application to the cloud, analyze and judge whether the application hot update behavior exists by the cloud, if the application hot update behavior exists, send a feedback result to the terminal, and receive a judgment result fed back by the cloud by the terminal, and also need to perform application security detection on the application under the condition that the judgment result indicates that the application hot update behavior exists.
Optionally, before uploading the first application behavior and all the code files to the cloud, the prompt window is correspondingly displayed after user consent, and the information is uploaded to the cloud under the condition of user consent, so that the safety of the terminal data is further ensured.
Optionally, an application hot update detection policy may be deployed locally at the terminal, where the case where the file verification result indicates that the first code file is not changed, but there is a case where the target API is called, all code files (second code file) of the application may be acquired, and based on the second code file and the first application behavior, whether the application has an application hot update behavior may be analyzed. After determining that the application has application hot update behavior, application security detection is performed on the application.
In step 305, in case it is determined that the application has application hot update behavior, application security detection is performed on the application.
The implementation of step 305 may refer to the above embodiments, and this embodiment is not described herein.
In this embodiment, by monitoring the call condition of the target interface with the embedded point, it is determined whether to trigger the identification operation of the application hot update behavior, so that the triggering operation of the application hot update behavior can be triggered timely, the application hot update behavior can be identified timely, and the timeliness of application safety detection in the application hot update scene is improved.
Fig. 4 is a schematic flow chart of another method for applying security detection according to an embodiment of the present application.
The method comprises the following steps:
step 401, whether to trigger an API with a buried point.
The API with buried points is an API related to application hot update behavior. The terminal judges whether the identification operation of the application hot update behavior needs to be triggered or not by detecting whether the API with the embedded point is called or not. If an API with a buried point is triggered, step 402 may be performed.
Step 402, acquiring software behaviors according to the triggered API with the buried points.
And the terminal acquires the software behavior executed by the terminal according to the triggered API with the embedded point so as to judge whether the software behavior is the identification behavior related to the application hot update or not.
Step 403, obtaining a file hash value and the number of files of the dex file of the APP.
Meanwhile, the terminal can also acquire the file hash value and the number of the file with the suffix of the dex file related to the application hot update in the APP, and judge whether the dex file is changed or not according to whether the file hash value and the number of the file are consistent with the history record.
Step 404, whether the file hash value is consistent with the number of files and the history result.
If it is determined that the file hash value and the number of files are both consistent with the history result, step 410 is entered, and if it is determined that at least one of the file hash value or the number of files is inconsistent with the history result, step 405 is entered, where it is determined that a dex file of the APP is changed.
Step 405, determining that a change occurs in the dex file of the APP.
Step 406, whether the software behavior is an identification behavior.
After determining that the dex file of the APP changes, it may further be determined whether the software behavior is an identification behavior (the identification behavior is a key behavior involved in the application hot update process), and if the software behavior is the identification behavior, step 407 may be entered to determine that the APP has an application hot update behavior.
In step 407, it is determined that an application hot update behavior of the APP is detected.
In step 408, code malicious detection is performed on the APP.
After determining that the APP has the application hot update behavior, the terminal firstly acquires all code files of the APP, and detects code maliciousness of all code files.
Step 409, performing attack behavior detection on the application behavior of the APP.
Further, the terminal can also acquire the application behaviors within a certain period of time after the application heat is updated, and perform attack behavior detection on the application behaviors of the APP to determine whether malicious application behaviors exist.
Step 410, determining that the dex file of the APP is unchanged.
Under the condition that the hash value of the file and the number of the files are consistent with the historical record value, determining that the dex file of the APP is unchanged, but the API with the embedded point is triggered, recording the software behavior indicated by the API triggering the embedded point for further identifying whether the application hot update behavior exists, uploading the software behavior and the APP code file to the cloud, and detecting the application hot update behavior.
In step 411, the software behavior indicated by the API with the embedded point is recorded and triggered, and the software behavior and the APP code file are uploaded to the cloud, so as to determine whether there is a hot update behavior.
If the cloud feedback result indicates that there is an application hot update behavior, step 407 to step 408 are continuously executed. And carrying out application security detection on the application.
Taking an application hot update to update an APP dex file as an example, applying the application security detection method shown in the above embodiment, the application security detection process of APP can be summarized as follows:
1. Security software (which may be referred to as sec _ manager) buries and monitors the APP dex file.
1) Based on analysis of the main stream application hot update mode, the security software extracts key behaviors in the application hot update process as identification behaviors for judging whether application hot update occurs or not, and buries related APIs.
For example, the writing operation of the dex suffix file or the actions of restarting activity, restarting the whole application and simultaneously changing the dex file during the running of the application software are used as the identification actions of the application hot update, and the relevant APIs are buried for subsequent triggering of the security software.
2) The security software periodically detects and records the hash values of the dex files and the number of the dex files of all application software on the maintenance terminal.
2. A hot update is applied.
1) The APP on the terminal starts running, and loads and executes the corresponding dex file (denoted as dex 1).
2) The APP is remotely connected to its server and detects the presence of a new patch dex file (denoted dex 2).
3) APP downloads dex2 and performs the application hot update procedure. According to a specific hot updating mode, a new dex file (marked as dex 3) obtained by combining dex1 and dex2 is obtained, or dex2 is stored (in this case, the dex1 and the dex2 are simultaneously stored under the APP sandbox catalog).
3. The security software performs the detection.
1) In the application hot update process of the APP, the hot update identification behavior calls the related API with the buried point to trigger the security software.
2) The security software obtains corresponding software behaviors according to the buried points, further detects the hash value of the dex files of the APP and the number of the dex files, compares the hash value with the previously recorded results, and judges whether the dex files are changed or not.
If the dex file is changed, the identification behavior is assisted, and the security software judges APP hot update.
If the dex file is not changed, under the condition that the popup window obtains user consent, information such as embedded point behaviors, APP code files and the like is recorded and reported to a server, whether hot update behaviors occur or not is judged through cloud analysis, and judgment results are fed back to security software.
3) Under the condition of judging the hot update of the APP, the security software carries out local security detection on the updated APP code file (comprising dex, jar, so and the like) or uploads the updated APP code file to the cloud for analysis, and the maliciousness of the hot updated code is judged.
4) And the security software carries out targeted behavior security detection and log recording on the APP within a certain period of time after the APP is thermally updated. The log can be used for subsequent cloud or manual analysis to identify whether an attack behavior capable of evading the safety detection of the safety software occurs.
5) After the application hot update, the safety software timely informs the user of the application hot update behavior and detection result of the application, and prompts the user to actively trigger the safety detection later.
6) In case the user triggers actively, or by predefined application critical sensitive actions (e.g. payment), or according to predefined detection policies (periodically, or when the device is idle), the security software performs security detection of the application software code on the terminal and its application actions.
4. Security software policy updates.
1) The security software regularly pulls new strategies from the cloud or issues the strategies from the cloud. The strategy content comprises a recognition judging mode of the hot update behavior and a targeted detection strategy of the application behavior after hot update, so that the judging accuracy of the hot update behavior and the typical malicious behavior after hot update is improved.
Fig. 5 is a schematic structural diagram of an application security detection device according to an embodiment of the present application.
Illustratively, as shown in FIG. 5, the apparatus 500 includes:
The file verification module 501 is configured to perform file verification on a first code file of an application to obtain a file verification result when an identification operation for an application hot update behavior is triggered, 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 is changed;
A determining module 502, configured to determine that the application has the application hot update behavior when the file verification result indicates that the first code file is changed;
A security detection module 503, configured to perform application security detection on the application if it is determined that the application has the application hot update behavior.
Optionally, the file verification module 501 is further configured to:
Acquiring a file hash value corresponding to the first code file and the number of files corresponding to the first code file;
And performing file verification on the first code file based on the file hash value and the number of files.
Optionally, the file verification module 501 is further configured to:
Acquiring a historical hash value corresponding to the first code file and a historical quantity corresponding to the first code file, wherein the historical hash value and the historical quantity are file hash values and file quantities recorded in the process of carrying out application security detection on the application last time;
Determining that the first code file is unchanged when the historical hash value is matched with the file hash value and the number of files is matched with the historical number;
And determining that the first code file is changed under the condition that the historical hash value is not matched with the file hash value and/or the historical quantity is not matched with the file quantity.
Optionally, the determining module 502 is further configured to:
And under the condition that the file verification result indicates that the first code file is changed and an identification behavior exists, determining that the application has the application hot update behavior, wherein the identification behavior is an application behavior involved in the execution process of the application hot update behavior.
Optionally, the apparatus further comprises:
The triggering module is used for responding to the calling operation of a target interface, triggering the identification operation of the application hot update behavior, wherein the target interface is an interface related to the application hot update behavior;
the first acquisition module is used for acquiring a first application behavior indicated by the calling operation under the condition of triggering an identification operation of the application hot update behavior;
the determining module 502 is further configured to:
and under the condition that the file verification result indicates that the first code file is changed and the identification behavior exists in the first application behavior, determining that the application has the application hot update behavior.
Optionally, the apparatus further comprises:
the second acquisition module is used for acquiring second code files of the application when the file verification result indicates that the first code files are not changed, wherein the second code files are all code files of the application;
And the analysis module is used for analyzing whether the application has the application hot update behavior or not based on the second code file and the first application behavior.
Optionally, the security detection module 503 is further configured to:
Acquiring a second code file of the application after the application hot update behavior is executed, wherein the second code file is all code files of the application;
And carrying out code exception checking on the second code file to obtain a code check result, wherein the code exception checking is used for checking whether an exception code exists in the application code of the application.
Optionally, the security detection module 503 is further configured to:
Acquiring a second application behavior in a target time period after the execution of the application hot update behavior under the condition that the code verification result indicates that the abnormal code does not exist in the second code file;
and performing behavior verification on the second application behavior to obtain a behavior verification result, wherein the behavior verification is used for verifying whether abnormal behavior exists in the application running process after the application hot update behavior is executed.
In summary, the application provides an application security detection method, which can perform file verification on a first code file related to an application hot update behavior in an application under the condition of triggering an identification operation of the application hot update behavior, and determine that the application hot update behavior is detected and perform application hot update on the application under the condition that a file verification result indicates that the first code file has a change. The method provides a feasible way for automatically triggering the application after executing the application hot update behavior to perform application safety detection, can bring the application hot update behavior into the range of automatically triggering the application safety detection, and timely performs the application safety detection on the application after executing the application hot update behavior, thereby ensuring the application safety in the application running process.
Fig. 6 is a schematic structural diagram of a terminal according to an embodiment of the present application.
By way of example, as shown in FIG. 6, a terminal 600 in the present application may include one or more of a processor 610 and a memory 620.
Processor 610 may include one or more processing cores. The processor 610 connects various parts within the overall terminal 600 using various interfaces and lines, performs various functions of the terminal 700 and processes data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 620, and invoking data stored in the memory 620. Alternatively, the processor 610 may be implemented in at least one hardware form of digital signal Processing (DIGITAL SIGNAL Processing, DSP), field-Programmable gate array (Field-Programmable GATE ARRAY, FPGA), programmable logic array (Programmable Logic Array, PLA). The processor 710 may integrate one or a combination of several of a central processing unit (Central Processing Unit, CPU), an image processor (Graphics Processing Unit, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like, the GPU is used for rendering and drawing contents required to be displayed by the display screen, and the modem is used for processing wireless communication. It will be appreciated that the modem may not be integrated into the processor 610 and may be implemented solely by a baseband chip.
The Memory 620 may include a random access Memory (Random Access Memory, RAM) or a Read-Only Memory (ROM). Optionally, the memory 720 includes a non-transitory computer-readable medium (non-transitory computer-readable storage medium). Memory 620 may be used to store instructions, programs, code sets, or instruction sets. The memory 620 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, which may be an Android (Android) system (including a system developed based on the Android system), an IOS system developed by apple corporation (including a system developed based on the IOS system), or other systems, instructions for implementing at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-described various method embodiments, and the like. The storage data area may also store data created by the terminal 600 in use (e.g., phonebook, audio-video data, chat-record data), etc.
In addition, those skilled in the art will appreciate that the structure of the terminal 600 illustrated in the above-described figures does not constitute a limitation of the terminal 600, and the terminal may include more or less components than illustrated, or may combine certain components, or may have a different arrangement of components. For example, the terminal 600 further includes a radio frequency circuit, a shooting component, a sensor, an audio circuit, a wireless fidelity (WIRELESS FIDELITY, WIFI) component, a power supply, a bluetooth component, and the like, which are not described herein.
The terminal provided by the embodiment of the application can be a chip, a component or a module, and the terminal can comprise a processor and a memory which are connected, wherein the memory is used for storing instructions, and when the terminal runs, the processor can call and execute the instructions so that the chip can execute any application security detection method described above.
The present embodiment provides a computer readable storage medium having instructions stored therein which, when executed on a computer or processor, cause the computer or processor to perform any of the application security detection methods described above.
The present embodiment also provides a computer program product comprising instructions which, when run on a computer or processor, cause the computer or processor to perform the above-described related steps to implement any of the application security detection methods described above.
The terminal, the computer readable storage medium, the computer program product or the chip containing the instructions provided in this embodiment are used to execute the corresponding application security detection method provided above, so that the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method provided above, and are not repeated herein.
It will be appreciated by those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the application is subject to the protection scope of the claims.
Claims (12)
1. An application security detection method, the method comprising:
Under the condition of triggering the identification operation of the application hot update behavior, performing file verification on a first code file of an 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 for verifying whether the first code file is changed or not;
determining that the application has the application hot update behavior under the condition that the file verification result indicates that the first code file is changed;
and carrying out application security detection on the application under the condition that the application is determined to have the application hot update behavior.
2. The method of claim 1, wherein the performing file verification on the first code file of the application to obtain a file verification result includes:
Acquiring a file hash value corresponding to the first code file and the number of files corresponding to the first code file;
And performing file verification on the first code file based on the file hash value and the number of files.
3. The method of claim 2, wherein the performing file verification on the first code file based on the file hash value and the number of files comprises:
Acquiring a historical hash value corresponding to the first code file and a historical quantity corresponding to the first code file, wherein the historical hash value and the historical quantity are file hash values and file quantities recorded in the process of carrying out application security detection on the application last time;
Determining that the first code file is unchanged when the historical hash value is matched with the file hash value and the number of files is matched with the historical number;
And determining that the first code file is changed under the condition that the historical hash value is not matched with the file hash value and/or the historical quantity is not matched with the file quantity.
4. A method according to any one of claims 1 to 3, wherein said determining that said application has said application hot update behaviour in the event that said file verification result indicates a change to said first code file comprises:
And under the condition that the file verification result indicates that the first code file is changed and an identification behavior exists, determining that the application has the application hot update behavior, wherein the identification behavior is an application behavior involved in the execution process of the application hot update behavior.
5. The method according to claim 4, wherein the method further comprises:
Triggering an identification operation of the application hot update behavior in response to a call operation of a target interface, wherein the target interface is an interface related to the application hot update behavior;
Under the condition of triggering the identification operation of the application hot update behavior, acquiring a first application behavior indicated by the calling operation;
and when the file verification result indicates that the first code file is changed and the identification behavior exists, determining that the application has the application hot update behavior comprises the following steps:
and under the condition that the file verification result indicates that the first code file is changed and the identification behavior exists in the first application behavior, determining that the application has the application hot update behavior.
6. The method of claim 5, wherein the method further comprises:
Acquiring a second code file of the application under the condition that the file verification result indicates that the first code file is not changed, wherein the second code file is all code files of the application;
Based on the second code file and the first application behavior, analyzing whether the application has the application hot update behavior.
7. A method according to any one of claims 1 to 3, wherein said applying security detection to said application comprises:
Acquiring a second code file of the application after the application hot update behavior is executed, wherein the second code file is all code files of the application;
And carrying out code exception checking on the second code file to obtain a code check result, wherein the code exception checking is used for checking whether an exception code exists in the application code of the application.
8. The method of claim 6, wherein the applying security detection to the application further comprises:
Acquiring a second application behavior in a target time period after the execution of the application hot update behavior under the condition that the code verification result indicates that the abnormal code does not exist in the second code file;
and performing behavior verification on the second application behavior to obtain a behavior verification result, wherein the behavior verification is used for verifying whether abnormal behavior exists in the application running process after the application hot update behavior is executed.
9. An application security detection device, the device comprising:
The file verification module is used for carrying out file verification on a first code file of an application under the condition of triggering the identification operation of the application hot update behavior 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 for verifying whether the first code file is changed or not;
the determining module is used for determining that the application has the application hot update behavior under the condition that the file verification result indicates that the first code file is changed;
And the security detection module is used for carrying out application security detection on the application under the condition that the application is determined to have the application hot update behavior.
10. A terminal comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein execution of the computer program by the processor causes the terminal to perform the application security detection method according to any one of claims 1 to 8.
11. A computer readable storage medium having instructions stored therein which, when executed on a computer or processor, cause the computer or processor to perform the application security detection method of any of claims 1 to 8.
12. A computer program product comprising a computer program, characterized in that the computer program, when executed by a processor, implements the application security detection method of any of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311023367.0A CN119494096B (en) | 2023-08-14 | 2023-08-14 | Application security detection methods, devices, terminals, storage media and program products |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311023367.0A CN119494096B (en) | 2023-08-14 | 2023-08-14 | Application security detection methods, devices, terminals, storage media and program products |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN119494096A true CN119494096A (en) | 2025-02-21 |
| CN119494096B CN119494096B (en) | 2025-10-14 |
Family
ID=94621648
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311023367.0A Active CN119494096B (en) | 2023-08-14 | 2023-08-14 | Application security detection methods, devices, terminals, storage media and program products |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119494096B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040107416A1 (en) * | 2002-12-02 | 2004-06-03 | Microsoft Corporation | Patching of in-use functions on a running computer system |
| CN107301105A (en) * | 2016-04-14 | 2017-10-27 | 华为技术有限公司 | Verify the method and device of hot patch or dynamic base |
| US20210026947A1 (en) * | 2019-07-22 | 2021-01-28 | Cloud Linux Software Inc. | Intrusion detection and prevention for unknown software vulnerabilities using live patching |
| CN112637307A (en) * | 2020-12-16 | 2021-04-09 | 平安消费金融有限公司 | File updating method, system, computer device and storage medium |
-
2023
- 2023-08-14 CN CN202311023367.0A patent/CN119494096B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040107416A1 (en) * | 2002-12-02 | 2004-06-03 | Microsoft Corporation | Patching of in-use functions on a running computer system |
| CN107301105A (en) * | 2016-04-14 | 2017-10-27 | 华为技术有限公司 | Verify the method and device of hot patch or dynamic base |
| US20210026947A1 (en) * | 2019-07-22 | 2021-01-28 | Cloud Linux Software Inc. | Intrusion detection and prevention for unknown software vulnerabilities using live patching |
| CN112637307A (en) * | 2020-12-16 | 2021-04-09 | 平安消费金融有限公司 | File updating method, system, computer device and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 丛丽晖;何国强;夏秀峰;: "PDM中基于cuckoo filter的数据完整性校验算法设计与实现", 计算机应用与软件, no. 02, 15 February 2017 (2017-02-15), pages 123 - 127 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN119494096B (en) | 2025-10-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11687653B2 (en) | Methods and apparatus for identifying and removing malicious applications | |
| CN106796524B (en) | Method, apparatus and electronic device for recording application configuration information | |
| CN107783795B (en) | Application startup method, apparatus, computer device and storage medium | |
| CN104462978B (en) | A kind of method and apparatus of application program rights management | |
| CN104751049B (en) | A kind of application program installation method and mobile terminal | |
| CN104268476B (en) | A kind of method for running application program | |
| US11503053B2 (en) | Security management of an autonomous vehicle | |
| CN104462980A (en) | Authority management method, device and system of application programs and mobile terminal | |
| CN104573435A (en) | Method for terminal authority management and terminal | |
| US8701195B2 (en) | Method for antivirus in a mobile device by using a mobile storage and a system thereof | |
| CN106355081A (en) | Android program start verification method and device | |
| CN112653655A (en) | Automobile safety communication control method and device, computer equipment and storage medium | |
| US20120096565A1 (en) | Device, method and system to prevent tampering with network content | |
| CN112241529B (en) | Malicious code detection method, device, storage medium and computer equipment | |
| CN111191226A (en) | Method, device, equipment and storage medium for determining program by using privilege-offering vulnerability | |
| CN103971056A (en) | Method and device for preventing application program in operating system from being uninstalled | |
| CN113157543A (en) | Credibility measuring method and device, server and computer readable storage medium | |
| CN113177200A (en) | Application package management method and device, computer equipment and storage medium | |
| CN108268272A (en) | Patch update method and device based on WSUS | |
| CN112395602B (en) | Processing method, device and system for static security feature database | |
| CN106302531B (en) | Safety protection method, device and terminal equipment | |
| CN111158729A (en) | System upgrading method, device, equipment and storage medium | |
| CN109325363A (en) | Management method, device, computer equipment and the storage medium of authority information | |
| CN119494096B (en) | Application security detection methods, devices, terminals, storage media and program products | |
| CN109784051B (en) | Information security protection methods, devices and equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |