Power system internet of things firmware multi-granularity vulnerability similarity detection method and device
By employing a multi-granularity vulnerability similarity detection method, which utilizes similarity calculations based on hash values, file and code-level feature attributes, the problem of low vulnerability detection efficiency under multiple firmware architectures in power system IoT devices is solved, achieving efficient and accurate vulnerability detection and remediation support.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ELECTRIC POWER RESEARCH INSTITUTE OF STATE GRID SHANDONG ELECTRIC POWER COMPANY
- Filing Date
- 2022-11-04
- Publication Date
- 2026-07-24
AI Technical Summary
Existing technologies are insufficient for efficiently detecting vulnerabilities in the firmware of IoT devices in power systems across various architectures, resulting in low detection efficiency and increased workload.
A multi-granularity vulnerability similarity detection method is adopted. By comparing the hash value of the firmware under test with known vulnerability samples, and combining the feature attributes and similarity calculations of the file and code layers, potential vulnerabilities are screened out step by step.
It improves the efficiency and accuracy of vulnerability detection, reduces redundant workload, and provides a more accurate basis for vulnerability verification and remediation.
Smart Images
Figure CN115659354B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet of Things (IoT) security technology, and in particular to a method and apparatus for detecting multi-granularity vulnerability similarity in IoT firmware for power systems. Background Technology
[0002] With the rapid development of IoT technology, IoT applications are becoming increasingly widespread, and the world has entered an era of interconnected everything. Among these applications, the power system, as a key national energy infrastructure, is undeniably crucial. The introduction of massive amounts of power IoT devices has gradually improved the informatization and intelligence of the power system, playing a vital role in data acquisition, power control, and process management. However, it has also created new avenues for cyberattacks, introduced numerous system vulnerabilities, and threatened the normal operation of the power system.
[0003] The operation of power IoT devices relies on the underlying hardware and software environment, with the IoT firmware being the most crucial component. If security vulnerabilities exist in the firmware and are exploited by attackers, they can severely disrupt the normal and stable operation of the power system, leading to issues such as information leakage, command execution, and memory overflows, ultimately causing serious security incidents. However, the large number, variety, and complex architecture of firmware for power system IoT devices make it difficult to conduct universal research and application adaptation.
[0004] Current vulnerability detection solutions for IoT firmware often employ similarity comparison methods, which determine the existence of vulnerabilities based on the similarity between the reverse-engineered disassembled code. However, these methods require repetitive similarity calculations between the firmware under test and the vulnerability sample, and are all based on comparisons of assembly code, which reduces analysis efficiency and increases the workload of vulnerability detection. Summary of the Invention
[0005] This invention provides a method and apparatus for multi-granularity vulnerability similarity detection in firmware for power system Internet of Things (IoT) devices. This method can detect vulnerabilities in firmware of power IoT devices with multiple architectures, reducing the workload of detection and analysis and effectively improving detection efficiency. To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.
[0006] According to a first aspect of the present invention, a method for detecting multi-granularity vulnerability similarity in firmware for power system Internet of Things (IoT) is provided, comprising:
[0007] Obtain the hash value of the firmware under test and compare it with the hash value of the sample firmware with known vulnerabilities. If they are the same, the firmware under test is considered to have known vulnerabilities.
[0008] If they are different, then:
[0009] The firmware under test is processed to extract a file set Fs. The hash value of the target file Ff in the file set Fs is compared with the hash value of the sample file with a known vulnerability. If they are the same, the firmware under test is considered to have a known vulnerability.
[0010] If they are different, then:
[0011] Extract the feature attributes of file Ff from file set Fs, and calculate the similarity between file Ff and sample files based on the feature attributes. Based on the comparison of the similarity with a first threshold, determine whether the firmware under test has known vulnerabilities.
[0012] In one embodiment, the method further includes:
[0013] If the similarity between file Ff and the sample file is lower than the first threshold, then it is considered that there is no known vulnerability.
[0014] In one embodiment, the method further includes:
[0015] If the similarity between file Ff and sample file is not lower than the first threshold, then the assembly code of file Ff is extracted, and the similarity between the target function Fg in file Ff and the sample function with known vulnerabilities is calculated. If the similarity is not lower than the second threshold, then the firmware under test is considered to have vulnerabilities. If it is lower than the second threshold, then the firmware under test is considered not to have known vulnerabilities.
[0016] In one embodiment, the step of obtaining the hash value of the firmware under test and comparing the hash value of the firmware under test with the hash value of a sample firmware containing a known vulnerability further includes:
[0017] First, the feature vector of the firmware to be tested is extracted. Based on the feature vector, the similarity between the firmware to be tested and the sample firmware with known vulnerabilities is calculated. The similarity calculation results are output in descending order. Then, the hash value of the firmware to be tested is calculated in descending order.
[0018] In one embodiment, the step of calculating the hash value of the firmware under test in descending order further includes:
[0019] The hash value of the firmware under test is calculated using a hash function in descending order.
[0020] In one embodiment, the feature vector of the firmware under test in this method includes at least one of the following: manufacturer, device, and version number.
[0021] In one embodiment, the step of extracting the file set Fs from the firmware under test further includes: using any one of binwalk or Firmware Mod Kit to extract the files of the firmware under test, and decompressing all the files to form the file set Fs.
[0022] In one embodiment, the step of comparing the hash value of the target file Ff in the file set Fs with the hash value of the sample file containing the known vulnerability further includes:
[0023] Based on the description of the sample file name and location, locate file Ff.
[0024] In one embodiment, the characteristic attributes of file Ff in this method include at least one of the following: filename, file path, file size, file type, architecture information, file comments, debugging information, and file static constants.
[0025] In one embodiment, the step of extracting the assembly code of file Ff further includes:
[0026] Use either IDA Pro or Ghidra to reverse engineer the file Ff to extract its assembly code.
[0027] In one embodiment, the step of calculating the similarity between the target function Fg in file Ff and the sample function with a known vulnerability further includes:
[0028] Based on the description of the sample function name and location, locate the function Fg.
[0029] In one embodiment, the step of extracting the assembly code of file Ff and calculating the similarity between the target function Fg in file Ff and a sample function with a known vulnerability further includes:
[0030] Non-architecture-dependent parameters are selected as feature vectors to extract the feature vector of function Fg. Based on the feature vector, the similarity between function Fg and sample functions is calculated.
[0031] In one embodiment, the feature vector in this method includes at least one of the following: function name, function comment, function static constant, three-level function call relationship, and constant string information of the code block where the vulnerability is triggered.
[0032] In one embodiment, the step of calculating the similarity between the function Fg and the sample function based on the feature vector further includes:
[0033] The similarity between function Fg and existing sample functions is calculated using any one of the following similarity algorithms: cosine similarity, Euclidean distance, Hamming distance, and Jaccard distance.
[0034] According to a second aspect of the present invention, a device for detecting multi-granularity vulnerability similarity in firmware for Internet of Things (IoT) systems in power systems is provided.
[0035] In one embodiment, the device includes a firmware layer detection module, a first file layer detection module, a second file layer detection module, and a code layer detection module; wherein,
[0036] The firmware layer detection module is used to obtain the hash value of the firmware under test and compare the hash value of the firmware under test with the hash value of the sample firmware with known vulnerabilities. If they are the same, the firmware under test is considered to have known vulnerabilities; if they are different, the first file layer detection module is started.
[0037] The first file layer detection module is used to extract the file set Fs from the firmware under test, compare the hash value of the target file Ff in the file set Fs with the hash value of the sample file with known vulnerability. If they are the same, the firmware under test is considered to have known vulnerability; if they are different, the second file layer detection module is started.
[0038] The second file-level detection module is used to extract the feature attributes of file Ff in the file set Fs, and calculate the similarity between file Ff and sample files based on the feature attributes. If the similarity is lower than the first threshold, it is considered that the firmware under test does not have any known vulnerabilities; if the similarity is not lower than the first threshold, the code-level detection module is activated.
[0039] The code-level detection module is used to extract the assembly code of file Ff, and calculate the similarity between the target function Fg in file Ff and the sample function with known vulnerabilities. If the similarity is not lower than the second threshold, the firmware under test is considered to have a vulnerability; if it is lower than the second threshold, the firmware under test is considered not to have any known vulnerabilities.
[0040] According to a third aspect of the present invention, a computer device is provided.
[0041] In some embodiments, the computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method as described in the first aspect.
[0042] According to a fourth aspect of the present invention, a computer-readable storage medium is provided.
[0043] In some embodiments, a computer program is stored on a computer-readable storage medium; the computer program is executed by a processor to perform the steps of the method as described in the first aspect.
[0044] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:
[0045] This invention proposes a multi-granularity vulnerability similarity detection method for firmware of power system Internet of Things (IoT). Based on the detailed description of disclosed vulnerabilities, it performs multi-granularity similarity detection on the target firmware at the firmware layer, file layer, and code layer. The similarity comparison is performed at each level from coarse to fine and from the outside to the inside, avoiding the computational overhead and performance loss caused by directly comparing at the code layer in conventional similarity detection. This method can effectively improve detection efficiency and accuracy, and provide a basis for subsequent vulnerability verification and remediation.
[0046] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description
[0047] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.
[0048] Figure 1 This is a flowchart of the method for detecting multi-granularity vulnerabilities in IoT firmware for power systems provided in this application embodiment;
[0049] Figure 2 This is a schematic diagram of firmware layer detection provided in an embodiment of this application;
[0050] Figure 3 This is a schematic diagram of file layer detection provided in an embodiment of this application;
[0051] Figure 4 This is a schematic diagram of code-level detection provided in an embodiment of this application;
[0052] Figure 5 This is a structural diagram of the power system Internet of Things firmware multi-granularity vulnerability similarity detection device provided in the embodiments of this application;
[0053] Figure 6 This is a schematic diagram of the structure of a computer device according to an exemplary embodiment. Detailed Implementation
[0054] The following description and accompanying drawings fully illustrate specific embodiments described herein to enable those skilled in the art to practice them. Some embodiments may include or substitute parts and features of other embodiments. The scope of the embodiments herein encompasses the entire scope of the claims and all available equivalents thereof. Throughout this document, the terms “first,” “second,” etc., are used only to distinguish one element from another without requiring or implying any actual relationship or order between the elements. Indeed, a first element can also be referred to as a second element, and vice versa. Furthermore, the terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a structure, apparatus, or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a structure, apparatus, or device. Without further limitation, an element defined by the phrase “comprising one…” does not exclude the presence of other identical elements in the structure, apparatus, or device that includes said element. The various embodiments described herein are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.
[0055] In this document, unless otherwise stated, the term "multiple" means two or more.
[0056] In power systems, the widespread deployment of IoT devices, while facilitating the normal operation of various power system functions, also increases the avenues for cyberattacks. Many open-source components used in IoT device firmware can introduce known vulnerabilities, posing a serious threat to power system security. The purpose of this invention is to utilize publicly disclosed IoT device firmware vulnerabilities to provide a multi-granularity firmware vulnerability detection method, improving detection efficiency, reducing redundant work, and providing technical support for subsequent vulnerability protection.
[0057] Figure 1 A flowchart of the power system Internet of Things firmware multi-granularity vulnerability similarity detection method of the present invention is shown, as follows: Figure 1 As shown:
[0058] S1: Obtain the hash value of the firmware under test and compare it with the hash value of the sample firmware with known vulnerabilities. If they are the same, the firmware under test is considered to have known vulnerabilities.
[0059] In this method, firmware layer detection, i.e., firmware granular similarity detection, is performed first. In some embodiments of this application, the feature vector of the firmware to be tested is first extracted. Based on the feature vector, the similarity between the firmware to be tested and sample firmware with known vulnerabilities is calculated, and the similarity calculation results are output in descending order. The hash value of the firmware to be tested is then calculated in descending order using a hash function.
[0060] Please see Figure 2 In specific implementation, the method of this application first obtains the IoT firmware of the power system to be detected, extracts the feature vector of the firmware, which includes information such as manufacturer, device name, version number, firmware size, etc., and saves it as similarity comparison features at the firmware layer granularity.
[0061] An exemplary solution provided in this embodiment is as follows: the firmware wr740nv3v4.bin of a TPLink router, the extracted firmware layer feature vector is (TPLink, Router, wr740vn3v4, 3.87M).
[0062] In practice, firmware information in the vulnerability database can be retrieved in the order of manufacturer-device-version number. Based on the firmware layer granularity feature vector, the similarity between the firmware to be tested and the vulnerable firmware can be calculated and sorted in descending order. An exemplary scheme provided in this embodiment is as follows: the similarity results are sorted as (0.96, 0.92, 0.88).
[0063] Furthermore, after performing the above steps, or if the manufacturer, device, or other information cannot be found in the firmware, the file hash value is calculated using a hash function in descending order. Optionally, hash functions such as MD5 or SHA256 algorithms can be used.
[0064] An exemplary solution provided in this embodiment is as follows: the firmware under test, firmware_test.bin, uses the SHA256 algorithm to obtain its hash value.
[0065] Hash(firmware_test.bin) =
[0066] cda8efce82f1cdf5b4cd1402e23bfc24045061cc67704519298b6bc0b2d0efd6.
[0067] Furthermore, the hash value of the firmware under test is compared with the hash value of a firmware sample with a known vulnerability. The known vulnerability firmware refers to firmware with a clearly disclosed vulnerability that has been published in the vulnerability database. If the hash values are the same, it proves that the firmware contains a known vulnerability of the sample, and the vulnerability detection result "Firmware layer granularity similarity detection, same hash, vulnerability exists" is output, ending the detection process.
[0068] In some embodiments of this application, if the hash values are different, file-level detection, i.e., file-granular similarity detection, is performed. Please continue to see... Figure 1 :
[0069] S2: Extract the file set Fs from the firmware under test, compare the hash value of the target file Ff in the file set Fs with the hash value of the sample file with known vulnerability. If they are the same, the firmware under test is considered to have known vulnerability.
[0070] S3: If the hash value of file Ff is different from the hash value of the sample file, extract the feature attributes of file Ff in the file set Fs, and calculate the similarity between file Ff and the sample file based on the feature attributes. If the similarity is lower than the first threshold, it is considered that the firmware under test does not have any known vulnerabilities.
[0071] In some embodiments of this application, the files of the firmware under test are extracted using either binwalk or Firmware Mod Kit, and all files are decompressed to form a file set Fs. Specifically, the file Ff is located based on the description of the sample file name and location. Specifically, the characteristic attributes of file Ff include at least one of the following: file name, file path, file size, file type, architecture information, file comments, debugging information, and file static constants.
[0072] Please see further. Figure 3 :
[0073] Tools such as binwalk and Firmware Mod Kit were used to extract the firmware files, decompressing all files into a file set Fs. The file where the known vulnerability trigger is located was used as a comparison benchmark, that is, the file Ff was located based on the description of the sample file name and location.
[0074] An exemplary solution provided in this embodiment is as follows: if a buffer overflow vulnerability exists in the file webs, then the webs file is used as a comparison standard to search for the webs file in the file set Fs of the firmware to be tested after decompression. If the file exists, the hash values of the webs file to be tested and the vulnerable webs file are calculated. If the webs file is not found, the search continues for the next set of files to be tested and the vulnerable file until all files in Fs are detected.
[0075] Furthermore, the hash values of the file under test and the vulnerable file are compared. If they are the same, it indicates that a vulnerability exists, and the detection result is output. If the hash results are different, the file name, file path, file size, file type, architecture information, file comments, debugging information, file static constants and other attributes of the file are extracted as feature vectors for file-level granular similarity comparison.
[0076] Furthermore, the similarity between the file to be tested (Ff) and known vulnerable files is calculated, and the results are recorded. If the result is less than the preset threshold for file-level similarity (i.e., the first threshold), it is considered that no known vulnerability exists, and the file-level detection process ends. If the result is not less than the first threshold, it indicates that the two files have a high similarity and there is a very high probability that a vulnerability exists. The detection similarity result is output, and one or more target files (Ff) are output in descending order of similarity results, moving to the next step of code-level detection, i.e., code-level similarity detection.
[0077] An exemplary solution provided in this embodiment is as follows: calculate the similarity between the file to be tested (Ff) and a known vulnerable file, and record the calculation result. If the calculation result is not less than the first threshold of 0.75, it indicates that the two files have a high similarity and there is a high probability that a vulnerability exists. Output the detection similarity result "File-level granularity similarity detection, similarity degree 0.82". Output one or more target files (Ff) in descending order of similarity results and proceed to code-level detection. If the calculation result is less than the preset threshold, the detection process ends.
[0078] S4: If the similarity between file Ff and sample file is not lower than the first threshold, extract the assembly code of file Ff, calculate the similarity between the target function Fg in file Ff and the sample function with known vulnerabilities, and if the similarity is not lower than the second threshold, the firmware under test is considered to have vulnerabilities; if it is lower than the second threshold, the firmware under test is considered not to have known vulnerabilities.
[0079] Specifically, reverse engineering of file Ff is performed using either IDA Pro or Ghidra to extract its assembly code. Function Fg is located based on the description of the sample function name and location. Non-architecture-dependent parameters are selected as feature vectors to extract the feature vector of function Fg, and the similarity between function Fg and the sample function is calculated based on the feature vector. The feature vector includes at least one of the following: function name, function comments, function static constants, three-layer function call relationships, and constant string information from the code block where the vulnerability is triggered. The similarity between function Fg and the existing sample function is calculated using any one of the following similarity algorithms: cosine similarity, Euclidean distance, Hamming distance, or Jaccard distance.
[0080] Please see further. Figure 4 :
[0081] In some embodiments of this application, reverse analysis tools such as IDA Pro or Ghidra are used to analyze the target file Ff. Based on the description of the known vulnerable function names and locations, reverse analysis of the target file Ff and location of the function to be tested are performed. In order to eliminate the differences between reverse analysis instructions of different architectures, non-architecture-dependent parameters are selected as feature vectors to extract the feature vector of the function to be tested, including function name, function comments, function static constants, three-level function call relationship (including parent function and child function), and constant string information (such as comments, static constants, etc.) of the code block where the vulnerability is triggered.
[0082] The code-granular similarity between the target function and the vulnerable function is compared. Similarity algorithms such as cosine similarity, Euclidean distance, Hamming distance, and Jaccard distance are used for calculation, and the result is compared with a preset similarity threshold. If the result is not less than the threshold, it indicates that the target function and the vulnerable function have a high similarity and there is a high probability that a vulnerability exists. The detection result is output, such as "Code granularity similarity detection, similarity 0.85". If the result is less than the preset threshold, the result is output that no vulnerability exists, and the detection process ends.
[0083] After the above steps, based on the detailed description of the disclosed vulnerabilities, multi-granularity similarity detection can be performed on the target firmware at the firmware layer, file layer, and code layer. The similarity comparison at each level is carried out from coarse to fine and from the outside to the inside, avoiding the computational overhead and performance loss caused by directly comparing from the code layer in conventional similarity detection. This can effectively improve detection efficiency and accuracy, and provide a basis for subsequent vulnerability verification and remediation.
[0084] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the diagram may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0085] Please see Figure 5 One embodiment of this application provides a firmware multi-granularity vulnerability similarity detection device for power system Internet of Things (IoT), including a firmware layer detection module 10, a file layer first detection module 20, a file layer second detection module 30, and a code layer detection module 40; wherein,
[0086] Firmware layer detection module 10 is used to obtain the hash value of the firmware under test and compare the hash value of the firmware under test with the hash value of the sample firmware with known vulnerabilities. If they are the same, the firmware under test is considered to have known vulnerabilities; if they are different, the file layer first detection module 20 is started.
[0087] The first file layer detection module 20 is used to extract the file set Fs from the firmware under test, compare the hash value of the target file Ff in the file set Fs with the hash value of the sample file with known vulnerability. If they are the same, the firmware under test is considered to have known vulnerability; if they are different, the second file layer detection module 30 is started.
[0088] The second file layer detection module 30 is used to extract the feature attributes of file Ff in the file set Fs, and calculate the similarity between file Ff and sample file based on the feature attributes. If the similarity is lower than the first threshold, it is considered that the firmware under test does not have any known vulnerabilities; if the similarity is not lower than the first threshold, the code layer detection module 40 is activated.
[0089] The code layer detection module 40 is used to extract the assembly code of file Ff, calculate the similarity between the target function Fg in file Ff and the sample function with known vulnerabilities, and if the similarity is not lower than the second threshold, the firmware under test is considered to have a vulnerability; if it is lower than the second threshold, the firmware under test is considered not to have a known vulnerability.
[0090] Specific limitations regarding the aforementioned power system IoT firmware multi-granularity vulnerability similarity detection device can be found in the limitations of the power system IoT firmware multi-granularity vulnerability similarity detection method described above, and will not be repeated here. Each module in the aforementioned power system IoT firmware multi-granularity vulnerability similarity detection device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.
[0091] In another embodiment of this application, a computer device is provided, which may be a server, and its internal structure diagram may be as follows. Figure 6 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores static and dynamic information data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the above method embodiments.
[0092] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0093] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the method embodiments described above.
[0094] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.
[0095] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.
Claims
1. A method for detecting multi-granularity vulnerability similarity in firmware for power system Internet of Things (IoT) systems, characterized in that, include: Obtain the hash value of the firmware under test, and compare the hash value of the firmware under test with the hash value of the sample firmware with a known vulnerability. If they are the same, the firmware under test is considered to have the known vulnerability. If they are different, then: The firmware under test is subjected to file set extraction to obtain file set Fs. The hash value of the target file Ff in file set Fs is compared with the hash value of the sample file containing the known vulnerability. If they are the same, the firmware under test is considered to contain the known vulnerability. If they are different, then: Extract the feature attributes of file Ff from the file set Fs, and calculate the similarity between file Ff and the sample file based on the feature attributes. Based on the comparison of the similarity with a first threshold, determine whether the firmware under test has the known vulnerability.
2. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 1, characterized in that, The method further includes: If the similarity between the file Ff and the sample file is lower than the first threshold, then it is considered that the known vulnerability does not exist.
3. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 2, characterized in that, The method further includes: If the similarity between the file Ff and the sample file is not lower than the first threshold, then the assembly code of the file Ff is extracted, and the similarity between the target function Fg in the file Ff and the sample function with the known vulnerability is calculated. If the similarity is not lower than the second threshold, then the firmware under test is considered to have the vulnerability. If it is lower than the second threshold, then the firmware under test is considered not to have the known vulnerability.
4. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 3, characterized in that, The step of obtaining the hash value of the firmware under test and comparing the hash value of the firmware under test with the hash value of a sample firmware containing a known vulnerability further includes: First, the feature vector of the firmware under test is extracted. Based on the feature vector, the similarity between the firmware under test and the sample firmware containing the known vulnerability is calculated, and the similarity calculation results are output in descending order. Then, the hash value of the firmware under test is calculated in descending order.
5. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 4, characterized in that, The step of calculating the hash value of the firmware under test in descending order further includes: The hash value of the firmware under test is calculated using a hash function in descending order.
6. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 3, characterized in that, The step of extracting the file set Fs from the firmware under test further includes: using either binwalk or Firmware Mod Kit to extract the files of the firmware under test, and decompressing all the files to form the file set Fs.
7. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 6, characterized in that, The step of comparing the hash value of the target file Ff in the file set Fs with the hash value of the sample file containing the known vulnerability further includes: Based on the description of the sample file name and location, the file Ff is located.
8. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 7, characterized in that, The characteristic attributes of the file Ff include at least one of the following: filename, file path, file size, file type, architecture information, file comments, debugging information, and file static constants.
9. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 8, characterized in that, The step of extracting the assembly code from the file Ff further includes: Use either IDA Pro or Ghidra to reverse engineer the file Ff to extract its assembly code.
10. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 9, characterized in that, The step of calculating the similarity between the objective function Fg in the file Ff and the sample function containing the known vulnerability further includes: Based on the description of the sample function name and location, the function Fg is located.
11. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 10, characterized in that, The step of extracting the assembly code of the file Ff and calculating the similarity between the target function Fg in the file Ff and the sample function containing the known vulnerability further includes: Non-architecture-dependent parameters are selected as feature vectors to extract the feature vector of the function Fg, and the similarity between the function Fg and the sample function is calculated based on the feature vector.
12. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 11, characterized in that, The feature vector includes at least one of the following: function name, function comment, function static constant, three-level function call relationship, and constant string information of the code block where the vulnerability is triggered.
13. The method for detecting multi-granularity vulnerability similarity in power system IoT firmware as described in claim 12, characterized in that, The step of calculating the similarity between the function Fg and the sample function based on the feature vector further includes: The similarity between the function Fg and the sample function is calculated using any one of the following similarity algorithms: cosine similarity, Euclidean distance, Hamming distance, and Jaccard distance.
14. A device for detecting multi-granularity vulnerability similarity in firmware for power system Internet of Things (IoT) applications, characterized in that, It includes a firmware layer detection module, a first file layer detection module, a second file layer detection module, and a code layer detection module; among which, The firmware layer detection module is used to obtain the hash value of the firmware under test and compare the hash value of the firmware under test with the hash value of the sample firmware with known vulnerabilities. If they are the same, the firmware under test is considered to have the known vulnerability; if they are different, the file layer first detection module is activated. The first file layer detection module is used to extract a file set Fs from the firmware under test, compare the hash value of the target file Ff in the file set Fs with the hash value of the sample file containing the known vulnerability, and if they are the same, the firmware under test is considered to have the known vulnerability; if they are different, the second file layer detection module is activated. The second file-level detection module is used to extract the feature attributes of file Ff in the file set Fs, and calculate the similarity between file Ff and the sample file based on the feature attributes. If the similarity is lower than a first threshold, it is considered that the firmware under test does not have the known vulnerability; if the similarity is not lower than the first threshold, the code-level detection module is activated. The code layer detection module is used to extract the assembly code of the file Ff, calculate the similarity between the target function Fg in the file Ff and the sample function with the known vulnerability, and if the similarity is not lower than the second threshold, the firmware under test is considered to have the vulnerability; if it is lower than the second threshold, the firmware under test is considered not to have the known vulnerability.
15. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-13.
16. A computer-readable storage medium, characterized in that, It stores a computer program thereon; the computer program is executed by a processor to implement the method as described in any one of claims 1-13.