Ransomware identification method based on energy consumption information and related device

Abstract

The application provides a ransomware identification method based on energy consumption information and related equipment. First, some software without ransom suspicion in the to-be-tested list is filtered out, and these software are directly determined as non-ransom software to obtain a suspicious software list. Those application software which are completely impossible to be ransom software are avoided to flow into the dynamic detection process, thereby affecting the average detection time length of the whole engine. Then, the energy consumption information log and the WakeLock log in the running process of the suspicious software are collected and integrated to obtain an integrated log, and the suspicious software is classified through a binary classification model based on energy consumption to obtain an identification result. The whole identification process does not depend on the system ROOT permission, has strong practicability, has strong ability to cope with new risks, and the discrimination range is not aimed at a single type of ransom software, covers both lock screen type and encryption type ransom software, and the identification range is more extensive.

Description

Technical Field

[0001] This application relates to the field of software detection technology, and in particular to a ransomware identification method and related equipment based on energy consumption information. Background Technology

[0002] With the widespread adoption of smartphones, their functions have expanded from making calls and sending text messages to social interaction, entertainment, work, and shopping. Smartphones running the Android system have the highest market share. However, with the development of the mobile internet, some criminals have specifically targeted smartphones, leading to a proliferation of various malicious software, among which ransomware is one of the most common. If a device is infected with this malware, the user typically needs to pay a ransom to the attacker to unlock the device. Ransomware is highly destructive and generates quick profits, making it more attractive to criminals than other types of malware. Therefore, research into novel detection methods for Android ransomware, helping users detect ransomware before it infects them, is of great significance.

[0003] Android ransomware detection is a preventative measure against ransomware. Such measures typically determine whether software is ransomware before the user installs it, using static or dynamic analysis of the target software. The aim is to inform users or businesses of the risks associated with installing the application before it causes substantial damage to the target device, thus preventing the ransomware from installing and running. There are numerous research findings on ransomware prevention and detection on the Android platform, broadly categorized into four methods: static analysis, dynamic analysis, behavioral analysis, and resource consumption analysis.

[0004] Numerous methods for detecting Android ransomware have emerged based on various principles, but they generally suffer from low detection rates for new types of ransomware, poor resistance to code obfuscation, reliance on device root privileges, and inability to cover both types of ransomware (encryption and screen-locking). Further research has revealed that detection methods overly reliant on system root privileges have poor practicality. Some methods require root privileges to monitor program API calls in real time. These analyzers need to become super administrators on the Android smartphone to activate hidden Linux mechanisms, thereby modifying Android's file access control mode or I / O response mode. Considering information security, most Android users do not choose to root their devices. However, only rooted devices can grant super administrator privileges to analyzers, allowing these dynamic analysis methods to execute successfully. Encryption ransomware can encrypt files without administrator privileges, but detection methods relying on root privileges cannot function properly on non-rooted devices. With the continuous upgrades to the Android system and the increasing emphasis on device security by mobile phone manufacturers, the cost of rooting is also rising. In the field of Android ransomware detection, there is an urgent need to propose new detection methods that have weak dependence on device root privileges and strong generalization capabilities. Summary of the Invention

[0005] In view of this, the purpose of this application is to propose a ransomware identification method and related equipment based on energy consumption information, so as to solve the above problems.

[0006] To achieve the above objectives, the first aspect of this application provides a ransomware identification method based on energy consumption information, comprising:

[0007] A list of suspicious software is obtained by filtering all software in the test list using a pre-built software filter.

[0008] For any one of the suspicious software programs in the list of suspicious software programs:

[0009] The suspicious software was run using automated testing components.

[0010] Collect energy consumption logs and WakeLock logs during the operation of the suspected software;

[0011] The energy consumption information log and the WakeLock log are integrated to obtain the integrated log;

[0012] Based on the integrated logs, the suspicious software is classified using a pre-trained binary classification model based on energy consumption to obtain the identification results;

[0013] The identification result is sent to the target mobile device;

[0014] Upon determining that all the suspicious software in the suspicious list has been identified, the identification process ends.

[0015] A second aspect of this application provides a ransomware identification device based on energy consumption information, comprising:

[0016] The filtering module is configured to use a pre-built software filter to filter all software under test in the test list to obtain a list of suspicious software.

[0017] The information extraction module is configured to run the suspicious software using an automated testing component;

[0018] Collect energy consumption logs and WakeLock logs during the operation of the suspected software;

[0019] The energy consumption information log and the WakeLock log are integrated to obtain the integrated log;

[0020] The model classification module is configured to: classify the suspicious software based on the integrated logs using a pre-trained binary classification model based on energy consumption, and obtain the identification result;

[0021] The identification process ends once it is determined that all the suspicious software in the suspicious list has been identified.

[0022] The interaction module is configured to send the recognition result to the target mobile terminal.

[0023] A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method provided in the first aspect of this application.

[0024] A fourth aspect of this application provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method provided in the first aspect of this application.

[0025] As can be seen from the above, the ransomware identification method and related equipment based on energy consumption information provided in this application first perform a static detection process to filter out some software in the test list that does not contain ransomware suspicion, and directly determine these software as non-ransomware, thus obtaining a list of suspicious software. This filtering process is in the first half of the identification process, preventing application software that is completely unlikely to be ransomware from entering the dynamic detection process, thereby affecting the overall average detection time of the engine. Then, a dynamic detection process is performed based on the list of suspicious software. While running the suspicious software using automated testing components, energy consumption information logs and WakeLock logs during the suspicious software's operation are collected and integrated to obtain integrated logs. The suspicious software is then classified using a pre-trained binary classification model based on energy consumption to obtain the identification results, which are sent to the target mobile terminal. When all software in the suspicious software list has been detected, the identification process ends. The entire identification process does not rely on system ROOT privileges, is highly practical, has a strong ability to cope with new risks, and its scope of judgment is not limited to a single type of ransomware, covering both screen lock and encryption ransomware, thus broadening the identification range. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a flowchart of a ransomware identification method based on energy consumption information according to an embodiment of this application;

[0028] Figure 2 This is a schematic diagram of the overall execution flow of the ransomware identification method based on energy consumption information according to an embodiment of this application;

[0029] Figure 3 This is a flowchart illustrating the training process of the binary classification model according to an embodiment of this application.

[0030] Figure 4 This is a bar chart comparing the energy consumption of ransomware and non-ransomware in an embodiment of this application.

[0031] Figure 5 This is a flowchart illustrating the construction of a list of items to be tested, as described in an embodiment of this application.

[0032] Figure 6 This is a schematic diagram illustrating the uploading of APK files to a web page according to an embodiment of this application;

[0033] Figure 7This is a flowchart illustrating the process of obtaining a list of suspicious software according to an embodiment of this application.

[0034] Figure 8 This is a statistical chart showing the frequency of ransomware permission requests in embodiments of this application;

[0035] Figure 9 This is a flowchart illustrating the operation of suspicious software via an automated execution component, as described in an embodiment of this application.

[0036] Figure 10 This is a flowchart illustrating log collection in an embodiment of this application;

[0037] Figure 11 This is a flowchart illustrating log integration in an embodiment of this application;

[0038] Figure 12 This is a schematic diagram of the ransomware identification device based on energy consumption information according to an embodiment of this application;

[0039] Figure 13 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0041] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0042] Ransomware identification methods in related technologies can be mainly divided into four categories:

[0043] (1) Ransomware detection based on static analysis.

[0044] Current static analysis methods for ransomware detection are fast, have low performance consumption, and are easy to operate. However, these methods have disadvantages such as poor anti-confusion ability, weak ability to identify new ransomware, and lower overall accuracy compared to dynamic analysis-based methods.

[0045] (2) Ransomware detection based on dynamic analysis.

[0046] Dynamic analysis methods often offer high accuracy, strong ability to identify new threats, and strong resistance to obfuscation, but they are slow (often taking minutes) and consume significant resources. Furthermore, the runtime parameters required for dynamic monitoring are often complex, and most rely heavily on root access to the device.

[0047] (3) Detect ransomware based on behavior.

[0048] Behavioral ransomware detection focuses on whether the software under test has performed the corresponding malicious actions of ransomware. For example, in related technologies, a decoy file is first created on the device to induce ransomware to encrypt the decoy file. In this way, suspicious processes can be detected, thereby locating the ransomware. However, this detection method also relies on root privileges on the device, and after the decoy file is encrypted, it requires very complex methods to locate the process performing the encryption action.

[0049] (4) Detect ransomware based on the usage of system resources.

[0050] Ransomware requires significant file input and output when encrypting files. Ransomware detection methods based on system resource usage are highly sensitive to ransomware file encryption and have achieved good results. However, this method also has its limitations. These methods use the system resource usage of the software under test as a criterion. However, this approach struggles to eliminate interference from other running processes (such as system processes and startup processes), leading to errors in the experimental results. Furthermore, these system resource usage-based detection methods are mostly used to identify file-encrypting ransomware, lacking research and attention to the system resource consumption of screen-locking ransomware.

[0051] The ransomware identification method based on energy consumption information provided in this application analyzes the differences in energy consumption indicators between ransomware and non-ransomware, proposing a method to distinguish ransomware from non-ransomware using time-series information of specific energy consumption indicators. This method identifies ransomware based on the time-series characteristics of energy consumption indicators during application software operation, does not rely on system root privileges, is highly practical, has a strong ability to respond to new risks, and its identification scope is not limited to a single type of ransomware, covering both screen-locking and encryption ransomware, thus broadening the identification range.

[0052] In some embodiments, such as Figure 1 As shown, a ransomware identification method based on energy consumption information includes:

[0053] Step 100: Use a pre-built software filter to filter all the software to be tested in the test list to obtain a list of suspicious software.

[0054] Among them, such as Figure 2 As shown, step 100 is the first half of the entire identification process, which is a static detection process. The software filter is a lightweight ransomware filter based on permission information. Its main function is to filter out applications that do not contain suspicious permission combinations in the Manifest.xml file (the entry file of Android applications) after the system receives the input application through static analysis based on permission information, and directly identify them as non-ransomware, thereby obtaining a list of suspicious software. This prevents applications that are completely unlikely to be ransomware from flowing into the dynamic detection process, thus affecting the overall average detection time of the engine.

[0055] For any suspicious software item in the suspicious software list, the dynamic detection process includes:

[0056] Step 200: Run the suspicious software using the automated testing component.

[0057] Optionally, the automated testing component can be the Monkey automated testing component. While ensuring the correct triggering of ransomware malicious behavior, the operation of complex non-ransomware functions should be minimized. The event streams that can be selected are mainly button click events in the navigation bar (back button, home button, application switching button, etc.). Triggering these buttons not only avoids interrupting various malicious behaviors of the ransomware, but also prevents the non-ransomware from running overly complex functions, improving the stability and consistency of the experimental process.

[0058] Step 300: Collect energy consumption information logs and WakeLock logs during the operation of suspicious software.

[0059] Optionally, energy consumption measurement and collection can be performed using the Powertutor tool. It uses a model to estimate the energy consumption of each resource on the device and performs resource energy consumption statistics on an application-by-application basis, allowing for more intuitive observation and statistical analysis of application energy consumption information. Powertutor is an open-source tool. To meet the need for real-time output and reporting of energy consumption information during automated testing, secondary development was performed on Powertutor. FileOutputStream (file byte output stream) is used to output the time-series information of energy consumption of each component during the operation of the software under test to the log, resulting in an energy consumption log.

[0060] WakeLock is a power management mechanism unique to the Android operating system. It ensures that all hardware devices serving the operating system remain awake and operational. From its implementation perspective, WakeLock is a locking mechanism within the Android operating system. If a process holds the lock, the operating system and its underlying hardware devices will never be able to enter a sleep state. Normally, when an Android smartphone is idle—that is, when no process holds a WakeLock—the smartphone system remains in a deep sleep state. If the device is operated at this time, such as pressing the power button, the system returns to its state before deep sleep. However, once an application successfully invokes the WakeLock mechanism, or a process holds the WakeLock, the device will remain awake, resulting in additional energy consumption compared to sleep mode.

[0061] For data collection on the number of times application software calls the WakeLock mechanism, Google's open-source energy analysis tool, Battery Historian, was used. This tool collects not only the number and timing of WakeLock calls from applications, but also information such as the application's execution flow, kernel execution records, and hardware device calls during runtime. Battery Historian's WakeLock analysis results are derived from the analysis of bugreport logs generated during Android runtime. Users can export the bugreport logs to their computers using the command "adb bugreport bugreport.zip," and then upload the bugreport file to Battery Historian to obtain detailed information on device WakeLock calls, i.e., the WakeLock logs.

[0062] Step 400: Integrate the energy consumption information log and the WakeLock log to obtain the integrated log.

[0063] In this step: extract the Wakelock call information from the Wakelock log and integrate it with the energy consumption time series log collected by PowerTutor to form the final integrated log format.

[0064] Step 500: Based on the integrated logs, classify the suspicious software using a pre-trained binary classification model based on energy consumption to obtain the identification results.

[0065] In this step, if the binary classification model based on energy consumption determines that the suspicious software is ransomware, then the suspicious software is labeled as ransomware, and the identification result of the suspicious software being ransomware is obtained; if the binary classification model based on energy consumption determines that the suspicious software is not ransomware, then the suspicious software is labeled as not ransomware, and the identification result of the suspicious software being not ransomware is obtained.

[0066] Step 600: Send the recognition results to the target mobile device.

[0067] In this step, the identification results are returned to the user. If the identification result indicates that the suspicious software is ransomware, the user is reminded not to install or run the ransomware; if the identification result indicates that the suspicious software is not ransomware, the user can install or run the non-ransomware normally.

[0068] Step 700: In response to the determination that all suspicious software in the suspicious list has been identified, the identification process ends.

[0069] In this step, once all suspicious software in the suspicious list has been identified, the test is complete, the identification process ends, and the identification process will restart when the user downloads new software again.

[0070] In some embodiments, such as Figure 3 As shown, training a binary classification model based on energy consumption specifically includes:

[0071] Step 001: Determine energy consumption indicators by analyzing the energy consumption information of ransomware and non-ransomware.

[0072] Optionally, the Koler ransomware family was selected as an example to test the power consumption of screen lock ransomware, and the SimpleLocker ransomware family was selected as an example to test the power consumption of encryption and hybrid ransomware. For non-ransomware, Google Chrome was selected as a representative of browser-based non-ransomware, YouTube as a representative of video-based non-ransomware, and Google Maps as a representative of map-based non-ransomware. The power consumption of these programs during operation was tested. The test and comparative analysis results are shown in Table 1.

[0073] Table 1. Summary of Experimental Results on Energy Consumption Comparison between Ransomware and Non-Ransomware

[0074]

[0075] like Figure 4 As shown, to more intuitively illustrate the differences in experimental results among different types of software in the monitoring experiment, the results were plotted as a stacked bar chart. The results show that ransomware differs significantly from ordinary non-ransomware in terms of energy consumption.

[0076] Firstly, looking at the total energy consumption, the three typical non-ransomware types consumed between 54.8J and 113.6J within 10 minutes, with an average total energy consumption of 93.3J. The screen-locking ransomware sample Koler consumed 345.5J, more than three times the average total energy consumption of the three non-ransomware types. The hybrid ransomware sample SimpleLocker consumed a staggering 1927.8J, more than 20 times the average total energy consumption of the three non-ransomware types. Ransomware, compared to non-ransomware, exhibits a significantly higher total energy consumption, demonstrating a substantial difference.

[0077] For screen-locking ransomware, the Koler family sample consumed a staggering 330.3 J of energy from the LCD module within 10 minutes, approximately 11 times the average LCD energy consumption of the three non-ransomware types. SimpleLocker ransomware, a hybrid ransomware, also exhibits screen-locking malicious behavior. SimpleLocker's screen-locking behavior resulted in an LCD screen module energy consumption of 413.2 J within 10 minutes, approximately 14 times the average LCD energy consumption of the three non-ransomware types. SimpleLocker's file encryption behavior resulted in a CPU module energy consumption of 1514.6 J within 10 minutes, approximately 24 times the average CPU energy consumption of the three non-ransomware types.

[0078] Based on the trends in energy consumption during the monitoring period, Google Chrome and YouTube videos exhibited the highest energy consumption within the first few tens of seconds of operation, followed by lower energy consumption. After initialization, the energy consumption trend of the LCD screen module in Google Maps was similar to the previous two types of benign applications; the energy consumption of the LCD screen module decreased significantly after initialization. However, since the Maps application needs to continuously acquire and process device location information after starting, the CPU module's energy consumption remained relatively stable throughout the monitoring process.

[0079] The screen-locking malicious behavior of Koler and SimpleLocker ransomware caused consistently high energy consumption of the LCD screen module, with minimal fluctuations in energy consumption (J) per second during the monitoring period. When the SimpleLocker ransomware sample performed file encryption operations, the CPU module's energy consumption also remained consistently high, stabilizing between 2.4J and 2.7J per second.

[0080] In summary, ransomware differs significantly from ordinary non-ransomware in both the numerical values ​​and trends of energy consumption indicators. Therefore, based on the experimental results, the eight indicators shown in Table 2 were selected as the distinguishing features between ransomware and non-ransomware. These indicators effectively reflect the execution characteristics of different types of ransomware, and the sequence of changes in these indicators over runtime can be extracted using relevant automatic energy consumption information collection tools.

[0081] Table 2. Energy Consumption Information Related Indicators

[0082]

[0083] Step 002: Construct the sample set.

[0084] In this step, the sample set includes ransomware and non-ransomware sets. Optionally, the ransomware set includes a total of 680 ransomware samples. Among them, 393 are purely screen-locking ransomware, 90 are purely file-encrypting ransomware, and 197 are hybrid ransomware. These include seven different ransomware families: SimpleLocker, Koler, WannaLocker, Xbot, DoubleLocker, Congur, and Pletor. We removed the Pletor ransomware family, which remains dormant in the background after installation, waiting for remote commands to execute malicious behavior, leaving 660 ransomware samples. The top 1000 downloaded non-ransomware apps were collected from major app stores. Applications labeled as "Malware" by two or more antivirus engines were removed from the non-ransomware dataset. After this processing, the final non-ransomware dataset contains 923 samples. The resulting sample set is shown in Table 3.

[0085] Table 3. Composition of the sample set

[0086]

[0087] Step 003: Based on the sample set and energy consumption index, train an energy consumption-based binary classification model using the HIVE-COTE ensemble learning algorithm.

[0088] Step 004: In response to the determination that the precision, recall, and F1-Score of the energy consumption-based binary classification model have all reached the preset standard values, training is complete.

[0089] Among them, binary classification models were trained using the HIVE-COTE, TFS, and ST algorithms respectively. The precision, recall, and F1 score of the binary classification models trained by the three algorithms are shown in Table 4.

[0090] Table 4. Results of 6-fold cross-validation for HIVE-COTE, TFS, and ST algorithms.

[0091]

[0092] As shown in Table 4, all three ensemble learning algorithms achieved good performance metrics in the experiment, reaching the preset standard values. The specific values ​​of the standard values ​​were set based on the actual situation. This is essentially because ransomware and non-ransomware have significant differences in energy consumption patterns. Among the three different algorithms tested, the model trained by the HIVE-COTE algorithm was slightly better than the other two algorithms. In the final engine implementation, this paper adopted the model trained by the HIVE-COTE algorithm.

[0093] In some embodiments, such as Figure 2 and Figure 5 As shown, prior to step 100, the ransomware identification method based on energy consumption information further includes:

[0094] Step 005: In response to the determination that the target mobile device is performing a software download, the detection engine is activated.

[0095] Step 006: Upload all software downloaded to the target mobile device to the test list of the detection engine.

[0096] Among them, such as Figure 2 As shown, the download interceptor works by automatically intercepting the installation package of an application downloaded to an Android device when the user does so, and uploading it to a detection engine for testing. This is because once ransomware gains control of a device, malicious actions such as screen locking or file encryption can cause significant harm. The download interceptor proactively uploads the software to be tested to the detection engine by intercepting the user's downloaded APK file, actively detecting and monitoring the software, and notifying the Android device user of the detection results. Figure 6 As shown, you can also choose to upload the downloaded APK file to the detection engine via a web browser.

[0097] In some embodiments, such as Figure 7 As shown, a pre-built software filter is used to screen all software in the test list to obtain a list of suspicious software, specifically including:

[0098] Step 110: Use a software filter to extract all permissions for each software in the test list.

[0099] Step 120: In response to the determination that the software under test does not contain any suspicious permission groups in its full permissions, the software under test is not ransomware.

[0100] Step 130: In response to the determination that the software under test contains a suspicious permission group in all permissions, the software under test is considered suspicious software, and all suspicious software constitutes a list of suspicious software.

[0101] The software filter differentiates between ransomware and non-ransomware based on the permissions requested during runtime. Android software requests specific permissions when executing certain code segments. When a user downloads and installs an application, the Android operating system typically informs the user of the required permissions. However, users usually don't pay sufficient attention to the list of permissions requested by an application during download and installation, creating an opportunity for ransomware. Ransomware and non-ransomware often exhibit similar behaviors, such as performing file read / write operations or creating a floating notification. Some other malware often doesn't want to be detected by the user after installation, choosing a specific time to execute malicious actions and damage the device. Ransomware differs from these; instead, it disguises itself as commonly used non-ransomware to lure users into clicking and running it, thus enabling malicious actions.

[0102] Therefore, in this embodiment of the application, permissions were extracted from all sample software in the final sample in Table 3, the permissions used by these sample software were statistically analyzed, and the differences between the permissions required by ransomware and the permissions required by non-ransomware were compared. As shown in Table 5, the permissions required by ransomware to perform malicious behavior and the usage of these permissions on non-ransomware are listed, and each permission is described according to the Android developer documentation.

[0103] Table 5 Comparison of Permission Requests Between Ransomware and Non-Ransomware Software

[0104]

[0105]

[0106] Then, the frequency of permissions used by ransomware was statistically analyzed. The data was compiled using 660 sample software programs from Table 4, with frequencies ranging from 0% to 100%. The top ten permissions by frequency of use are as follows: Figure 8 As shown. According to Figure 8 Based on the statistical results in Table 5, the suspicious permission combinations are summarized as shown in Table 6.

[0107] Table 6 summarizes the suspicious permission combinations.

[0108]

[0109]

[0110] If the software under test requests no permissions from any of the suspicious permission groups in Table 6, then the software under test is directly classified as non-ransomware. Otherwise, the software under test is identified as suspicious software and added to the suspicious software list.

[0111] In some embodiments, such as Figure 9 As shown, running suspicious software using automated testing components specifically includes:

[0112] Step 210: Obtain the number of repetitions by running the calculator application in the automated testing component.

[0113] In this step, the calculator application is run, making it easier to switch from the suspicious software to other software in the following step 250.

[0114] Step 220: Use automated testing components to grant full permissions to the suspicious software.

[0115] In this step, the suspicious application is installed, granted all permissions, and then run. Since only by granting all permissions can the ransomware be guaranteed to launch an attack, it is necessary to grant all permissions to the suspicious application.

[0116] Step 230: Run the suspicious software based on full permissions and a preset first waiting time.

[0117] Optionally, the first waiting time can be 1 minute, during which the suspicious software runs for 1 minute, waiting for the malicious payload of the ransomware family to be loaded and executed.

[0118] Step 240: Based on a preset time interval, click one of the following buttons on the navigation bar: back button, home button, or switch application button, and count the number of clicks.

[0119] Optionally, the time interval can be set to 2 seconds, randomly clicking one of the navigation bar's back button, home button, or switch application button.

[0120] Step 250: In response to determining that the number of clicks equals the number of repetitions, run the suspicious software again.

[0121] Optionally, the number of repetitions can be set to 30. Once the number of clicks reaches 30, the clicking stops and the suspicious software continues to run.

[0122] Step 260: In response to the determination that the time for the suspicious software to run again is equal to the preset second waiting time, terminate the operation of the suspicious software.

[0123] In this step, the second waiting time can be set to 3 minutes. No action is taken, and the process continues to wait for the suspicious software to execute for 3 minutes before ending the automated test.

[0124] In some embodiments, such as Figure 10 As shown, energy consumption logs and WakeLock logs were collected during the operation of the suspicious software, specifically including:

[0125] Step 310: Use the energy consumption information collection component in the detection engine to collect energy consumption information logs during the operation of suspicious software;

[0126] Step 320: Use the WakeLock log collection component in the detection engine to collect WakeLock logs during the execution of suspicious software.

[0127] Optionally, Figure 2 The automated energy consumption information collection tool AutoEnergy includes the Monkey automated testing component, the PowerTutor energy consumption information collection component, the Battery Histrian WakeLock log collection component, and a log integration component. It utilizes the energy consumption information collection component within the detection engine to collect energy consumption logs during the operation of suspicious software; and it utilizes the Battery Histrian WakeLock log collection component within the detection engine to collect WakeLock logs during the operation of suspicious software.

[0128] In some embodiments, such as Figure 11 As shown, by integrating the energy consumption information log and the WakeLock log, a combined log is obtained, which specifically includes:

[0129] Step 410: Extract Wakelock call information from the WakeLock log.

[0130] Step 420: Extract the energy consumption time series from the energy consumption information log.

[0131] Step 430: Integrate the energy consumption time series with the Wakelock call information to obtain the integrated log.

[0132] The WakeLock call information includes the caller's package name, the class name that called WakeLock, and a timestamp. The log integration component periodically uses the "adb pull" command (to pull information from the phone to the local computer) to pull the PowerTutor energy consumption logs stored in the emulator to the PC for storage, facilitating later integration with the WakeLock call information extracted from BatteryHistorianWakeLock. After reading both log files into memory, the log integration component uses the data processing function of the AutoEnergy prototyping tool's log integration component to integrate the WakeLock call information recorded in BatteryHistorianWakeLock into a WakeLock time series. The time interval of this time series is one second, and the number of WakeLock calls occurring within each second is the value of the time series. If a certain type of call method acquires a WakeLock within a certain time period, the sequence value for that time period is incremented by 1; if a certain type of call method releases a WakeLock, the sequence value for that time period is decremented by 1. Finally, the WakeLock time series and the energy consumption time series in the energy consumption information log are integrated to obtain the integrated log as shown in Table 7. As can be seen from Table 7, the integrated log includes 8 indicators as shown in Table 2.

[0133] Table 7. Examples of integration logs generated by the AutoEnergy prototyping tool.

[0134]

[0135] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0136] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0137] Based on the same inventive concept, and corresponding to any of the above embodiments, this application also provides a ransomware identification device based on energy consumption information.

[0138] refer to Figure 12 The ransomware identification device based on energy consumption information includes:

[0139] Filtering module 01 is configured to: use a pre-built software filter to filter all software to be tested in the test list to obtain a list of suspicious software;

[0140] Information extraction module 02 is configured to: run suspicious software using automated testing components;

[0141] Collect energy consumption logs and WakeLock logs during the operation of suspicious software;

[0142] Integrate energy consumption information logs and WakeLock logs to obtain a unified log;

[0143] Model classification module 03 is configured to: classify suspicious software based on integrated logs using a pre-trained binary classification model based on energy consumption, and obtain the identification results;

[0144] The identification process ends once all suspicious software in the suspicious list has been identified.

[0145] Interaction module 04 is configured to send the recognition results to the target mobile device.

[0146] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0147] The apparatus described above is used to implement the ransomware identification method based on energy consumption information in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0148] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the ransomware identification method based on energy consumption information as described in any of the above embodiments.

[0149] Figure 13This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0150] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0151] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0152] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0153] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0154] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0155] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0156] The electronic devices described above are used to implement the ransomware identification methods based on energy consumption information in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0157] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the ransomware identification method based on energy consumption information as described in any of the above embodiments.

[0158] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0159] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the ransomware identification method based on energy consumption information as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0160] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.

[0161] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0162] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0163] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A ransomware identification method based on energy consumption information, characterized by, The method comprises the following steps: screening all software to be tested in a list of software to be tested by using a pre-constructed software filter to obtain a list of suspicious software; for any suspicious software in the list of suspicious software: running the suspicious software by using an automated test component; collecting energy consumption information logs and WakeLock logs during the running of the suspicious software; integrating the energy consumption information logs and the WakeLock logs to obtain integrated logs; based on the integrated logs, classifying the suspicious software by using a pre-trained energy consumption-based binary classification model to obtain a recognition result; and sending the recognition result to a target mobile terminal; in response to determining that all the suspicious software in the suspicious list has been identified, ending the identification.

2. The method of claim 1, wherein, training the energy consumption-based binary classification model, specifically comprising: determining an energy consumption indicator by analyzing the energy consumption information of ransomware and non-ransomware; constructing a sample set; based on the sample set and the energy consumption indicator, training the energy consumption-based binary classification model by using a HIVE-COTE integrated learning algorithm; in response to determining that the model precision, recall rate and F1-Score of the energy consumption-based binary classification model all reach preset standard values, the training is completed.

3. The method of claim 1, wherein, Before screening all software to be tested in a list of software to be tested by using a pre-constructed software filter to obtain a list of suspicious software, the method further comprises: in response to determining that a target mobile terminal performs a software download behavior, activating a detection engine; uploading all software downloaded to the target mobile terminal to a list of software to be tested of the detection engine.

4. The method of claim 1, wherein, The method of screening all software to be tested in a list of software to be tested by using a pre-constructed software filter to obtain a list of suspicious software specifically comprises: extracting all permissions of each software to be tested in the list of software to be tested by using the software filter; in response to determining that the all permissions of the software to be tested do not contain a suspicious permission group, the software to be tested is non-ransomware; in response to determining that the all permissions of the software to be tested contain a suspicious permission group, the software to be tested is suspicious software, and all the suspicious software constitutes the list of suspicious software.

5. The method of claim 4, wherein, The method of running suspicious software by using an automated test component specifically comprises: obtaining a repetition number by running a calculator application in the automated test component; opening all permissions of the suspicious software by using the automated test component; based on the all permissions and a preset first waiting time, running the suspicious software; based on a preset time interval, clicking one of a navigation bar back key, a home key and an application switching key, and counting the number of clicks; in response to determining that the number of clicks is equal to the repetition number, running the suspicious software again; in response to determining that the time of running the suspicious software again is equal to a preset second waiting time, ending the running of the suspicious software.

6. The method of claim 3, wherein, The method of collecting energy consumption information logs and WakeLock logs during the running of the suspicious software specifically comprises: collecting energy consumption information logs during the running of the suspicious software by using an energy consumption information collection component in the detection engine; acquiring the WakeLock log in a running process of the suspicious software by using a WakeLock log collection component in the detection engine.

7. The method of claim 1, wherein, The method further includes: extracting Wakelock calling information in the WakeLock log; extracting energy consumption time sequence in the energy consumption information log; integrating the energy consumption time sequence and the Wakelock calling information to obtain the integrated log.

8. A ransomware identification apparatus based on energy consumption information, characterized by, The method further includes: a filtering module configured to filter all software to be tested in a list of software to be tested by using a pre-constructed software filter to obtain a list of suspicious software; an information extraction module configured to run the suspicious software by using an automated test component; acquiring energy consumption information log and WakeLock log in a running process of the suspicious software; integrating the energy consumption information log and the WakeLock log to obtain an integrated log; a model classification module configured to classify the suspicious software by using a pre-trained energy consumption-based binary classification model based on the integrated log to obtain a recognition result; ending the recognition in response to determining that all the suspicious software in the suspicious list has been recognized; an interaction module configured to send the recognition result to a target mobile terminal. 9.An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 7 when executing the program. 10.A non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method of any one of claims 1 to 7.

Images