Test method for indirect jump table solving process of binary disassembler
By constructing a C file dataset and using the OracleGT compiler to trace the compilation process, indirect jump table information is automatically collected, solving the difficulty of performance evaluation in binary disassemblers, realizing an efficient and accurate testing method, and discovering and improving tool defects.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NANJING UNIV
- Filing Date
- 2023-03-21
- Publication Date
- 2026-05-01
AI Technical Summary
Existing binary disassemblers lack effective automated testing frameworks when solving indirect jump tables, making performance evaluation difficult and hindering the assurance of accurate and complete results.
By using the SCsmith tool to build a C file dataset and leveraging the OracleGT compiler to trace the compilation process, indirect jump table information is automatically collected. Binary test sets under different optimization levels are constructed to verify the solution results of the disassembler, thus achieving performance evaluation of the indirect jump table solution process.
It achieves efficient and automated performance evaluation of disassemblers, can discover tool defects and improve performance, improve testing efficiency, and the constructed test set contains more effective jump tables with greater density, making it easier to point out error locations.
Smart Images
Figure CN116414701B_ABST
Abstract
Description
Test methods for solving indirect jump tables in binary disassemblers Technical Field
[0001] This invention relates to an automated testing method, specifically a testing method for the indirect jump table solving process of binary disassemblers, belonging to the field of software quality and security technology. Background Technology
[0002] With the widespread application of information technology across all sectors of society, software quality and security have received increasing attention. Binary disassembly, the process of converting machine-readable binary code into assembly code that is easily understood by humans, is fundamental to many security efforts, such as binary code security hardening, binary code similarity detection, patching binary code, and binary-level vulnerability discovery.
[0003] Because compiler over-optimization introduces complex structures such as indirect jump tables, and indirect control flow targets are difficult to determine statically, existing binary disassemblers employ numerous algorithms to solve for these targets. These include heuristic algorithms based on expert knowledge summaries and reliability algorithms utilizing program analysis to correctly disassemble binary code. However, since the details of these algorithms are not revealed, the performance of indirect jump table solving cannot be evaluated, and the accuracy or completeness of the results remains unknown. This poses a challenge for binary security researchers using disassemblers.
[0004] Currently, discussions on evaluating indirect jump table solving algorithms focus on how to build test sets. Existing techniques include: (1) manually building test sets, which is difficult to implement on a large scale; (2) reusing existing disassemblers, which results in inaccurate and incomplete test sets; (3) relying on intermediate input from the compiler, which makes it difficult to correlate jump table information with indirect jumps; (4) relying on debugging information from the compilation process, which results in false positives in the test set; and (5) tracing the compilation process, which results in low construction efficiency. In summary, it is difficult to use existing techniques to establish a practical, accurate, and efficient automated testing framework for indirect jump table solving algorithms.
[0005] Therefore, for the functional evaluation of binary disassemblers, it is necessary to design a testing method for binary disassemblers based on indirect jump table solving algorithms. Summary of the Invention
[0006] Purpose of the invention: To address the problems and shortcomings of existing technologies, this invention provides a testing method for the indirect jump table solving process of binary disassemblers.
[0007] Technical solution: A testing method for the indirect jump table solving process of binary disassemblers, comprising the following steps:
[0008] (1) Construct a C file dataset. Each C file in the dataset can generate an indirect jump table after compilation;
[0009] (2) Use the compiler to trace the compilation process of C files to automatically collect indirect jump table information and build binary test sets under different optimization levels;
[0010] (3) Based on the binary test set, verify the results of the disassembler solving the indirect jump table, realize the test of the indirect jump table solving process, and obtain the performance evaluation of the disassembler.
[0011] The performance evaluation in step (3) can be combined with manual analysis to further discover the defects of the disassembler and improve its performance.
[0012] In step (1), the SCsmith tool is used to automatically, efficiently, and effectively construct a large C file dataset that can generate jump tables.
[0013] In step (2), the OracleGT compiler is used to trace the compilation process of C files to automatically collect indirect jump table information and build binary test sets under different optimization levels.
[0014] The SCsmith tool is described below: SCsmith is an extension of the Csmith-2.3.0 tool, responsible for automating the writing of C files that can generate jump tables. It can generate switch-case statements within C files. Because Csmith defines top-down generation rules, it can generate several functions, each containing several local variables and statements, according to these rules.
[0015] The specific steps for generating a C file dataset using the SCsmith tool are as follows:
[0016] Step 10: Use Csmith to automatically generate C files with random content. For each function in the C file, generate switch-case statements according to rules 101-104, ensuring that switch-case statements exist in the C file.
[0017] Rule 101: Assume the current function contains T statements. Randomly find an insertion point before the i-th statement to insert a switch statement, and 0 ≤ i < T.
[0018] Rule 102: Randomly select a currently available local or global numeric type variable, including char, short, int, long, or enum, as the expression in the switch statement. In this case, the current switch statement can contain m = Ti.
[0019] Rule 103: Randomly determine the size of the current "jump list" as N. N determines the upper limit of constant expressions in the case statement. To increase the chances of the switch-case statement being compiled into a jump list by the compiler, SCsmith defines the range of N as 2 ≤ N < 2*m.
[0020] Rule 104: Randomly insert c case statements between the i-th and T-th statements (excluding the T-th statement). To ensure that each case contains at least one statement, c satisfies 2 ≤ c < min(N, m). To ensure semantic correctness, SCcsmith also needs to ensure that the constant expressions between cases are different, and that one constant expression is N-1, which determines the size of the compiled jump table to be N.
[0021] Step 11: Repeat step 10 until the set time.
[0022] Ultimately, this results in a dataset of C files. Each C file in the dataset contains a switch-case statement.
[0023] The OracleGT compiler is described below: OracleGT is responsible for tracking the compilation process of mainstream compilers and automatically collecting indirect jump table information into binary files. In step (2), the OracleGT compiler is used to track the compilation process of C files to automatically collect indirect jump table information and construct binary test sets under different optimization levels; the specific execution steps are as follows (taking the GCC compiler as an example):
[0024] Step 20: Input the C file dataset generated by SCsmith into the compiler.
[0025] Step 21: The compiler hands the processed file to the assembler.
[0026] Step 22: The assembler hands the processed file over to the linker.
[0027] Step 23: The linker hands the processed file to the associator.
[0028] The jump table test set obtained through steps 20-23 above can only correspond to cross-references in the jump table, not to the final indirect jump instructions. Therefore, OracleGT is used to associate the jump table information with the corresponding indirect jumps. For each test case in the jump table test set, OracleGT generates a control flow graph during compilation, tracks and updates taint information in registers and stack memory at each instruction in the control flow graph to find the indirect jump corresponding to the jump table and the test case.
[0029] In step 20, the compiler compiles the C file dataset generated by SCsmith. For each C file, the following steps are performed on the compiler side:
[0030] Step 201: Select compiler parameters and optimization level, and pass the C file as input to the compiler.
[0031] Step 202: The GCC compiler's RTL Pass (Register Transfer Language Pass) translates the switch-case statements in the C file into RTL intermediate language. Here, the GIMPILE_SWITCH structure records the jump table size and the target address of each entry in the jump table.
[0032] Step 203: The GCC backend traverses each RTL intermediate language instruction and data generated in step 202. For the rtx_jmp_table_data data structure (which corresponds to the jump table information in assembly language), OracleGT defines additional assembly pseudo-instructions to mark it.
[0033] Step 204: GCC converts the traversed RTL intermediate language and data into assembly language to generate an assembly file.
[0034] In step 21, the compiler hands the processed file to the assembler, which then performs the following steps:
[0035] Step 211: The GAS (GNU Assembler) assembler linearly parses the assembly instructions in the assembly file generated in step 204. Step 212 is executed whenever the .bbinfo_JMPTBL pseudo-instruction is encountered, and step 22 is executed when the last instruction has been parsed; otherwise, step 211 is executed.
[0036] Step 212: Gather information about the current jump table here.
[0037] Step 213: Record the position of the next label. This will serve as the base address of the jump table.
[0038] Step 214: Associate the current jump table information obtained in step 212 with the base address reference obtained in step 213, record the offset of the base address reference in the object file, and execute step 211.
[0039] In step 22, the assembler hands the processed file to the linker; the linker merges the different object files to generate the final binary file, and in the process, it updates the offset of the jump table in the final binary file.
[0040] Step 23: The linker hands the processed file to the association unit, which performs the following steps:
[0041] Step 231: Begin taint analysis from the reference pointing to the base address of the jump table.
[0042] Step 232: Initialize taint information for instructions containing jump table cross-references, and taint all registers and stack memory used by the instruction for writing.
[0043] Step 233: Update the taint information in the registers and stack memory of the next instruction based on the control flow information. Traverse the registers and stack memory of all source operands to determine whether the source operands of the instruction have been tainted.
[0044] Step 234: If the source operand is colored, the registers and stack memory in the destination operand need to be colored; otherwise, the coloring information in the registers and stack memory of the destination operand is cleared. Then, proceed to step 235.
[0045] Step 235: If the current instruction is an indirect jump and the registers or stack memory in the source operand are stained, then the corresponding indirect jump instruction has been found; otherwise, proceed to step 233. Update the target address of the indirect jump to the control flow graph to facilitate the execution of cross-reference taint analysis for other jump tables.
[0046] The specific execution steps for the disassembler test are as follows:
[0047] Step 300: Input the test set generated by OracleGT into the disassembler.
[0048] Step 301: Collect the results from the disassembler.
[0049] Step 302: Compare with the correct results and record the relevant data.
[0050] Step 303: Calculate the precision, recall, and F1 results.
[0051] Beneficial Effects: Compared with existing technologies, this invention uses SCsmith to automatically, efficiently, and effectively construct a large C file dataset capable of generating jump tables. By tracing the compilation process using the OracleGT compiler, it further constructs binary test sets under different optimization levels. Based on these test sets, the results of disassemblers solving indirect jump tables are verified, enabling performance evaluation of the indirect jump table solving algorithm of disassemblers. Furthermore, since the test cases correspond to indirect jumps, it is easy to pinpoint the location of errors. Experiments have shown that the test sets constructed by this invention contain a greater number and density of valid jump tables, and can be automatically constructed, greatly improving testing efficiency. This invention can be used for performance evaluation of disassemblers and can also help disassemblers discover defects and improve performance, showing broad application prospects. Attached Figure Description
[0052] Figure 1 is a schematic diagram of the method principle of an embodiment of the present invention. Detailed Implementation
[0053] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading the present invention, any modifications of the present invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.
[0054] This paper presents a testing method for the indirect jump table solving process of binary disassemblers. SCsmith is used to automatically, efficiently, and effectively construct a large C file dataset that can generate jump tables. The compilation process is traced using the OracleGT compiler to further construct binary test sets under different optimization levels. By comparing the results of the disassembler's indirect jump table solving with the correct results, the performance of the disassembler's indirect jump table solving algorithm is evaluated, and the location of errors is identified.
[0055] As shown in Figure 1, the testing method for solving the indirect jump table of a binary disassembler includes the following steps:
[0056] Step 1: First, use the SCsmith tool to automatically, efficiently, and effectively build a large C file dataset that can generate jump tables.
[0057] Step 2: Then, the OracleGT compiler traces the C file compilation process to automatically collect indirect jump table information and build binary test sets at different optimization levels, specifically through the compiler, assembler, linker, and associator.
[0058] Step 3: Next, use an automaton script to compare the results of the disassembler being tested in solving the indirect jump table on the binary test set with the correct results, thereby testing the indirect jump table solving process and obtaining a performance evaluation.
[0059] Step 4: Finally, performance evaluation can be combined with manual analysis to further identify the defects of the disassembler and improve its performance.
[0060] The specific steps for generating a C file dataset of jump tables using the SCsmith tool are as follows:
[0061] Step 10: For each function, generate switch-case statements according to rules 101-104.
[0062] Rule 101: Assume the current function contains T statements. Randomly find an insertion point before the i-th statement to insert a switch statement, and 0 ≤ i < T.
[0063] Rule 102: Randomly select a currently available local or global numeric type variable, including char, short, int, long, or enum, as the expression in the switch statement. In this case, the current switch statement can contain m = Ti.
[0064] Rule 103: Randomly determine the size of the current "jump list" as N. N determines the upper limit of constant expressions in the case statement. To increase the chances of the switch-case statement being compiled into a jump list by the compiler, SCsmith defines the range of N as 2 ≤ N < 2*m.
[0065] Rule 104: Randomly insert c case statements between the i-th and T-th statements (excluding the T-th statement). To ensure that each case contains at least one statement, c satisfies 2 ≤ c < min(N, m). To ensure semantic correctness, SCcsmith also needs to ensure that the constant expressions between cases are different, and that one constant expression is N-1, which determines the size of the compiled jump table to be N.
[0066] Step 11: Repeat step 10 until the set time.
[0067] (1) Functions generated by Csmith:
[0068]
[0069]
[0070] The Csmith-generated function initializes local variables at the beginning (as shown in the code line "int a = 1, b = 2, c = 3, i = 0;"). The following lines are statements referencing the initialized local variables or function parameters (it should be noted that the for loop and its operations are also treated as a statement by SCsmith). The program after SCsmith inserts a switch / case statement shows the modified function, where the statements marked in bold are inserted by SCsmith. Specifically, SCsmith first selects an insertion point (in this example, the code line "*p += a;" in the Csmith-generated function), then searches for available numeric variables at the insertion point (such as a, b, c, i, and *p; in this example, *p is selected), and uses the selected variable (*p) as the expression for the switch statement (as shown in the code line "switch(*p)" in the program after SCsmith inserts a switch / case statement). At this point, SCsmith calculates that the switch statement can contain 4 statements (the statements from the line "*p+=a;" to the end of the line in the Csmith-generated function, where the entire for loop is considered one statement). Next, SCsmith randomly determines the size of the jump table to N=6. Finally, SCsmith randomly inserts 4 case statements into the following statements, and randomly determines whether to add a break statement under each case. It should be noted that since the newly added switch / case statements only involve referencing variables and do not define new variables, there is no change in the lifetime of variables. Therefore, SCsmith does not introduce new compilation errors.
[0071] The OracleGT compiler is used to trace the compilation process of C files to automatically collect indirect jump table information and build binary test sets under different optimization levels; the specific execution steps are as follows (taking GCC as an example):
[0072] Step 20: Input the C file dataset generated by SCsmith into the compiler.
[0073] Step 21: The compiler hands the processed file to the assembler.
[0074] Step 22: The assembler hands the processed file over to the linker.
[0075] Step 23: The linker hands the processed file to the associator.
[0076] The jump table test set obtained through steps 20-23 above can only correspond to cross-references in the jump table, and cannot correspond to the final indirect jump instruction. Therefore, OracleGT is used to associate the jump table information with the corresponding indirect jumps, and to track and update the taint information in registers and stack memory at each instruction in the control flow graph in order to find the indirect jump corresponding to the test case.
[0077] Step 20: Input the C file dataset generated by SCsmith into the compiler. The compiler will perform the following steps:
[0078] Step 201: Select compiler parameters and optimization level, and pass the C file as input to the compiler.
[0079] Step 202: Use the GCC compiler's RTL Pass (Register Transfer Language Pass) to convert the switch-case statement in the C file into RTL intermediate language. Here, the GIMPILE_SWITCH structure will record the jump table size and the target address of each entry in the jump table.
[0080] Step 203: The GCC backend converts the RTL intermediate language into assembly language. Specifically, it iterates through each instruction and data, generating the instruction data represented by the RTL into an assembly file. Here, OracleGT intercepts the process of GCC converting rtx_jmp_table_data into jump tables in the assembly code.
[0081] Step 204: OracleGT defines additional assembly pseudo-instructions to mark the jump table information in the assembly file described in step 203.
[0082] In step 21, the compiler hands the processed file to the assembler, which then performs the following steps:
[0083] Step 211: The GAS (GNU Assembler) assembler linearly parses all assembly instructions in the assembly file. Whenever it encounters the .bbinfo_JMPTBL pseudo-instruction, it executes step 212. When the last instruction has been parsed, it executes step 22; otherwise, it executes step 211.
[0084] Step 212: Collect information about the current jump table.
[0085] Step 213: Record the position of the next label as the base address of the jump table.
[0086] Step 214: Associate the current jump table information with the base address reference, record the offset of the base address reference in the object file, and execute step 211.
[0087] In step 22, the assembler hands the processed file to the linker; the linker merges the different object files to generate the final binary file, updating the jump table offsets in the final binary file during this process.
[0088]
[0089] The code above is a schematic diagram illustrating the example of OracleGT compiler marking jump table information in assembly code. The execution order of the OracleGT compiler is as follows: it takes the C file generated by SCsmith as input, and after execution by the compiler, assembler, and linker, it produces a file with content similar to the code above (but in binary form). Line 3, .L1001, is a reference to the jump table base address. However, for more accurate evaluation by disassemblers and to facilitate researchers' analysis of jump table errors, OracleGT also associates the jump table information with the corresponding indirect jumps, i.e., an associator. Ultimately, the jump table base address will directly correspond to the indirect jump in line 4.
[0090] The indirect jump target search algorithm described in this invention is explained below. The algorithm is as follows:
[0091]
[0092]
[0093] The input and output are as follows:
[0094] Input: Assume that the input JTR is the cross-reference array corresponding to the identified indirect jump table, and jtr_i is an element in the array representing a cross-reference, where i ranges from 1 to n, and n is the number of elements in the array. Assume that CFG is the control flow graph.
[0095] Output: Assume that the output M is the cross-reference and jump table mapping array corresponding to the indirect jump table, (jtr_i, ij_i) is the element in the array, where ij_i represents the found indirect jump, i ranges from 1 to n, and n is the number of array elements.
[0096] Thus, the process for finding the indirect jump target is as follows:
[0097] Step 1: Begin taint analysis from the references pointing to the base address of the jump table.
[0098] Step 2: Initialize taint information for instructions containing jump table cross-references, and color all registers and stack memory used by the instruction for writing.
[0099] Step 3: Update the taint information in the registers and stack memory of the next instruction based on the control flow information. Iterate through the registers and stack memory of all source operands to determine whether the source operands of the instruction have been tainted.
[0100] Step 4: If the source operand is colored, the registers and stack memory in the destination operand need to be colored; otherwise, the coloring information in the registers and stack memory of the destination operand is cleared. Then, proceed to step 5.
[0101] Step 5: If the current instruction is an indirect jump and the registers or stack memory in the source operand are stained, then the corresponding indirect jump instruction has been found; otherwise, proceed to step 3. Update the target address of the indirect jump to the control flow graph to facilitate the execution of cross-reference taint analysis for other jump tables.
[0102] Step 6, the calculation process is complete.
[0103] In summary, this invention can be applied to many aspects, including disassembler evaluation, disassembler improvement, software quality analysis, and software error analysis. For example, in disassembler improvement, automated cross-disassembler testing can be performed to identify differences in results between disassemblers, thereby discovering potential problems with related disassemblers. The causes can then be located and addressed through error location analysis. Therefore, this invention can be used for disassembler performance evaluation and can also help disassemblers discover defects and improve performance, demonstrating broad application prospects. Because the test set can be generated automatically and continuously, and testing can also be automated and continuously performed, and the constructed test set contains a larger number and higher density of valid jump tables, testing efficiency is greatly improved. Therefore, this technology has high practical value.
[0104] This invention can automate the testing of C language files under different optimization levels of the GCC or Clang / LLVM compilers. The above description is merely an implementation of this invention in a specific environment and can be further extended to other languages and compilers. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.
Claims
1. A testing method for the indirect jump table solving process of binary disassemblers, characterized in that, The following steps are included: (1) Construct a C file dataset. Each C file in the dataset can generate an indirect jump table after compilation. Use the SCsmith tool to generate the C file dataset. The specific execution steps are as follows: Step 10: Use Csmith to automatically generate C files with random content. For each function in the C file, generate switch-case statements through rules 101-104 so that switch-case statements exist in the C file. Rule 101: Assuming that the current function contains T statements, randomly find an insertion point before the i-th statement to insert the switch statement, and 0≤i<T. Rule 102: Randomly select the currently available local or global numeric type variables as the expression of the switch statement. At this time, the number of statements that the current switch can contain is m=Ti. Rule 103: Randomly determine the size of the current "jump table" as N. N determines the upper limit of the constant expression in the case statement. In order to make the switch-case statement more likely to be compiled into a jump table by the compiler, SCsmith defines the range of N as 2≤N<2*m. Rule 104: Randomly insert c case statements between the i-th and T-th statements excluding the T-th statement; to ensure that each case contains at least one statement, c satisfies 2≤c<min(N,m); to ensure semantic correctness, SCcsmith also needs to ensure that the constant expressions between cases are different, and one constant expression is N-1, which determines that the size of the compiled jump table is N; Step 11: Repeat step 10 until the set time; finally, a C file dataset is obtained, and each C file in the dataset contains switch-case statements; (2) Use the compiler to trace the C file compilation process to automatically collect indirect jump table information and build binary test sets under different optimization levels; OracleGT compiler is used to trace the C file compilation process to automatically collect indirect jump table information and build binary test sets under different optimization levels; the specific execution steps are as follows: Step 20: Input the C file dataset generated by SCsmith into the compiler; Step 21: The compiler hands the processed file to the assembler; Step 22: The assembler hands the processed file to the linker; Step 23: The linker hands the processed file to the associator; OracleGT is used to associate the jump table information with the corresponding indirect jumps; For each test case in the jump table test set, OracleGT generates a control flow graph during the compilation process, tracks and updates the taint information of registers and stack memory at each instruction of the control flow graph in order to find the indirect jumps corresponding to the jump table and the test case (3) Based on the binary test set, the results of the disassembler solving the indirect jump table are verified, the process of solving the indirect jump table is tested, and the performance evaluation of the disassembler is obtained.
2. The testing method for the indirect jump table solving process of binary disassemblers according to claim 1, characterized in that, By combining the performance evaluation in step (3) with manual analysis, we can further discover the defects of the disassembler and improve its performance.
3. The testing method for the indirect jump table solving process of binary disassemblers according to claim 1, characterized in that, In step (1), the SCsmith tool is used to construct a C file dataset that can generate jump tables.
4. The testing method for the indirect jump table solving process of binary disassemblers according to claim 1, characterized in that, In step (2), the OracleGT compiler is used to trace the compilation process of the C file to automatically collect indirect jump table information and build binary test sets under different optimization levels.
5. The testing method for the indirect jump table solving process of binary disassemblers according to claim 1, characterized in that, In step 20, the compiler compiles the C file dataset generated by SCsmith. For each C file, the compiler performs the following steps: Step 201: Select compiler parameters and optimization level, and pass the C file as input to the compiler; Step 202: The GCC compiler's RTL Pas converts the switch-case statements in the C file into RTL intermediate language; the GIMPILE_SWITCH structure records the jump table size and the target address of each entry in the jump table; Step 203: The GCC backend traverses each RTL intermediate language instruction and data generated in step 202. For the rtx_jmp_table_data data structure, OracleGT defines additional assembly pseudo-instructions to mark it; Step 204: GCC converts the traversed RTL intermediate language and data into assembly language to generate an assembly file.
6. The testing method for the indirect jump table solving process of binary disassemblers according to claim 5, characterized in that, In step 21, the compiler hands the processed file to the assembler, which performs the following steps: Step 211: The GAS assembler linearly parses the assembly instructions in the assembly file generated in step 204; whenever the .bbinfo_JMPTBL pseudo-instruction is encountered, step 212 is executed; when the last instruction is parsed, step 22 is executed, otherwise step 211 is executed; Step 212: Collect the information of the current jump table here; Step 213: Record the position of the next tag as the base address of the jump table; Step 214: Associate the current jump table information obtained in step 212 with the reference of the base address obtained in step 213, record the offset of the base address reference in the object file, and execute step 211.
7. The testing method for the indirect jump table solving process of binary disassemblers according to claim 1, characterized in that, In step 22, the assembler hands the processed file to the linker; the linker merges the different object files to generate the final binary file, and in the process, it updates the offset of the jump table in the final binary file.
8. The testing method for the indirect jump table solving process of binary disassemblers according to claim 1, characterized in that, Step 23: The linker hands the processed file to the associator, which performs the following steps: Step 231: Perform taint analysis starting from the reference to the jump table base address; Step 232: Initialize taint information for instructions containing jump table cross-references, coloring all registers and stack memory used for writing by the instruction; Step 233: Update the taint information of registers and stack memory in the next instruction according to the control flow information; Traverse all registers and stack memory in the source operands to determine whether the source operands of the instruction are tainted; Step 234: If the source operands are tainted, the registers and stack memory in the destination operands need to be tainted; otherwise, clear the taint information of registers and stack memory in the destination operands. Then, proceed to step 235; Step 235: If the current instruction is an indirect jump and the registers or stack memory in the source operand are colored, then the corresponding indirect jump instruction has been found; otherwise, proceed to step 233. Update the target address of the indirect jump to the control flow graph to facilitate the execution of taint analysis for cross-references in other jump tables.