Abnormal behavior detection method and device, equipment, medium and product

By obtaining the application's global configuration file and interface call records, as well as data interception of the operating system simulator, identifying the application's abnormal behavior, solving the problem of insufficient detection accuracy in the prior art, and achieving more efficient and accurate abnormal behavior detection.

CN120541831APending Publication Date: 2025-08-26BEIJING BANGCLE TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410202728.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-02-23
Publication Date
2025-08-26

AI Technical Summary

Technical Problem

In the prior art, how to ensure the accuracy of the abnormal behavior recognition results of the application is an urgent problem.

Method used

By obtaining the global configuration file of the application package and the interface call record that specifies the operation behavior as static characteristics, and combining the data interception of the target application in the operating system simulator as dynamic characteristics, identifying whether the application has abnormal behavior.

Benefits of technology

Faster and more accurate abnormal behavior detection is achieved, reducing manual intervention, improving detection efficiency, and fully identifying various types of malicious behavior.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120541831A_ABST
    Figure CN120541831A_ABST
Patent Text Reader

Abstract

The embodiment of the invention discloses an abnormal behavior detection method and device, equipment, a medium and a product, and the method comprises the steps: obtaining a global configuration file of an application package from a target application, and specifying a calling record of an interface triggered and called by an operation behavior as a static feature; data interception is carried out on a specified target in the target application program running in the operating system simulator, and intercepted data are obtained and serve as dynamic features; and based on the static characteristics and the dynamic characteristics, identifying whether the target application program has an abnormal behavior or not. Therefore, an automatic detection mode is used for replacing a manual participation detection scheme in the prior art, the detection efficiency is improved, manual intervention is reduced, and quicker detection is realized. Moreover, when abnormal behavior detection is carried out, static features and dynamic features are comprehensively considered, and multi-dimensional factors are considered, so that various types of malicious behaviors can be more comprehensively and accurately identified.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This specification relates to the field of computer software technology, and in particular to an abnormal behavior detection method, device, electronic device, computer-readable storage medium, and computer program product. Background Art

[0002] With the rapid development of the Internet, the number of malware has reached an unprecedented peak, and malware is posing a serious threat to global network security.

[0003] In this context, identifying whether published applications (Applications, Apps), such as Android applications, have abnormal behavior is essential. Based on the identification results, we can determine whether the application has abnormal behavior and take effective measures to avoid potential security risks and prevent losses to users after the application is released.

[0004] Existing technologies can already identify abnormal behavior based on collected application data using abnormal behavior recognition algorithms such as rule engines or deep learning models. However, ensuring the accuracy of abnormal behavior recognition results is a pressing issue in existing technologies. Summary of the Invention

[0005] The embodiments of this specification provide an abnormal behavior detection method to solve the problem existing in the prior art of how to ensure the accuracy of abnormal behavior identification results for an application program.

[0006] The embodiments of this specification also provide an abnormal behavior detection device, an electronic device, a computer-readable storage medium, and a computer program product.

[0007] To solve the above technical problems, the embodiments of this specification are implemented as follows:

[0008] First, a method for detecting abnormal behavior is proposed, including:

[0009] Obtaining a global configuration file from an application package of a target application and a call record of an interface triggered by a specified operation behavior as static features;

[0010] By intercepting data of a designated target in the target application running in the operating system simulator, the intercepted data is obtained as a dynamic feature; the designated target includes a class method and / or a class constructor;

[0011] Based on the static features and the dynamic features, it is identified whether the target application has abnormal behavior.

[0012] In a second aspect, an abnormal behavior detection device is proposed, comprising:

[0013] A first acquisition module is used to acquire, as static features, a global configuration file of an application package of a target application and a call record of an interface triggered by a specified operation behavior;

[0014] a second acquisition module, configured to intercept data of a designated target in the target application running in the operating system simulator, and obtain the intercepted data as a dynamic feature; the designated target includes a class method and / or a class constructor;

[0015] An identification module is used to identify whether the target application has abnormal behavior based on the static features and the dynamic features.

[0016] In a third aspect, an electronic device is provided, comprising:

[0017] processor; and

[0018] A memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the steps of the abnormal behavior detection method according to the first aspect.

[0019] In a fourth aspect, a computer-readable storage medium is proposed, which stores one or more programs. When the one or more programs are executed by an electronic device including multiple applications, the electronic device performs the steps of the abnormal behavior detection method described in the first aspect.

[0020] In a fifth aspect, a computer program product is proposed, which stores instructions, and when the instructions are executed by a computer, the computer implements the steps of the abnormal behavior detection method described in any one of claims 1 to 5.

[0021] It can be seen from the technical solutions provided by the above embodiments of this specification that, by obtaining the global configuration file of the application package from the target application and the call record of the interface triggered by the specified operation behavior as static features; by intercepting data of the specified target in the target application running in the operating system simulator, the intercepted data is obtained as dynamic features; based on the static features and the dynamic features, it is identified whether the target application has abnormal behavior. Thus, the manual participation detection scheme in the existing technology is replaced by automatic detection, which improves detection efficiency, reduces manual intervention, and achieves faster detection. Moreover, when performing abnormal behavior detection, static features and dynamic features are comprehensively considered, and multi-dimensional factors are considered to more comprehensively and accurately identify various types of malicious behaviors. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0023] Figure 1 This is a schematic diagram of the steps of an abnormal behavior detection method proposed in this application.

[0024] Figure 2 This is a schematic diagram of the abnormal behavior detection process of an Android application software provided by this application.

[0025] Figure 3 This is a schematic diagram of the steps of Android static analysis provided by this application.

[0026] Figure 4 This is a schematic diagram of the specific steps of Android dynamic analysis provided by this application.

[0027] Figure 5 It is a structural diagram of the abnormal behavior detection device provided by this application.

[0028] Figure 6 It is a structural diagram of the electronic device provided in this application. DETAILED DESCRIPTION

[0029] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0030] Considering the continuous emergence of new malicious behaviors and attack methods, existing methods are difficult to keep up with the evolution of malicious behaviors. Traditional malicious behavior detection methods require a lot of manual intervention and manual analysis, resulting in low detection efficiency. In view of this, the present application proposes an abnormal behavior detection solution, which obtains the global configuration file of the application package from the target application and the call record of the interface triggered by the specified operation behavior as static features; intercepts the data of the specified target in the target application running in the operating system simulator, and obtains the intercepted data as dynamic features; based on the static features and the dynamic features, it identifies whether the target application has abnormal behavior. Thus, the manual participation detection solution in the existing technology is replaced by automatic detection, which improves detection efficiency, reduces manual intervention, and achieves faster detection. Moreover, when performing abnormal behavior detection, static features and dynamic features are comprehensively considered, and multi-dimensional factors are considered to more comprehensively and accurately identify various types of malicious behaviors.

[0031] The abnormal behavior detection scheme involved in this application is described in detail through the following examples. It should be noted that the following examples are only some examples listed to facilitate understanding of the scheme and do not limit the scope of protection of this application.

[0032] Example 1

[0033] Figure 1 This is a schematic diagram of the steps of an abnormal behavior detection method proposed in this application. It should be understood that the execution subject of this method can be an abnormal behavior detection device, which can be a software module or a hardware device. Taking a software module as an example, it can be an application software installed on an electronic device with the following abnormal behavior detection functions, or an abnormal behavior detection module integrated into an existing processing module with the following abnormal behavior detection functions. Taking a hardware device as an example, it can be a computing and processing device with the following abnormal behavior detection functions, such as a computer, a personal digital assistant (PDA), a smart wearable device, and other electronic devices with computing and data processing capabilities. In specific implementation, the abnormal behavior detection device can be an ordinary server, a cloud server, etc.

[0034] Reference Figure 1 As shown, the abnormal behavior detection method may include the following steps:

[0035] Step 102: Obtain a global configuration file from the application package of the target application and a call record of an interface triggered by a specified operation behavior as static features.

[0036] Considering that the global configuration file stores the app's main initialization and global information, and that the four major components that carry Android software developer logic must be registered in the global configuration file, obtaining the global configuration file is equivalent to obtaining the system's component index. Furthermore, considering that any complete application software will contain hundreds of thousands or millions of lines of code, although custom variables and functions in the final source code files are generally obfuscated, by establishing query rules for calls to the unobfuscated application programming interface (API) for specified operations, and obtaining call records for key APIs, it is possible to detect common privilege escalation attacks and other behaviors in applications from a code perspective.

[0037] Among them, the four major components in the global configuration can include: Activity, service component Service, broadcast receiver BroadcastReceivers and content provider ContentProvider.

[0038] When obtaining the global configuration file and the call record of the specified operation behavior, they can be obtained according to different file processing methods.

[0039] Optionally, when obtaining the global configuration file from the application package of the target application in step 102 , the global configuration file may be obtained by decompiling the application package.

[0040] Decompilation is the process of converting compiled machine code or bytecode (such as Java bytecode) back into a high-level programming language (such as source code). The goal of decompilation is to understand and analyze the compiled code, potentially modifying, studying, or reverse engineering it. Decompilers are the tools used to perform this process. They attempt to convert binary code into a form that resembles the original source code, allowing developers to better understand the program's behavior and logic.

[0041] In practice, ApkTool can be used to decompile the Android application package (.apk file) to obtain the gai application's global configuration file, AndroidManifest.xml. After obtaining the global configuration file, it can be further parsed to obtain access permissions and the usage of the four major components, thereby extracting static features related to the global configuration.

[0042] Optionally, in step 102, when obtaining the call record of the interface triggered by the specified operation behavior, the virtual machine executable file obtained from the application package can be converted into a source code file; based on the information of the specified behavior operation, the call record of the interface triggered by the specified behavior operation is obtained from the source code file.

[0043] In a specific implementation, the installation package file can be decompressed and converted using a decompression tool to obtain an executable file. The executable file is then decompiled into a source code file. The corresponding function call is then searched for in the source code file based on keywords, and a call record of the called application programming interface is obtained. Static features related to the source code file are then extracted from the call record.

[0044] In this way, static features related to the global configuration and static features related to the source code files can be obtained through the obtained global configuration file and call records, and these features can be used together as static features required for subsequent detection.

[0045] Step 104: intercepting data of a designated target in the target application running in the operating system simulator to obtain intercepted data as a dynamic feature; the designated target includes a class method and / or a class constructor.

[0046] In a specific implementation, the dynamic hook framework can be built to monitor the key functions called when the operation behavior triggered by the simulation tool occurs, intercept these functions, and then extract dynamic features from the intercepted key functions. In other words, after building the dynamic hook framework and installing the hook program, the target application is installed into the simulation tool, and the simulation tool is triggered to simulate the user's interaction with the application. Based on the installed hook program, the key functions called when the operation behavior occurs are monitored, and dynamic features are obtained based on the call records of these key functions.

[0047] Optionally, in step 104, when intercepting data of a specified target in the target application running in the operating system simulator, the method of simulating user behavior can be adopted to interact with the running target application; during the process of the interaction, data is intercepted for the specified target of the target application.

[0048] Optionally, the class method includes at least one of the following: network access class, file access class, encryption and decryption class, and system setting class;

[0049] The class constructor includes at least one of the following: a network access class constructor, a file access class constructor, an encryption and decryption class constructor, and a system setting class constructor.

[0050] Optionally, the key function is an operation function related to at least one operation type of network access, file access, encryption and decryption, and system settings; the method call of the operation function is hooked and monitored through the corresponding hook function in the hook program.

[0051] Step 106: Based on the static features and the dynamic features, identify whether the target application has abnormal behavior.

[0052] In a specific implementation, abnormal behavior in the target application can be determined based on whether the return value of the information identifier carried by the static feature and / or the information identifier carried by the dynamic feature changes. When the return value of the information identifier carried by the static feature changes, the target application is determined to have abnormal behavior; when the return value of the information identifier carried by the dynamic feature changes, the target application is determined to have an anomaly; and when the return value of the information identifier carried by the static feature and the return value of the information identifier carried by the dynamic feature change, the target application is determined to have an anomaly. Thus, the static and / or dynamic features can be used to identify abnormal behavior in the target application, improving the accuracy and comprehensiveness of abnormal behavior identification. Furthermore, the type of abnormal attack behavior can be identified based on a trained anomaly classifier. The anomaly classifier can classify various attack behaviors, such as injection attack types, sensitive information leakage types, remote code execution types, Trojan virus types, static attack types, dynamic attack types, and so on. In a specific implementation, the identified abnormal behavior can be further classified and identified. This allows identification of abnormal behavior in the target application and the attack category to which the abnormal behavior belongs. Further improving recognition accuracy will facilitate the blocking and analysis of abnormal behaviors and target applications.

[0053] Taking static features as an example, suppose an attacker attacks the Activity / WebView component permission permission: true / false. When monitoring component layer information, once it is found that the component is called and there are signs of tampering, for example, the original permission is set to false, and it becomes true after tampering, then it will trigger the acquisition of static features. If the static feature remains permission: false, it is determined that there is no abnormal behavior. If the static feature changes to permission: true, it is determined that abnormal behavior has occurred and it will be banned.

[0054] Taking dynamic features as an example, when an attacker wants to perform a HOOK attack or dynamic analysis, the application kernel layer data is dynamically changing. At this time, monitoring the entry function address of the kernel layer can determine the attacker's behavior. For example, the entry function address of a normal kernel function call is 0x00, but if the attacker calls the kernel function through HOOK technology, the entry function address is not equal to 0x00. This feature can be used to determine whether the behavior is abnormal.

[0055] The above identification and determination methods are provided as examples for ease of understanding. During the specific identification and determination process, analysis and identification can be performed based on the return values ​​of the specific information identifiers carried by the static and / or dynamic features. The return values ​​of the information identifiers of the static and / or dynamic features can be predefined or agreed upon in a certain protocol. If the return values ​​differ from the predefined or agreed upon return values, an anomaly is determined to exist in the target application.

[0056] The following combination Figure 2 And detailed examples are given to introduce the abnormal behavior detection solution of this application.

[0057] Reference Figure 2 The figure shows a flow chart of abnormal behavior detection for an Android application software provided by this application.

[0058] Step 202: Build a data collection architecture.

[0059] To address the highly complex and dynamic data collection challenges within an app cluster, a real-time data collection architecture can be built to ensure that the performance of the app cluster is not impacted. This architecture collects multi-dimensional data, including service information, status information, behavior trajectory, and traffic information, from each app in real time to provide comprehensive data.

[0060] Step 204: Obtain service information.

[0061] When collecting data, obtain service information in the APP cluster, including identifying and recording the services provided by each APP for subsequent analysis and monitoring.

[0062] Step 206: Obtain a detection model based on deep reinforcement learning training.

[0063] Use multi-dimensional data, including service associations, attack type characteristics, and app behavior data, to train anomaly detection and malicious attack classifiers.

[0064] Step 208: Perform anomaly detection and malicious type identification based on the detection model.

[0065] For apps associated with services in an app cluster, an anomaly monitoring method was designed to detect abnormal behavior or malicious activity, helping to ensure secure data sharing and transmission within the app cluster. Furthermore, an attack type classifier was designed to categorize different attack types based on attack type characteristics and app behavior data. This classifier considers multiple factors, such as service characteristics, attack location, traffic flow, and frequency information, to achieve accurate attack identification.

[0066] Step 210: Secure data sharing and transmission.

[0067] The abnormal behavior detection solution of this application can ensure that data in the APP cluster can be shared and transmitted in a safe environment. Through the above-mentioned abnormal monitoring and classification methods, the data in the APP cluster can be protected from the threat of malicious attacks, thereby achieving secure data sharing and transmission.

[0068] Among them, when obtaining APP behavior information, dynamic analysis and static analysis methods can be used to dynamically collect real-time behavior information data of running APP. For Android application software, if you want to perform specific abnormal behavior, it will definitely trigger related configurations or function calls. Although the skills of abnormal behavior developers vary, and the methods and purposes of implementing abnormal behaviors are ever-changing, only by understanding the application software and determining the breakthrough points can you operate in a targeted manner and then conduct behavioral analysis. Although the Android application software installation package .apk file is readily available, it is not practical to directly perform behavioral analysis on a software that has undergone the compilation, packaging, and signature optimization process. Therefore, this application performs static analysis and dynamic analysis on the APP, and then extracts the behavioral characteristics of the Android application software for subsequent research and implementation of abnormal behavior detection.

[0069] <Static Analysis Phase>

[0070] Android applications run within the Dalvik virtual machine, making decompilation and analysis of .apk files easy. First, the .apk file is actually a compressed zip file. Most commercially available decompression software can decompress it, revealing all the files within, including static resource files like res and assets, as well as libraries. Secondly, Java must be compiled through the Dalvik VM to avoid generating binary code. All source code files are compiled into a single .dex file by the Dalvik VM, making it possible to retrieve the source code using decompilation tools like apktool.

[0071] Reference Figure 3 The following is a schematic diagram of the steps for Android static analysis. The specific steps are:

[0072] Step 302: Read the installation package of the Android application software.

[0073] Step 304: Use the ApkTool tool to decompile the installation package of the Android application software, that is, the .apk file, to obtain the configuration file AndroidManifest.xml in the root directory of the sample project.

[0074] Step 306: Parse the configuration file to obtain the access permissions and usage of the four major components.

[0075] Step 308: decompress the .apk file using a decompression tool to obtain an executable file of the Dalvik virtual machine;

[0076] Step 310: Use the Dex2jar tool to operate the .dex file and convert the .dex file into a Java .class file;

[0077] Step 312: Use JAD to decompile all Class files into Java source code files.

[0078] Step 314: Check the specific details of the .java program, find relevant function keywords based on sensitive behavior operations, and obtain the Android system API call status.

[0079] Step 316: After obtaining the Android application software resources, configuration and source code files, extract static behavior features.

[0080] <Dynamic Analysis Phase>

[0081] Hooking is a crucial technique for both normal and abnormal behavior. Its essence is to hijack function calls. It operates at two levels: Java and native. This article focuses solely on the Java level. By injecting the Android platform's virtual machine and using Java reflection, function calls are altered, achieving Java function redirection.

[0082] Xposed is a renowned Java-based hook framework. Developers can use custom hook implementation modules to modify the behavior of Android applications without modifying the source code. These modules modify the application's behavior in memory, without modifying the original APK. Because Xposed uses a plugin mechanism, modules can be compatible with different versions of the framework and ROMs. Developers simply install the module on the device and reboot.

[0083] Another key consideration in dynamic analysis is the coverage of runtime behavior hooks. For many Android anomalous behavior attacks, simply installing the app into the runtime environment won't trigger the anomalous payload. Triggering the attack requires interaction between the user and the app, and even requires some anomalous behavior. To effectively test each behavioral path of the target app, this project leverages Monkey to simulate user actions like touch screens, swipes, keystrokes, and clicks.

[0084] Therefore, using the above tools, automatic dynamic abnormal behavior analysis can be performed, and the process is as follows: Figure 4 As shown, the specific steps of Android dynamic analysis are:

[0085] Step 402: Build the Xposed framework in the test device and install the Hook program module.

[0086] Specifically, build the Xposed framework on the Android emulator, load the Hook program module into Xposed, and complete the preparation work.

[0087] Step 404: Install the apk file into the test real machine environment.

[0088] Install the Android application for experimentation on the emulator.

[0089] Step 406: Use Monkey to randomly trigger click, slide, key press and other operations to simulate the user's interaction with the application.

[0090] Step 408: Monitor application behavior through the background module.

[0091] Step 410: Record calls to key functions of the Android application process.

[0092] Through the Hook module loaded in the background, the running behavior of the APP can be monitored and the call records of key functions can be saved locally.

[0093] After the above steps, we can get the calling status of key functions during the Android APP runtime, and further perform dynamic analysis.

[0094] The dynamic behavior analysis section uses a computer program to control the mobile phone to capture behavioral information, and the computer automatically simulates the user's interaction with the Android software to be tested. To facilitate the analysis of specific dynamic behaviors, this project saves the hooked information to a local log file. Based on the dynamic behavior analysis tool designed above, a program is written to implement a non-user interface hook software to monitor the software to be tested. The specific hooking method is as follows:

[0095] (1) Network access

[0096] Hook the constructors of InetSocketAddress, DatagramSocket, ServerSocket and other classes through the findAndHookConstructor() function.

[0097] Use the findAndHookMethodf() function to hook calls to related methods, including the send(), createSocket(), and bind() methods of java.net.DatagramSocket, the loadUrl() and postUrl() methods of android.webkit.WebView, the write() method of java.io.OutputStream, the open() method of java.nio.channels.SocketChannel, the startupSocket(), connect(), and bind() methods of java.net.Socket, the openConnection() method of java.net.URL, and the execute() method of org.apache.http.impl.client.AbstractHttpClient.

[0098] (2) File access

[0099] Hook the constructors of FileInputStream.class, File.class, FileOutputStream.class and other classes and the openFilelnput() method of android.content.Context.

[0100] (3) Encryption and decryption

[0101] Hook the getInstance() method of java.security.KeyPairGenerator, java.security.KeyGenerator and other classes, the init() method of java.security.KeyGenerator, the generatePrivate() method of java.security.KeyFactory, and the getInstance() method, doFinal() method, and init() method of javax.crypto.Cipher.

[0102] (4) System Settings

[0103] Hook methods such as putLong(), putFloat(), putString(), and putConfiguration() of android.provider.Settings.System.

[0104] After implementing the tool, you can begin dynamic behavior analysis. First, configure the mobile environment. Install the downloaded Xposed framework on a rooted Android phone and install the implemented hook software. Then, install and run the Android software to be tested using the adb commands "adb install tagret.apk" and "adb shell am start—ntarget.package / target.package.MainActivity." "target.package" is the package name of the target software, and "MainActivity" is the name of the main program class, both of which can be found in the static analysis configuration file. Simultaneously, start Monkey and execute the command "adb shell monkey -p target.package -s 400 --ignore—timeouts --ignore-crashes 5000." The "--ignore—timeouts --ignore-crashes" parameters ignore timeouts and program crashes, and the "5000" parameter generates 5000 random events. Finally, log the hooked dynamic behavior to a local log file.

[0105] After obtaining the Android application's runtime network access, file access, encryption and decryption, and system configuration information through the above steps, further review can be performed: based on the static behavior analysis data, dynamic behavior analysis can be used to determine whether the Android software behavior under test is abnormal. The specific determination process can be found in the description and examples related to step 106 above.

[0106] Optionally, when using static features and dynamic features to detect abnormal behavior of an application, the static features and the dynamic features may be subjected to feature preprocessing, including: combining the static features and the dynamic features to obtain a mixed feature of the target application;

[0107] Then, a preset anomaly detection model is input for analysis, and a detection result is output, which includes: inputting the mixed feature into a preset anomaly classifier for analysis, and outputting a classification result.

[0108] For example, suppose the extracted static feature is A and the dynamic feature is B. The features are stored in the rule {A, B} to obtain a combined feature. After combining, a new rule can be formed, named C. Subsequently, if a traffic request hits rule C, an alarm and ban will be issued.

[0109] In other words, static and dynamic features each have multiple types. When static feature A of one type is combined with dynamic feature B of another type, a new combined feature C can be formed, which serves as the judgment rule. When the return values ​​of the information identifiers carried by static features A and B of the target application change, that is, when they do not match the expected values, the target application is determined to have experienced abnormal behavior.

[0110] In the present application scheme, the anomaly classifier is trained in the following manner: obtaining an application sample set to be trained, the application sample set containing historical behavior data and sample labels of multiple application samples, the historical behavior data containing: a first type of historical behavior data reflecting the static attributes of the sample application, and a second type of historical behavior data reflecting the dynamic behavior of the sample application; the sample label is used to characterize whether the application is abnormal and the type of anomaly; extracting static features based on the first type of behavior data of the sample application; and extracting dynamic features based on the second type of historical behavior data of the sample application; based on the static features and dynamic features of the multiple application samples, and the sample labels, using one or more combinations of the random forest method, guided aggregation algorithm, and boosting algorithm in the classification algorithm to identify and classify the applications in the application sample set to obtain an anomaly classifier.

[0111] The static and dynamic features of the application samples can refer to the types of static and dynamic features mentioned in the above solution. The sample label can be the presence of abnormal behavior in the application or the absence of abnormal behavior in the application. Based on the return value of the information identifier carried by the static and dynamic features of the sample application, as well as the true label of the sample application, a combination of one or more of the random forest method, guided aggregation algorithm, and boosting algorithm is used to identify and obtain an anomaly classifier. The anomaly classifier is essentially a set or array that stores the judgment rules formed by the collected multi-dimensional features or feature combinations.

[0112] In the technical solution of this application, the global configuration file of the application package from the target application and the call record of the interface triggered by the specified operation behavior are obtained as static features; the data of the specified target in the target application running in the operating system simulator is intercepted to obtain the intercepted data as dynamic features; based on the static features and the dynamic features, it is identified whether the target application has abnormal behavior. Thus, the manual participation detection scheme in the existing technology is replaced by automatic detection, which improves detection efficiency, reduces manual intervention, and achieves faster detection. Moreover, when performing abnormal behavior detection, static features and dynamic features are comprehensively considered, and multi-dimensional factors are considered to more comprehensively and accurately identify various types of malicious behaviors.

[0113] Example 2

[0114] Figure 5 This is a schematic diagram of the structure of an abnormal behavior detection device provided in one embodiment of this specification. Figure 5 In a software implementation, the abnormal behavior detection device 500 may include:

[0115] The first acquisition module 501 is used to acquire, as static features, a global configuration file of an application package of a target application and a call record of an interface triggered by a specified operation behavior;

[0116] The second acquisition module 502 is configured to intercept data of a designated target in the target application running in the operating system simulator and obtain the intercepted data as a dynamic feature; the designated target includes a class method and / or a class constructor;

[0117] The identification module 503 is configured to identify whether the target application has abnormal behavior based on the static features and the dynamic features.

[0118] The technical solution of this specification obtains the global configuration file of the application package from the target application and the call record of the interface triggered by the specified operation behavior as static features; intercepts the data of the specified target in the target application running in the operating system simulator, and obtains the intercepted data as dynamic features; based on the static features and the dynamic features, it identifies whether the target application has abnormal behavior. Thus, the manual detection scheme in the existing technology is replaced by automatic detection, which improves detection efficiency, reduces manual intervention, and achieves faster detection. Moreover, when performing abnormal behavior detection, static features and dynamic features are comprehensively considered, and multi-dimensional factors are considered to more comprehensively and accurately identify various types of malicious behaviors.

[0119] Optionally, as an embodiment, when acquiring the global configuration file from the application package of the target application, the first acquisition module 501 is specifically configured to obtain the global configuration file by decompiling the application package.

[0120] In a specific implementation of an embodiment of the present specification, when obtaining the call record, the first acquisition module 502 is specifically used to convert the virtual machine executable file obtained from the application package into a source code file; according to the information of the specified behavior operation, obtain the call record of the interface triggered by the specified behavior operation from the source code file.

[0121] In another specific implementation of the embodiment of this specification, the class method includes at least one of the following: network access class, file access class, encryption and decryption class, and system setting class;

[0122] The class constructor includes at least one of the following: a network access class constructor, a file access class constructor, an encryption and decryption class constructor, and a system setting class constructor.

[0123] In another specific implementation of the embodiments of this specification, when intercepting data from a specified target in the target application running in the operating system simulator, the second acquisition module 502 is specifically used to interact with the running target application by simulating user behavior; during the interaction, data is intercepted from the specified target of the target application.

[0124] It should be understood that the abnormal behavior detection device of the embodiment of this specification can also perform Figures 1-4 The method executed by the abnormal behavior detection device (or equipment) in Figures 1-4 The functions of the illustrated embodiment will not be described in detail here.

[0125] Example 3

[0126] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 6 At the hardware level, the electronic device includes a processor and, optionally, an internal bus, a network interface, and memory. The memory may include internal memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for its services.

[0127] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0128] The memory is used to store programs. Specifically, the program may include program code, which includes computer operating instructions. The memory may include internal memory and non-volatile memory, and provides instructions and data to the processor.

[0129] The processor reads the corresponding computer program from the non-volatile memory into the internal memory and then runs it, forming a shared resource access control device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0130] The global configuration file of the application package from the target application and the call record of the interface triggered by the specified operation behavior are obtained as static features; the intercepted data is obtained as dynamic features by intercepting data of the specified target in the target application running in the operating system simulator; the specified target includes class methods and / or class constructors; based on the static features and the dynamic features, it is identified whether the target application has abnormal behavior.

[0131] The above is as in this manual Figures 1-4 The methods performed by the abnormal behavior detection device disclosed in the illustrated embodiments can be applied to or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in the processor or by software instructions. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of this specification can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in conjunction with the embodiments of this specification can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0132] The electronic device may also perform Figure 1 Method, and realize abnormal behavior detection device in Figures 1-4The functions of the embodiments shown in this specification will not be described in detail here.

[0133] Of course, in addition to software implementation, the electronic device of the embodiments of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0134] Example 4

[0135] The embodiment of this specification also proposes a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including multiple application programs, can enable the portable electronic device to execute Figure 1 The method of the embodiment shown is specifically used to perform the following method:

[0136] The global configuration file of the application package from the target application and the call record of the interface triggered by the specified operation behavior are obtained as static features; the intercepted data is obtained as dynamic features by intercepting data of the specified target in the target application running in the operating system simulator; the specified target includes class methods and / or class constructors; based on the static features and the dynamic features, it is identified whether the target application has abnormal behavior.

[0137] In short, the above description is only a preferred embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of protection of this specification.

[0138] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0139] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0140] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0141] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

Claims

1. A method for detecting abnormal behavior, characterized in that: include: Obtaining a global configuration file from an application package of a target application and a call record of an interface triggered by a specified operation behavior as static features; By intercepting data of a designated target in the target application running in the operating system simulator, the intercepted data is obtained as a dynamic feature; The specified target includes a class method and / or a class constructor; Based on the static features and the dynamic features, it is identified whether the target application has abnormal behavior.

2. The method according to claim 1, wherein Get the global configuration files from the target application's application package, including: The global configuration file is obtained by decompiling the application package.

3. The method according to claim 1, wherein Obtain the call record, including: Converting the virtual machine executable file obtained from the application package into a source code file; According to the information of the designated behavior operation, a call record of the interface triggered by the designated behavior operation is obtained from the source code file.

4. The method according to claim 1, wherein: The class method includes at least one of the following: Network access class, file access class, encryption and decryption class, system settings class; The constructor of the class includes at least one of the following: Constructor of network access class, constructor of file access class, constructor of encryption and decryption class, constructor of system settings class.

5. The method according to claim 1, wherein Data interception is performed on a specified target in the target application running in the operating system simulator, including: Interacting with the running target application by simulating user behavior; During the interaction, data is intercepted for the designated target of the target application.

6. An abnormal behavior detection device, characterized in that: include: A first acquisition module is used to acquire, as static features, a global configuration file of an application package of a target application and a call record of an interface triggered by a specified operation behavior; A second acquisition module is configured to intercept data of a designated target in the target application running in the operating system simulator, and obtain the intercepted data as a dynamic feature; The specified target includes a class method and / or a class constructor; An identification module is used to identify whether the target application has abnormal behavior based on the static features and the dynamic features.

7. The device according to claim 6, characterized in that The second acquisition module is specifically configured to: Interacting with the running target application by simulating user behavior; During the interaction, data is intercepted for the designated target of the target application.

8. An electronic device comprising: processor; as well as A memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the steps of the abnormal behavior detection method according to any one of claims 1 to 5.

9. A computer-readable storage medium storing one or more programs, which, when executed by an electronic device including a plurality of application programs, enable the electronic device to perform the steps of the abnormal behavior detection method according to any one of claims 1 to 5.

10. A computer program product, characterized in that The computer program product stores instructions, which, when executed by a computer, enable the computer to implement the steps of the abnormal behavior detection method according to any one of claims 1 to 5.