CN115310100B - Intelligent contract vulnerability repairing method, equipment and medium - Google Patents
Intelligent contract vulnerability repairing method, equipment and medium Download PDFInfo
- Publication number
- CN115310100B CN115310100B CN202211244063.2A CN202211244063A CN115310100B CN 115310100 B CN115310100 B CN 115310100B CN 202211244063 A CN202211244063 A CN 202211244063A CN 115310100 B CN115310100 B CN 115310100B
- Authority
- CN
- China
- Prior art keywords
- instruction
- intelligent contract
- vulnerability
- information
- basic block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/447—Target code generation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses an intelligent contract vulnerability repairing method, equipment and a medium, and relates to the field of intelligent contracts. The method comprises the following steps: acquiring running data of the Ethernet virtual machine when the intelligent contract runs, wherein the running data comprises block information, transaction information and instruction information; detecting a vulnerability of the intelligent contract according to the operating data, and determining an instruction execution sequence corresponding to the vulnerability; according to the operation data, determining a target basic block where an instruction execution sequence is located from a control flow graph of the intelligent contract, and obtaining context logic association information of the vulnerability; generating a target patch according to the type of the vulnerability, the byte code level correlation information and a preset patch template; and repairing the original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after bug repairing. According to the method and the device, the operation logic of the intelligent contract is not changed after the intelligent contract is repaired, and then the automatic repair of the intelligent contract is realized.
Description
Technical Field
The application relates to the field of intelligent contracts, in particular to an intelligent contract vulnerability fixing method, equipment and medium.
Background
In the related technology, the appearance of the intelligent contract widens the application scene of the block chain, so that the block chain application scene is not limited to the currency payment field any more, and the fields of finance, medical care, internet of things and the like are expanded. At present, the research on the security problem of the intelligent contract mainly focuses on the vulnerability detection of the intelligent contract, but the work of only detecting the vulnerability is far from enough, and the more important is to repair the vulnerability of the intelligent contract.
However, the manual repair method is time-consuming, labor-consuming and inefficient.
Disclosure of Invention
The application mainly aims to provide an intelligent contract vulnerability repair method, equipment and a medium, and aims to solve the technical problem that existing manual vulnerability repair on an intelligent contract is low in efficiency.
In order to achieve the above object, the present application provides an intelligent contract vulnerability fixing method, including:
acquiring running data of an Ethernet virtual machine when the Ethernet virtual machine runs an intelligent contract, wherein the running data comprises block information, transaction information and instruction information;
detecting a vulnerability of the intelligent contract according to the operating data, and determining an instruction execution sequence corresponding to the vulnerability;
determining a target basic block where the instruction execution sequence is located from a control flow graph of the intelligent contract according to the operation data, and obtaining context logic associated information of the vulnerability, wherein the context logic associated information comprises execution sequence information of the target basic block in the control flow graph and byte code level associated information of the instruction execution sequence;
generating a target patch according to the type of the vulnerability, the byte code level correlation information and a preset patch template;
and repairing the original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after bug repairing.
In a possible embodiment of the application, the repairing an original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after bug repairing includes:
determining a target code segment corresponding to the target basic block from the original program code;
creating a duplicate copy of the target code segment at the end of the original program code;
modifying the copy according to the target patch to obtain a repaired code segment;
replacing an entry instruction in the target code segment by using a first preset jump instruction, wherein the first preset jump instruction points to the entry instruction of the repaired code segment;
replacing the rest instructions except the entry instruction in the target code segment by a preset invalid instruction;
and associating the repaired code segment with a subsequent basic block of the target basic block according to the execution sequence information to obtain the intelligent contract after bug repair.
In a possible embodiment of the present application, the associating, according to the execution sequence information, the repaired code segment with a subsequent basic block of the target basic block to obtain an intelligent contract after bug repair includes:
judging whether the target basic block has the subsequent basic block to be jumped or not according to the execution sequence information;
if so, adding a second preset jump instruction after the repaired code segment to obtain an intelligent contract after bug repair; wherein the second preset jump code points to an entry instruction in the subsequent basic block.
In a possible embodiment of the present application, after determining whether the target basic block has the subsequent basic block to be skipped, the method further includes:
if not, judging whether an entry instruction of a next basic block of the target basic block is a preset jump address instruction or not according to the execution sequence information;
if the entry instruction of the next basic block of the target basic block is the preset jump address instruction, adding a second preset jump instruction after the repaired code segment to obtain an intelligent contract after bug repair; the second preset jump code points to the preset jump address instruction;
and if the entry instruction of the next basic block of the target basic block is not the preset jump address instruction, adding a copy code segment of the next basic block after the repaired code segment to obtain the intelligent contract after bug repair.
In a possible embodiment of the present application, the generating a target patch according to the type of the vulnerability, the bytecode-level association information, and a preset patch template includes:
if the type of the bug is a reentrant bug, determining that the type of a first repair operation in the preset patch template is a first newly added operation, the position corresponding to the first newly added operation is a last instruction of a CALL instruction, and the instruction corresponding to the first newly added operation is a state variable update instruction sequence according to the byte code level correlation information;
and according to the byte code level correlation information, determining that the type of a second repair operation in the preset patch template is a deletion operation, a next instruction with a position corresponding to the deletion operation being a CALL instruction and the instruction corresponding to the deletion operation being the state variable update instruction sequence, so as to generate the target patch.
In a possible embodiment of the present application, the obtaining context logic association information of the vulnerability includes:
determining execution sequence information of the target basic block in the control flow graph;
according to the operating data, simulating the storage process of the data to obtain two instructions related to any data;
and determining the dependency relationship between the instructions according to the two instructions related to the data so as to obtain the byte code level related information of the instruction execution sequence.
In a possible embodiment of the present application, the generating a target patch according to the type of the vulnerability, the bytecode-level association information, and a preset patch template includes:
if the type of the bug is an integer overflow bug, determining that the repair operation in the preset patch template is a second new operation according to the byte code level correlation information, wherein the position corresponding to the second new operation is a last instruction of an operation instruction, and the instruction corresponding to the second new operation is a preset judgment instruction and a repair sequence, so as to generate the target patch.
In a possible embodiment of the present application, the obtaining context logic association information of the vulnerability includes:
if the running data is monitored to comprise PUSH AND AND instructions, determining the integer type to be an unsigned integer;
and if the operating data is monitored to comprise a SIGNEXTEND instruction, determining that the integer type is a signed integer.
In a second aspect, the present application further provides an intelligent contract vulnerability fixing device, including: the intelligent contract bug fixing method comprises a processor, a memory and an intelligent contract bug fixing program stored in the memory, wherein the intelligent contract bug fixing program realizes the steps of the intelligent contract bug fixing method when being operated by the processor.
In a third aspect, the present application further provides a computer-readable storage medium, where an intelligent contract bug fixing program is stored on the computer-readable storage medium, and when being executed by a processor, the data cache program implements the intelligent contract bug fixing method described above.
The embodiment of the application provides an intelligent contract vulnerability fixing method, which comprises the following steps: acquiring running data of an Ethernet virtual machine when the Ethernet virtual machine runs an intelligent contract, wherein the running data comprises block information, transaction information and instruction information; detecting a vulnerability of the intelligent contract according to the operating data, and determining an instruction execution sequence corresponding to the vulnerability; determining a target basic block where the instruction execution sequence is located from a control flow graph of the intelligent contract according to the operation data, and obtaining context logic associated information of the vulnerability, wherein the context logic associated information comprises execution sequence information of the target basic block in the control flow graph and byte code level associated information of the instruction execution sequence; generating a target patch according to the type of the vulnerability, the byte code level correlation information and a preset patch template; and repairing the original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after bug repairing.
Therefore, when the vulnerability is detected, the type of the triggered vulnerability and the instruction execution sequence can be obtained based on the operation data of the intelligent contract operated by the EtherFang virtual machine, and more context logic associated information related to vulnerability code segments can be obtained from the operation data, namely, the execution sequence information of the target basic block in the control flow graph and the byte code level associated information of the instruction execution sequence can be relied on to preset a patch template to automatically customize a patch for repairing the vulnerability, and the execution sequence information and the byte code level associated information of the instruction execution sequence are relied on to repair the code, so that the operation logic of the intelligent contract is not changed after the repair, and the automatic repair of the intelligent contract is realized.
Drawings
Fig. 1 is a schematic structural diagram of an embodiment of an intelligent contract vulnerability fixing device according to the present application;
FIG. 2 is a flowchart illustrating a first embodiment of an intelligent contract vulnerability fix method according to the present application;
FIG. 3 is a flowchart illustrating a second embodiment of an intelligent contract vulnerability fixing method according to the present application;
FIG. 4 is a schematic diagram of a default patch template of the present application;
fig. 5 is a schematic diagram of the trampoline concept of the intelligent contract vulnerability remediation method of the present application.
The implementation, functional features and advantages of the objectives of the present application will be further explained with reference to the accompanying drawings.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
In the related technology, the appearance of the intelligent contract widens the application scene of the block chain, so that the block chain application scene is not limited to the currency payment field any more, and the fields of finance, medical care, internet of things and the like are expanded. Because smart contracts have the characteristic of being unable to be modified once deployed, the security problem they face is more troublesome than that of traditional application software. At present, the research on the security problem of the intelligent contract mainly focuses on the vulnerability detection of the intelligent contract, but the work of only detecting the vulnerability is far from enough, and the more important is to repair the vulnerability of the intelligent contract. At present, automatic bug fixing still mainly adopts a manual fixing mode, which is time-consuming and labor-consuming and is easy to make mistakes.
The application provides a solution, through the operating data when running intelligent contracts based on the Ether Fang virtual machine, can obtain the type and the instruction execution sequence of triggering the vulnerability when detecting out the vulnerability, and obtain more context logic associated information related to the vulnerability code segment from the operating data, thereby can rely on the automatic customization of the patch of repairing the vulnerability of presetting the patch template, and rely on the execution sequence information and the byte code level associated information of the instruction execution sequence carries out the restoration of code, thereby does not change the operating logic of intelligent contracts after the restoration, and then realizes the automatic restoration of intelligent contracts.
The inventive concept of the present application is further illustrated below with reference to some specific embodiments.
Referring to fig. 1, fig. 1 is a schematic structural diagram of an intelligent contract vulnerability fixing device of a hardware operating environment according to an embodiment of the present application.
As shown in fig. 1, the intelligent contract vulnerability fixing device may include: a processor 1001, such as a Central Processing Unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display), an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a WIreless interface (e.g., a WIreless-FIdelity (WI-FI) interface). The Memory 1005 may be a Random Access Memory (RAM) Memory, or may be a Non-Volatile Memory (NVM), such as a disk Memory. The memory 1005 may alternatively be a storage device separate from the processor 1001.
Those skilled in the art will appreciate that the architecture shown in FIG. 1 does not constitute a limitation on intelligent contract vulnerability repair devices, and may include more or fewer components than those shown, or some components in combination, or a different arrangement of components.
As shown in fig. 1, a memory 1005, which is a storage medium, may include therein an operating system, a data storage module, a network communication module, a user interface module, and an intelligent contract vulnerability fixing program.
In the data caching device shown in fig. 1, the network interface 1004 is mainly used for data communication with a network server; the user interface 1003 is mainly used for data interaction with a user; the processor 1001 and the memory 1005 of the intelligent contract bug fixing device can be arranged in the intelligent contract bug fixing device, and the data cache device calls the intelligent contract bug fixing program stored in the memory 1005 through the processor 1001 and executes the intelligent contract bug fixing method provided by the embodiment of the application.
Based on the hardware structure but not limited to the structure, the intelligent contract vulnerability fixing method is provided. Referring to fig. 2, fig. 2 is a first embodiment of an intelligent contract vulnerability fixing method according to the present invention.
In this embodiment, the method includes:
step S100, obtaining operation data when the Etherhouse virtual machine operates an intelligent contract, wherein the operation data comprises block information, transaction information and instruction information;
specifically, in order to effectively fix the bug, an accurate location of the bug, an execution path of the bug, and information related to the bug need to be obtained first, and in this embodiment, the information may be obtained based on the operation information.
The specific running information can be completed by adding an information collector in the Etherhouse virtual machine. The information collector is used for recording each transaction and each result generated by the execution of the instructions of the Ethernet workshop virtual machine during the running of the Ethernet workshop virtual machine so as to obtain all running information. In the present embodiment, based on the research of the inventor on the go-ethereum source code, the operation information is divided into three parts, namely block information, transaction information and instruction information, according to the type of the information. The present embodiment will be specifically described below:
firstly, collecting block information. It will be appreciated that in an ethernet bay, a block is made up of a block header and a block body, the block header containing the block number, the difficulty of mining the block, the user of the mining block, the reward for mining, the timestamp of the mining block, etc. And the block body stores transaction information. It is worth mentioning that some blocks may not have memory transactions, and the block body is empty. In one embodiment, the tile information may be collected by collecting information contained in the tile header in core/state _ processor.
And secondly, collecting transaction information. The transactions of the etherhouse can be divided into external transactions and internal transactions according to the type of the address (account) of the initiator. More generally, external transactions are intelligent contract invocation requests initiated by external accounts, and are recorded by a block chain, internal transactions are mutual invocation between intelligent contracts, and the transactions are performed during the execution of an Ethernet virtual machine, the execution process is not recorded, but part of the execution result, such as transfer records, is recorded on the block chain. The external transaction and the internal transaction are similar in execution logic, and therefore can be implemented by sharing the same information acquisition algorithm. The collection of the external transaction information can be performed through an applyTransaction function deployed in the EtherFang virtual machine, and the collection of the internal transaction information can be completed by adding a collection function into an interpreter of an instruction code which possibly generates an internal transaction.
And thirdly, acquiring instruction information. It can be understood that the ethernet workshop virtual machine can support 140 instructions, and the embodiment may complete the collection of the execution information of the instructions by adding a collection function in the interpreter of all the ethernet workshop virtual machine instructions to record the running information of all the executed ethernet workshop virtual machine instructions. It should be noted that, since the following contract patching needs more detailed information such as the execution path to accurately perform the analysis and speculation at the byte code level, in order to avoid missing any possibly useful information, the name, parameters, the result generated by the instruction execution and the instruction execution sequence of each instruction may be recorded. Wherein the order of instruction execution is available via a program counter PC.
And S200, detecting the vulnerability of the intelligent contract according to the running data, and determining an instruction execution sequence corresponding to the vulnerability.
It can be understood that vulnerability detection of an intelligent contract is the prior art, and therefore, how to implement a detection process of the vulnerability of the intelligent contract is not described herein in detail.
After the bug is detected, the instruction execution sequence for executing the malicious transaction can be determined according to the data stream (such as block information and transaction information) and the instruction information in the operation information, in particular the name and the parameter of each instruction in the instruction information, the result generated by instruction execution and the instruction execution sequence.
It is understood that the instruction execution sequence corresponding to the bug includes, but is not limited to, at least one instruction.
Step S300, according to the operation data, determining a target basic block where the instruction execution sequence is located from a control flow graph of the intelligent contract, and obtaining context logic associated information of the vulnerability, wherein the context logic associated information comprises execution sequence information of the target basic block in the control flow graph and byte code level associated information of the instruction execution sequence.
Specifically, the nodes in a Control Flow Graph (CFG) are basic blocks, and the control flow graph represents the execution order of two nodes by adding directed edges between them. Each basic block is formed by a series of instructions and has an inlet and an outlet, wherein the inlet is the first instruction, and the outlet is the last instruction. Therefore, each node of the CFG can be constructed through the collected executed instruction information, when the instruction STOP, RETURN, REVERT, INVALID or SUICIDE3 is encountered, which indicates that the boundary is the boundary of the basic block, the construction of the current node is stopped, and the next instruction in the original program code is used as the start of a new node.
In addition, when the instructions JUMP and JUMP are encountered, the boundary of the basic block is marked, and the construction of the current node is stopped, but the two instructions are JUMP instructions, and the next instruction in the original program code cannot be taken as the start of a new node in sequence. For a JUMP instruction, which is an unconditional JUMP instruction and thus starts with the instruction at the target address (i.e., the JUMP address) as the new node, for a JUMP instruction, which is a conditional JUMP instruction, there is a need to construct two execution sequences, one branch in the original execution order (not fulfilling the JUMP situation) and one branch from the target address.
After obtaining the operation information (such as the name, the parameter, the result generated by the instruction execution, the instruction execution sequence, etc. in the instruction information), the target basic block where the instruction execution sequence corresponding to the bug is located, that is, the basic block that needs to be code-modified, can be determined by comparing the operation information with the control flow graph.
It can be understood that, it can be obviously seen from the control flow diagram that there is a corresponding directing relationship between the target basic block and other basic blocks, that is, after the instruction corresponding to the target basic block is executed, the instruction corresponding to which basic block is continuously directed downwards. Therefore, in order to avoid that the running logic of the intelligent contract is damaged after the bug is repaired at the byte code level, the execution sequence information of the target basic block in the control flow graph needs to be obtained in advance according to the running data.
In addition, since bug fixing at the byte code level generally fixes bugs by adding instructions or deleting corresponding error instructions, processing of data by each instruction in the instruction execution sequence corresponding to the target basic block may also change, for example, adjustment of a data reference address is required after modifying the byte code. Therefore, in order to enable a plurality of instructions corresponding to the target basic block to normally run after the bug is fixed at the byte code level, byte code level related information of an instruction execution sequence needs to be obtained.
The bytecode-level association information may be a dependency relationship between the instruction and the data, for example, after the instruction a processes the data B, the instruction C processes the data B, and at this time, it is considered that the dependency relationship exists between the data of the instruction B and the instruction a. Alternatively, the bytecode-level association information may further include a write address of the data.
And S400, generating a target patch according to the type of the vulnerability, the byte code level correlation information and a preset patch template.
Specifically, the preset patch template includes an operation type, a position where the pos operation is executed, and an instruction that the content repair needs to be executed. The operation type may be "Add" or "delete DEL. The location where the operation is performed is the relative location of the fix operation to the bug, such as "before" or "after". It is understood that, since the present embodiment is an automatic repair of an intelligent contract, the instructions that the content repair needs to execute include multiple pieces of instructions preset in advance according to the type of the bug. For example, the default patch template may include an instruction library that has a plurality of default content instructions that are dedicated to modifying a particular vulnerability. And also prestores the mapping relation between the vulnerability type and the preset content instruction. Therefore, after the loophole is detected, the corresponding preset content instruction can be directly called according to the loophole type.
And then, determining the position of pos operation execution corresponding to the preset content instruction based on the byte code level correlation information, thereby obtaining the target patch.
And S500, repairing the original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after bug repairing.
Specifically, after the target patch is obtained, in order to avoid destroying the running logic of the intelligent contract after the repair, the original program code of the intelligent contract needs to be repaired in combination with the target patch depending on the execution sequence information, so as to obtain the intelligent contract after the bug repair.
It can be seen that, in this embodiment, based on the running data of the ethernet virtual machine when running the intelligent contract, when detecting a bug, the type and the instruction execution sequence of triggering the bug may be obtained, and more context logic related information related to a bug code segment may be obtained from the running data, that is, the execution sequence information of the target basic block in the control flow graph and the byte code level related information of the instruction execution sequence may be obtained, so that a patch for repairing the bug may be automatically customized depending on a preset patch template, and the code repair may be performed depending on the execution sequence information and the byte code level related information of the instruction execution sequence, so that the running logic of the intelligent contract is not changed after the repair, and the automatic repair of the intelligent contract is further implemented.
Based on the first embodiment, a second embodiment of the intelligent contract vulnerability fixing method is provided. Referring to fig. 3, fig. 3 is a schematic flowchart of a second embodiment of an intelligent contract vulnerability fixing method.
Specifically, in this embodiment, step S500 specifically includes:
step S501, determining a target code segment corresponding to the target basic block from the original program code.
Step S502, creating a copy of the target code segment at the end of the original program code.
And S503, modifying the copy according to the target patch to obtain a repaired code segment.
Step S504, replacing an entry instruction in the target code segment by a first preset jump instruction, wherein the first preset jump instruction points to the entry instruction of the repaired code segment.
And step S505, replacing the rest instructions except the entry instruction in the target code segment by using a preset invalid instruction.
And S506, associating the repaired code segment with a subsequent basic block of the target basic block according to the execution sequence information to obtain the intelligent contract after bug repair.
Specifically, in order to avoid that the adjustment of the original memory structure requires accurate control flow graph recovery and data flow analysis when the intelligent contract bytecode is repaired, the present embodiment allows the repair to work at the basic block level based on the trampoline concept.
When a certain basic block needs to be changed during patching, a copy of the target code segment is created at the end of the original program code, and then bytecode change is executed on the copy, so that a repaired code segment is obtained. After the copy is created, in order to normally run the repaired code segment during the running process of the intelligent contract, at this time, the entry instruction in the target code segment may be replaced with a first preset jump instruction pointing to the entry instruction of the repaired code segment. And in order to avoid the influence of the original target code segment on the operation of the repaired code segment, the original target code segment is replaced by using INVALID. Where INVALID is an INVALID instruction provided by the etherhouse.
Specifically, referring to fig. 5, when a new bytecode is inserted into the bytecode segment beginning with 0xAB, the new bytecode is copied to the last 0xFFB of the original program code, the original instruction at 0xAB is changed to an instruction jumping to 0xFFB, and the rest is filled with an invalid instruction. The byte code repair is performed in 0 xFFB.
Similarly, after the repaired code segment is executed, in order to make the operation of the intelligent contract return to the original execution sequence, the repaired code segment needs to be associated with the subsequent basic block of the target basic block to obtain the intelligent contract after bug repair.
In this embodiment, the repairing idea of the trampoline is adopted, that is, creating the copy by copying to the end avoids the need of adjusting the data reference address after modifying the bytecode, but it introduces an additional jump instruction, which may destroy the execution order of the basic blocks in the original stone contract, and therefore, as an option of this embodiment, step S506 includes:
step S5061, determining whether the target basic block has the subsequent basic block to be skipped according to the execution sequence information.
Step S5062, if yes, adding a second preset jump instruction after the repaired code segment to obtain an intelligent contract after bug repair; wherein the second preset jump code points to an entry instruction in the subsequent basic block.
Step S5063, if not, determining whether an entry instruction of a next basic block of the target basic block is a preset jump address instruction according to the execution sequence information;
step S5064, if the entry instruction of the next basic block of the target basic block is the preset jump address instruction, adding a second preset jump instruction after the repaired code segment, and obtaining an intelligent contract after bug repair; the second preset jump code points to the preset jump address instruction;
step S5065, if the entry instruction of the next basic block of the target basic block is not the preset jump address instruction, adding a copy code segment of the next basic block after the repaired code segment, and obtaining the vulnerability-repaired intelligent contract.
In particular, for intelligent contract bytecode, there are three cases of the execution order of basic blocks,
(1) And (5) conditional jumping. The instruction in the ether house virtual machine responsible for conditional jump is JUMPI, which reads 2 values from the stack, respectively representing the jump condition and a program counter pc (program counter), where the pc value is the instruction position to be jumped to, i.e. a preset jump address instruction JUMPDEST. And if the jump condition is met, jumping to a subsequent basic block, and jumping back to continue to execute the next basic block after all instructions in the subsequent basic block are executed. If the condition is not satisfied, the next basic block is directly executed.
(2) To show control flow instruction termination, such as JUMP, RETURN, REVERT. Where RETURN and reverse belong to the finish instruction, only the JUMP instruction will be discussed here. The JUMP instruction triggers unconditional JUMP in the Ethern virtual machine, when the JUMP instruction is executed each time, 1 value is read out from the stack, and the pc value is the instruction position to be jumped to, namely a preset JUMP address instruction JUMPDEST, which represents the entry of a subsequent basic block to be jumped. Similar to the JUMP instruction, the JUMP instruction continues to execute downwards after the JUMP block is executed.
(3) fall through. Some basic blocks of the EtherFang virtual machine have no jump instruction and no ending instruction, and for the instructions, after the last instruction of the current basic block is executed, the instructions of the next basic block are continuously executed. If the jump condition is not satisfied in the conditional jump, a fall through situation also exists.
Therefore, in order to ensure the correct execution of the repaired intelligent contract, the boundaries between the basic blocks still need to be repaired by acquiring the execution order of the repaired basic block and the subsequent repair blocks through the control flow graph, and ensuring that the execution logic of the repaired basic block and the subsequent repair blocks does not change. Therefore, based on the above, it is determined whether the target basic block has the subsequent basic block to be skipped, i.e., whether corresponding JUMP instructions and JUMP instructions exist. If so, adding a second preset jump instruction after the repaired code segment; wherein the second preset jump code points to an entry instruction in the subsequent basic block. I.e. the preset jump address instruction JUMPDEST of the subsequent basic block.
For example, referring to fig. 5, if a new bytecode is required to be inserted into the bytecode segment beginning with 0xAB, the new bytecode segment is copied to the last 0xFFB of the original program code, the original instruction at 0xAB is changed to an instruction jumping to 0xFFB, and the rest is filled with invalid instructions. And finally added to the 0xCD jump instruction to ensure that the original contract code at address 0xCD can continue execution.
But not all basic blocks have definite jump targets, when the target basic block has a fall through condition. If the basic block reached through the fall through takes the jump EST instruction as an entry, only a second preset jump instruction is added at the end after the repaired code segment to jump to the position of the original basic block end.
If the basic block reached through the fall through is not entered in the JUMPDEST instruction, the Etherhouse virtual machine will prohibit any display jump to that address. At this time, the embodiment copies the code segment of the basic block that the fall through arrives to the repaired code segment to ensure the execution order of the basic block.
Therefore, in the embodiment, by applying the jump instruction, the execution sequence of the basic block in the original intelligent contract is prevented from being damaged, and the execution logic of the basic block is ensured not to be changed.
Based on the above embodiments, a third embodiment of the intelligent contract vulnerability fixing method is provided.
In this embodiment, the method includes:
step S301, obtaining operation data when the Ethenhouse virtual machine operates the intelligent contract, wherein the operation data comprises block information, transaction information and instruction information;
step S302, detecting the vulnerability of the intelligent contract according to the operation data, and determining an instruction execution sequence corresponding to the vulnerability.
Specifically, for reentrant holes. The nature of the reentry vulnerability is that the updating of the state variable of the balance in the transaction information in the function execution process lags behind the external transfer operation in the instruction information, while the intelligent integration triggers the execution of a fallback function when receiving the token, the fallback function is a special mechanism provided by the Ethengfang, and the mechanism can cause the function to enter the function again after the function executes the transfer operation, and the transfer operation is repeated.
In this embodiment, the detection cycle of the reentry vulnerability starts from the execution of the external transaction. When the instruction of the external transaction is executed, the initialization part of the reentry vulnerability detection algorithm is triggered, such as setting a calling root node, opening up the space required by a calling tree, and the like. And updating the calling tree in the transaction execution process by the reentry vulnerability detection algorithm, and detecting the vulnerability when the external transaction is finished. Before calling a transaction execution function each time, the deployed information collector sends the information of the transaction to a reentry vulnerability detection algorithm, the action triggers the operation of calling tree updating in the detection algorithm, and the reentry vulnerability detection algorithm acquires the addresses of both parties of the transaction and updates the calling tree. Before the external transaction is finished, the incoming vulnerability detection is cut off, at the moment, all calling information in the transaction process is stored in a calling tree building mode in a reentry vulnerability detection algorithm, at the moment, the calling tree is traversed in a backward sequence in an iteration mode from the first address of the external transaction, whether the condition that the current node has called the used node exists or not is checked in the traversing process, if yes, the loop is formed, and the situation that the same loop exists or not is continuously searched downwards. When the number of rings exceeds 2, the reentrant attack is considered to have occurred. I.e. a reentry hole is detected.
Step S303, according to the operation data, determining a target basic block where the instruction execution sequence is located from a control flow graph of the intelligent contract, and obtaining context logic associated information of the vulnerability, wherein the context logic associated information comprises execution sequence information of the target basic block in the control flow graph and byte code level associated information of the instruction execution sequence;
specifically, the obtaining of the context logic association information of the vulnerability includes:
step S3031, determining the execution sequence information of the target basic block in the control flow graph;
step S3032, simulating the storage process of the data according to the running data to obtain two instructions related to any data;
step S3033, determining a dependency relationship between the instructions according to the two instructions associated with the data, so as to obtain the bytecode-level association information of the instruction execution sequence.
Specifically, the re-entry bug requires the instruction execution order to be swapped. In the instruction exchange process, in order to firstly confirm the dependency relationship between the instructions and avoid data processing errors after instruction jump. However, since the etherhouse virtual machine is a stack-based virtual machine, the information analyzed only from the static contract bytecode level may be incomplete. Therefore, after the CFG is obtained, the data dependency relationship needs to be obtained by analyzing the execution result of the ethernet virtual machine bytecode. The ether house virtual machine has three places related to data flow, namely a stack, a memory and a storage, and the storage result is obtained from the stack, so the embodiment only needs to analyze the data flow between the stack and the memory.
Specifically, the operation of the stack and the memory is simulated, that is, the storage process of the data is simulated, and the data is marked in the simulation process to obtain the dependency relationship of the data stream. For example, if instruction a pushes parameter 1 onto the stack, marking parameter 1 is obtained by instruction a, and if subsequent instruction b operates on parameter 1 in the stack, it indicates that the data of instruction b depends on instruction a.
Similarly, for the memory, if the instruction a writes data 1 into the memory, the addr position (address) written into the memory is marked as being written by the instruction a, and if the subsequent instruction b operates on the data in the addr position of the memory, the data of the instruction b depends on the instruction a.
It should be noted that not all the read or write memory addresses are determined, and some addresses are calculated according to the input data, for this case, the embodiment may obtain the write address through the bug bytecode execution sequence collected from the operation data.
And S304, generating a target patch according to the type of the vulnerability, the byte code level correlation information and a preset patch template.
Specifically, in this embodiment, step S304 includes:
step S3041, according to the bytecode-level association information, determining that the type of a first repair operation in the preset patch template is a first add-on operation, a position corresponding to the first add-on operation is a last instruction of a CALL instruction, and an instruction corresponding to the first add-on operation is a state variable update instruction sequence;
step S3042, according to the bytecode-level association information, determining that the type of the second repair operation in the preset patch template is a delete operation, a next instruction whose position corresponding to the delete operation is a CALL instruction, and an instruction corresponding to the delete operation are the state variable update instruction sequence, so as to generate the target patch.
Specifically, referring to fig. 4, for a reentrant vulnerability, the preset patch template provided in this embodiment is used. Namely, the execution order of the instructions needs to be exchanged, so that two changes need to be made to the original basic block:
the first is to add a state variable update operation before the CALL instruction is executed, that is, the type of the first repair operation in the preset patch template is a first new adding operation, the position corresponding to the first new adding operation is a last instruction of the CALL instruction, and the instruction corresponding to the first new adding operation is a state variable update instruction sequence.
And deleting statements for updating state variables after the CALL instruction is executed. That is, the type of the first repair operation in the preset patch template is a first add-on operation, the position corresponding to the first add-on operation is the last instruction of the CALL instruction, and the instruction corresponding to the first add-on operation is a state variable update instruction sequence.
At this time, the preset content instruction in the preset patch template is a specific state variable update instruction sequence.
And S305, repairing the original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after bug repairing.
As can be seen, in this embodiment, based on the strategy of the trampoline, the data dependency is analyzed, the instruction execution sequence is exchanged to complete the repair, and the repair is effectively performed on the reentry hole. And the extra gas consumption generated by the operation of the intelligent contract after the repair is less.
Based on the above embodiments, a fourth embodiment of the intelligent contract vulnerability fixing method is provided.
In this embodiment, the method includes:
step S401, obtaining operation data when the Etherhouse virtual machine operates an intelligent contract, wherein the operation data comprises block information, transaction information and instruction information;
and S402, detecting the vulnerability of the intelligent contract according to the running data, and determining an instruction execution sequence corresponding to the vulnerability.
In particular, for integer vulnerabilities. Because the EtherFang virtual machine is designed into a 256-bit virtual machine and can only run on 256-bit values, parameters are already converted into 256-bit values during calculation, data width and symbol information are lost during compilation, and overflow detection cannot be simply performed on the operation result of the current parameters. Therefore, when detecting the integer overflow, we need to first know the type information of the integer, i.e. the width (e.g. the type uint32 represents a number with a size of 32 bits) and the sign (e.g. the type int is a signed number, and the type uint is an unsigned number), where the width and sign information are necessary for correctly checking the arithmetic operation.
The specific manner of obtaining the type information and the symbol information of the integer may be as follows:
for unsigned integers, the compiler introduces an AND opcode as a bit mask to mask bits that are not within 256 widths. If there is an integer of uint32, the compiler first adds a PUSH instruction that pushes data 0xffffffff onto the stack as one of the parameters of the AND instruction. This is inferred to be an unsigned integer by the PUSH AND AND instructions in the run data, which is 32 bits wide from the bitmask 0 xfffffffff in the run data. For signed integers, the EtherFang virtual machines are all represented by complements, and the compiler expands the width of the integer by introducing a SIGNEXTEND instruction (increasing the number of bits of the binary number while preserving the sign and value of the integer). If there is a int32 variable, the signed integer can be determined by the signal executed in the data instruction, and the width of the instruction is determined to be 32 (y = 8 x (x + 1)) by the first parameter 3 of the instruction.
According to the above thought, the integer type information can be deduced through taint analysis, we choose to introduce taint when PUSH 0xF.. F, AND and SIGNEXTEND instructions are executed, and simulate the influence of the later instructions on the stack, the memory and the storage by recording the data at the top of the stack and the current structure of the memory and the storage each time. Taking an unsigned integer as an example, when the PUSH instruction pushes the 0xF.
Specifically, step S403 determines, according to the running data, a target basic block where the instruction execution sequence is located from a control flow graph of the intelligent contract, and obtains context logic association information of the vulnerability, where the context logic association information includes execution sequence information of the target basic block in the control flow graph and bytecode-level association information of the instruction execution sequence;
specifically, based on the analysis of the integer vulnerability, the obtaining of the context logic association information of the vulnerability includes:
step S4031, if the running data is monitored to include PUSH AND AND instructions, determining the integer type to be an unsigned integer;
step S4032, if it is monitored that the operating data includes a signalend instruction, determine that the integer type is a signed integer.
And S404, generating a target patch according to the type of the vulnerability, the byte code level correlation information and a preset patch template.
Specifically, in this embodiment, step S404 includes:
and S405, repairing the original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after bug repairing.
If the type of the vulnerability is an integer overflow vulnerability, step S405 specifically includes:
and determining that the repair operation in the preset patch template is a second new operation according to the byte code level correlation information, wherein the position corresponding to the second new operation is a last instruction of an operation instruction, and the instruction corresponding to the second new operation is a preset judgment instruction and a repair sequence, so as to generate the target patch.
Specifically, referring to fig. 4, for an integer overflow bug, the repair operation and the operation execution position that need to be performed are the same, and a preset determination instruction and a repair sequence are added before the integer operation to determine whether the integer overflow operation exists. That is, although the integer overflow needs to be divided into three cases of addition (subtraction) integer overflow, integer overflow by multiplication, and integer underflow. However, in all of the three cases, it is necessary to first perform a step of determining whether there is an integer overflow, so that effective patching can be performed when there is an integer overflow. But the specific preset repair sequence, i.e. the preset content instruction, is adjusted according to the change of the overflow condition.
In order to facilitate the use of the preset patch template, the value which needs to be changed according to the actual situation in the preset content instruction is represented by an abstract statement. In the actual patching, these abstract statements in the content need to be replaced, where PUSH _ Dest represents a jump address Dest pushed to the stack, and is replaced with an address to which jump is needed by JUMPI in the patching process, and Boundary is used to mark a Boundary (MAX _ VALUE,0, etc.) when judging integer overflow.
It can be seen that, in this embodiment, based on a trampoline policy, for an integer overflow vulnerability, after obtaining the type and width of an integer through taint analysis, an integer overflow judgment operation and a corresponding repair operation are performed, so that overflow caused by a non-uint 256-type integer can be effectively repaired, the defect that the existing research can only repair 256-bit data is overcome, and economic loss caused by malicious utilization of the vulnerability can be more comprehensively prevented.
In the embodiment, by combining vulnerability detection based on runtime information, the instruction execution sequence triggering the vulnerability can be obtained, more context information related to vulnerability code segments can be obtained during patching, and by obtaining more perfect context information from contract byte codes, a template-based patch is combined with a semantic patch, so that the vulnerability can be patched more comprehensively and effectively. Therefore, the patch does not need to be manually customized for the specific contract vulnerability in the patching process, and the method is an extensible automatic intelligent contract repairing method.
In addition, an embodiment of the present application further provides a computer storage medium, where an intelligent contract bug fixing program is stored on the storage medium, and the intelligent contract bug fixing program, when executed by a processor, implements the steps of the above intelligent contract bug fixing method. Therefore, a detailed description thereof will be omitted. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in the embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of the embodiments of the method of the present application. It is determined that the program instructions may be deployed to be executed on one computing device or on multiple computing devices located at one site or distributed across multiple sites and interconnected by a communication network, as examples.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above may be implemented by a computer program, which may be stored in a computer readable storage medium and includes the processes of the embodiments of the methods described above when the program is executed. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.
It should be noted that the above-described embodiments of the apparatus are merely schematic, where units illustrated as separate components may or may not be physically separate, and components illustrated as units may or may not be physical units, may be located in one place, or may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. In addition, in the drawings of the embodiments of the apparatus provided in the present application, the connection relationship between the modules indicates that there is a communication connection therebetween, which may be specifically implemented as one or more communication buses or signal lines. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that the present application can be implemented by software plus necessary general-purpose hardware, and certainly can also be implemented by special-purpose hardware including special-purpose integrated circuits, special-purpose CPUs, special-purpose memories, special-purpose components and the like. Generally, functions performed by computer programs can be easily implemented by corresponding hardware, and specific hardware structures for implementing the same functions may be various, such as analog circuits, digital circuits, or dedicated circuits. However, for the present application, the implementation of a software program is more preferable. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, where the computer software product is stored in a readable storage medium, such as a floppy disk, a usb disk, a removable hard disk, a Read-only memory (ROM), a random-access memory (RAM), a magnetic disk or an optical disk of a computer, and includes instructions for enabling a computer device (which may be a personal computer, a server, or a network device) to execute the methods of the embodiments of the present application.
The above description is only a preferred embodiment of the present application, and not intended to limit the scope of the present application, and all modifications of equivalent structures and equivalent processes, which are made by the contents of the specification and the drawings of the present application, or which are directly or indirectly applied to other related technical fields, are included in the scope of the present application.
Claims (7)
1. An intelligent contract vulnerability fixing method is characterized by comprising the following steps:
acquiring running data of an Ethernet virtual machine when the Ethernet virtual machine runs an intelligent contract, wherein the running data comprises block information, transaction information and instruction information;
detecting a vulnerability of the intelligent contract according to the operating data, and determining an instruction execution sequence corresponding to the vulnerability;
determining a target basic block where the instruction execution sequence is located from a control flow graph of the intelligent contract according to the operation data, and obtaining context logic associated information of the vulnerability, wherein the context logic associated information comprises execution sequence information of the target basic block in the control flow graph and byte code level associated information of the instruction execution sequence;
generating a target patch according to the type of the vulnerability, the byte code level correlation information and a preset patch template;
repairing the original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after bug repairing;
generating a target patch according to the type of the vulnerability, the byte code level association information and a preset patch template, wherein the generating comprises the following steps:
if the type of the bug is a reentrant bug, determining that the type of a first repair operation in the preset patch template is a first newly added operation, the position corresponding to the first newly added operation is a last instruction of a CALL instruction, and the instruction corresponding to the first newly added operation is a state variable update instruction sequence according to the byte code level correlation information;
and according to the byte code level correlation information, determining that the type of a second repair operation in the preset patch template is a deletion operation, a next instruction with a position corresponding to the deletion operation being a CALL instruction and the instruction corresponding to the deletion operation being the state variable update instruction sequence, so as to generate the target patch.
2. The intelligent contract vulnerability fixing method according to claim 1, wherein the fixing the original program code of the intelligent contract according to the target patch and the execution sequence information to obtain the intelligent contract after vulnerability fixing comprises:
determining a target code segment corresponding to the target basic block from the original program code;
creating a duplicate copy of the target code segment at the end of the original program code;
modifying the copy according to the target patch to obtain a repaired code segment;
replacing an entry instruction in the target code segment by using a first preset jump instruction, wherein the first preset jump instruction points to the entry instruction of the repaired code segment;
replacing the rest instructions except the entry instruction in the target code segment by preset invalid instructions;
and associating the repaired code segment with a subsequent basic block of the target basic block according to the execution sequence information to obtain an intelligent contract after the bug is repaired.
3. The intelligent contract vulnerability fixing method according to claim 2, wherein the associating the fixed code segment with a subsequent basic block of a target basic block according to the execution sequence information to obtain the vulnerability fixed intelligent contract comprises:
judging whether the target basic block has the subsequent basic block to be jumped or not according to the execution sequence information;
if the current bug is detected to exist, adding a second preset jump instruction after the repaired code segment to obtain an intelligent contract after bug repair; wherein the second preset jump code points to an entry instruction in the subsequent basic block.
4. The intelligent contract vulnerability fixing method according to claim 3, wherein after the judging whether the target basic block has the subsequent basic block to be jumped, the method further comprises:
if not, judging whether an entry instruction of a next basic block of the target basic block is a preset jump address instruction or not according to the execution sequence information;
if the entry instruction of the next basic block of the target basic block is the preset jump address instruction, adding a second preset jump instruction after the repaired code segment to obtain an intelligent contract after bug repair; the second preset jump code points to the preset jump address instruction;
and if the entry instruction of the next basic block of the target basic block is not the preset jump address instruction, adding a copy code segment of the next basic block after the repaired code segment to obtain the intelligent contract after bug repair.
5. The intelligent contract vulnerability fixing method according to claim 1, wherein the obtaining context logic association information of the vulnerability comprises:
determining execution sequence information of the target basic block in the control flow graph;
according to the operating data, simulating the storage process of the data to obtain two instructions related to any data;
and determining the dependency relationship between the instructions according to the two instructions related to the data so as to obtain the byte code level related information of the instruction execution sequence.
6. An intelligent contract vulnerability fix device, comprising: a processor, a memory, and an intelligent contract bug fix program stored in the memory, the intelligent contract bug fix program when executed by the processor implementing the steps of the intelligent contract bug fix method as claimed in any of claims 1-5.
7. A computer-readable storage medium having stored thereon an intelligent contract vulnerability repair program, the data cache program when executed by a processor implementing an intelligent contract vulnerability repair method according to any of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211244063.2A CN115310100B (en) | 2022-10-12 | 2022-10-12 | Intelligent contract vulnerability repairing method, equipment and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211244063.2A CN115310100B (en) | 2022-10-12 | 2022-10-12 | Intelligent contract vulnerability repairing method, equipment and medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115310100A CN115310100A (en) | 2022-11-08 |
| CN115310100B true CN115310100B (en) | 2023-02-03 |
Family
ID=83868175
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211244063.2A Active CN115310100B (en) | 2022-10-12 | 2022-10-12 | Intelligent contract vulnerability repairing method, equipment and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115310100B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115718922B (en) * | 2022-11-28 | 2023-05-26 | 暨南大学 | High-availability intelligent contract byte code rewriting method, medium and device |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020249572A1 (en) * | 2019-06-12 | 2020-12-17 | NEC Laboratories Europe GmbH | Method and contract rewriting framework system for supporting smart contracts in a blockchain network |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109948345A (en) * | 2019-03-20 | 2019-06-28 | 杭州拜思科技有限公司 | A kind of method, the system of intelligence contract Hole Detection |
| CN111125716B (en) * | 2019-12-19 | 2022-05-31 | 中国人民大学 | Method and device for detecting Ethernet intelligent contract vulnerability |
| CN111832026B (en) * | 2020-06-18 | 2022-04-26 | 广州大学 | Vulnerability utilization positioning method, system, device and medium |
| WO2022078632A1 (en) * | 2020-10-13 | 2022-04-21 | NEC Laboratories Europe GmbH | Method and system for supporting smart contracts in a blockchain network |
| CN115168847A (en) * | 2022-07-27 | 2022-10-11 | 中国电信股份有限公司 | Application patch generation method and device, computer equipment and readable storage medium |
| CN115168855A (en) * | 2022-07-28 | 2022-10-11 | 西安交通大学 | Patch existence detection method based on key basic block |
| CN115033896B (en) * | 2022-08-15 | 2022-11-08 | 鹏城实验室 | Method, device, system and medium for detecting Ethernet intelligent contract vulnerability |
-
2022
- 2022-10-12 CN CN202211244063.2A patent/CN115310100B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020249572A1 (en) * | 2019-06-12 | 2020-12-17 | NEC Laboratories Europe GmbH | Method and contract rewriting framework system for supporting smart contracts in a blockchain network |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115310100A (en) | 2022-11-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6698135B2 (en) | Method and system for securing smart contracts within a blockchain | |
| EP3906488B1 (en) | Method and contract rewriting framework system for supporting smart contracts in a blockchain network | |
| Rodler et al. | {EVMPatch}: Timely and automated patching of ethereum smart contracts | |
| CN105009139B (en) | For being unpacked to the general of application for malware detection | |
| US9146759B2 (en) | Assumption-based compilation | |
| JP4572259B1 (en) | Information device, program, and illegal program code execution prevention method | |
| JP7154365B2 (en) | Methods for securing software code | |
| US8141035B2 (en) | Method for accessing internal states of objects in object oriented programming | |
| US10942718B2 (en) | Systems and/or methods for type inference from machine code | |
| CN115310100B (en) | Intelligent contract vulnerability repairing method, equipment and medium | |
| US8806138B1 (en) | Dynamic dependencies and parameterizations for execution and caching | |
| Li et al. | Detecting standard violation errors in smart contracts | |
| JP4754635B2 (en) | Control flow protection mechanism | |
| CN114880189A (en) | Application program monitoring method and device and computing equipment | |
| CN110807195B (en) | Intelligent contract issuing method, issuing platform device and issuing system | |
| CN112214266A (en) | Android shelling method and device for deception call chain, storage medium and computer equipment | |
| US9396239B2 (en) | Compiling method, storage medium and compiling apparatus | |
| JP6906057B2 (en) | How to secure your software code | |
| JP2009199529A (en) | Information equipment, program and method for preventing execution of unauthorized program code | |
| KR101341328B1 (en) | User definition api function creation | |
| JP6674048B2 (en) | Judgment device, judgment method and judgment program | |
| CN111309444A (en) | Method, device, system and storage medium for anti-debugging by using process virtual machine | |
| US11989537B2 (en) | Dataflow-based computer program visualization and refactoring | |
| Wright et al. | Using Event-B to construct instruction set architectures | |
| CN111782189B (en) | Medical system deployment method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |