Defense method for firmware defects of Internet of Things equipment

Abstract

The invention relates to the technical field of network security, and discloses a defense method for firmware defects of Internet of Things equipment. The method comprises the following steps: firstly, collecting samples of a binary program, firmware and a library with symbols, and establishing a symbol feature library by means of an embedded model vectorization technology; performing symbol matching on the input firmware program according to the symbol feature library; performing automatic reverse engineering on the program with the matched symbols to obtain a possible parameter injection point set P in the program; and for each element in the set P, generating a cue word, using the generated cue word to call LLM to generate a protection rule, and finally importing all the generated protection rules into a rule-based protection system. Through an automatic technical means, the security defects in the firmware of the Internet of Things equipment are automatically and accurately identified and repaired, the corresponding protection rule is generated, manual intervention is reduced, the protection efficiency and accuracy are improved, and the security and stability of the system are improved.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a defense method for firmware defects of Internet of Things devices. Background Art

[0002] With the rapid development and widespread application of IoT technology, more and more devices are intelligently managed and exchange data through firmware. Firmware, as a type of embedded system software, is responsible for providing the most basic control program and operating system functions of the device. However, the complexity of firmware and its continuous interaction with the outside world make it a prime target for attackers. Once the firmware is compromised, the functionality of the entire device may be severely affected, or even cause security risks.

[0003] Although there are many firmware security solutions in the industry, such as regular manual firmware updates and the use of traditional antivirus software, these methods often require a lot of manual intervention and cannot effectively respond to rapidly evolving security threats. In addition, many IoT devices have limited resources and cannot support complex protection measures, so there is an urgent need for a technology that can automatically and efficiently protect against firmware vulnerabilities. Summary of the invention

[0004] In view of the above problems, the purpose of the present invention is to provide a defense method for IoT device firmware defects, which can automatically and accurately identify and repair security defects in IoT device firmware through automated technical means, generate corresponding protection rules, reduce manual intervention, improve protection efficiency and accuracy, and improve the security and stability of the system. The technical solution is as follows:

[0005] A defense method for IoT device firmware flaws includes the following steps:

[0006] Step 1: Establish a symbolic feature library: By collecting samples of signed binary programs, firmware, and libraries, a symbolic feature library is established using embedded model vectorization technology;

[0007] Step 2: Symbol recognition: Use the symbol feature library established in step 1 to recognize the symbols in the firmware program and perform symbol matching on the input firmware program;

[0008] Step 3: Automated reverse engineering: Automated reverse engineering is performed on the firmware program that has matched the symbol to obtain a set P of possible parameter injection points in the firmware program;

[0009] Step 4: For each element in the set P, generate a prompt word;

[0010] Step 5: Use the prompt words generated in step 4 to call LLM to generate protection rules. The calling method is to use the llm.invoke function of the LangChain framework;

[0011] Step 6: Apply all generated protection rules to any existing mature rule-based protection system.

[0012] Furthermore, the process of establishing the symbol feature library in step 1 is as follows:

[0013] Step 1.1: Collect binary files with symbols from web crawlers, compiled binaries of open source projects, Linux software sources, C language libraries, and OpenSSL algorithm libraries;

[0014] Step 1.2: Perform the following steps for each binary file with symbols;

[0015] Step 1.3: Call the idautils.Functions function to obtain the function list of the current analysis program. The function returns an array containing all function addresses of the target program. For each function address in the array, execute the subsequent steps.

[0016] Step 1.4: Call ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, i.e. pseudocode;

[0017] Step 1.5: Determine whether the current function name has a symbol; the determination method is to determine whether the current function name starts with "sub_". If it starts with "sub_", it means that the current function does not have a symbol, so it is discarded and jump to step 1.4 to process the next function; if the current function has a symbol, continue to execute subsequent steps;

[0018] Step 1.6: Call the vectorization model to vectorize the pseudocode;

[0019] Step 1.7: Insert the vectorization result into the vectorization database to obtain the symbol feature library.

[0020] Furthermore, the symbol matching process in step 2 is as follows:

[0021] Step 2.1: Call the idautils.Functions function to obtain the function list of the current analysis program. The function returns an array containing all function addresses of the target program. For each function address in the array, execute the subsequent steps.

[0022] Step 2.2: Call ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, i.e. pseudocode;

[0023] Step 2.3: Call the embedding model vectorization on the pseudo code;

[0024] Step 2.4: Retrieve the pseudocode with the highest similarity from the vectorized database, and use its symbol as the symbol of the current pseudocode; calculate the cosine similarity between the input pseudocode and the signed pseudocode in the database, and set the similarity threshold to match, otherwise it is considered not to match; for the matching pseudocode, execute step 2.5, otherwise execute step 2.2 to analyze the next function;

[0025] Step 2.5: Call the idc.set_name function to rename the pseudocode function.

[0026] Furthermore, the process of automated reverse engineering in step 3 is as follows:

[0027] Step 3.1: Call the idautils.Functions function to get the function list of the current analysis program. This function returns an array containing all the function addresses of the target program. For each function address in the array, execute the subsequent steps.

[0028] Step 3.2: Call ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, i.e. pseudocode;

[0029] Step 3.3: Call LLM to analyze whether the current pseudocode contains the front-end parameter name; the input of the current step is pseudocode, and the output is an array containing the front-end parameter name; the front-end parameter refers to the parameter that the user can control on the web front-end page, which is the entry point for vulnerability exploitation;

[0030] Step 3.4: For each parameter name analyzed by LLM, further collect the cross-references of the function where the parameter is located; for each cross-reference address, collect N1 lines of code above and below the reference point, and record the collected information as XREFS;

[0031] Step 3.5: For each parameter name analyzed by LLM, collect the pseudo code of the entire function where the parameter name is located, and the collected information is recorded as PCODE;

[0032] Step 3.6: Add parameter name, XREFS, and PCODE to set P.

[0033] Furthermore, in step 4, in the process of generating the prompt word, the position wrapped by the "{}" placeholder is replaced with the actual value by text replacement; the placeholders used are {PLACE_HOLDER_XREFS}, {PLACE_HOLDER_PARAMETER}, and {PLACE_HOLDER_PCODE}, which are read from the elements in the set P.

[0034] The beneficial effects of the present invention are:

[0035] 1) The present invention automatically analyzes the vulnerabilities and defects in the firmware through an automatic protection rule generation system and generates corresponding protection rules; the rule-based protection system performs real-time protection on the firmware according to the generated rules to prevent malware attacks and vulnerability exploits.

[0036] 2) The automatic protection rule generation system of the present invention is based on LLM, can understand the semantic information of firmware code vulnerabilities, and generate more accurate protection rules; it can automatically identify the user's front-end input parameters and generate corresponding detection rules according to the parameter semantics.

[0037] 3) The present invention uses automated technical means to automatically and accurately identify and repair security defects in the firmware of IoT devices, generate corresponding protection rules, reduce manual intervention, improve protection efficiency and accuracy, and improve the security and stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 The present invention is a flowchart of a method for defending against firmware defects in IoT devices.

[0039] Figure 2 Create a process flow chart for the symbol feature library.

[0040] Figure 3 Flowchart of the symbol matching process.

[0041] Figure 4 Flowchart for automated reverse engineering. DETAILED DESCRIPTION

[0042] The present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0043] The present invention proposes a defense method for firmware defects of IoT devices. It is completed by two major parts: an automatic protection rule generation system and a firmware symbol recognition system. The goal is to reduce manual intervention and improve protection efficiency and accuracy through automated technical means. The input of the automatic protection rule generation system is the firmware file. The system will automatically analyze the vulnerabilities and defects in the firmware and generate corresponding protection rules. The rule-based protection system performs real-time protection on the firmware according to the generated rules to prevent malware attacks and vulnerability exploits. The automatic protection rule generation system is based on LLM (Large Language Model), which can understand the semantic information of firmware code vulnerabilities and generate more accurate protection rules. The cause of embedded vulnerabilities is usually that the input parameters of the user front end are not strictly checked, resulting in vulnerabilities such as buffer overflow and command injection. The present invention can automatically identify the user front-end input parameters and generate corresponding detection rules according to the parameter semantics.

[0044] Specifically, the method for defending against firmware defects of IoT devices of the present invention comprises the following steps: Figure 1 ):

[0045] Step 1: Establish a symbolic feature library. By collecting samples of signed binary programs, firmware, libraries, etc., a symbolic feature library is established using embedded model vectorization technology.

[0046] The biggest difficulty in firmware program reverse engineering is the lack of symbol information. Completing the symbol information helps LLM to accurately understand the program semantics. The specific steps for establishing a symbol feature library are shown in steps 1.1 to 1.7 of "Establishing a symbol feature library". After the symbol library is successfully established, it can be reused many times.

[0047] Symbol recognition technology: The biggest difficulty in firmware program reverse engineering is the missing function symbol information. In order to improve the accuracy of LLM analysis, the present invention designs a symbol recognition system. The symbol recognition system consists of two processes, the symbol feature library establishment process (step 1.1-step 1.7) and the symbol feature recognition process (step 2.1-2.5).

[0048] The process of building a symbol signature library supports all types of binary programs with symbols, such as EXE, ELF, DLL, etc.

[0049] The process of establishing the symbol feature library is as follows: Figure 2 As shown, the specific process is as follows:

[0050] Step 1.1: Collect a large number of binary files with symbols. These files come from web crawlers, open source project compiled binary files, Linux software sources, C language libraries, OpenSSL algorithm libraries, etc.

[0051] Step 1.2: Perform the following steps for each binary file with symbols.

[0052] Step 1.3: Call the idautils.Functions function to obtain the function list of the current analysis program. This function returns an array containing all the function addresses of the target program. For each function address in the array, execute the subsequent steps of step 1.3.

[0053] Step 1.4: Call the ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, hereinafter referred to as pseudocode.

[0054] Step 1.5: Determine whether the current function name has a symbol. The determination method is to determine whether the current function name starts with "sub_". If it starts with "sub_", it means that the current function does not have a symbol and should be discarded, and jump to step 1.4 to process the next function. If the current function has a symbol, continue to execute the subsequent steps.

[0055] Step 1.6: Call the vectorization model to vectorize the pseudocode. The specific model of the vectorization model can be adjusted according to the actual situation. The present invention adopts the local vectorization model nomic-embed-text by default.

[0056] Step 1.7: Insert the vectorization results into the vectorization database, i.e., the feature library.

[0057] Step 2: Symbol recognition. Match the symbols of the input firmware program. For the specific process, see Figure 3 The symbol feature recognition process flow is shown.

[0058] Using the symbol feature library established in step 1 to identify symbols in the firmware program, non-firmware symbols can be migrated to the firmware program for analysis. The firmware program is a type of binary program. In the process of establishing the symbol feature library, the input material can be any binary program with symbols, not limited to firmware; the recognition process is to match the firmware program with symbols.

[0059] The specific steps for symbol matching in the symbol library are as follows:

[0060] Step 2.1: Call the idautils.Functions function to obtain the function list of the current analysis program. This function returns an array containing all the function addresses of the target program. For each function address in the array, execute the subsequent steps of step 2.1.

[0061] Step 2.2: Call the ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, hereinafter referred to as pseudocode.

[0062] Step 2.3: Call the embedding model vectorization on the pseudo code.

[0063] Step 2.4: Retrieve the pseudocode with the highest similarity from the vectorized database, and use its symbol as the symbol of the current pseudocode. Use the cosine similarity in the similarity calculation method to calculate the similarity between the input pseudocode and the signed pseudocode in the database, and set the similarity threshold to be above 0.9 to be considered a match, otherwise it is considered a mismatch. For the matching pseudocode, execute step 2.5, otherwise execute step 2.2 to analyze the next function.

[0064] Step 2.5: Call the idc.set_name function to rename the pseudocode function.

[0065] Step 3: Automated reverse engineering. Perform automated reverse engineering on the firmware program that has matched the symbol, and obtain the set P of possible parameter injection points (parameter name, XREFS, PCODE) in the firmware program. See steps 3.1 to 3.6 for specific steps.

[0066] Automated reverse engineering: Automated reverse engineering refers to the automatic decompilation of the firmware binary program input by the user without human intervention, identifying the user-controllable input parameters (front-end parameters) therein, and collecting the PCODE of the function where the parameter is parsed and the cross-reference context information XREFS of the function where the parameter is parsed.

[0067] The automated reversing is implemented based on the IDALIB framework of IDA Pro 9.0, which can directly schedule user scripts to analyze the target program without displaying the user interaction interface, which provides convenience for the automated reversing of the present invention.

[0068] Automated reverse engineering processes such as Figure 4 As shown, the specific steps are as follows:

[0069] Step 3.1: Call idautils.Functions to get the function list of the current analysis program. This function returns an array containing all the function addresses of the target program. For each function address in the array, execute the subsequent steps of step 3.2.

[0070] Step 3.2: Call the ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, hereinafter referred to as pseudocode.

[0071] Step 3.3: Call LLM to analyze whether the current pseudo code contains the front-end parameter name (the front-end input controllable parameter). The input of the current step is pseudo code, and the output is an array containing the front-end parameter name. The front-end parameter refers to the parameter that the user can control on the web front-end page, which is the entry point for vulnerability exploitation.

[0072] Use LLM to analyze the front-end parameter name information in the code. The prompt words are as follows:

[0073]

[0074] {CODE_PLACE_HOLDER} is a text placeholder, which is replaced by pseudo code text in the form of text replacement when generating prompt words.

[0075] Step 3.4: For each parameter name analyzed by LLM, further collect the cross-references of the function where the parameter is located. The function called to collect cross-references is idautils.CodeRefsTo(func_ea,0). For each cross-reference address, collect N1 lines of code above and below the reference point. N1 is configurable and defaults to 5. The collected information is recorded as XREFS.

[0076] Step 3.5: For each parameter name analyzed by LLM, collect the pseudo code of the entire function where the parameter name is located, and the collected information is recorded as PCODE.

[0077] Step 3.6: Add (parameter name, XREFS, PCODE) to set P.

[0078] Step 4: For each element in the set P, generate a prompt word according to the following template.

[0079]

[0080] In the process of generating prompt words, the places wrapped with "{}" placeholders will be replaced with actual values ​​by text replacement. These placeholders are {PLACE_HOLDER_XREFS},

[0081] {PLACE_HOLDER_PARAMETER} and {PLACE_HOLDER_PCODE} are read from the elements in the set P. {PLACE_HOLDER_EXAMPLES} are rule examples provided by the user, and the rule format is imitated with the help of LLM's few-shot learning mechanism to ensure the correctness of the generated rule format.

[0082] Step 5: Use the prompt words generated in step 4 to call the LLM generation rule by using the llm.invoke function of the LangChain framework.

[0083] Step 6: Finally, apply all generated rules to any existing mature rule-based protection system.

[0084] Through the above steps, the present invention can automatically and accurately identify and repair security defects in the firmware of IoT devices, generate corresponding protection rules, greatly reduce manual intervention, and improve the security and stability of the system.

Claims

1. A defense method for firmware defects of IoT devices, characterized in that: The following steps are involved: Step 1: Establish a symbolic feature library: By collecting samples of signed binary programs, firmware, and libraries, a symbolic feature library is established using embedded model vectorization technology; Step 2: Symbol recognition: Use the symbol feature library established in step 1 to recognize the symbols in the firmware program and perform symbol matching on the input firmware program; Step 3: Automated reverse engineering: Automated reverse engineering is performed on the firmware program that has matched the symbol to obtain a set P of possible parameter injection points in the firmware program; Step 4: For each element in the set P, generate a prompt word; Step 5: Use the prompt words generated in step 4 to call LLM to generate protection rules. The calling method is to use the llm.invoke function of the LangChain framework; Step 6: Apply all generated protection rules to any existing mature rule-based protection system.

2. The method for defending against firmware defects of IoT devices according to claim 1, characterized in that: The process of establishing the symbol feature library in step 1 is as follows: Step 1.1: Collect binary files with symbols from web crawlers, compiled binaries of open source projects, Linux software sources, C language libraries, and OpenSSL algorithm libraries; Step 1.2: Perform the following steps for each binary file with symbols; Step 1.3: Call the idautils.Functions function to obtain the function list of the current analysis program. The function returns an array containing all function addresses of the target program. For each function address in the array, execute the subsequent steps. Step 1.4: Call ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, i.e. pseudocode; Step 1.5: Determine whether the current function name has a symbol; the determination method is to determine whether the current function name starts with "sub_". If it starts with "sub_", it means that the current function does not have a symbol, so it is discarded and jump to step 1.4 to process the next function; if the current function has a symbol, continue to execute subsequent steps; Step 1.6: Call the vectorization model to vectorize the pseudocode; Step 1.7: Insert the vectorization result into the vectorization database to obtain the symbol feature library.

3. The method for defending against firmware defects in IoT devices according to claim 1, characterized in that: The process of symbol matching in step 2 is as follows: Step 2.1: Call the idautils.Functions function to obtain the function list of the current analysis program. The function returns an array containing all function addresses of the target program. For each function address in the array, execute the subsequent steps. Step 2.2: Call ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, i.e. pseudocode; Step 2.3: Call the embedding model vectorization on the pseudo code; Step 2.4: Retrieve the pseudocode with the highest similarity from the vectorized database, and use its symbol as the symbol of the current pseudocode; calculate the cosine similarity between the input pseudocode and the signed pseudocode in the database, and set the similarity threshold to match, otherwise it is considered not to match; for the matching pseudocode, execute step 2.5, otherwise execute step 2.2 to analyze the next function; Step 2.5: Call the idc.set_name function to rename the pseudocode function.

4. The method for defending against firmware defects in IoT devices according to claim 1, characterized in that: The process of automated reverse engineering in step 3 is as follows: Step 3.1: Call the idautils.Functions function to get the function list of the current analysis program. This function returns an array containing all the function addresses of the target program. For each function address in the array, execute the subsequent steps. Step 3.2: Call ida_hexrays.decompile function to decompile the target function and obtain its high-level pseudocode representation, i.e. pseudocode; Step 3.3: Call LLM to analyze whether the current pseudocode contains the front-end parameter name; the input of the current step is pseudocode, and the output is an array containing the front-end parameter name; the front-end parameter refers to the parameter that the user can control on the web front-end page, which is the entry point for vulnerability exploitation; Step 3.4: For each parameter name analyzed by LLM, further collect the cross-references of the function where the parameter is located; for each cross-reference address, collect N1 lines of code above and below the reference point, and record the collected information as XREFS; Step 3.5: For each parameter name analyzed by LLM, collect the pseudo code of the entire function where the parameter name is located, and the collected information is recorded as PCODE; Step 3.6: Add parameter name, XREFS, and PCODE to set P.

5. The method for defending against firmware defects in IoT devices according to claim 1, characterized in that: In step 4, in the process of generating the prompt word, the position wrapped by the "{}" placeholder is replaced with the actual value by text replacement; the placeholders used are {PLACE_HOLDER_XREFS}, {PLACE_HOLDER_PARAMETER}, and {PLACE_HOLDER_PCODE}, which are read from the elements in the set P.

Images