A defense method for IoT device firmware flaws

Abstract

The present invention relates to the field of network security technology, and discloses a defense method for firmware defects of Internet of Things devices. First, by collecting samples of binary programs, firmware and libraries with symbols, a symbol feature library is established with the help of embedded model vectorization technology; then, based on the symbol feature library, the input firmware program is symbol matched; for the program with matched symbols, automated reverse engineering is performed to obtain a set P of possible parameter injection points in the program; for each element in the set P, a prompt word is generated, and the generated prompt word is used to call LLM to generate protection rules, and finally all the generated protection rules are imported into a rule-based protection system. The present invention automatically and accurately identifies and repairs security defects in the firmware of Internet of Things devices through automated technical means, generates corresponding protection rules, reduces manual intervention, improves protection efficiency and accuracy, and improves the security and stability of the system.

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 in Internet of Things devices. Background Art

[0002] With the rapid development and widespread adoption of IoT technology, more and more devices are relying on firmware for intelligent management and data exchange. Firmware, a type of embedded system software, is responsible for providing a device's most basic control programs and operating system functions. However, its complexity and constant interaction with the outside world make it a prime target for attackers. Once the firmware is compromised, the functionality of the entire device can be severely impacted, even posing a security risk.

[0003] While various firmware security solutions exist, such as regular manual firmware updates and traditional antivirus software, these approaches often require extensive manual intervention and are ineffective against rapidly evolving security threats. Furthermore, many IoT devices have limited resources and cannot accommodate complex protection measures. Therefore, a technology that can automatically and efficiently protect against firmware vulnerabilities is urgently needed. Summary of the Invention

[0004] To address the above issues, the present invention aims to provide a defense method for IoT device firmware flaws. This method uses automated technical means to automatically and accurately identify and repair security flaws in IoT device firmware, generate corresponding protection rules, reduce manual intervention, improve protection efficiency and accuracy, and enhance system security and stability. The technical solution is as follows:

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

[0006] Step 1: Build a symbolic feature library: By collecting samples of signed binary programs, firmware, and libraries, we build a symbolic feature library using embedded model vectorization technology.

[0007] Step 2: Symbol recognition: Use the symbol feature library established in step 1 to identify 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 symbols 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, open source project compiled binaries, 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 analyzed program. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the following steps.

[0016] Step 1.4: Call the 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 method of determination is to determine whether the current function name begins with "sub_". If it does, it means that the current function does not have a symbol. In this case, it is discarded and the process jumps to step 1.4 to process the next function. If the current function has a symbol, continue to execute the subsequent steps.

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

[0019] Step 1.7: Insert the vectorization results 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 analyzed program. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the following steps.

[0022] Step 2.2: Call the 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 a similarity threshold to consider it a match; otherwise, it is considered a mismatch; if the pseudocode matches, 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 obtain the function list of the current program being analyzed. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the following steps.

[0028] Step 3.2: Call the 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 front-end parameter names. The input of this step is pseudocode, and the output is an array containing front-end parameter names. The front-end parameters are parameters that can be controlled by the user on the web front-end page and are 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. The collected information is recorded as PCODE;

[0032] Step 3.6: Add parameter name, XREFS, and PCODE to the 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 the text replacement method; 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 then 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, which can understand the semantic information of firmware code vulnerabilities and generate more accurate protection rules; it can automatically identify user front-end input parameters and generate corresponding detection rules based on 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 enhance the security and stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 This is a flowchart of the present invention's defense method for IoT device firmware flaws.

[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 the lack of strict inspection of the user front-end input parameters, which leads to 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 IoT device firmware defects of the present invention comprises the following steps: (Attached 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 challenge in reverse engineering firmware is missing symbol information. Completing symbol information helps LLM accurately understand program semantics. For detailed steps on building a symbol signature library, see steps 1.1 through 1.7 in "Symbol Signature Library Construction." Once a symbol library is successfully built, it can be reused multiple times.

[0047] Symbol Recognition: The greatest difficulty in firmware reverse engineering lies in missing function symbol information. To improve the accuracy of LLM analysis, this paper designs a symbol recognition system. This system consists of two steps: symbol signature library creation (steps 1.1-1.7) and symbol signature recognition (steps 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 a list of functions in the program being analyzed. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the steps following 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. This is determined by checking whether the current function name begins with "sub_." If so, the current function name does not have a symbol and should be discarded. The process then jumps to step 1.4 to process the next function. If the current function name has a symbol, the process continues with the following steps.

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

[0056] Step 1.7: Insert the vectorized results into the vectorized 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 signature library established in step 1 to identify symbols within firmware programs, you can migrate non-firmware symbols to firmware program analysis. Firmware programs are a type of binary program. When establishing the symbol signature library, the input material can be any binary program with symbols, not just firmware. The identification process involves symbol matching within firmware programs.

[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 program being analyzed. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the steps following 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 for the current pseudocode. Use the cosine similarity method to calculate the similarity between the input pseudocode and the signed pseudocode in the database. Set a similarity threshold of 0.9 or higher to consider a match; otherwise, consider it a mismatch. For matching pseudocodes, proceed to step 2.5; otherwise, proceed to 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 with matching symbols to obtain the set P of possible parameter injection points (parameter names, XREFS, PCODE) in the firmware program. See Steps 3.1-3.6 for the detailed 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] Automated reversing is implemented based on the IDALIB framework of IDA Pro 9.0. The framework 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 The specific steps are as follows:

[0069] Step 3.1: Call the idautils.Functions function to obtain the function list of the target program. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the steps following 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 the current pseudocode for front-end parameter names (controllable parameters input by the front-end). The input of this step is pseudocode, and the output is an array containing the front-end parameter names. Front-end parameters are parameters that the user can control on the web front-end page and are 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 that is replaced with pseudocode text when generating prompt words.

[0075] Step 3.4: For each parameter name analyzed by LLM, further collect cross-references to the function containing the parameter. 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. This 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. The collected information is recorded as PCODE.

[0077] Step 3.6: Add (parameter name, XREFS, PCODE) to the 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 set P. {PLACE_HOLDER_EXAMPLES} are rule examples provided by the user. 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 word 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, significantly reduce manual intervention, and improve the security and stability of the system.

Claims

1. A defense method for IoT device firmware defects, characterized in that: The following steps are involved: Step 1: Build a symbolic feature library: By collecting samples of signed binary programs, firmware, and libraries, we build a symbolic feature library using embedded model vectorization technology. Step 2: Symbol recognition: Use the symbol feature library established in step 1 to identify 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 symbols 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 in 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, open source project compiled binaries, 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 analyzed program. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the following steps. Step 1.4: Call the 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 method of determination is to determine whether the current function name begins with "sub_". If it does, it means that the current function does not have a symbol. In this case, it is discarded and the process jumps to step 1.4 to process the next function. If the current function has a symbol, continue to execute the subsequent steps. Step 1.6: Call the vectorization model to vectorize the pseudocode; Step 1.7: Insert the vectorization results 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 analyzed program. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the following steps. Step 2.2: Call the 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 a similarity threshold to consider it a match; otherwise, it is considered a mismatch; if the pseudocode matches, 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, wherein: The process of automated reverse engineering in step 3 is as follows: Step 3.1: Call the idautils.Functions function to obtain the function list of the current analyzed program. This function returns an array containing the addresses of all functions in the target program. For each function address in the array, execute the following steps. Step 3.2: Call the 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 front-end parameter names. The input of this step is pseudocode, and the output is an array containing front-end parameter names. The front-end parameters are parameters that can be controlled by the user on the web front-end page and are 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. The collected information is recorded as PCODE; Step 3.6: Add parameter name, XREFS, and PCODE to the set P.

5. The method for defending against firmware defects in IoT devices according to claim 1, wherein: In step 4, during the process of generating the prompt word, the position wrapped by the "{}" placeholder is replaced with the actual value using the text replacement method; 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