A device code-based risk scanning method, system and computing device

Abstract

The application discloses a kind of based on device code's risk scanning method, system and computing device, comprising: obtaining a device code, the device code is obtained from first device, and the device code is sent from first device to second device;Wherein, the device code includes at least one software code;Generate an update record;Wherein, the update record includes the relationship record between the device code and the first device and / or the second device;When detecting that there is security risk in the device code, according to the update record, scanning result is sent to the first device and / or the second device.The application can automatically send scanning result to user by the update record generated automatically, improve the efficiency and accuracy of risk scanning.

Description

Technical Field

[0001] This invention relates to the field of code risk prevention and control, and in particular to a risk scanning method, system and computing device based on device code. Background Technology

[0002] When performing vulnerability detection on website backend systems and online hardware devices on online servers (e.g., web servers), since the intermediate code, binary code on the server, and binary code in the hardware device are all code that cannot be recognized by humans (e.g., Linux Kernel, Web Server, etc.), and the server and hardware device are already online and running, the current technology involves sending a network packet simulating an attack on the server and hardware device based on a specific vulnerability's behavioral description via the network. After the server and hardware device receive the network packet, it monitors whether the server and hardware device's response matches the behavioral description of the specific vulnerability. If they match, it indicates that the online server and hardware device contains the specific vulnerability, thus providing vulnerability scanning functionality for the operators of the server and online hardware device.

[0003] When analyzing and scanning for vulnerabilities in online servers and / or hardware devices, the code running on these devices is primarily intermediate or binary code. Without the source code, it's impossible to compare the patched source code with the online system's source code; source code comparison is impossible without it. Furthermore, vulnerability analysis using simulated packets requires network support. In offline or network-unavailable situations, simulated packets cannot be delivered to the tested online server and / or hardware device, making vulnerability analysis and risk monitoring impossible. Additionally, if a specific vulnerability's driver cannot be triggered by simulated packets, that specific vulnerability cannot be detected using simulated packets.

[0004] For IoT sensors, network communication devices (such as WiFi routers), or other embedded devices with limited computing power, code component analysis cannot be performed directly on these devices like virus scanning software on a personal computer. Firstly, the hardware and software specifications of a personal computer, besides considering the computing power required by the operating system itself, also reserve sufficient computing power for user-installed applications. Secondly, personal computers provide general-purpose operating platforms, not for single or specific functions, allowing different applications to be installed and expanded into the operating environment; hence, virus scanning software can be installed and used on a personal computer. For IoT sensors, network communication devices (such as WiFi routers), or other embedded devices with limited computing power, their function is not as a general-purpose operating platform but rather to provide single or specific services. They do not have the conditions to arbitrarily install applications to expand their capabilities. Furthermore, their hardware and software specifications are designed primarily to optimize the single or specific services they provide. Therefore, code component analysis is difficult to run on these devices.

[0005] In summary, a significant technical challenge in the field of information security risk scanning technology is how to perform vulnerability scanning on hardware devices that lack source code, are online, or whose software and hardware specifications are designed for single or specific functions. Currently, there is no device code risk scanning method, software system, or computing device capable of providing vulnerability analysis for devices in situations where the device system's source code is lacking, the network is offline, computing power is insufficient, and / or application expansion is not possible. Therefore, such a method and system are urgently needed. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a risk scanning method, system, and computing device based on device code, which automatically sends scan results to the user through self-generated update records, thereby improving the efficiency and accuracy of risk scanning.

[0007] Option 1:

[0008] A risk scanning method based on device code includes:

[0009] A device code is acquired from a first device, and the device code is sent from the first device to a second device; wherein the device code includes at least one piece of software code;

[0010] An update record is generated; wherein the update record includes a record of the relationship between the device code and the first device and / or the second device;

[0011] When a security risk is detected in the device code, a scan result is sent to the first device and / or the second device based on the update record.

[0012] Furthermore, issuing the scan result means sending a notification of the scan result to at least one of the users, operators, or managers of the first and second devices through at least one network communication channel.

[0013] Furthermore, the at least one piece of software code comprises at least one piece of binary code.

[0014] Furthermore, the acquisition device code specifically includes:

[0015] Based on an update request, the device code is obtained from a storage medium of the first device.

[0016] Furthermore, the method for obtaining the device code also includes:

[0017] When the update request is received, a device code corresponding to the version information or device specification information in the update request is obtained from the storage medium and used as the device code; wherein, the device specification information includes at least one of a device's product specifications, hardware specifications, and software specifications.

[0018] Furthermore, sending the device code to the second device specifically includes:

[0019] Based on the network location information of the second device included in the update request, the device code is sent to the second device.

[0020] Furthermore, the detection of security risks in the device code specifically includes:

[0021] When at least one code analysis event is triggered, at least one risky code is compared with the at least one software code in terms of component content; wherein, the at least one risky code includes at least one of patch code, malicious program code, and computer program code written in any computer programming language associated with the at least one software code.

[0022] Furthermore, the at least one risk code is pre-collected based on a list of at least one risk code logins, or it is collected when a risk code is added to or updated to the list of at least one risk code logins.

[0023] Furthermore, the at least one code analysis event is triggered when a list of the at least one software code is obtained, or when the at least one risky code is added to or updated.

[0024] Furthermore, comparing the at least one risk code with the at least one software code specifically includes:

[0025] Extract at least one first component feature corresponding to the at least one risk code;

[0026] Extract at least one second component feature corresponding to the at least one software code;

[0027] Compare the at least one first component feature and the at least one second component feature.

[0028] Furthermore, the at least one first component feature is obtained by analyzing the code composition content and / or code execution result corresponding to the at least one risk code.

[0029] Furthermore, the code composition includes the at least one risk code and / or at least one first intermediate code compiled from the at least one risk code, and the code execution result includes the semantic information revealed by the at least one risk code and / or the at least one first intermediate code during the simulated execution process.

[0030] Furthermore, the at least one second component feature is obtained by analyzing the content of at least one code component corresponding to the at least one software code and / or the execution result of at least one code.

[0031] Furthermore, the at least one code component includes at least one binary code and / or at least one second intermediate code after the at least one binary code is decompiled, and the execution result of the at least one code includes the semantic information revealed by the at least one binary code and / or the at least one second intermediate code during the simulated execution process.

[0032] Furthermore, the programming language structure of the intermediate code is declared by an intermediate language, an intermediate representation, a structured language, and / or a structured protocol.

[0033] Furthermore, before the code analysis event is triggered, it also includes:

[0034] Based on the list of components of the at least one software code, at least one code analysis event is detected, and the code analysis event corresponding to the at least one risky code is one of the at least one code analysis events.

[0035] Furthermore, the composition list is obtained by scanning and / or analyzing the composition of the device code when the device code is acquired.

[0036] Furthermore, the component list includes metadata of the device code itself and / or metadata of the at least one piece of software code contained in the components of the device code.

[0037] Furthermore, the at least one piece of software code exists in the composition of the device code in the form of a system kernel, driver, application, component, and / or category library.

[0038] Furthermore, based on the component list, the risk code login list corresponding to each software code contained in the component list is monitored, and code analysis events are detected by monitoring the anomalies in the risk code login list.

[0039] Furthermore, the method for obtaining the component list specifically includes:

[0040] The device code is a system image file. The components contained in the system image file are scanned and / or analyzed to identify the at least one piece of software code present in the system image file, thereby obtaining the list of components of the at least one piece of software code.

[0041] Alternatively, the device code may be a software code package. The components contained in the software code package are scanned and / or analyzed to identify the at least one software code present in the software code package, thereby obtaining the list of components of the at least one software code.

[0042] Furthermore, the step of sending the scan result to the first device and / or the second device based on the updated record specifically includes:

[0043] Search the update records to obtain the relationship records within them;

[0044] Based on the relationship record, scan results are issued to at least one user, operator, or manager of the first and second devices.

[0045] Furthermore, the scan result includes at least one of a scan report and a scan status notification; wherein, the scan report is used to display the comparison results of the component content of the at least one software code and the at least one risk code; and the scan status notification is used to provide a notification of the scan status to at least one of the users, operators, or managers of the first device and the second device.

[0046] Option 2:

[0047] A risk scanning system based on device code includes: a code sending module, an update record generation module, and a scan result notification module;

[0048] The code sending module is used to acquire a device code, which is acquired from a first device, and send the device code from the first device to a second device; wherein, the device code includes at least one piece of software code;

[0049] The update record generation module is used to generate an update record; wherein, the update record includes a record of the relationship between the device code and the first device and / or the second device;

[0050] The scan result notification module is used to send scan results to the first device and / or the second device according to the update record when a security risk is detected in the device code.

[0051] Furthermore, it also includes: a first feature extraction unit, a second feature extraction unit, and a feature comparison unit;

[0052] The first feature extraction unit is used to extract at least one first component feature corresponding to at least one risk code;

[0053] The second feature extraction unit is used to extract at least one second component feature corresponding to the at least one software code;

[0054] The feature comparison unit is used to compare at least one first component feature and at least one second component feature.

[0055] Furthermore, the first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one extraction unit;

[0056] The at least one analysis unit is used to analyze the code composition content and / or code execution result corresponding to the at least one risk code to obtain the at least one first component feature, and / or analyze the code composition content and / or code execution result corresponding to the at least one software code to obtain the at least one second component feature;

[0057] The at least one extraction unit is used to extract the at least one first component feature and / or the at least one second component feature obtained after analysis.

[0058] Furthermore, it also includes: at least one detection unit,

[0059] The at least one detection unit is used to monitor the risk code login list corresponding to each software code in the composition list based on the composition list of the at least one software code, and to detect code analysis events by monitoring the anomalies of the risk code login list.

[0060] Option 3:

[0061] A computing device for risk scanning based on device code includes: a code sending module, an update record generation module, and a scan result notification module;

[0062] The code sending module is used to acquire a device code, which is acquired from a first device, and send the device code from the first device to a second device; wherein, the device code includes at least one piece of software code;

[0063] The update record generation module is used to generate an update record; wherein, the update record includes a record of the relationship between the device code and the first device and / or the second device;

[0064] The scan result notification module is used to send scan results to the first device and / or the second device according to the update record when a security risk is detected in the device code. Attached Figure Description

[0065] Figure 1 This is a flowchart illustrating a risk scanning method based on device code according to the present invention;

[0066] Figure 2 This is a schematic diagram of the structure of a risk scanning system based on device code according to the present invention.

[0067] Figure 3 This is a schematic diagram of the structure of a risk scanning computing device based on device code according to the present invention.

[0068] In the diagram, 1 is the risk scanning system; 2 is the code sending module; 3 is the update record generation module; 4 is the scan result notification module; 5 is the first device; 6 is the second device; 11 is the computing device; 21 is the code sending module; 31 is the update record generation module; and 41 is the scan result notification module. Detailed Implementation

[0069] This invention will be more fully understood through the following description, including the following glossary of terms and concluding examples. For the sake of brevity, publications referenced in this specification, including patent disclosures, are incorporated herein by reference.

[0070] The following are detailed descriptions of embodiments. These embodiments are not limiting and merely represent various forms and features of the invention. They are used only as illustrative examples and do not limit the scope of protection intended by the invention. Furthermore, the drawings in the embodiments omit unnecessary components or components that can be accomplished with ordinary techniques to clearly demonstrate the technical features of the invention.

[0071] In its most limited technical sense, the term "software code" as used herein comprises any binary code, intermediate code, and / or any computer program code written in a computer programming language for loading and execution. The term "device code" as used herein refers to code used to run on a device and provide logical operations and services to that device. This device code consists of binary code, intermediate code, and / or any computer program code written in a computer programming language; that is, the device code contains at least one piece of software code, which exists in the component form of the device code as a component including a system kernel, driver, application program, component, and / or class library. The term "binary code" as used herein can include any code that uses binary as its representation format. The term "intermediate code" as used herein can include any code represented by a structure declared by an intermediate language, intermediate representation, structured language, and / or structured protocol; for example, Java Bytecode represented according to a format defined by an intermediate representation, and LLVM bitcode derived from binary code, are both types of intermediate code and can be considered as intermediate code. The "risk code" described herein comprises any type of binary code, intermediate code, and / or any type of computer program code written in a computer programming language for loading and execution. The types of risk code include patch code, malicious code, and / or any code used to correct or create a software vulnerability or software virus. The "metadata" described herein, also known as interpretive data, intermediate data, or metadata, is data describing an object or related information. The "risk code registry" described herein may include any list registered, recorded, and / or represented according to a structure declared by a structured language and / or structured protocol. This list may be stored and published in the form of a file, database, and / or webpage. The content of the list includes registry information for the risk codes described herein, including the content of the risk code itself, the metadata of the risk code, and the software vulnerability or software virus information corresponding to the risk code. The CVE (Common Vulnerabilities and Exposures) repository is one implementation of the risk code registry described herein, but is not limited thereto. The "semantic information" mentioned in this article may include, during the execution of a code in a simulated manner, the values ​​retrieved from memory and / or intermediate variables, the execution history of each instruction during the execution process, the output / input values ​​of functions, and / or any kind of numerical information that can be extracted.All or part of the semantic information of two codes can be used as component features for comparison. The similarity between the two codes is determined by the degree of agreement between the comparisons.

[0072] Furthermore, the "code sending module," "update record generation module," "scan result notification module," "first feature extraction unit," "second feature extraction unit," "feature comparison unit," "analysis unit," "extraction unit," and "detection unit" described herein are processing units that provide logical operations or services. The implementation of the processing unit may include a category library, software component, software agent, application program, any program block that can be built into, installed, imported, or extended into the "device code-based risk scanning system or computing device" described herein, or any integrated circuit unit designed in a hardware description language that can be embedded in the "device code-based risk scanning computing device" described herein.

[0073] The "Device Code-Based Risk Scanning System" described herein can be implemented as a system firmware, application program, software engine, website system, operating system, or any software platform that can be extended by the program. In a preferred embodiment, the "Device Code-Based Risk Scanning System" described herein can be deployed and run on a single machine, that is, all the code sending module, update record generation module, scan result notification module, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, extraction unit, and detection unit described herein are integrated into a single system and deployed on a single machine. In another preferred embodiment, the "Device Code-Based Risk Scanning System" described herein can be implemented through the collaboration of multiple machines. That is, the processing units described herein, such as the code sending module, update record generation module, scan result notification module, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, extraction unit, and detection unit, are provided to different machines. The processing units in different machines interact and collaborate with each other through connection methods including the Internet, WiFi, and Bluetooth, thereby integrating multiple machines into a device code-based risk scanning system.

[0074] The "computing device for risk scanning based on device code" described herein may be implemented as a network communication device, a server, or any information and communication device with networking, data processing, or control capabilities. In a preferred embodiment, the "computing device for risk scanning based on device code" described herein may be implemented in a single machine, that is, all the code sending module, update record generation module, scan result notification module, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, extraction unit, and detection unit described herein may be integrated into the same machine as the computing device for risk scanning based on device code. In another preferred embodiment, the "device code-based risk scanning computing device" described herein can be implemented through the collaboration of multiple machines. That is, the processing units described herein, such as the code sending module, update record generation module, scan result notification module, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, extraction unit, and detection unit, are provided to different machines. The processing units in different machines can interact with each other through connection methods including the Internet, WiFi, and Bluetooth, thereby integrating multiple machines into a device code-based risk scanning computing device.

[0075] Continuing from the above, in a preferred embodiment, the "code sending module," "update record generation module," "scan result notification module," "first feature extraction unit," "second feature extraction unit," "feature comparison unit," "analysis unit," "extraction unit," and "detection unit" described herein can be individually implemented in different processing units. In another preferred embodiment, at least two of the "code sending module," "update record generation module," "scan result notification module," "first feature extraction unit," "second feature extraction unit," "feature comparison unit," "analysis unit," "extraction unit," and "detection unit" described herein can also be implemented within the same processing unit.

[0076] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0077] See Figure 1 The above is a flowchart illustrating a risk scanning method based on device code provided in an embodiment of the present invention, specifically including the following steps:

[0078] S1. Obtain a device code, the device code being obtained from a first device 5, and send the device code from the first device 5 to a second device 6; wherein the device code is generated by the first device 5 and includes at least one software code;

[0079] S2. Generate an update record; wherein, the update record includes a record of the relationship between the device code and the first device 5 and / or the second device 6;

[0080] S3. When a security risk is detected in the device code, a scan result is sent to the first device 5 and / or the second device 6 according to the update record.

[0081] like Figure 2 The diagram shows a structural block diagram of a device code risk scanning system 1 according to the present invention. A preferred embodiment of the device code risk scanning method of this invention is provided. The risk scanning system 1 is a website system, which can be deployed on a first device 5, a second device 6, or any computing device 11 with network connectivity and logical operation processing capabilities; the code sending module 2, the update record generation module 3, and the scan result notification module 4 are processing units integrated into the risk scanning system 1.

[0082] In a preferred embodiment, the risk scanning system 1 is deployed in the second device 6. The first device 5, through an application programming interface (API) provided by the code sending module 2, can call the API within its own software system to provide device code to the code sending module 2. This allows the code sending module 2 to obtain the device code from the first device 5 and send it to the second device 6. The API may include technologies such as REST API and WebService, but is not limited thereto. The code sending module 2 itself may also include a web front-end program or a software agent program implemented in Java. The first device 5 can dynamically load the code sending module 2 implemented as a web front-end program through a browser and execute the web front-end program in the browser. Alternatively, after the risk scanning system 1 provides another API for downloading the software agent program, the first device 5 can call the other API to download the software agent program, dynamically load it, and execute it in the Java virtual environment of the first device 5. After the dynamic loading and execution of the web page front-end program or the software agent program are completed, the web page front-end program or the software agent program can obtain the device code obtained from the first device 5 on the first device 5, and send the device code from the first device 5 to the second device 6 through the application interface. The device code is the device code stored in the storage medium of the first device 5, and the web application or the software agent program can obtain the device code by reading the storage medium. Alternatively, the code sending module 2 can also directly establish a TCP / UDP socket connection to the first device 5. For example, an authorized identity can access the first device 5 through a connection using the SSH (Secure Socket Shell) communication protocol. After traversing the storage medium and searching for the device code through system commands for accessing the storage medium, the required device code can be obtained from the storage medium of the first device 5 through a connection using the SCP (Secure Copy Protocol) communication protocol, and the obtained device code can be sent to the second device 6, thus enabling the device code to be sent from the first device 5 to the second device 6.

[0083] In a preferred embodiment, the risk scanning system 1 is deployed in the first device 5. Device code is stored in the storage medium of the first device 5. The code sending module 2 obtains the device code by reading the storage medium, and then establishes a TCP / UDP socket connection to the second device 6. Through a pre-agreed communication protocol, the device code is sent to the second device 6 and updated to the device code running on the second device 6. For example, the code sending module 2 can establish a TCP / UDP socket connection to the second device 6, access the first device 6 through an authorized identity via the SSH (Secure Socket Shell) communication protocol, obtain the required device code from the storage medium of the first device 5 through the SCP (Secure Copy Protocol) communication protocol, and send the obtained device code to the second device 6. This allows the device code to be sent from the first device 5 to the second device 6 and updated on the second device 6, making the device code the device code running on the second device 6.

[0084] In a preferred embodiment, the risk scanning system 1 is deployed on a computing device 11, separate from the first device 5 and the second device 6. Using an implementation equivalent to "risk scanning system 1 on the second device 6" described above, the risk scanning system 1 deployed on the computing device 11 can, through the application interface of the code sending module 2 called by the first device 5 and / or by dynamically loading the web application or software agent program included in the code sending module 2 into the first device 5, allow the code sending module 2 to obtain a device code from the first device 5. This enables the establishment of a TCP / UDP socket connection to the second device 6, and the transmission of the device code to the second device 6 via a pre-agreed communication protocol. The device code is stored in the storage medium of the first device 5.

[0085] In a preferred embodiment, the second device 6 may have an HTTP interface enabled, allowing the code sending module 2 to establish a TCP / UDP socket connection to the HTTP interface and transmit the device code to the second device 6 via the HTTP communication protocol.

[0086] The method of obtaining device code from the first device 5 and sending it to the second device 6 described above is not limited to this, and those skilled in the art can make any equivalent modifications according to actual application needs. The advantage of the above-described implementation method is that when the risk scanning system 1 is deployed on the second device 6, regardless of whether the first device 5 is an online server, an IoT sensor, a network communication device (e.g., a WiFi router), or other embedded device with limited computing power, the code component analysis of the device code obtained from the first device 5 does not need to be performed on the first device 5; nor does it require installing additional applications on the first device 5 to obtain the device code. Similarly, when the risk scanning system 1 is deployed on the first device 5, regardless of whether the second device 6 is an online server, an IoT sensor, a network communication device (e.g., a WiFi router), or other embedded device with limited computing power, the code component analysis of the device code running on the second device 6 does not need to be performed on the second device 6. When the risk scanning system 1 is deployed on another computing device 11 that is different from the first device 5 and the second device 6, regardless of whether the first device 5 and / or the second device 6 is an online server, an IoT sensor, a network communication device (e.g., a WiFi wireless router) or other embedded device with limited computing power, the computational work of code component analysis of the device code obtained from the first device 5, and / or the computational work of code component analysis of the device code running on the second device 6, does not need to be performed on the first device 5 and the second device 6.

[0087] In a preferred embodiment, the code sending module 2 in the risk scanning system 1 obtains a device code from the first device 5 in response to an update request.

[0088] In a preferred embodiment, the risk scanning system 1 operates on the second device 6, and the update request is an update request generated on the first device 5. When the update request is generated, version information or device specification information is provided to the update request. Option 1: The update request is generated by a software system running on the first device 5. When generating the update request, version information or device specification information is provided in the update request. Based on the version information or device specification information in the update request, the software system retrieves a device code corresponding to the version information or device specification information from the storage medium of the first device 5. Then, the software system calls the application interface provided by the code sending module 2 to provide the device code to the code sending module 2. Alternatively, the software system calls the application interface provided by the risk scanning system 1 for submitting update requests to submit the update request to the code sending module 2 of the risk scanning system 1. The code sending module 2 on the second device 6 then connects to the first device 5 through an authorized identity using the SSH (Secure Socket Shell) communication protocol. Based on the version information or device specification information in the update request, it traverses the storage medium using system instructions to access the storage medium to find the device code. Finally, it retrieves the required device code from the storage medium of the first device 5 through the SCP (Secure Copy Protocol) communication protocol. Option 2: The update request is generated by a user operating on a human-machine interface (e.g., operating an interface for creating and submitting update requests) that dynamically loads and executes a web front-end program or software agent program on the first device 5. When generating the update request, the user can input version information or device specification information into the update request through the human-machine interface. After submitting the update request, the dynamically loaded web front-end program or software agent program can retrieve a device code corresponding to the version information or device specification information from the storage medium of the first device 5 according to the version information or device specification information in the update request, and send it to the second device 6.

[0089] In a preferred embodiment, the risk scanning system 1 runs on the first device 5. The update request is sent from the second device 6 to the first device 5. When generating the update request, version information or device specification information is provided in the update request. Alternatively, the software system running on the second device 6 generates the update request and fills it with version information of the required device code or device specification information of the second device 6. The update request is then sent to the code sending module 2 of the risk scanning system 1 running on the first device 5 by calling the application interface provided by the risk scanning system 1 for submitting an update request. After receiving the update request, the code sending module 2 retrieves the device code corresponding to the version information or device specification information from the storage medium of the first device 5 and sends it to the second device 6 to update it with the device code running on the second device 6. Option 2: The update request can also be generated by the risk scanning system 1 running on the first device 5. When the update request is generated, version information or device specification information is provided in the update request. The code sending module 2 obtains the device code corresponding to the version information or device specification information from the storage medium of the first device 5 according to the version information or device specification information in the update request, and then sends it to the second device 6 to update it with the device code running on the second device 6.

[0090] In a preferred embodiment, the risk scanning system 1 runs on a separate computing device 11, distinct from the first device 5 and the second device 6. The update request is generated on the first device 5, and version information or device specification information is provided in the update request when it is generated. Alternatively, the update request is generated by the second device 6 and sent to the first device 5, and version information or device specification information is provided in the update request when it is generated. In one embodiment, the update request is generated by a software system running on the first device 5 or by a user through a web front-end program or software agent program dynamically loaded by the code sending module 2. Through a call to an application interface provided by the risk scanning system 1 for sending device code, the device code corresponding to the version information or device specification information is sent to the other computing device 11, and then sent by the code sending module 2 to the second device 6, updating to the device code running on the second device 6. Option 2: The update request is generated by the software system running on the first device 5 or by the web front-end program or software agent program of the dynamically loaded code sending module 2. The update request is submitted to the code sending module 2 of the risk scanning system 1 via a call to an application interface provided by the risk scanning system 1 for submitting update requests. The code sending module 2, through an authorized identity, connects to the first device 5 via an SSH (Secure Socket Shell) communication protocol connection. Based on the version information or device specification information in the update request, it traverses the storage media using system instructions to access the storage media to find the device code. Then, through an SCP (Secure Copy Protocol) communication protocol connection, it retrieves the required device code from the storage media of the first device 5 and sends it to the second device 6 to update it with the device code running on the second device 6. Option 3: The software system running on the second device 6 generates the update request, and fills the update request with version information of the required device code or device specification information of the second device 6. The update request is then sent to the code sending module 2 of the risk scanning system 1 running on the first device 5 via the application interface provided by the risk scanning system 1 for submitting an update request. After receiving the update request, the code sending module 2 retrieves the device code corresponding to the version information or device specification information from the storage medium of the first device 5, and then sends it to the second device 6 to update it with the device code running on the second device 6.

[0091] In a preferred embodiment, both the version information and the device specification information are part of the metadata of the device code. The device specification information includes at least one of the product specifications, hardware specifications, and software / firmware specifications of the device supported by the device code.

[0092] The advantage derived from the technical means of generating the update request by the first device 5 is that the second device 6 does not need to know the network location information of the first device 5 and / or the other computing device 11. The first device 5 and the other computing device 11 update the device code for the second device 6 by pushing the update. In a preferred embodiment, the network location information of the second device 6 is filled in by the user through the human-machine interface of the dynamically loaded web front-end program or software agent program in the update request, or the network location information of the second device 6 is written into the update request by the risk scanning program 1 after receiving the update request; then the code sending module 2 transmits the device code to the second device 6 for update based on the network location information in the update request. In this asynchronous method of updating the device code, the sending of the update request and the receiving of the device code are completed through two connections with different connection objects, which is different from the traditional OTA update where the second device 6 itself establishes a connection to the server providing the update code to download it.

[0093] In fact, the above scenario eliminates the need for the second device 6 to download the device code itself. Either the first device 5 or the other computing device 11, with the required permissions, can send an update request to the risk scanning system 1 using the improved method described above. Subsequently, the risk scanning system 1 establishes a connection with the second device 6 based on its network location information and then actively transmits the device code to it to complete the update.

[0094] The network location information can be simply an IP address. The risk scanning system 1 and the second device 6 share a default communication protocol (the port supported by the device by default) for transmitting device code. In this case, the risk scanning system 1 only needs to know the device's IP address to actively connect and transmit updated device code. Alternatively, the network location information can be an IP address plus a port, meaning it includes the specified network communication protocol. In this case, the risk scanning system 1 and the second device 6 do not need any default network communication protocol. The risk scanning system 1 can also establish a connection between the first device 5 and the other computing device 11 based on the IP address (location) plus the port (communication protocol) and transmit updated device code. The method of asynchronously updating device code is not limited to this; those skilled in the art can make any equivalent design changes based on actual application requirements.

[0095] There are several ways for the risk scanning system 1 to obtain the network location information of the second device 6. In one approach, the user of the second device 6 registers and logs in the metadata of the second device 6 to the database of the risk scanning system 1. This metadata includes the network location information of the second device 6. The risk scanning system 1 can then find the network location information of the second device 6 from the database by searching its metadata. Alternatively, the metadata of the second device 6 can also include at least one of its product specifications, hardware specifications, and software / firmware specifications. The risk scanning system 1 can search the database using the information included in the update request (such as the product specifications, hardware specifications, and software / firmware specifications supported by the device code). Option 2: Risk scanning system 1 and second device 6 are both in a network environment that can interact via multicast packets. Risk scanning system 1 can periodically send multicast packets to the network to search for devices. When second device 6 is a device that supports the communication protocol of multicast packets, after receiving the multicast packet, second device 6 can write its own network location information, as well as at least one of its product specifications, hardware specifications, and software specifications, into a corresponding multicast packet and send it to the network environment. After receiving it, risk scanning system 1 can understand the network location information, product specifications, hardware specifications, and software specifications of second device 6 and log it into the database.

[0096] In a preferred embodiment, the risk scanning system 1 runs on the first device 5 or another computing device 11. When the code sending module 2 of the risk scanning system 1 receives an update request, it can obtain the required device code based on the version information and device specification information (at least one of product specifications, hardware specifications, and software and firmware specifications) included in the update request. It can also search the database mentioned above through the device specification information, locate the network location information of the second device 6, and then send the device code to the second device 6 to update the device code running on the second device 6.

[0097] In a preferred embodiment, the code sending module 2, the update record generation module 3, and the scan result notification module 4 are processing units integrated into the risk scanning system 1. Each processing unit can provide at least one function to realize interaction with other processing units. When a processing unit needs to send a request to another processing unit, it can use the content of the request as a parameter and input the content of the request to the other processing unit in the form of a function call. After receiving the content of the request, the other processing unit can provide services for the request based on the content of the request. In another preferred embodiment, each processing unit can also interact with other processing units via network connection or inter-process communication. When a processing unit needs to send a request to another processing unit, it can establish a TCP / UDP socket connection with the other processing unit and transmit the request content to the other processing unit through a pre-agreed communication protocol. Alternatively, it can send the request content to the other processing unit through an inter-process communication mechanism implemented with partial memory sharing, so that the other processing unit can receive the request content and provide services for the request based on the request content. The implementation of how a request is provided to a processing unit and how the processing unit receives the request is not limited thereto. Those skilled in the art can make any equivalent design changes according to actual application needs.

[0098] In another preferred embodiment, the update request is directly generated by the risk scanning system 1 and submitted to the code sending module 2. The risk scanning system 1 can generate the update request and submit it to the code sending module 2 based on the content of a configuration file. The configuration file may consist of the necessary related information, including the aforementioned acquisition of a device code from the first device 5 and sending the device code to the second device 6. This related information includes, but is not limited to, the network location information of the first device 5 and / or the second device 6, the authorized identity of the first device 5 and / or the second device 6, version information, and / or device specification information. The configuration file can be set by the administrator of the risk scanning system 1 during deployment, or provided to the risk scanning system 1 by the administrator and / or its users through the operation settings on the human-machine interface of the risk scanning system 1 when the system is already online.

[0099] In summary, the generation and transmission of update request content, as well as the method by which the code sending module 2 obtains update requests, are not limited to this. Those skilled in the art can make any equivalent changes based on actual application needs.

[0100] In a preferred embodiment, the code sending module 2, upon receiving the update request, not only transmits the device code from the first device 5 to the second device 6, but may further store the device code in a database or an archive server, and request the update record generation module 3 to establish an update record in the database of the risk scanning system 1. In one embodiment, the risk scanning system 1 runs on the first device 5. The update record includes, in addition to the version information of the device code, the device specifications supported by the device code, and the storage location information of the device code in the archive server, a relationship record, which includes the metadata of the second device 6. In another embodiment, the risk scanning system 1 runs on the second device 6. The update record includes, in addition to the version information of the device code, the device specifications supported by the device code, and the storage location information of the device code in the archive server, a relationship record, which includes the metadata of the first device 5. Option 3: The risk scanning system 1 runs on a separate computing device 11, distinct from the first device 5 and the second device 6. The update record includes, in addition to, the version information of the device code, the device specifications supported by the device code, and the storage location information of the device code in the file server, a relationship record. This relationship record includes the metadata of the first device 5 and the metadata of the second device 6. The metadata of the first device 5 includes its network location information and the account information of its users, operators, and / or administrators.

[0101] In a preferred embodiment, the first device 5 and / or the second device 6 is an embedded system device, a server device, an Internet of Things sensing device, a network communication device, or any computer device with network capabilities.

[0102] Furthermore, the device code is obtained from the first device 5, and the device code includes at least one piece of binary code among at least one piece of software code.

[0103] The device code risk scanning method described above enables the risk scanning system 1 to acquire device code from the first device 5 and subsequently update the device code of the second device 6, making the device code the code executed when the second device 6 is online. When the first device 5 and the second device 6 are offline, the risk scanning system 1 implementing the device code risk scanning method can perform risk scanning on the device code of both devices, that is, by performing code component analysis on the device code stored in the file server. Under the above method, even when the first device 5 and the second device 6 are online, the risk scanning system 1 can still perform device code risk scanning on both devices, meaning that both online and offline scenarios are included in the device code risk scanning method.

[0104] In one preferred embodiment, the device code obtained from the first device 5 is obtained in the form of a software code package, that is, the device code is packaged into a software code package; the software code package may include a compressed file containing all the software code contained in the device code. In another preferred embodiment, the device code is obtained in the form of a system image file, which contains all the software code contained in the device code.

[0105] In a preferred embodiment, regardless of whether it is in the form of a system image file or a software code package, the code sending module 2 of the risk scanning system 1 acquires the device code and can then scan all the software code contained within the device code. During scanning, the system image file containing the device code is mounted to memory or a sector partitioned from the hard disk memory (if it is a zImage, its contents can be decompressed to a folder), or the software code package containing the device code is decompressed to a designated folder in the hard disk memory. Then, the complete content of the device code can be stored on a file server. Traversing the files and directories of the device code stored on the file server is equivalent to scanning the components contained in the system image file and the software code package. Based on the traversal results, after understanding the file and directory structure of the device code, it can be compared with the file and directory structures of known operating system kernels, drivers, applications, common software components, and / or category libraries to identify operating system kernels, drivers, applications, common software components, and / or category libraries whose file and directory structures match. Following the above procedure, after collecting the device code, the risk scanning system 1 can scan and analyze a list of software codes contained in the device code. This list may consist of metadata (data describing information related to the software code, such as the name of each software code, which can be a type of metadata) of each software code existing in the form of operating system kernel, driver, application, common software components and / or category library, etc. The content of this list may also include the metadata of the device code itself (data describing information related to the device code).

[0106] In a preferred embodiment, based on the list of at least one software code included in the device code, the risk scanning system 1 can monitor the CVE list corresponding to each software code in the list (e.g., for the Linux Kernel, monitoring the CVE list corresponding to the Linux Kernel), and detect code analysis events by monitoring changes in the CVE list. A code analysis event is triggered when a vulnerability is added to the list, a patch for that vulnerability is provided and added to the vulnerability record, or the patch for that vulnerability is updated, causing changes in the list's contents. The patch is one type of risky code, but not limited to it. Those skilled in the art can make any equivalent design changes for any type of malicious code within the risky code, depending on the actual application requirements. The code analysis event corresponding to the risky code is triggered when the risky code is added or updated, and the triggered event is received by the risk scanning system 1. The CVE list is one implementation of the risk code login list described in this article, and is not limited thereto. Those skilled in the art can provide any equivalent design changes to different forms of risk code login lists according to actual application needs.

[0107] In a preferred embodiment, when a patch code is added or updated, causing a code analysis event corresponding to the patch code to be triggered, the risk scanning system 1 can retrieve the patch code from the storage medium storing the patch code; wherein, the storage medium may be the same storage medium as the file server storing the device code, or a different storage medium. In another preferred embodiment, when the risk scanning system 1 detects that a patch code has been added or updated, it can first retrieve the source code of the patch code stored in another storage medium (e.g., a GitHub repository for releasing patch code), compile it, and store the compiled result (binary code or intermediate code) in the file server. In this case, the pre-compiled result can be considered as part of the patch code as a whole. Then, in the component comparison, the risk scanning system 1 retrieves the entire patch code (including source code, binary code, and / or intermediate code) from the file server and the other storage medium. The above methods for monitoring and retrieving risk code from the registry are not limited thereto, and those skilled in the art can make any equivalent modifications according to actual application needs.

[0108] In a preferred embodiment, after the risk scanning system 1 retrieves the patch code, it can compare the content of the patch code and at least one corresponding software code in the device code. When the comparison result shows that the at least one software code contains at least one security risk, it can request the scan result notification module 4 to issue a scan result regarding the security risk.

[0109] In a preferred embodiment, the scan result includes a scan status notification and / or a scan report. Sending a scan result means sending the scan status notification and / or the scan report to at least one of the users, operators, or managers of the first device 5 and the second device 6 through at least one network communication channel, such as email, mobile push notification, mobile SMS notification, web push notification, etc. The scan report is used to display the comparison results of the component content of at least one software code and at least one risk code. Patch code is one type of risky code. The existence of patch code indicates that there is a corresponding known or newly discovered vulnerability in the software code contained in the device code, and the patch code is the code that corrects the vulnerability. If the comparison between the patch code and the software code shows that the software code does not contain the patch code, it means that the vulnerability still exists in the device code. Unscrupulous individuals can exploit the vulnerability to attack the first device 5 and / or the second device 6 that executes the device code and is running online. In other words, the existence of the vulnerability includes the risk of the first device 5 or the second device 6. Accordingly, the component comparison results displayed in the scan report may include "description information of the at least one risk code", "description information of the at least one software code", "description information of the device code", "description information of the vulnerability", "description information of the risk", "number of vulnerabilities contained in the device code and / or the at least one software code", "security level of the device code and / or the at least one software code", and / or "judgment result of whether the at least one software code contains the at least one risk code", etc., but are not limited thereto. Scan status notification information is notification information issued to relevant parties regarding the completion status of the scan results. That is, through at least one network communication channel, notification of the scan status is provided to at least one of the users, operators, or managers of the first device 5 and the second device 6 regarding the completion status of the scan results. The content of the scan status notification information may include "description information of the scan report and / or its contents" and / or "complete or partial content of the scan report", etc., but is not limited thereto.

[0110] In a preferred embodiment, when the risk code is malicious code, the malicious code represents code with a known vulnerability. That is, if the comparison result between the malicious code and the software code shows that the software code still contains the malicious code, it indicates that the vulnerability still exists in the device code, and a scan result needs to be issued.

[0111] In a preferred embodiment, the scan result notification module 4 can retrieve the update record of the device code from the database of the risk scanning system 1, and find a relationship record from the content of the update record. Based on the user account information of at least one of the users, operators, or managers of the first device 5 and / or the second device 6 recorded in the relationship record, the module 4 sends the scan result to at least one of the users, operators, and / or managers of the first device 5 and / or the second device 6 through the at least one user account information. That is, based on the at least one user account information, the module identifies the email address and / or mobile phone number of at least one of the users, operators, and / or managers, and sends the scan result (scan report and / or scan status notification information) to the users, operators, and / or managers through network communication channels such as email, mobile push notification, and mobile SMS notification.

[0112] In a preferred embodiment, the scan result notification module 4 can send the scan result backend to the web frontend program when the user, operator, and / or manager is using the web frontend program of the risk scanning system 1 on the first device 5 or the second device 6.

[0113] The content of the scan results, scan reports, and scan status notifications, as well as the method of sending the scan results, are not limited thereto. Those skilled in the art may make any equivalent design changes based on actual application needs.

[0114] In a preferred embodiment, before acquiring the device code, the risk scanning system 1 can read the contents of at least one risk code registry (e.g., a CVE list for different software projects), identify the release source of the patch code (e.g., a GitHub repository for patch code release) based on the vulnerability records contained in the at least one risk code registry, retrieve the source code of the patch code from another storage medium (e.g., a GitHub repository for patch code release), compile it, and store the compiled result (binary code or intermediate code) in the file server. Through this technical implementation, at least one patch code (an embodiment of a risk code) corresponding to the at least one risk code registry is pre-collected in the file server. In this way, when the component list of the at least one software code contained in the device code is obtained through the analysis of the device code, the risk scanning system 1 can locate the risk code registry list corresponding to each software code in the component list, and then retrieve the risk codes pre-collected according to the corresponding risk code registry list from the file server and compare them with the component content of each software code in the device code to obtain the scanning result for the entire device code. As can be seen from the above, the code analysis event can be triggered in different situations, including at least: 1) when a component list of at least one software code contained in the device code is obtained; 2) when at least one risk code is added to the corresponding risk code registry list; or 3) when at least one risk code is updated in the corresponding risk code registry list, but it is not limited thereto, and those skilled in the art can make any equivalent changes according to actual application needs. It is also understood that the at least one risk code can be collected in advance from the at least one risk code login list to the file server, or it can be collected when a risk code is added or updated to the at least one risk code login list. However, the method of collecting risk codes is not limited to this, and those skilled in the art can make any equivalent design changes according to actual application needs.

[0115] Regarding the "components of software code" and "components of risky code" mentioned herein, the "components" refer to "program instructions contained in the code's code components," "the storage structure of the code in memory," and "the environment settings and configuration data required to execute the code." The code's code components include any type of binary code, intermediate code, and / or any type of computer program code written in a computer programming language for loading and execution. Furthermore, the "security risks" mentioned herein include the risk of the code containing vulnerabilities, viruses, and / or malware, and / or any risk that causes the code to perform unpredictable logical operations. The method of scanning for security risks by comparing risky code and software code described above is not limited to this; those skilled in the art can make any equivalent modifications based on actual application needs.

[0116] like Figure 1 As shown, S3's code component analysis before detecting a security risk in the device code specifically includes the following steps:

[0117] S31. Extract at least one first component feature corresponding to the risk code;

[0118] S32. Extract at least one second component feature corresponding to the at least one software code;

[0119] S33. Compare at least one first component feature and at least one second component feature.

[0120] Furthermore, the first component feature in S31 is obtained by analyzing the code composition content and / or code execution result corresponding to the risk code; wherein, the code composition content includes the risk code and / or the first intermediate code compiled from the risk code, and the code execution result includes the semantic information revealed by the risk code and / or the first intermediate code during the simulated execution process.

[0121] Furthermore, the at least one second component feature mentioned in S32 is obtained by analyzing the at least one code component content and / or the at least one code execution result corresponding to the at least one software code; wherein, the at least one code component content includes at least one binary code and / or at least one second intermediate code after the at least one binary code is decompiled, and the at least one code execution result includes the semantic information revealed by the at least one binary code and / or the at least one second intermediate code during the simulated execution process when the at least one binary code and / or the at least one second intermediate code is simulated.

[0122] Furthermore, the programming language structure of the first intermediate code and / or the at least one second intermediate code is declared by an intermediate language, an intermediate representation, a structured language, and / or a structured protocol.

[0123] In a preferred embodiment, the types of risky code include a patch code associated with the at least one software code, malicious program code, and / or any type of code used to fix or create a software vulnerability or software virus.

[0124] In a preferred embodiment, the code analysis event of the risk code is triggered when the risk code is added to or updated to a risk code login list (e.g., a CVE list).

[0125] In a preferred embodiment, before the code analysis event is triggered, the process further includes: the risk scanning system 1 detecting at least one code analysis event based on a list of components of the at least one software code. The code analysis event corresponding to the risk code is one of the at least one code analysis events.

[0126] In a preferred embodiment, the device code may consist of software code of different types, including system kernel, drivers, applications, components, and / or class libraries. The content of each software code may include scripts, binary code, and / or intermediate code. Therefore, at least one piece of software code can be understood as part of the device code. And the content of at least one code component can be understood as part of the at least one piece of software code.

[0127] The software code contained in a device is generally comprised of a manifest, which may include components such as the Linux Kernel, OpenSSL, and SQLite. As these components are continuously tested, vulnerabilities are discovered and corresponding patches are released, which are then added to or updated to the CVE repository and Git Hub.

[0128] When these vulnerabilities and patch codes are added or updated to the CVE list and GitHub by the relevant unit or organization, the risk scanning system 1 described in this article will not be notified. Therefore, for code analysis events to be triggered, the risk scanning system 1 should monitor the CVE lists such as Linux Kernel, OpenSSL, and SQLite, as well as GitHub, based on the component list of the device code, to detect these code analysis events before triggering.

[0129] The resulting technical effect is that the risk scanning system 1 can instantly perform code security checks on the device code when a vulnerability and patch code are added or updated to a list of risky codes on the network (e.g., a CVE list).

[0130] Furthermore, the composition list is obtained by the risk scanning system 1 scanning and / or analyzing the composition of the device code when the device code is provided to the risk scanning system 1.

[0131] The device code can be a single .o file (target file), .img file (system image file), .so file (library file), or a .zip or .gz compressed file (containing the .o and .so files required for the entire device, and also containing the path structure of these files in the compressed file).

[0132] The overall device code contains numerous software code files, each group forming different components (e.g., Linux Kernel, OpenSSL, SQLite). These software code files reside in different paths. There are several ways to obtain a list of the software code components within the device code. One method is to scan the entire device code based on file path information. As different components, their related files are located in different locations, thus allowing a basic determination of the components within the device code. Another method is to read the contents of each software code file and compare them to identify any characteristics specific to a particular component to determine the component list. For example, when reading the code components within a software code file, it can be compared with known code snippets from known software such as Linux Kernel, OpenSSL, and SQLite. Based on the comparison results, the components within the device code can be determined. The method of scanning and / or analyzing the components of device code to obtain a list of the components of each software code in the device code is not limited thereto, and those skilled in the art can make any equivalent design changes according to actual application requirements.

[0133] In a preferred embodiment, the patch code comprises a file written in JavaScript containing JavaScript code. The patch code corrects a vulnerability in software code contained in the device code. The risk scanning system 1 first locates the position of the JavaScript file corresponding to its name within the software code's structure using the filename. After reading the contents of both the patch code's JavaScript file and the corresponding JavaScript file of the software code, the system compares the contents of the two files. Specifically, it compares whether the contents of the two files contain the corrected code fragment. The corrected code fragment is used as the comparison feature. A matching comparison indicates that the software code does not contain the vulnerability; a mismatch indicates that the software code contains the vulnerability.

[0134] In a preferred embodiment, the component features used for comparison, besides using segments contained in the code as features, can also be the storage structure of the patch code and software code in memory, and / or the environment settings and configuration information of the patch code and software code. For example, if a patch code adds a new file whose filename does not exist in the corresponding software code, and / or the patch code adds a new parameter in the environment settings and configuration that does not exist in the corresponding software code, then the software code does not contain the patch code, and therefore the software code still contains the vulnerability corresponding to the patch code.

[0135] Following the example above, the code snippets, filename structures, and / or configuration content of the patch code used for comparison constitute the first component feature in the component content comparison. The code snippets, filename structures, and / or configuration content of the software code used for comparison constitute the second component feature in the component content comparison. The method of comparison based on component features derived from analyzing the code components is not limited to this, and those skilled in the art can make any equivalent modifications according to actual application needs.

[0136] In a preferred embodiment, the code components of a software code include a first file containing binary code, and the filename of the first file and its relative position in the storage structure correspond to a second file containing C / C++ source code within a patch code. The second file contains code for fixing a vulnerability. In this case, the first file is first disassembled into first intermediate code (code represented using LLVM's IR as the intermediate code representation), and the second file is also compiled and then disassembled into second intermediate code (code represented using LLVM's IR as the intermediate code representation). Then, simulation execution can be performed on the first and second intermediate codes; that is, by reading the program instructions from the first and second intermediate codes, feeding in simulation parameters, and performing logical operations according to the read program instructions. After all program instructions have been executed, the semantic information revealed during the simulated execution can be obtained based on the execution history of each instruction, the output and input of function calls, and / or the execution order. Here, "semantic information" includes the values ​​of memory and / or intermediate variables during program execution, and / or the instructions, functions, and their output and input values ​​called during the simulated execution. A similarity score is obtained by comparing the semantic information of the first intermediate code and the semantic information of the second intermediate code. Based on this similarity score, it can be determined whether the code segments of the first and second intermediate codes match, and further, whether the first file contains the code in the second file used to correct the vulnerability. Specifically, if the component features constituted by all the content of the semantic information of the first and second intermediate codes are completely contained within each other's semantic information, the similarity can be considered 100%. If only a portion of the component features are contained within each other's semantic information, the proportion of that portion to the total content is considered its similarity. Based on this, similarity results from 0% to 100% can be obtained. A similarity score exceeding a set threshold indicates that the first file contains code from the second file. The threshold is a reference value used to determine whether the code of the second file is contained in the code of the first file. For example, if the threshold is set to 90%, it means that if the similarity is higher than 90%, the first file contains the code of the second file, and vice versa.

[0137] In a preferred embodiment, the code components of a software code include a first file containing intermediate code (Java bytecode), and the filename of the first file and its relative position in the storage structure can correspond to a second file containing Java source code included in a patch code. The second file contains code for fixing a vulnerability. In this case, after compiling the second file into intermediate code (Java bytecode), its semantic information is obtained through simulated execution. Then, by comparing the values ​​retrieved from memory and / or intermediate variables contained in the semantic information, and / or the characteristics of the instructions, functions, and their output and input values ​​called during simulated execution, it can be determined whether the first file contains the code in the second file used to fix the vulnerability.

[0138] The method described above for comparing the component features of semantic information obtained by simulation is not limited to this, and those skilled in the art can make any equivalent changes according to actual application needs.

[0139] like Figure 3 As shown, this embodiment also provides a device code risk scanning and calculation device 11, including a code sending module 21, an update record generation module 31, and a scan result notification module 41;

[0140] The code sending module 21 is used to acquire a device code, which is acquired by the first device 5, and send the device code from the first device 5 to the second device 6; wherein, the device code includes at least one software code;

[0141] The update record generation module 31 is used to generate an update record; wherein, the update record includes a record of the relationship between the device code and the first device 5 and / or the second device 6;

[0142] The scan result notification module 41 is used to send scan results to the first device 5 and / or the second device 6 according to the update record when a security risk is detected in the device code.

[0143] When the scan results show that the at least one piece of software code contains at least one security risk, the scan result notification module 41 is also used to send the scan results. The scan result notification module 41 sends the scan results to at least one of the users, operators or managers of the first device 5 and the second device 6 through at least one network communication channel.

[0144] In a preferred embodiment, the computing device 11 is an embedded device. The code sending module 21, the update record generation module 31, and / or the scan result notification module 41 are designed using a hardware description language and can be integrated into the embedded system of the computing device 11 as integrated circuit units or as software code. The code sending module 21, the update record generation module 31, and the scan result notification module 41 are driven by the embedded system running in the computing device 11.

[0145] In another preferred embodiment, the computing device 11 is a server, and the code sending module 21, the update record generation module 31, and / or the scan result notification module 41 are integrated into a software system in the form of software code. The software system is provided to the computing device 11 for operation by being built-in or installed, and the code sending module 21, the update record generation module 31, and the scan result notification module 41 are driven by the software system running in the computing device 11.

[0146] In another preferred embodiment, the computing device 11 is composed of distributed servers. The code sending module 21, the update record generation module 31, and / or the scan result notification module 41 are integrated into a distributed software system in the form of software code. The distributed software system is deployed and runs on the distributed servers to form a computing device 11. The code sending module 21, the update record generation module 31, and the scan result notification module 41 are driven by the distributed software system running in the computing device 11.

[0147] The above-described methods of combining different forms of hardware and software to form the computing device 11 are not limited thereto, and those skilled in the art can make any equivalent design changes according to actual application needs.

[0148] Furthermore, in combination Figure 2 The risk scanning system 1 includes a first feature extraction unit, a second feature extraction unit, and a feature comparison unit;

[0149] The first feature extraction unit is used to extract at least one first component feature corresponding to the at least one risk code;

[0150] The second feature extraction unit is used to extract at least one second component feature corresponding to the at least one software code;

[0151] The feature comparison unit is used to compare at least one first component feature and at least one second component feature.

[0152] Furthermore, the first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one extraction unit;

[0153] At least one analysis unit is used to analyze the code composition content and / or code execution result corresponding to the at least one risk code to obtain the at least one first component feature, and / or analyze the code composition content and / or code execution result corresponding to the at least one software code to obtain the at least one second component feature;

[0154] At least one extraction unit is used to extract the at least one first component feature or the at least one second component feature obtained after analysis.

[0155] Combination Figure 3 The device code risk scanning computing device 11 further includes at least one detection unit;

[0156] The at least one detection unit is configured to monitor the risk code registry list (e.g., CVE list) corresponding to each software code in the component list of the device code, based on the component list of the at least one software code included in the component list, and detect code analysis events by monitoring the anomalies of the risk code registry list.

[0157] In summary, this invention discloses a device code risk scanning method, system, and computing device 11. By acquiring the device code of an online device, updating the device code of an online device, comparing the risk code with the components of the device code, and issuing scanning results to the device, risk scanning can be performed on the device regardless of whether the device is offline, whether the network status is normal, or whether the computing power is insufficient, thereby achieving risk prevention and control of device code.

[0158] The above detailed description is a specific description of feasible embodiments of the present invention. The embodiments are not intended to limit the scope of protection of the present invention. All equivalent implementations or modifications that do not depart from the present invention should be included in the scope of protection of the present invention.

Claims

1. A risk scanning method based on device code, characterized in that, include: A device code is acquired from a first device, and the device code is sent from the first device to a second device; wherein the device code includes at least one software code, and the at least one software code contains at least one binary code; An update record is generated; wherein the update record includes a relationship record between the device code and the first device and / or the second device, and the relationship record includes user account information of at least one of the users, operators or managers of the first device and / or the second device; When a security risk is detected in the device code, the update record is searched to obtain the relationship record in the update record; based on the relationship record, a scan result is issued to at least one user, operator or manager of the first device and / or the second device; The detection of security risks in the device code specifically includes: When at least one code analysis event is triggered, at least one risky code is compared with the at least one software code in terms of component content; wherein, the at least one risky code includes at least one of patch code, malicious program code, and computer program code written in any computer programming language associated with the at least one software code.

2. The risk scanning method based on device code as described in claim 1, characterized in that: The issuance of the scan result refers to sending a notification of the scan result to at least one of the users, operators, or managers of the first and second devices through at least one network communication channel.

3. The risk scanning method based on device code as described in claim 1, characterized in that, The acquisition of a device code specifically includes: Based on an update request, the device code is obtained from a storage medium of the first device.

4. The risk scanning method based on device code as described in claim 3, characterized in that, The method for obtaining a device code further includes: When the update request is received, a device code corresponding to the version information or device specification information in the update request is obtained from the storage medium and used as the device code; wherein, the device specification information includes at least one of a device's product specifications, hardware specifications, and software specifications.

5. The risk scanning method based on device code as described in claim 3, characterized in that, Sending the device code to the second device specifically includes: Based on the network location information of the second device included in the update request, the device code is sent to the second device.

6. The risk scanning method based on device code as described in claim 1, characterized in that: The at least one risk code is collected in advance based on a list of at least one risk code logins, or when a risk code is added to or updated to the list of at least one risk code logins.

7. The risk scanning method based on device code as described in claim 1, characterized in that: The at least one code analysis event is triggered when a list of the at least one software code is obtained, or when the at least one risky code is added or updated.

8. The risk scanning method based on device code as described in claim 1, characterized in that, The comparison of the at least one risk code with the at least one software code specifically includes: Extract at least one first component feature corresponding to the at least one risk code; Extract at least one second component feature corresponding to the at least one software code; Compare the at least one first component feature and the at least one second component feature.

9. The risk scanning method based on device code as described in claim 8, characterized in that: The at least one first component feature is obtained by analyzing the code composition content and / or code execution result corresponding to the at least one risk code.

10. The risk scanning method based on device code as described in claim 9, characterized in that, The code composition includes the at least one risk code and / or at least one first intermediate code compiled from the at least one risk code, and the code execution result includes the semantic information revealed by the at least one risk code and / or the at least one first intermediate code during the simulated execution process.

11. The risk scanning method based on device code as described in claim 8, characterized in that: The at least one second component feature is obtained by analyzing the content of at least one code component corresponding to the at least one software code and / or the execution result of at least one code.

12. The risk scanning method based on device code as described in claim 11, characterized in that: The at least one code component includes at least one binary code and / or at least one second intermediate code after the at least one binary code is decompiled. The execution result of the at least one code includes the semantic information revealed by the at least one binary code and / or the at least one second intermediate code during the simulated execution process.

13. The risk scanning method based on device code as described in claim 10 or 12, characterized in that: The intermediate code's programming language structure is declared by an intermediate language, an intermediate representation, a structured language, and / or a structured protocol.

14. The risk scanning method based on device code as described in claim 1, characterized in that: Before the code analysis event is triggered, it also includes: Based on the list of components of the at least one software code, at least one code analysis event is detected, and the code analysis event corresponding to the at least one risky code is one of the at least one code analysis events.

15. The risk scanning method based on device code as described in claim 7, characterized in that: The composition list is obtained by scanning and / or analyzing the composition of the device code when the device code is acquired.

16. The risk scanning method based on device code as described in claim 15, characterized in that: The component list includes metadata of the device code itself and / or metadata of the at least one piece of software code contained in the components of the device code.

17. The risk scanning method based on device code as described in claim 16, characterized in that: The at least one piece of software code exists in the composition of the device code in the form of a system kernel, driver, application program, component, and / or class library.

18. The risk scanning method based on device code as described in claim 15, characterized in that: Based on the component list, the risk code login list corresponding to each software code contained in the component list is monitored, and code analysis events are detected by monitoring the changes in the risk code login list.

19. The risk scanning method based on device code as described in claim 15, characterized in that, The method for obtaining the component list specifically includes: The device code is a system image file. The components contained in the system image file are scanned and / or analyzed to identify the at least one piece of software code present in the system image file, thereby obtaining the list of components of the at least one piece of software code. Alternatively, the device code may be a software code package. The components contained in the software code package are scanned and / or analyzed to identify the at least one software code present in the software code package, thereby obtaining the list of components of the at least one software code.

20. The risk scanning method based on device code as described in claim 1, characterized in that, The scan results include at least one of a scan report and a scan status notification; wherein, the scan report is used to display the component content comparison results of the at least one software code and the at least one risk code; the scan status notification is used to provide a notification of the scan status to at least one of the users, operators or managers of the first device and the second device.

21. A risk scanning system based on device codes, characterized in that, include: The module includes a code sending module, an update record generation module, and a scan result notification module. The code sending module is used to acquire a device code, which is acquired from a first device, and send the device code from the first device to a second device; wherein, the device code includes at least one software code, and the at least one software code contains at least one binary code; The update record generation module is used to generate an update record; wherein, the update record includes a relationship record between the device code and the first device and / or the second device, and the relationship record includes user account information of at least one of the users, operators or managers of the first device and / or the second device; The scan result notification module is used to search the update record when a security risk is detected in the device code, obtain the relationship record in the update record, and issue a scan result to at least one user, operator or manager of the first device and / or the second device based on the relationship record; The detection of security risks in the device code specifically includes: When at least one code analysis event is triggered, at least one risky code is compared with the at least one software code in terms of component content; wherein, the at least one risky code includes at least one of patch code, malicious program code, and computer program code written in any computer programming language associated with the at least one software code.

22. The risk scanning system based on device codes as described in claim 21, characterized in that, It also includes: a first feature extraction unit, a second feature extraction unit, and a feature comparison unit; The first feature extraction unit is used to extract at least one first component feature corresponding to at least one risk code; The second feature extraction unit is used to extract at least one second component feature corresponding to the at least one software code; The feature comparison unit is used to compare at least one first component feature and at least one second component feature.

23. The device code-based risk scanning system as described in claim 22, characterized in that, The first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one extraction unit; The at least one analysis unit is used to analyze the code composition content and / or code execution result corresponding to the at least one risk code to obtain the at least one first component feature, and / or analyze the code composition content and / or code execution result corresponding to the at least one software code to obtain the at least one second component feature; The at least one extraction unit is used to extract the at least one first component feature and / or the at least one second component feature obtained after analysis.

24. The device code-based risk scanning system as described in claim 21, characterized in that, Also includes: At least one detection unit, The at least one detection unit is used to monitor the risk code login list corresponding to each software code in the composition list based on the composition list of the at least one software code, and to detect code analysis events by monitoring the anomalies of the risk code login list.

25. A computing device for risk scanning based on device codes, characterized in that, include: The module includes a code sending module, an update record generation module, and a scan result notification module. The code sending module is used to acquire a device code, which is acquired from a first device, and send the device code from the first device to a second device; wherein, the device code includes at least one software code, and the at least one software code contains at least one binary code; The update record generation module is used to generate an update record; wherein, the update record includes a relationship record between the device code and the first device and / or the second device, and the relationship record includes user account information of at least one of the users, operators or managers of the first device and / or the second device; The scan result notification module is used to search the update record when a security risk is detected in the device code, obtain the relationship record in the update record, and issue a scan result to at least one user, operator or manager of the first device and / or the second device based on the relationship record; The detection of security risks in the device code specifically includes: When at least one code analysis event is triggered, at least one risky code is compared with the at least one software code in terms of component content; wherein, the at least one risky code includes at least one of patch code, malicious program code, and computer program code written in any computer programming language associated with the at least one software code.

Images