An Automated System and Method for Repairing Smart Contract Vulnerabilities Based on Bytecode Rewriting

Abstract

This invention discloses an automated smart contract vulnerability repair system and method based on bytecode rewriting, comprising at least a virtual execution engine component, a vulnerability detector component, and a bytecode rewriter component. The system accepts the original contract bytecode and an optional control policy file as input. The virtual execution engine component mines more semantic information at the bytecode level, the vulnerability detector component identifies vulnerability-related semantics and filters sensitive instructions, and finally the bytecode rewriter rewrites the bytecode, outputting hardened contract bytecode and a repair report. This achieves superior automated repair results while ensuring minimal hardening code and minimal additional gas overhead.

Description

Technical Field

[0001] This invention belongs to the field of blockchain smart contract vulnerability detection and repair technology, and mainly relates to an automated repair system and method for smart contract vulnerabilities based on bytecode rewriting. Background Technology

[0002] Security research on smart contracts has been an extremely important task in recent years. However, despite numerous efforts in vulnerability detection, many well-known vulnerabilities still appear in newly deployed smart contracts. A prominent example is the reentrancy attack that occurred in a Uniswap contract in 2020. This vulnerability was discovered as early as April 2019 but was not properly patched. The root cause of this problem is that many developers lack professional vulnerability patching skills. Even when vulnerabilities are discovered with the help of automated detection tools, most developers lack the ability to patch them. Therefore, research on automated patching techniques is just as urgent as research on vulnerability detection techniques.

[0003] Existing smart contract auto-repair technologies mainly focus on two research directions. One is to insert patches at the source code level, which has the drawback of over-reliance on the contract source code and poor general applicability. The other research direction is to insert patches at the bytecode level, with typical implementations including EVMPatch, Elysium, and SmartShield. Existing methods share a common drawback: a lack of semantic analysis of the contract bytecode. This leads to a proliferation of repetitive hardening code, resulting in massive additional gas overhead and ultimately limiting the effectiveness of the hardened contract in a real-world production environment. Summary of the Invention

[0004] This invention addresses the shortcomings of existing technologies, such as the lack of semantic extraction from bytecode, limited support for automated vulnerability repair, and overly simplistic vulnerability repair solutions. It provides an automated smart contract vulnerability repair system and method based on bytecode rewriting, comprising at least a virtual execution engine component, a vulnerability detector, and a bytecode rewriter. The virtual execution engine component includes symbolic execution and semantic extraction, tracks the stack state of each instruction, and records current memory and storage usage, enabling the extraction of more semantic information at the bytecode level. The vulnerability detector has an embedded instruction filter responsible for parsing the semantic information extracted from the virtual execution engine component, identifying sensitive instructions, and filtering them according to sensitive instruction filtering rules. The bytecode rewriter performs bytecode rewriting based on trampoline injection and offset correction injection. The system accepts the original contract bytecode and an optional control policy file as input. The virtual execution engine component extracts more semantic information at the bytecode level, the vulnerability detector filters sensitive instructions, and finally the bytecode rewriter rewrites the bytecode, outputting the hardened contract bytecode and a repair report. This achieves superior automated repair results while minimizing the amount of hardened code and additional gas overhead.

[0005] To achieve the above objectives, the technical solution adopted by this invention is: an automated smart contract vulnerability repair system based on bytecode rewriting, comprising at least a virtual execution engine component, a vulnerability detector component, and a bytecode rewriter component.

[0006] The virtual execution engine components include symbolic execution and semantic extraction, track the stack state of each instruction, and record the current memory and storage usage, enabling the extraction of more semantic information at the bytecode level;

[0007] The vulnerability detector component has an embedded instruction filter, which is responsible for parsing the semantic information extracted from the virtual execution engine component and finding sensitive instructions, and filtering them according to the sensitive instruction filtering rules.

[0008] The bytecode rewriter component combines two schemes—trampoline-based injection and offset-correction-based injection—to achieve bytecode rewriting.

[0009] The system accepts the original contract bytecode and an optional control policy file as input. The virtual execution engine component mines more semantic information at the bytecode level, the vulnerability detector component identifies vulnerability-related semantics and filters sensitive instructions, and finally the bytecode is rewritten by the bytecode rewriter, outputting the hardened contract bytecode and a repair report.

[0010] To achieve the above objectives, the present invention also adopts the following technical solution: an automated method for repairing smart contract vulnerabilities based on bytecode rewriting, comprising the following steps:

[0011] S1: Input the original contract bytecode and control policy file;

[0012] S2: Start the local virtual execution engine component to perform symbolic execution and semantic extraction and generate a control flow graph;

[0013] S3: By using a vulnerability detector, based on multiple sensitive instruction filtering rules, vulnerability-related semantics are filtered to find the locations that need to be fixed;

[0014] S4: Bytecode rewriting is performed using bytecode rewriters based on trampoline injection and offset correction injection to achieve automated repair with minimal gas overhead;

[0015] S5: Outputs the hardened contract bytecode and a repair report.

[0016] As an improvement of the present invention, in step S1, the original contract bytecode is a bytecode file with the .bin extension; the control strategy file is optional and assists the user in explicitly specifying the specific functions in the bytecode that need to be repaired.

[0017] As an improvement of the present invention, step S2 specifically involves: truncating the metadatahash and deploymentcode in the original contract bytecode to obtain the remaining part, which is then tested and hardened into runtimecode; by identifying characteristic instructions, splitting all instructions into multiple basic blocks; starting the local virtual execution engine, opening a global call stack, and reading and performing symbolic execution starting from the first instruction of the runtimecode; during the symbolic execution process, identifying the preceding and following basic blocks for each basic block, and finally constructing the control flow graph (CFG) of the original contract bytecode.

[0018] As an improvement to the present invention, during the symbolic execution of step S2, if the current execution flow reaches the last instruction of the basic block, the type of the current basic block is determined based on that instruction to determine the subsequent execution flow, specifically as follows:

[0019] a) If the last instruction of a basic block is a JUMP instruction, then the current basic block is an unconditional jump basic block, and the current top element of the stack is the offset of the next basic block to be executed.

[0020] b) If the last instruction of the basic block is the JUMPI instruction, it means that the current basic block is a conditional jump basic block. The current top element of the stack specifies the basic block corresponding to the condition being true. The two branch basic blocks are executed in turn according to the principle of depth-first traversal.

[0021] c) If the last instruction of a basic block is a STOP, RETURN, REVERT, SELFDESTRUCT, or ASSERTFAIL instruction, then the current basic block is the terminating basic block, serving as the boundary for recursive calls.

[0022] d) All remaining basic blocks are executed sequentially. After execution, their subsequent basic blocks can be executed directly.

[0023] As another improvement of the present invention, in step S3, the existence of a vulnerability is determined based on three semantic features: stack state, control flow, and block content.

[0024] As another improvement of the present invention, step S3, filtering sensitive instructions based on sensitive instruction filtering rules, specifically includes:

[0025] 1) If the basic block is automatically generated by the compiler solc, the instructions in it are assumed to be safe by default;

[0026] 2) If an instruction has been hardened, subsequent instructions on the path containing that instruction do not need to be hardened again;

[0027] 3) In the conditional jump logic, the SMT solver Z3 is used to determine the satisfiability of the conditional expression. If there is an unreachable path, the hardening of the branch path is canceled by default.

[0028] As another improvement of the present invention, in step S4, the hardening code based on the offset-modified injection scheme is inserted before and after the sensitive instructions, and the hardening code based on the trampoline-based injection scheme is sequentially concatenated at the end of the original bytecode, and the address offsets of each instruction in the hardened bytecode are reallocated.

[0029] As another improvement of the present invention, step S5 specifically involves: reassembling the deploymentcode, runtimecode, and metadata hash; matching the PUSH instruction in the deploymentcode using regular expressions; correcting its push value to the length of the hardened runtimecode; and outputting the hardened contract bytecode .bin file and the repair report .json file.

[0030] Compared with existing technologies, this invention offers the following advantages: Based on the concept of symbolic execution, it implements an automated smart contract vulnerability repair system and method based on bytecode rewriting. This system accepts the original contract bytecode and an optional control policy file as input, ultimately outputting hardened contract bytecode and a repair report. The virtual execution engine component within this invention is responsible for generating the control flow graph (CFG). During the traversal of all possible execution paths, this component tracks the stack state of each instruction and records the current memory and storage usage, thereby extracting more semantic information at the bytecode level. The vulnerability detector component is responsible for parsing the semantic information extracted from the previous component and identifying sensitive instructions. Simultaneously, through customized sensitive instruction filtering rules, it successfully reduces the amount of hardened code. The bytecode rewriter component combines trampoline-based injection and offset-modified injection, successfully overcoming the minimum 5-byte block size limit and eliminating the gas overhead caused by "dead code."

[0031] The automated remediation solution provided by this invention successfully addresses the shortcomings of existing technologies, including: lack of semantic extraction of bytecode, limited support for automated remediation of vulnerability types, and overly simplistic vulnerability remediation solutions. This invention achieves superior remediation results while ensuring minimal hardening code and minimal additional gas overhead. Attached Figure Description

[0032] Figure 1 This is a flowchart of the steps of the method of the present invention;

[0033] Figure 2 This is a flowchart illustrating the process of bytecode semantic extraction based on symbolic execution in step S2 of the method of the present invention. Detailed Implementation

[0034] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0035] Example 1

[0036] This bytecode rewriting-based automated smart contract vulnerability patching system is used to immediately detect and patch potentially vulnerable smart contracts in Ethereum. It includes at least a virtual execution engine that performs symbolic execution and semantic extraction, a vulnerability detector with an embedded instruction filter, and a bytecode rewriter combining trampoline injection and offset correction injection. The virtual execution engine component includes symbolic execution and semantic extraction, tracks the stack state of each instruction, and records current memory and storage usage, enabling the extraction of more semantic information at the bytecode level. The vulnerability detector has an embedded instruction filter responsible for parsing the semantic information extracted from the virtual execution engine component and identifying sensitive instructions. It filters these instructions according to sensitive instruction filtering rules, successfully reducing the amount of hardened code. The bytecode rewriter, based on trampoline injection and offset correction injection, performs bytecode rewriting.

[0037] The system accepts the original contract bytecode and an optional control policy file as input. A virtual execution engine component extracts more semantic information at the bytecode level, a vulnerability detector filters sensitive instructions, and finally a bytecode rewriter rewrites the bytecode, outputting the hardened contract bytecode and a remediation report. This invention successfully overcomes the shortcomings of existing technologies, such as the lack of semantic extraction from bytecode, limited support for automated vulnerability remediation, and overly simplistic vulnerability remediation solutions. It achieves superior automated remediation results while minimizing the amount of hardened code and additional gas overhead.

[0038] Example 2

[0039] An automated method for fixing smart contract vulnerabilities based on bytecode rewriting, such as Figure 1 As shown, the specific steps include the following:

[0040] Step S1: Input the original contract bytecode and an optional control policy file;

[0041] The original contract bytecode is written to a specified file, resulting in a bytecode file with the .bin extension. If only the contract source code is currently provided, it needs to be pre-compiled into bytecode using the solc compiler before being written to the file.

[0042] The control policy file is optional and is designed to help users explicitly specify the specific functions in the bytecode that need to be fixed. The control policy is described in JSON format. "action" specifies the specific operation the current tool is required to perform, and "scope" specifies an array where each element is an Object. Two key values ​​must be specified: "func_sig" and "para_types". "func_sig" specifies the first four bytes of the target function's hash value, and "para_types" specifies the parameter types of the target function.

[0043] The prepared .bin and .json files are used together as input to the tool.

[0044] Step S2: Start the local virtual execution engine to perform semantic extraction and generate a control flow graph;

[0045] like Figure 2 As shown, the steps for starting the local virtual execution engine to perform semantic extraction and generate a control flow graph include:

[0046] The metadata hash in the original contract bytecode is detected and truncated using regular expressions. Currently, there are two forms: one is a 43-byte swarm hash, i.e., 0xa1 0x65'b”z”z”r''0'0x58 0x20 <32 bytes swarmhash>0x00 0x29; the other is a 53-byte IPFS hash, i.e., 0xa2 0x64'i”p”f”s'0x58 0x22 <34 bytes IPFS hash>0x64's”o”l”c'0x43 <3 bytes version encoding>0x00 0x33;

[0047] The deployment code in the original contract bytecode was detected and extracted using regular expressions. There are two forms: one form has the deployment code ending with the RETURN and STOP instructions, and the runtime code starting with PUSH1 0x80 and PUSH1 0x40, corresponding to the bytecode "f30060806040"; the other form has the deployment code ending with the RETURN and INVALID instructions, and the runtime code starting with PUSH1 0x80 and PUSH1 0x40, corresponding to the bytecode "f3fe60606040".

[0048] The original bytecode is truncated to obtain the remaining part, which is the runtime code that needs to be detected and hardened.

[0049] Use EVM to disassemble the runtime code to obtain the EVM instruction set corresponding to the bytecode;

[0050] By identifying the characteristic instructions JUMPDEST, JUMPI, JUMP, STOP, RETURN, REVERT, SELFDESTRUCT, and ASSERTFAIL, all instructions are broken down into multiple basic blocks;

[0051] The local virtual execution engine is started, a global call stack is allocated, and symbolic execution is performed starting from the first instruction of the runtime code. Internally, the local virtual execution engine maintains a large switch-case structure, with each instruction in the EVM instruction set corresponding to a case. Any input from the outside is represented by the symbol "instr_offset(operand list)".

[0052] For all instructions in a basic block, record the current stack state before the instructions are symbolically executed, and also record the current global memory and storage usage.

[0053] If the current execution flow reaches the last instruction of a basic block, the type of the current basic block is determined based on that instruction to determine the subsequent execution flow. This can be categorized into four cases:

[0054] a) If the last instruction of a basic block is a JUMP instruction, then the current basic block is an unconditional jump basic block, and the current top element of the stack is the offset of the next basic block to be executed.

[0055] b) If the last instruction of the basic block is the JUMPI instruction, it means that the current basic block is a conditional jump basic block. The current top element of the stack specifies the basic block corresponding to the condition being true. The two branch basic blocks are executed in turn according to the principle of depth-first traversal.

[0056] c) If the last instruction of a basic block is a STOP, RETURN, REVERT, SELFDESTRUCT, or ASSERTFAIL instruction, then the current basic block is the terminating basic block, serving as the boundary for recursive calls.

[0057] d) All remaining basic blocks are executed sequentially. After execution, their subsequent basic blocks can be executed directly.

[0058] During symbolic execution, for each basic block, its preceding and following basic blocks are identified, and finally the control flow graph (CFG) of the original contract bytecode is constructed.

[0059] Step S3: Based on multiple sensitive instruction filtering rules, filter vulnerability-related semantics to find the locations that need to be fixed;

[0060] Identifying loop structures and coarse-grained function semantics in CFG, specifically including:

[0061] Some CFGs may contain nested calls and loop structures. To avoid potential path explosion problems, the virtual execution engine will constrain the maximum number of times each instruction can be executed to 5. Once this limit is reached, the current instruction will stop being executed, and backtracking analysis will be performed on multiple basic blocks that have reached the limit consecutively to determine that it is a loop structure.

[0062] After symbolic execution, coarser-grained structure-related semantics are identified at the bytecode level, that is, all the basic blocks contained in a complete function logic, including function selectors, function wrappers, function bodies, etc.

[0063] Furthermore, the tuples associated with jump instructions (PUSH, JUMP / JUMPI, JUMPDEST) specifically include:

[0064] Iterate through all instructions in the original contract bytecode;

[0065] If it is a JUMP / JUMPI instruction, then manage the JUMPDEST instruction corresponding to its top stack element; determine which instruction it comes from based on the push offset of the top stack element;

[0066] If it is a SWAP instruction or a DUP instruction, it is marked as a interference instruction. Further backtracking is performed until the PUSH instruction whose stack top value is equal to the push value. The three are associated to form a mutually bound tuple.

[0067] Based on multiple sensitive instruction filtering rules, this invention filters vulnerability-related semantics. It primarily examines three semantic features to determine the existence of a vulnerability: stack state, control flow, and block content. Specifically:

[0068] a) Regarding the Tx.Origin authentication vulnerability, check whether the EQ command contains the ORIGIN content;

[0069] b) For denial-of-service vulnerabilities, check if the third element of the CALL instruction in the stack is non-zero. Also, the basic block containing the CALL instruction must not only be within a loop but also end with a JUMPI instruction;

[0070] c) Regarding reentrancy vulnerabilities, first check if the third element of the stack in the CALL instruction is non-zero and if the top of the stack is a specific value of 2300 (gas limit). Then check if the path where the CALL instruction is located contains the SLOAD instruction, and if the top of the stack in the SLOAD instruction is unmodifiable;

[0071] d) For unchecked external call vulnerabilities, check whether the CALL content is contained in the ISZERO instruction;

[0072] e) To address the untrusted delegate call vulnerability, check if the DELEGATECALL instruction exists in the path of the EQ instruction. The second element of the DELEGATECALL instruction's stack is in the stack of the EQ instruction.

[0073] f) For vulnerabilities in unprotected self-destruct instructions, check if the path where the SELFDESTRUCTION instruction is located contains the EQ instruction. The stack top of the SELFDESTRUCTION instruction is in the stack of the EQ instruction.

[0074] g) For arithmetic overflow vulnerabilities, use hardened templates for matching.

[0075] All collected sensitive commands are further filtered based on sensitive command filtering rules, specifically including:

[0076] 1) If the basic block is automatically generated by the compiler solc, the instructions in it are assumed to be safe by default;

[0077] 2) If an instruction has been hardened, subsequent instructions on the path containing that instruction do not need to be hardened again;

[0078] 3) In the conditional jump logic, the SMT solver Z3 is used to determine the satisfiability of the conditional expression. If there is an unreachable path, the hardening of the branch path is canceled by default.

[0079] Step S4: Combine trampoline jump and offset correction schemes to achieve automated repair that minimizes gas overhead;

[0080] The sensitive instructions are moved to the end of the original bytecode, and verification logic is inserted before and after them to form a new basic block. The first instruction of the new basic block is the JUMPDEST instruction, and the last instruction is filled with the JUMP instruction.

[0081] Insert trampoline instructions at the original location of the sensitive instructions. Specifically, there are three instructions: the first is the PUSH instruction, which is used to insert the return address; the second is the PUSH instruction, which is used to insert the target address to which the jump is needed; and the third is the JUMP instruction, which is used to jump to the hardened code, usually at the end of the original bytecode.

[0082] After inserting the trampoline instruction, the instructions before and after these three instructions are re-associated to avoid "dead code" introduced due to the excessive length of the original basic block, namely the INVALID / JUMPDEST instructions;

[0083] When the control flow escapes to the hardened code, if the verification fails, it will REVERT; if the verification succeeds, it will resume the normal execution flow.

[0084] If the hardened code needs to introduce state variables, then a new slot is re-allocated using the used storage recorded by the virtual execution engine, and its address is max(storage_record)+1;

[0085] If local variables need to be introduced in the hardening code, modify the first three instructions in the bytecode that control the memory layout. For example, change (PUSH1 0x80,PUSH1 0x40,MSTORE) to (PUSH1 0xa0,PUSH1 0x40,MSTORE). Then 0x80-0x9f becomes the dedicated memory space for hardening.

[0086] The CFG of the reconstructed and hardened bytecode specifically includes:

[0087] For the original bytecode, maintain the original logical order;

[0088] Hardening code based on offset-modified injection is inserted before or after sensitive instructions;

[0089] The hardened code based on the trampoline-based injection scheme is sequentially appended to the end of the original bytecode.

[0090] The address offsets of each instruction in the hardened bytecode are reallocated;

[0091] Based on the triplet of associated jump instructions (PUSH, JUMP / JUMPI, JUMPDEST), correct the stack values ​​of all related PUSH instructions.

[0092] Step 5: Output the hardened contract bytecode and repair report.

[0093] The steps for outputting the hardened contract bytecode and repair report include:

[0094] Reassemble the deploymentcode, runtimecode, and metadata hash;

[0095] The regular expression r"61\w{4}8061\w{4}6000396000f300" is used to match the PUSH instruction in the deployment code, and its push value is corrected to the length of the hardened runtime code.

[0096] Output the hardened contract bytecode (.bin file) and the repair report (.json file).

[0097] In summary, this invention introduces the concept of symbolic execution, performing semantic analysis at the bytecode level of smart contracts. This makes the types of vulnerabilities that can be automatically patched more diverse. By combining the advantages of various vulnerability patching schemes, it achieves better patching results while ensuring minimal hardening code and minimal additional gas overhead.

[0098] It should be noted that the above content merely illustrates the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. For those skilled in the art, various improvements and modifications can be made without departing from the principle of the present invention, and all such improvements and modifications fall within the scope of protection of the claims of the present invention.

Claims

1. An automated method for fixing smart contract vulnerabilities based on bytecode rewriting, characterized in that, Includes the following steps: S1: Input the original contract bytecode and control policy file; S2: Start the local virtual execution engine component to perform symbolic execution and semantic extraction and generate a control flow graph; specifically: truncate the metadata hash and deployment code in the original contract bytecode to obtain the remaining part, and perform detection and hardening of the runtime code; by identifying characteristic instructions, split all instructions into multiple basic blocks; start the local virtual execution engine, open a global call stack, and start reading from the first instruction of the runtime code to perform symbolic execution. During the symbolic execution process, for each basic block, identify its preceding and following basic blocks, and finally construct the control flow graph (CFG) of the original contract bytecode; S3: Identify vulnerability-related semantics through the vulnerability detector component and filter them based on multiple sensitive instruction filtering rules to find the locations that need to be patched; the filtering of sensitive instructions based on the sensitive instruction filtering rules specifically includes: 1) If the basic block is automatically generated by the compiler solc, the instructions in it are assumed to be safe by default; 2) If an instruction has been hardened, subsequent instructions on the same path do not need to be hardened again; 3) In the conditional jump logic, the SMT solver Z3 is used to determine the satisfiability of the conditional expression. If there is an unreachable path, the reinforcement of the branch path is canceled by default. S4: By combining two correction schemes, trampoline-based injection and offset-based injection, bytecode rewriting is performed to achieve automated repair with minimal gas overhead. Among them, the hardened code based on the offset-modified injection scheme is inserted before and after sensitive instructions, while the hardened code based on the trampoline-based injection scheme is sequentially concatenated at the end of the original bytecode, and the address offsets of each instruction in the hardened bytecode are reallocated. S5: Outputs the hardened contract bytecode and a repair report.

2. The automated smart contract vulnerability repair method based on bytecode rewriting as described in claim 1, characterized in that: In step S1, the original contract bytecode is a bytecode file with the .bin extension; the control strategy file is optional and assists the user in explicitly specifying the specific functions in the bytecode that need to be repaired.

3. The automated smart contract vulnerability repair method based on bytecode rewriting as described in claim 2, characterized in that: During the symbolic execution of step S2, if the current execution flow reaches the last instruction of a basic block, the type of the current basic block is determined based on that instruction to determine the subsequent execution flow, specifically as follows: a) If the last instruction of a basic block is a JUMP instruction, then the current basic block is an unconditional jump basic block, and the current top element of the stack is the offset of the next basic block to be executed. b) If the last instruction of the basic block is the JUMPI instruction, it means that the current basic block is a conditional jump basic block. The current top element of the stack specifies the basic block corresponding to the condition being true. The two branch basic blocks are executed in turn according to the principle of depth-first traversal. c) If the last instruction of a basic block is a STOP, RETURN, REVERT, SELFDESTRUCT, or ASSERTFAIL instruction, then the current basic block is the terminating basic block, serving as the boundary for recursive calls; d) All remaining basic blocks are executed sequentially. After execution, their subsequent basic blocks can be executed directly.

4. The automated smart contract vulnerability repair method based on bytecode rewriting as described in claim 3, characterized in that: In step S3, the existence of a vulnerability is determined based on three semantic features: stack state, control flow, and block content.

5. The automated smart contract vulnerability repair method based on bytecode rewriting as described in claim 4, characterized in that: Step S5 specifically involves: reassembling the deploymentcode, runtimecode, and metadata hash; matching the PUSH instruction in the deploymentcode using regular expressions; correcting its push value to the length of the hardened runtimecode; and outputting the hardened contract bytecode .bin file and the repair report .json file.

6. An automated smart contract vulnerability repair system based on bytecode rewriting, implementing the automated smart contract vulnerability repair method based on bytecode rewriting as described in claim 1, characterized in that: It includes at least a virtual execution engine component, a vulnerability detector component, and a bytecode rewriter component. The virtual execution engine components include symbolic execution and semantic extraction, track the stack state of each instruction, and record the current memory and storage usage, enabling the extraction of more semantic information at the bytecode level; The vulnerability detector component has an embedded instruction filter, which is responsible for parsing the semantic information extracted from the virtual execution engine component and finding sensitive instructions, and filtering them according to the sensitive instruction filtering rules. The bytecode rewriter component combines two correction schemes—trampoline-based injection and offset-correction injection—to achieve bytecode rewriting. The system accepts the original contract bytecode and an optional control policy file as input. The virtual execution engine component mines more semantic information at the bytecode level, the vulnerability detector component identifies vulnerability-related semantics and filters sensitive instructions, and finally the bytecode is rewritten by the bytecode rewriter, outputting the hardened contract bytecode and a repair report.

Images