EOSIO smart contract vulnerability detection method based on AFL fuzzifier

Abstract

The invention discloses an EOSIO smart contract vulnerability detection method based on an AFL fuzzy device, and relates to the technical field of block chain smart contracts, and the method comprises the steps that a fuzzy controller scans and analyzes byte codes and application binary interface files of a smart contract; the fuzzy controller loads and registers a plurality of vulnerability detection plug-ins, and the vulnerability detection plug-ins define attack scenes for triggering specific types of vulnerabilities; according to the attack scene, the fuzzy controller starts an AFL agent to interact with an AFL fuzzy device; the data collector collects an execution track of the smart contract; obtaining code coverage rate information according to the binary interface file of the application program and the basic corpus; the fuzzy controller uses a vulnerability detection plug-in to detect security vulnerabilities in the smart contract according to the collected execution track; according to the method, the information collection step, the fuzzy input generation step and the vulnerability detection step are modularly designed, so that a user can easily develop different vulnerability detection plug-ins according to actual needs to detect corresponding vulnerabilities.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain smart contracts, and in particular to an EOSIO smart contract vulnerability detection method based on an AFL fuzzer. Background Art

[0002] EOSIO is a next-generation open-source blockchain platform with industry-leading transaction speed and flexible utility. It uses Delegated Proof-of-Stake (DPoS) as a consensus protocol and supports smart contracts. As of 2019, the total value of EOSIO's on-chain transactions has exceeded $6 billion. Unfortunately, smart contracts that hold large amounts of cryptocurrency have become a profitable target for attackers.

[0003] Existing smart contract vulnerability detection methods can be roughly divided into formal verification, symbolic execution, and fuzz testing. Formal verification methods use theorem provers or mathematical formal methods to prove specific properties in smart contracts. However, most of them require a lot of manual work to define the correct properties of smart contracts, which makes them difficult to use for automatic vulnerability detection. Symbolic execution methods can effectively explore smart contracts to check for vulnerable patterns and defects expected at runtime. However, symbolic execution methods have the problem of path explosion, which increases the difficulty of applying them to analyze complex smart contracts. Fuzz testing methods provide random transactions as input to smart contracts and then monitor whether the smart contracts have unexpected behaviors or vulnerability patterns. However, black box fuzz testing has low code coverage and may miss many vulnerabilities. AFL (American Fuzzy Lop) is a security-oriented fuzz testing tool that uses a new compile-time instrumentation technology and genetic algorithm to automatically discover test cases that trigger the target two-process program, thereby greatly improving the functional coverage of the test code.

[0004] To address this problem, some grey-box fuzz testing techniques have been proposed and proven to be effective in improving code coverage. However, to the best of the knowledge of the present invention, these existing studies have mainly focused on Ethereum smart contracts. The differences between the Ethereum and EOSIO ecosystems, from virtual machines to bytecode structures and vulnerability scenarios, hinder the direct transfer of Ethereum-centric analysis techniques to EOSIO smart contracts. EOSIO's more complex virtual machine supports a variety of instructions such as floating-point operations and advanced jumps, presenting additional complexity that does not exist in Ethereum. In addition, the complex nested structure of WASM bytecode hinders semantic-level recovery and analysis, requiring complex vulnerability detection methods. In addition, EOSIO vulnerabilities often involve complex scenarios such as integer overflows, which require a deep understanding of platform-specific data structures for accurate analysis, and applying them to EOSIO smart contracts is a challenging task. In addition, existing research has limited detection capabilities and only supports the detection of 5 types of vulnerabilities in EOSIO smart contracts. Summary of the invention

[0005] The purpose of the present invention is to overcome the shortcomings of the prior art, provide an EOSIO smart contract vulnerability detection method based on AFL fuzzer, and increase the scalability of vulnerability detection in EOS related smart contract fuzz testing.

[0006] The objective of the present invention is achieved through the following technical solutions: An EOSIO smart contract vulnerability detection method based on AFL fuzzer, including: Step 1: The fuzzy controller scans and analyzes the bytecode and application binary interface files of the smart contract, extracts the basic corpus as the fuzz test input seed, and initializes the fuzz test environment; Step 2: The fuzzy controller loads and registers multiple vulnerability detection plug-ins, wherein the vulnerability detection plug-ins define attack scenarios that trigger specific types of vulnerabilities; Step 3: According to the attack scenario, the fuzzy controller starts the AFL agent to interact with the AFL fuzzer. The AFL fuzzer generates fuzz test input and sends it to the AFL agent. The AFL agent converts the fuzz test input into transactions. Step 4: The data collector collects the execution trace of the smart contract according to the transaction; obtains the code coverage information according to the application binary interface file and the basic corpus; the fuzzy controller detects security vulnerabilities in the smart contract using the vulnerability detection plug-in according to the collected execution trace; the data collector feeds the collected code coverage information back to the AFL fuzzifier as feedback to change the fuzzy input at the end of each fuzzy iteration.

[0007] Furthermore, the extracting of a basic corpus as a fuzz test input seed and initializing a fuzz test environment specifically includes: The fuzzy controller scans and analyzes the bytecode of the smart contract and builds the constant values ​​and strings appearing in the bytecode into a basic corpus; The fuzzy controller scans and analyzes the binary interface file of the smart contract, extracts the parameter list in each binary interface file and the data type of each parameter; Initialize the fuzz testing environment, including deploying contracts and creating accounts.

[0008] Furthermore, the step 3 specifically includes: The AFL agent generates C programs that simulate the execution of EOSIO smart contracts based on the Kelinci method; Connecting the C program to the shared memory and writing to the location corresponding to the C program branch; AFL fuzzer fuzzifies the EOSIO smart contract by fuzzing the C program to generate fuzz testing input; Using the C program as a forking server, the AFL fuzzer requests the C interface program to fork a new process for the fuzz test input and hand over the fuzz test input to the AFL agent; The AFL agent converts the fuzz testing input into transactions.

[0009] Furthermore, the AFL agent converts the fuzz test input into a transaction, specifically: the AFL agent sorts the parameters according to the data type and length of the parameters in the binary interface file, and converts the fuzz test input of the unstructured byte sequence generated by the AFL fuzzer into a structured transaction parameter suitable for the smart contract.

[0010] Furthermore, the data collector collects the execution track of the smart contract according to the transaction, specifically including: For WASM instructions, add the code to be detected to the interpretation handlers of all control flow related instructions and digital instructions, detect and record the opcode, operand and result of the instruction, as well as the source address and target address of the code block to be detected when the instruction is executed; For the EOSIO built-in functions provided by the EOSIO platform for smart contracts, add detection code to the built-in function handler to record the calling parameters of the built-in functions and the effects of calling the built-in functions; the EOSIO built-in functions are used to implement blockchain status query, smart contract interaction, on-chain data operations and permission checking functions; Test the transfer() function of eosio.token to record the transfer operations of EOS tokens and monitor the account balance.

[0011] Further, the obtaining code coverage information according to the application binary interface file and the basic corpus includes: Detect the interpretation processing program of all control flow related instructions of EOS VM, and whenever EOS VM executes the control flow related instruction, generate a random number as a seed to calculate the identification value cur_location for identifying the currently executed code block; Calculate the number of hit paths based on the identifier value cur_location, and use the number of hit paths as the code coverage of the smart contract; The code coverage information is saved in the shared memory slice, and the identification value cur_location is shifted right by 1 bit.

[0012] Furthermore, the data collector feeds the collected code coverage information back to the AFL fuzzifier, and the specific steps are: writing the shared memory storing the code coverage information into a bitmap memory mapping file and sending it back to the AFL fuzzifier; the AFL fuzzer receives the bitmap memory mapping file collecting the code coverage information from the data collector through the C interface program and writes it into the shared memory.

[0013] Furthermore, it also includes: reversing the transaction with the highest code coverage as a seed input of the AFL fuzzer, and the AFL fuzzer generates a fuzz test of an unstructured byte sequence according to the new seed conversion.

[0014] Furthermore, the vulnerability detection plug-in includes: beforeFuzz() interface, fuzz() interface and afterFuzz() interface; the fuzzy controller uses the vulnerability detection plug-in to detect security vulnerabilities in the smart contract according to the collected execution traces, including: Use the beforeFuzz() interface to pre-configure the necessary blockchain state required to trigger a specific vulnerability; According to the attack scenario, the fuzz() interface constructs an attack scenario description for the fuzzified smart contract and generates the corresponding fuzzy input; After a fuzzy iteration is completed, the fuzzy controller calls the afterFuzz() interface to analyze the execution trace collected by the data collector and uses the test oracle defined by the afterFuzz() interface to check whether the execution trace conforms to the test oracle.

[0015] The beneficial effects of the present invention are: 1) This paper designs a highly scalable fuzz testing framework, which can realize the easy development of emerging vulnerability detection plug-ins, increase scalability by using easy-to-develop plug-ins, reduce the development difficulty, and promote vulnerability mining in fuzz testing of EOS-related smart contracts; and realize information collection by using blockchain software detection to obtain the necessary information for detecting vulnerabilities.

[0016] 2) The present invention adopts a gray-box testing method based on AFL, and uses the AFL fuzzer as the fuzzy input generation engine, which can effectively trigger branches that are difficult to cover, improve code coverage, and thus more effectively identify vulnerabilities; in order to interface with AFL, the present invention designs a Kelinci-based C program in the AFL agent to interact with AFL, and the C program can simulate the execution of EOSIO smart contracts.

[0017] 3) The present invention provides a unified interface for developing detection plug-ins. The detection plug-in only needs a small amount of code to describe the attack scenario, and the test oracle can detect new vulnerability types. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is the basic framework of the EOSIO smart contract vulnerability detection method based on AFL fuzzer. DETAILED DESCRIPTION

[0019] The technical solution of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0020] See also Figure 1 , the present invention provides a technical solution: like Figure 1 , an EOSIO smart contract vulnerability detection method based on AFL fuzzer, including: Step 1: The fuzzy controller scans and analyzes the bytecode and application binary interface files of the smart contract, extracts the basic corpus as the fuzz test input seed, and initializes the fuzz test environment; Extract the basic corpus as the fuzz test input seed and initialize the fuzz test environment, including: Step 11: The fuzzy controller scans and analyzes the bytecode of the smart contract and constructs the constant values ​​and strings appearing in the bytecode into a basic corpus; Step 12: The fuzzy controller scans and analyzes the binary interface file of the smart contract, extracts the parameter list in each binary interface file and the data type of each parameter; Step 13: Initialize the fuzz testing environment, including deploying contracts and creating accounts.

[0021] Step 2: The fuzzy controller loads and registers multiple vulnerability detection plug-ins, wherein the vulnerability detection plug-ins define attack scenarios that trigger specific types of vulnerabilities; The vulnerability detection plug-in includes: beforeFuzz() interface, fuzz() interface and afterFuzz() interface.

[0022] The beforeFuzz() interface is responsible for setting the necessary blockchain state configuration required to trigger a specific vulnerability; at the same time, some detection plug-ins will deploy attack agents, which are smart contracts that simulate attacker behavior to build attack scenarios.

[0023] The interface fuzz() is responsible for describing how to build an attack scenario for the fuzzed smart contract; technically speaking, the attack scenario specifies how to trigger the vulnerability, that is, to generate fuzzy inputs for the functions of the smart contract or the deployed attack agent. According to the attack scenario, the fuzz controller requests the fuzz test input from the AFL agent and sends it to the data collector to execute and collect transaction execution traces.

[0024] The afterFuzz() interface defines the test oracle for a specific vulnerability. After a fuzz iteration is completed, the fuzzy controller calls the afterFuzz() of the detection plugin to analyze the execution trace collected by the data collector and check whether the execution trace meets the test oracle.

[0025] Each vulnerability detection plug-in is an independent Java class that meets the three interfaces defined in the present invention. During the compilation process, the default folder will be searched to load the detection plug-in, and the plug-in will be compiled into the framework. This design has two advantages. On the one hand, since the plug-ins are compiled into the framework, they run in the same process, which enables the plug-in to directly obtain the execution trace and fuzz test input. On the other hand, the present invention can directly call the interface in the detection plug-in, so the costly IPC (inter-process communication) is eliminated.

[0026] Step 3: According to the attack scenario, the fuzzy controller starts the AFL agent to interact with the AFL fuzzer. The AFL fuzzer generates a fuzz test input and sends it to the AFL agent. The AFL agent converts the fuzz test input into a transaction. Step 3 specifically includes: Step 31: The AFL agent generates a C program that simulates the execution of the EOSIO smart contract based on the Kelinci method; Step 32: Connect the C program to the shared memory and write it to the location corresponding to the C program branch; Step 33: AFL fuzzer fuzzifies the EOSIO smart contract by fuzzifying the C program to generate fuzz test input; Step 34: Using the C program as a forking server, the AFL fuzzer requests the C interface program to fork a new process for the fuzz test input and transfer the fuzz test input to the AFL agent; Step 35: The AFL agent converts the fuzz testing input into transactions.

[0027] In fact, the AFL fuzzer does not know that it is fuzzing an EOSIO smart contract, but thinks that it is fuzzing this C program. The C program implements a forked server that is identical to the forked server in the program that the AFL compiler is instrumenting.

[0028] For the subsequent processing, when the AFL fuzzer generates fuzzy input and requests the interface program to fork the process, the fuzzy input is handed over to the AFL agent. Then, the fuzz test input is converted into transactions and executed in the data collector. After execution, the C interface program receives the collected code coverage bitmap memory mapping file from the data collector and writes it to the shared memory. Therefore, from the perspective of the AFL fuzzer, the execution path of this C program is exactly the same as that of the EOSIO smart contract.

[0029] The AFL agent converts the fuzz test input into a transaction, specifically: the AFL agent sorts the parameters according to the data type and length of the parameters in the binary interface file, and converts the fuzz test input of the unstructured byte sequence generated by the AFL fuzzer into a structured transaction parameter suitable for the smart contract.

[0030] In order to solve the problem that the AFL fuzzer generates unstructured byte sequences as fuzz testing inputs, while the smart contract function only accepts structured transactions, the AFL agent needs to convert the byte sequences generated by AFL into transaction parameters of the smart contract. The specific operation is as follows: the AFL agent sorts the parameters according to the data type and length of the parameters in the binary interface file obtained in step 1. The sorting rules are as follows: fixed-length parameter types are placed in front, and variable-length parameter types (such as strings) are placed at the end of the parameter list. For each fixed-length parameter in the parameter list, the AFL agent intercepts the corresponding number of bits from the byte sequence according to the length of its type. For variable-length parameters, after intercepting the bytes of the fixed-length parameters, the AFL agent evenly distributes the remaining bytes according to the number of variable-length parameters.

[0031] Taking the hexadecimal byte sequence 0x1623 416e7446757a7a6572 as an example, the parameter list of the function is (string, uint8,uint8). After sorting the ABI, the sorted parameter list is (uint8, uint8,string). Then, the AFL agent intercepts the first 8 bits (i.e., the first byte, 0x16) from the byte sequence and converts it to a uint8 type parameter (22 in decimal). Then, the AFL agent generates the second uint8 type parameter in the same way. Finally, the remaining bytes 0x416e7446757a7a6572 are converted to a string type parameter. In order to ensure that all parameters can be allocated enough bits, the present invention makes minimal modifications to AFL to support the generation of fuzzy inputs with a specified minimum length.

[0032] Step 4: The data collector collects the execution trace of the smart contract according to the transaction; obtains the code coverage information according to the application binary interface file and the basic corpus; the fuzzy controller detects security vulnerabilities in the smart contract using the vulnerability detection plug-in according to the collected execution trace; the data collector feeds the collected code coverage information back to the AFL fuzzifier as feedback to change the fuzzy input at the end of each fuzzy iteration.

[0033] The data collector collects the execution track of the smart contract according to the transaction, including: Step 401: For WASM instructions, add the code to be detected to the interpretation handlers of all control flow related instructions and digital instructions, detect and record the opcode, operand and result of the instruction, as well as the source address and target address of the code block to be detected when the instruction is executed; control flow related instructions include call, call_indirect, br and br_if, etc. By tracking WASM instructions, scalable analysis supporting various vulnerabilities can be achieved.

[0034] Step 402: For the EOSIO built-in functions provided by the EOSIO platform for smart contracts, add detection code to the built-in function handler to record the call parameters of the built-in functions and the effects of calling the built-in functions; the EOSIO built-in functions are used to implement blockchain status query, smart contract interaction, on-chain data operations and permission checking functions; these built-in functions are implemented as the host environment of the EOS VM and imported into the bytecode of the smart contract.

[0035] Step 403: Check the transfer() function of eosio.token, record the transfer operation of EOS tokens and monitor the account balance.

[0036] The recorded execution trace will be stored in a separate trace file to be analyzed by the instrumentation plugin.

[0037] Obtaining code coverage information according to the application binary interface file and the basic corpus includes: Step 411: Detect the interpretation processing program of all control flow related instructions of EOS VM, and whenever EOS VM executes the control flow related instruction, generate a random number as a seed to calculate the identification value cur_location for identifying the code block currently being executed; Step 412: Calculate the number of hit paths according to the identification value cur_location, and use the number of hit paths as the code coverage of the smart contract; Step 413: Save the code coverage information in the shared memory slice and shift the identification value cur_location right by 1. The shared memory will be written into the bitmap memory mapping file and sent back to the AFL fuzzer.

[0038] The present invention implements a code coverage calculation method compatible with AFL in a data collector. AFL uses C / C++ programs to initialize compile-time random variables to identify code blocks, and AFL uses shared memory slices to save code coverage information. The code coverage calculation algorithm of the present invention does not need to detect WASM bytecode to identify code blocks, but detects EOS VM to achieve the same purpose. By plugging EOS VM instead of WASM bytecode, the present invention compiles the test code of EOS VM into native code, which will reduce the cost of testing contracts one by one, improve the efficiency of fuzz testing, and speed up the algorithm operation.

[0039] The fuzzy controller uses the vulnerability detection plug-in to detect security vulnerabilities in smart contracts based on the collected execution traces, including: Step 421: Use the beforeFuzz() interface to pre-configure the necessary blockchain state required to trigger a specific vulnerability; Step 422: According to the attack scenario, the fuzz() interface constructs an attack scenario description for the fuzzified smart contract and generates the corresponding fuzzy input; Step 423: After a fuzzy iteration is completed, the fuzzy controller calls the afterFuzz() interface, analyzes the execution trace collected by the data collector, and uses the test oracle defined by the afterFuzz() interface to check whether the execution trace meets the test prediction.

[0040] Since AFL can only detect direct misbehavior, such as crashes or failed assertions. However, security vulnerabilities in smart contracts are closely related to their business logic and cannot be simply judged by these crashes or failures. The present invention only uses AFL for input generation and uses detection plug-ins to complete complex vulnerability detection tasks. It is easy to develop detection plug-ins on the present invention because it already provides services for fuzzy input generation and data collection in its modularity, AFL agent, and data collector. The detection plug-in only needs to implement attack scenarios that trigger specific vulnerabilities and test the oracle to detect them, without modifying the EOS VM or understanding any details of fuzzy input generation.

[0041] Furthermore, the data collector feeds the collected code coverage information back to the AFL fuzzer, and the specific steps are: writing the shared memory storing the code coverage information into a bitmap memory mapping file and sending it back to the AFL fuzzer; the AFL fuzzer receives the bitmap memory mapping file collecting the code coverage information from the data collector through a C interface program, and writes it into the shared memory. The code coverage information is fed to the AFL fuzzer through the memory mapping file and the shared memory, and the present invention effectively reduces the communication overhead to achieve ideal fuzz testing efficiency.

[0042] Furthermore, it also includes: reversing the transaction with the highest code coverage as a seed input of the AFL fuzzer, and the AFL fuzzer generates a fuzz test of an unstructured byte sequence according to the new seed conversion.

[0043] As a mutation-based gray-box fuzzer, AFL relies on seed input to guide the fuzz testing process. The present invention uses a two-stage method to select good seeds by reversing the transaction with the highest code coverage as the seed of the AFL fuzzer after one iteration to better generate fuzz tests.

[0044] The present invention uses AFL-style grey-box testing, which can effectively trigger branches that are difficult to cover, improve code coverage, and thus more effectively identify vulnerabilities; uses easy-to-develop plug-ins to increase scalability, reduce development difficulty, and promote vulnerability mining in fuzz testing of EOS-related smart contracts; uses multiple performance optimization designs, and effectively reduces communication overhead between modules by using memory mapping and shared memory to exchange code coverage information and fuzz testing inputs.

[0045] The above is only a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the form disclosed herein, and should not be regarded as excluding other embodiments, but can be used in various other combinations, modifications and environments, and can be modified within the scope of the concept described herein through the above teachings or the technology or knowledge of the relevant field. The changes and modifications made by those skilled in the art shall not deviate from the spirit and scope of the present invention, and shall be within the scope of protection of the claims attached to the present invention.

Claims

1. A method for detecting EOSIO smart contract vulnerabilities based on AFL fuzzer, characterized by: include: Step 1: The fuzzy controller scans and analyzes the bytecode and application binary interface files of the smart contract, extracts the basic corpus as the fuzz test input seed, and initializes the fuzz test environment; Step 2: The fuzzy controller loads and registers multiple vulnerability detection plug-ins, wherein the vulnerability detection plug-ins define attack scenarios that trigger specific types of vulnerabilities; Step 3: According to the attack scenario, the fuzzy controller starts the AFL agent to interact with the AFL fuzzer. The AFL fuzzer generates fuzz test input and sends it to the AFL agent. The AFL agent converts the fuzz test input into transactions. Step 4: The data collector collects the execution trace of the smart contract according to the transaction; Obtaining code coverage information according to the application binary interface file and the basic corpus; The fuzzy controller uses the vulnerability detection plug-in to detect security vulnerabilities in the smart contract based on the collected execution traces; The data collector feeds the collected code coverage information back to the AFL fuzzer as feedback to change the fuzzing input at the end of each fuzzing iteration.

2. The EOSIO smart contract vulnerability detection method based on AFL fuzzer according to claim 1 is characterized by: The extracting of the basic corpus as the fuzz test input seed and initializing the fuzz test environment specifically includes: The fuzzy controller scans and analyzes the bytecode of the smart contract and builds the constant values ​​and strings appearing in the bytecode into a basic corpus; The fuzzy controller scans and analyzes the binary interface file of the smart contract, extracts the parameter list in each binary interface file and the data type of each parameter; Initialize the fuzz testing environment, including deploying contracts and creating accounts.

3. The EOSIO smart contract vulnerability detection method based on AFL fuzzer according to claim 2 is characterized by: The step 3 specifically includes: The AFL agent generates C programs that simulate the execution of EOSIO smart contracts based on the Kelinci method; Connecting the C program to the shared memory and writing to the location corresponding to the C program branch; AFL fuzzer fuzzifies the EOSIO smart contract by fuzzing the C program to generate fuzz testing input; Using the C program as a forking server, the AFL fuzzer requests the C interface program to fork a new process for the fuzz test input and hand over the fuzz test input to the AFL agent; The AFL agent converts the fuzz testing input into transactions.

4. The EOSIO smart contract vulnerability detection method based on AFL fuzzer according to claim 3 is characterized by: The AFL agent converts the fuzz test input into a transaction, specifically: the AFL agent sorts the parameters according to the data type and length of the parameters in the binary interface file, and converts the fuzz test input of the unstructured byte sequence generated by the AFL fuzzer into a structured transaction parameter suitable for the smart contract.

5. The EOSIO smart contract vulnerability detection method based on AFL fuzzer according to claim 1 is characterized by: The data collector collects the execution track of the smart contract according to the transaction, specifically including: For WASM instructions, add the code to be detected to the interpretation handlers of all control flow related instructions and digital instructions, detect and record the opcode, operand and result of the instruction, as well as the source address and target address of the code block to be detected when the instruction is executed; For the EOSIO built-in functions provided by the EOSIO platform for smart contracts, add detection code to the built-in function handler to record the calling parameters of the built-in functions and the effects of calling the built-in functions; the EOSIO built-in functions are used to implement blockchain status query, smart contract interaction, on-chain data operations and permission checking functions; Test the transfer() function of eosio.token to record the transfer operations of EOS tokens and monitor the account balance.

6. The EOSIO smart contract vulnerability detection method based on AFL fuzzer according to claim 5 is characterized by: The obtaining of code coverage information according to the application binary interface file and the basic corpus includes: Detect the interpretation processing program of all control flow related instructions of EOS VM, and whenever EOS VM executes the control flow related instruction, generate a random number as a seed to calculate the identification value cur_location for identifying the currently executed code block; Calculate the number of hit paths based on the identifier value cur_location, and use the number of hit paths as the code coverage of the smart contract; The code coverage information is saved in the shared memory slice, and the identification value cur_location is shifted right by 1 bit.

7. The EOSIO smart contract vulnerability detection method based on AFL fuzzer according to claim 6 is characterized by: The data collector feeds the collected code coverage information back to the AFL fuzzifier. The specific steps are: writing the shared memory storing the code coverage information into a bitmap memory mapping file and sending it back to the AFL fuzzifier; the AFL fuzzifier receives the bitmap memory mapping file containing the collected code coverage information from the data collector through a C interface program and writes it into the shared memory.

8. The EOSIO smart contract vulnerability detection method based on AFL fuzzer according to claim 7 is characterized by: Also includes: The transaction with the highest code coverage is reversed as the seed input of the AFL fuzzer, and the AFL fuzzer generates fuzz tests of unstructured byte sequences based on the new seed transformation.

9. The EOSIO smart contract vulnerability detection method based on AFL fuzzer according to claim 7 is characterized by: The vulnerability detection plug-in includes: beforeFuzz() interface, fuzz() interface and afterFuzz() interface; the fuzzy controller uses the vulnerability detection plug-in to detect security vulnerabilities in the smart contract according to the collected execution traces, including: Use the beforeFuzz() interface to pre-configure the necessary blockchain state required to trigger a specific vulnerability; According to the attack scenario, the fuzz() interface constructs an attack scenario description for the fuzzified smart contract and generates the corresponding fuzzy input; After a fuzzy iteration is completed, the fuzzy controller calls the afterFuzz() interface to analyze the execution trace collected by the data collector and uses the test oracle defined by the afterFuzz() interface to check whether the execution trace conforms to the test oracle.

Images