CN116861433A - No GIL parallel-based intelligent Ethernet contract transaction defect detection method and device - Google Patents
No GIL parallel-based intelligent Ethernet contract transaction defect detection method and device Download PDFInfo
- Publication number
- CN116861433A CN116861433A CN202310594839.1A CN202310594839A CN116861433A CN 116861433 A CN116861433 A CN 116861433A CN 202310594839 A CN202310594839 A CN 202310594839A CN 116861433 A CN116861433 A CN 116861433A
- Authority
- CN
- China
- Prior art keywords
- data
- transaction
- operation code
- gil
- instruction
- 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.)
- Pending
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 55
- 230000007547 defect Effects 0.000 title claims abstract description 18
- 238000012545 processing Methods 0.000 claims abstract description 73
- 238000000034 method Methods 0.000 claims abstract description 53
- 238000010586 diagram Methods 0.000 claims abstract description 29
- 230000008569 process Effects 0.000 claims abstract description 23
- 238000004088 simulation Methods 0.000 claims description 25
- 238000004891 communication Methods 0.000 claims description 19
- 238000004590 computer program Methods 0.000 claims description 7
- 238000012512 characterization method Methods 0.000 claims description 3
- 238000000638 solvent extraction Methods 0.000 claims description 3
- 238000006243 chemical reaction Methods 0.000 abstract description 5
- 238000010276 construction Methods 0.000 abstract description 4
- 238000004458 analytical method Methods 0.000 description 10
- 230000006872 improvement Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 238000012216 screening Methods 0.000 description 4
- 101000823100 Homo sapiens Putative alpha-1-antitrypsin-related protein Proteins 0.000 description 3
- 102100022709 Putative alpha-1-antitrypsin-related protein Human genes 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 241001178520 Stomatepia mongo Species 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
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/577—Assessing vulnerabilities and evaluating computer system security
-
- 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/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- 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/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/562—Static detection
-
- 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/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- 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/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- 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/43—Checking; Contextual analysis
- G06F8/433—Dependency analysis; Data or control flow analysis
-
- 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
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Business, Economics & Management (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Databases & Information Systems (AREA)
- Virology (AREA)
- Computing Systems (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a method and a device for detecting intelligent contract transaction defects of an Ethernet based on No GIL parallelism, wherein the method for detecting the intelligent contract transaction defects of the Ethernet based on No GIL parallelism is provided by the invention: replaying the transaction by using the Ethernet virtual machine, and collecting the tracking data of the byte code level in the transaction process; dividing the tracking data according to the dependency relationship among the tracking data to simulate the EVM stack to construct a transaction processing diagram; processing the transaction processing diagram based on the No GIL, and constructing intermediate representation information to obtain a data file; and detecting the data file by using a preset detection rule, so as to detect whether the hidden danger of being attacked exists in the transaction process. Because the embodiment of the invention uses the No GIL-based parallel method to analyze the byte codes, the efficiency of the transaction processing diagram construction and conversion part which is originally easiest to timeout is greatly improved, and the attack detection time is shortened.
Description
Technical Field
The invention belongs to the technical field of intelligent contract dynamic detection, and particularly relates to an intelligent contract transaction defect detection method and device for an Ethernet based on No GIL parallelism.
Background
The smart contract is embodied as a piece of program that has a state, is event driven, and runs on a blockchain system. Up to now, there are over 5000 ten thousand intelligent contracts on ethernet only. At the same time, attacks against smart contracts are increasing. The smart contracts that control large amounts of funds on the blockchain inevitably have security holes caused by program flaws, and manage large amounts of digital token assets that an attacker can gain tremendous benefits from attacking.
Vulnerability detection of smart contracts has been a challenge due to the unique operating environment of smart contracts, the complexity of smart contracts, and the rapid development of blockchain technology. Nowadays, more and more detection tools are proposed. The main problems and defects existing in the prior art are as follows:
(1) Most of the existing vulnerability detection tools are static detection tools, only the codes provided to them can be analyzed, and the contexts cannot be combined, so that external factors affecting the behavior of intelligent contracts and vulnerabilities of specific use cases cannot be detected. The symbolic execution based tool encounters path explosion problems and cannot detect vulnerabilities involving multiple intelligent contracts. These tools generally have the problems of limited detection range, false alarm omission and the like.
(2) When the existing vulnerability detection tool analyzes the byte code of the transaction, the problems of overtime and the like are often caused by complex operation and large number of certain special bytes, so that the overall detection efficiency is affected.
(3) After the Ethernet platform is upgraded, a consensus mechanism and a node synchronization mechanism are changed, and many detection tools are not suitable for a new platform and are difficult to detect.
Accordingly, the prior art is in need of improvement.
Disclosure of Invention
In order to solve the problems in the prior art, the invention provides an intelligent contract transaction defect detection method for an Ethernet based on No GIL parallelism. The technical problems to be solved by the invention are realized by the following technical scheme:
in a first aspect, an embodiment of the present invention provides a No GIL parallel-based method for detecting defects in an intelligent ethernet contract transaction, including:
replaying the transaction by using the Ethernet virtual machine, and collecting the tracking data of the byte code level in the transaction process;
dividing the tracking data according to the dependency relationship among the tracking data to simulate the EVM stack to construct a transaction processing diagram;
processing the transaction processing diagram based on the No GIL, and constructing intermediate representation information to obtain a data file;
and detecting the data file by using a preset detection rule, so as to detect whether the hidden danger of being attacked exists in the transaction process.
The tracking data comprises a plurality of byte code data, and each byte code data comprises a program counter, an operation code and parameter values of the operation code.
Dividing the trace data according to the dependency relationship between the trace data to simulate the EVM stack to construct a transaction processing diagram, comprising:
determining byte code data to be processed according to the dependency relationship of the tracking data;
performing simulation processing on the byte code data to be processed to obtain simulation data information;
and obtaining the transaction processing diagram based on the simulation data information.
The determining the byte code data to be processed according to the dependency relationship of the tracking data comprises the following steps:
assigning a corresponding opcode location value to each byte code data in the trace data; the corresponding positioning value of each data is different;
determining the dependency relationship between byte code data based on the operation code positioning value, and taking the byte code data with the dependency relationship as byte code data to be processed;
performing simulation processing on the byte code data to be processed to obtain simulation data information, wherein the simulation data information comprises:
and performing simulation processing on the byte code data to be processed by using the Ethernet virtual machine to obtain simulation data information.
Processing the transaction processing diagram based on the No GIL, constructing intermediate representation information, and obtaining a data file, wherein the method comprises the following steps:
converting the operation code sequence into a first instruction block and a second instruction block; the operation code sequence consists of operation codes of byte code data to be processed in the transaction processing diagram; the instruction characterization execution flow of the first instruction block is changed from one intelligent contract to another intelligent contract, and the second instruction block comprises a contract calling instruction;
the No GIL tool is used for processing a first instruction block in a multithreading parallel processing mode, and a second instruction block is processed in a serial processing mode, so that intermediate representation information is obtained;
and extracting parameter data from the intermediate representation information to obtain data files, wherein each operation code is provided with data files with depth arranged in sequence, and the data files comprise a program counter, a register, an operation code positioning value, calling depth and calling times.
The method for detecting the data file by using the preset detection rule further detects whether the hidden danger of being attacked exists in the transaction process or not, and comprises the following steps:
detecting each data file by using a preset detection rule, and determining whether the transaction has hidden danger of being attacked at each calling depth;
if the hidden danger of being attacked exists, the operation code corresponding to the data file is recorded as a result file.
Each data file is detected by using a preset detection rule, and whether the transaction has a hidden danger of being attacked under each calling depth is determined, which comprises the following steps:
classifying the operation codes based on the data file to obtain a first operation code set, a second operation code set and a third operation code set; the first operation code set comprises a contract calling instruction, the second operation code comprises a contract calling instruction and a reserved caller, and the third operation code set comprises a delegated calling instruction;
and matching each operation code in the first operation code set, the second operation code set and the third operation code set with the jump instruction operation code, and if unmatched operation codes exist, then the hidden danger of being attacked exists.
Wherein the matching each opcode in the first opcode set, the second opcode set, and the third opcode set with the jump instruction opcode includes:
and if the positioning values of the operation codes in the first operation code set, the second operation code set and the third operation code set are smaller than those of the jump instruction operation code, determining that the operation codes are not matched.
In a third aspect, an embodiment of the present invention provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus;
the memory is used for storing a computer program;
the processor is configured to implement the steps of the transaction defect detection method provided by the embodiment of the present invention when executing the program stored in the memory.
In a fourth aspect, embodiments of the present invention provide a computer readable storage medium having a computer program stored therein, which when executed by a processor, implements the steps of the transaction defect detection method provided by the embodiments of the present invention.
The invention has the beneficial effects that:
the method for detecting the intelligent contract transaction defects of the Ethernet based on No GIL parallelism comprises the following steps: replaying the transaction by using the Ethernet virtual machine, and collecting the tracking data of the byte code level in the transaction process; dividing the tracking data according to the dependency relationship among the tracking data to simulate the EVM stack to construct a transaction processing diagram; processing the transaction processing diagram based on the No GIL, and constructing intermediate representation information to obtain a data file; and detecting the data file by using a preset detection rule, so as to detect whether the hidden danger of being attacked exists in the transaction process. The invention uses the parallel method based on No GIL to analyze the byte code, so the efficiency of the transaction processing diagram construction and conversion part which is originally easiest to overtime is greatly improved, and the attack detection time is shortened.
Drawings
FIG. 1 is a schematic flow chart of a No GIL-parallel-based method for detecting defects in intelligent contract transactions of Ethernet;
FIG. 2 is a schematic flow chart of S2 in FIG. 1;
FIG. 3 is a schematic flow chart of S3 in FIG. 1;
FIG. 4 is a schematic flow chart of S4 in FIG. 1;
fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
As shown in fig. 1, a flow chart of an embodiment of a No GIL parallel-based intelligent ethernet contract transaction defect detection method according to an embodiment of the present invention includes the following steps S1 to S4:
s1: and replaying the transaction by using the Ethernet virtual machine, and collecting the tracking data of the byte code level in the transaction process.
Specifically, in the process of executing the ethernet transaction in the ethernet virtual machine EVM, records of transaction byte code levels are collected together. Wherein each byte code level record is a sequence of 3 tuples. For each byte code executed by the EVM, each byte code data comprises a program counter, an operation code and parameter values of the operation code, and the Program Counter (PC), the operation code (OPCODE) and the parameter values (ARGS) of the operation code in the EVM are recorded as a 3-tuple, namely { < PC >; < OPCODE >; < ARGS > }. The opcode is an instruction set of the EVM that defines the operations required to execute the smart contract.
In one embodiment, to obtain byte code level information at transaction processing, it is necessary to replay the transaction that has been executed by synchronizing the nodes of the ethernet network and modifying the ethernet client source code to extract the transaction record and store it in the Trace Database along with the associated metadata.
The ethernet is merged in 2022, 9 and 15 days, and is updated to 2.0, the consensus mechanism is changed from the original Work Proof (PoW) to the Proof of equity (PoS, proof of status), and the mechanism of the synchronization node is changed. Before the Ethernet merging, the user can only run the executing client to synchronize without running the local executing client, and can access the Ethernet network by using a server similar to Inura; after the ethernet is merged, the user must run an execution layer client, and only if the execution layer client and the consensus layer client run together, the ethernet network can be accessed. Wherein the execution layer is responsible for processing transactions and data, and the consensus layer is responsible for processing PoS consensus mechanisms. For the selection of the execution Client and the consensus Client, according to the usage data condition of each Client of the Ethernet Client Diversity statistics, we choose to run the Prysm consensus layer Client and the Go-Etherum execution layer Client, and adopt a full node synchronization strategy (full sync), download complete blockchain data from the generation block, replay the transaction in the execution block, and this way can provide the highest security and data integrity for us. To obtain complete transaction opcode information, we synchronize in a fully synchronized mode at the execution layer, while optimistically synchronizing is used at the consensus layer.
Meanwhile, in order to facilitate centralized collection and processing of byte code level records, the source codes of the Go-Ethereum client are modified, and a Mongo Database module is added in the source codes to extract transaction records and store the transaction records in Trace Database together with related metadata.
S2: the trace data is divided according to the dependency relationship among the trace data to simulate the EVM stack to construct a transaction processing diagram.
In S1, we extract the trace data, the data information of byte code level in the trace data, and can not directly use the pre-defined rule detection file to judge whether the transaction has the transaction defects of undetected return value, etc., so we also need to further convert the extracted data set.
In an alternative embodiment, referring to fig. 2, S2 includes the following steps:
s21: and determining the byte code data to be processed according to the dependency relationship of the tracking data.
Specifically, each byte code data in the tracking data is endowed with a corresponding operation code positioning value; the corresponding positioning value of each data is different; and determining the dependency relationship between the byte code data based on the operation code positioning value, and taking the byte code data with the dependency relationship as byte code data to be processed. Specifically, in order to distinguish data that does not have a dependency, an opcode locating value loc needs to be assigned to each piece of bytecode data, the locating value of each piece of bytecode data is different, and the data that has a dependency is put into the same block.
S22: and performing simulation processing on the byte code data to be processed to obtain simulation data information.
And performing simulation processing on byte code data to be processed by using the Ethernet virtual machine to obtain simulation data information. Specifically, according to the result of data dependence partitioning processing, the byte code data to be processed is subjected to simulation processing based on stack operation of the simulation Ethernet virtual machine EVM, and data information after transaction simulation is collected.
The transaction execution simulation process uses the result process from the data dependent partitioning process to obtain further opcode information. The stack operation of the EVM is simulated for the operation code information for further analysis. For part of operation codes, the execution parameters of the operation codes are known in the information collection stage, the execution parameters are collected for stacking, the execution parameters of the other part of operation codes such as Jumpi, mstore and the like cannot be obtained in the information collection stage, the stack-stripping operation is carried out in the simulation stage, and the data obtained by the stack-stripping operation is the execution parameters of the operation codes. This step is to obtain more complete data information, and the analysis in the subsequent step requires the execution parameters of all the operation codes to be used for judging more detailed relations between the operation codes.
Step S23: a transaction processing graph is obtained based on the simulated data information.
The transaction processing diagram comprises all byte code level traces collected after transaction replay, wherein the trace comprises a large number of operation codes, and for the operation codes such as Jumpi, mstore and the like, parameters of the operation codes are determined after transaction execution, so that the trace on the byte code level needs to simulate the stack operation of the EVM to further analyze to obtain a real value corresponding to the operation code execution, and the stack operation codes are numbered for analysis of a logic relationship.
In order to record important information of the whole process of transaction execution, a transaction processing diagram TPC is constructed according to the order of intelligent contract execution. Each node in the TPC represents the execution of a smart contract that contains the execution trace of the byte code level generated by the smart contract. Each edge in the TPC represents a transfer of control flow from one smart contract to another. The construction of nodes and edges are dynamically generated, and when the byte code level tracking is analyzed, if a CALL or STOP related operation code is encountered, a new node is generated, and when the execution flow is transferred from one intelligent contract to another intelligent contract, the execution flow graph generator generates edges representing the control flow between the two nodes. Thus, the EVM stack is simulated according to the intelligent contract execution sequence to construct a transaction processing diagram which contains the information in the transaction (PC, OPCODE, ARGS, idx, depth, callnum), and the stack operation codes are numbered so as to facilitate the extraction and analysis of the logic relationship.
S3: based on the No GIL (NO Global Interpreter Lock, global interpretation locks are removed) the transaction processing graph is processed, and intermediate representation information is constructed to obtain a data file.
In an alternative embodiment, referring to fig. 3, S3 includes the following steps:
s31: the operation code sequence is converted into a first instruction block and a second instruction block, and the operation code sequence is composed of operation codes of byte code data to be processed in a transaction processing diagram.
Specifically, each basic block of the transaction processing diagram is divided into two types according to the difference of the first row operation codes, so that analysis is convenient to carry out later.
Specifically, in S2, a transaction processing diagram has been generated, the tracked operation code sequence is converted into two types of basic blocks evm _block and evm_block, which are a block (a first instruction block) with a head line operation code instruction of 0PUSH1 and a block (a second instruction block) with a head line instruction of special characters such as CALL, wherein the instruction characterization execution flow of the first instruction block is changed from one intelligent contract to another intelligent contract, and the second instruction block comprises a contract calling instruction; in one embodiment, the second instruction block characterizes the case where a CALL related opcode is encountered, generating a new node. The two basic blocks are separated, so that subsequent parallel processing is facilitated.
S32: the No GIL tool is used for processing the first instruction block in a multithreading parallel processing mode, and processing the second instruction block in a serial processing mode, so that intermediate representation information is obtained.
In the logical relationship generator, we need to parse the transaction processing graph to construct intermediate representation Information (IR) suitable for analysis, i.e., converting the EVM opcode sequence into a register transfer language. In this step, the rule indicated by IR in vandal is referred to, and expansion and improvement are performed. First, real values need to be processed instead of sign values. In the logical relationship generator this is achieved by using registers with real values to simulate EVM stack operation, so that the values of the registers are updated accordingly and all intermediate values are correctly recorded. This is a key step in capturing all dynamic information during the execution of a transaction, which is not possible with static analysis tools. For example, when processing a timestamp, the real timestamp value recorded in the bytecode level trace is pushed onto the stack and assigned to its associated register. Second, inter-contract calls need to be handled. Call classification between contracts is respectively corresponding to two types of edges in TPC: for the I-class edge in TPC, the current stack is sealed and an empty stack is created. For class II edges in TPC, the current stack is deleted and the last sealed stack is restored. Third, the naming of the register is changed, and the register is generally marked as 'V+sequence number' according to the sequence of all recorded operation codes, and the operation codes are changed into 'block number+V+intra-block sequence number', so that the inter-block relation is broken, the parallel processing is convenient after that, and meanwhile, the register number is prevented from reaching hundreds of thousands of large numbers due to excessive transaction information.
To increase the parsing speed, we process the block beginning with 0PUSH1 (i.e., the first instruction block) in a multithreaded manner with the No GIL tool.
Specifically, due to the characteristics of the CPython interpreter, the GIL global interpretation lock limits that only one thread runs at the same time, and even if the multithreading is started, the processing is actually single-core processing, which is equivalent to serial running, and the efficiency cannot be improved. The No GIL tool is adopted to realize parallelism, a plurality of threads are opened to convert the 0PUSH1 blocks into basic blocks expressed by IR language in parallel, and stack stacks generated in the analysis process of each block are stored into a total list stacks according to the corresponding block numbers.
For the block (i.e., the second instruction block) at the beginning of the special operation code such as CALL, the stack of the previous block is called in the parsing process, and the parallel conversion condition is not met, so that the second instruction block is processed in series, and the required stack is fetched from stacks according to the conversion rule if necessary. The transaction processing diagram is ultimately converted to IR form.
S33: and extracting parameter data from the intermediate representation information to obtain a data file, wherein each operation code is provided with the data files with sequentially arranged depths, and the data file comprises a program counter, a register, an operation code positioning value, a calling depth and calling times.
And extracting parameter data from the intermediate representation information IR which is successfully converted according to the detection rule to obtain a data file. The data files include a program counter PC, a Register, an opcode location value Idx, a call Depth and a call number Callnum, denoted as (PC, register, idx, depth, callnum), and parallel extraction is used for calls of different depths to improve efficiency, i.e., each opcode has a data file with its respective Depth ordered from small to large.
S4: and detecting the data file by using a preset detection rule, so as to detect whether the hidden danger of being attacked exists in the transaction process.
Specifically, an attack detector is constructed based on the Datalog language, and the constructed attack detector and a preset detection rule are utilized to detect a data file (pictures file), so as to detect whether hidden danger of attack exists in the transaction process.
At different depths, multi-threading techniques are used to detect attacks that may exist in transactions in parallel.
S4, an attack detection rule is formulated in advance based on a specific Datalog language, an attack detector is constructed based on the specific Datalog language, and a data file is detected, so that whether the hidden danger of being attacked exists in the transaction process is determined. If the hidden danger of being attacked exists, the operation code corresponding to the data file is recorded as a result file.
An attack detector built based on a particular Datalog contains an open-source Datalog tool engine and detection rules formulated for various transaction attacks. The open source Datalog engine comprises an interpreter and a compiler to execute the Datalog program, and the detection rules are the Datalog program written according to the collected information and the functions to be completed, and the detection rules comprise the processing under different depth calls. The attack detector carries out parallel detection on the extracted key operation code information according to the formulated detection rule, judges whether the transaction has hidden danger of being attacked at each depth, and records the operation code information of the corresponding problem into a final result file if the hidden danger of being attacked exists. Different from the serial detection rules in the common attack detector, the S4 performs parallelization improvement operation on the detection of different depth calls in the transaction, so that the efficiency of detecting the attack is greatly improved, and the specific security of the transaction is also improved.
Taking the processing flow of the problem that the return value is not detected as an example, the return value is not detected, namely, a transaction uses a contract Call instruction Call, a contract Call instruction and a caller Callcode or a delegated Call instruction Delegatecall operation code when being executed, after the use is finished, whether the return value accords with the expectations or not is not judged, namely, no corresponding Jumpi operation is not carried out, and no related processing measures are taken.
In an alternative embodiment, S4 specifically includes:
s41: classifying the operation codes based on the data file to obtain a first operation code set, a second operation code set and a third operation code set.
The first operation code set comprises a contract calling instruction Call, the second operation code comprises a contract calling instruction and a caller Callcode is reserved, and the third operation code set comprises a delegation calling instruction Delegatecall.
According to the requirement of parameter usage record in the detection rule, call (contract Call instruction), callcode (contract Call instruction and reservation caller) and Delegatecall (delegated Call instruction) operation codes in the data file are required to be filtered to obtain a filtering result file. Specifically, the detection rules, when formulated, condition-filter Call, callcode and deltatecall opcodes to determine if the opcode is likely to have a return value detection opcode that matches it. Only eligible Call, callcode and Delegatecall opcodes will be match detected corresponding to the Jumpi opcode.
Because the matching operation is time-consuming, in order to save detection time, it is necessary to determine whether the depths of two operation codes are identical before the matching operation, and the operation codes with identical depths can be subjected to matching determination, that is, the matched operation codes must have identical depth parameters.
In one embodiment, if the location value of the opcode in the first opcode set, the second opcode set, and the third opcode set is greater than the location value of the jump instruction opcode, then the opcode is determined to correspond to a Jumpi opcode, and the condition is met. If the positioning values of the operation codes in the first operation code set, the second operation code set and the third operation code set are smaller than those of the jump instruction operation code, determining that the operation codes do not correspond to the Jumpi operation codes, do not meet the conditions and do not match.
In the detection, the screening condition is that a certain parameter involved in these calls must be recorded in another opcode data file for recording the parameter usage. If the positioning values of the operation codes in the first operation code set, the second operation code set and the third operation code set are larger than those of the jump instruction operation code, the operation code is determined to correspond to the Jumpi operation code, and the condition is met. And taking the information meeting the conditions as screened information, and storing the screened information into a screening result file, wherein the screening result file can be named as 'filtered_res'.
S42: and matching each operation code in the first operation code set, the second operation code set and the third operation code set with the jump instruction operation code, and if unmatched operation codes exist, then the hidden danger of being attacked exists.
And if the positioning values of the operation codes in the first operation code set, the second operation code set and the third operation code set are smaller than those of the jump instruction operation code, determining that the operation codes are not matched.
Different from the method for checking whether the return value is undetected or not by only calling the first layer depth under the general condition, the method and the device for checking the return value of the attack by using the pre-processing result file and based on the depth in the attack detection rule and the requirement of the operation code positioning value, the Call, callcode and Delegatecall operation codes and the Jumpi operation codes are subjected to matching value judgment in parallel under different depths, and the Call, callcode and Delegatecall operation code information which represents successful matching and is detected by the return value is obtained and stored in the matching result file;
in this step, for Call, callcode and deltatecall opcodes and Jumpi opcodes, the matched opcodes must have the same depth parameters, so that the efficiency can be improved by parallelizing each pair of opcodes of different depths on this basis.
The opcode information that matches successfully stores it in a match result file, which may be named "matched_res".
And re-matching the screening result file and the matching result file to obtain Call, callcode and Delegatecall operation codes without Jumpi matching as operation codes with undetected return values, and storing the information called by the operation codes into a final result file.
The Call, callcode and Delegatecall opcodes without Jumpi matching can be obtained in the S42 mode, which shows that the transaction has the undetected return value problem, namely the opcodes are not matched, and the hidden danger of being attacked exists.
The method for detecting the intelligent contract transaction defects of the Ethernet based on No GIL parallelism comprises the following steps: first, executing the playback of the Ethernet transaction based on Ethernet 2.0 and recording the tracking of byte code level; secondly, coding according to the dependency relationship between the data, and simulating an EVM stack to construct a transaction processing diagram; then, the transaction processing diagram is analyzed in parallel to construct intermediate representation information IR, and required information is extracted to generate a data file; finally, an attack detector based on Datalog is constructed, and attacks in transactions are detected in parallel under different depths by utilizing the attack detector and formulated rules, so that the attack detection on intelligent contract transactions can be realized.
Because the embodiment of the invention uses the No GIL-based parallel method to analyze the byte codes, the efficiency of the construction and conversion part of the transaction processing diagram which is originally easiest to timeout is greatly improved, and the attack detection time is shortened. In the process of extracting key information and calling rule detection, a parallel method is also used for improving efficiency. In addition, in the condition of undetected return values, key operation code information of different depths is extracted, so that the detection range is enlarged, and the detection accuracy is improved.
In addition, since the improvement of the byte code analysis part has universality, the defect detection tool for all byte code-based execution is improved, the limitation of CPython interpreter global interpretation lock on the computationally intensive task is avoided by using No GIL, and more fields are expanded for the migration of the parallel byte code analysis framework.
Meanwhile, the embodiment of the invention belongs to the technical field of intelligent contract dynamic detection, and the verified transaction is a transaction really existing in reality, so that the dynamic verification method is applied to detect whether the truly generated transaction has the problem of undetected return value, so that the corresponding parameters of each operation code are determined when the intelligent contract runs, and the execution condition of each branch is determined, thereby effectively ensuring the high efficiency and accuracy of intelligent contract verification.
In a third aspect, an embodiment of the present invention further provides an electronic device, as shown in fig. 5, including a processor 401, a communication interface 402, a memory 403, and a communication bus 404, where the processor 401, the communication interface 402, and the memory 403 complete communication with each other through the communication bus 404;
the memory is used for storing a computer program;
the processor is configured to implement any of the steps of the method according to the first aspect of the present invention when executing the program stored in the memory.
The communication bus mentioned above for the electronic devices may be a peripheral component interconnect standard (Peripheral Component Interconnect, PCI) bus or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, etc. The communication bus may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, the figures are shown with only one bold line, but not with only one bus or one type of bus.
The communication interface is used for communication between the electronic device and other devices.
The Memory may include random access Memory (Random Access Memory, RAM) or may include Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the aforementioned processor.
The processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; but also digital signal processors (Digital Signal Processing, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.
The method provided by the embodiment of the invention can be applied to electronic equipment. Specifically, the electronic device may be: desktop computers, portable computers, intelligent mobile terminals, servers, etc. Any electronic device capable of implementing the present invention is not limited herein, and falls within the scope of the present invention.
The embodiment of the invention also provides a computer readable storage medium, wherein a computer program is stored in the computer readable storage medium, and when the computer program is executed by a processor, the steps of any intelligent Ethernet contract transaction defect detection method based on No GIL parallelism provided by the first aspect of the embodiment of the invention are realized.
For the apparatus/electronic device/storage medium embodiments, the description is relatively simple as it is substantially similar to the method embodiments, as relevant see the section description of the method embodiments.
It should be noted that, the electronic device and the storage medium according to the embodiments of the present invention can implement all the embodiments of any of the methods described above, and can achieve the same or similar beneficial effects.
Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. In the description of the present invention, the meaning of "a plurality" is two or more, unless explicitly defined otherwise.
The foregoing description is only of the preferred embodiments of the present invention and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.
Claims (10)
1. An intelligent contract transaction defect detection method for an Ethernet based on No GIL parallelism is characterized by comprising the following steps:
replaying the transaction by using the Ethernet virtual machine, and collecting the tracking data of the byte code level in the transaction process;
dividing the tracking data according to the dependency relationship among the tracking data to simulate the EVM stack to construct a transaction processing diagram;
processing the transaction processing diagram based on the No GIL, and constructing intermediate representation information to obtain a data file;
and detecting the data file by using a preset detection rule, so as to detect whether the hidden danger of being attacked exists in the transaction process.
2. The method of claim 1, wherein the trace data comprises a plurality of byte code data, each byte code data comprising a program counter, an opcode, and a parameter value for the opcode.
3. The method of claim 2, wherein partitioning the trace data according to dependencies between the trace data to simulate an EVM stack to construct a transaction processing diagram comprises:
determining byte code data to be processed according to the dependency relationship of the tracking data;
performing simulation processing on the byte code data to be processed to obtain simulation data information;
and obtaining the transaction processing diagram based on the simulation data information.
4. A method according to claim 3, wherein said determining the byte code data to be processed from the dependency of the trace data comprises:
assigning a corresponding opcode location value to each byte code data in the trace data; the corresponding positioning value of each data is different;
determining the dependency relationship between byte code data based on the operation code positioning value, and taking the byte code data with the dependency relationship as byte code data to be processed;
performing simulation processing on the byte code data to be processed to obtain simulation data information, wherein the simulation data information comprises:
and performing simulation processing on the byte code data to be processed by using the Ethernet virtual machine to obtain simulation data information.
5. The method of claim 2, wherein processing the transaction processing graph based on the No GIL, constructing intermediate representation information, and obtaining the data file, comprises:
converting the operation code sequence into a first instruction block and a second instruction block; the operation code sequence consists of operation codes of byte code data to be processed in the transaction processing diagram; the instruction characterization execution flow of the first instruction block is changed from one intelligent contract to another intelligent contract, and the second instruction block comprises a contract calling instruction;
the No GIL tool is used for processing a first instruction block in a multithreading parallel processing mode, and a second instruction block is processed in a serial processing mode, so that intermediate representation information is obtained;
and extracting parameter data from the intermediate representation information to obtain data files, wherein each operation code is provided with data files with depth arranged in sequence, and the data files comprise a program counter, a register, an operation code positioning value, calling depth and calling times.
6. The method of claim 5, wherein detecting the data file using a predetermined detection rule to detect whether there is an attack risk during the transaction process comprises:
detecting each data file by using a preset detection rule, and determining whether the transaction has hidden danger of being attacked at each calling depth;
if the hidden danger of being attacked exists, the operation code corresponding to the data file is recorded as a result file.
7. The method of claim 6, wherein detecting each data file using a preset detection rule to determine whether a transaction has a hidden danger of being attacked at each call depth comprises:
classifying the operation codes based on the data file to obtain a first operation code set, a second operation code set and a third operation code set; the first operation code set comprises a contract calling instruction, the second operation code comprises a contract calling instruction and a reserved caller, and the third operation code set comprises a delegated calling instruction;
and matching each operation code in the first operation code set, the second operation code set and the third operation code set with the jump instruction operation code, and if unmatched operation codes exist, then the hidden danger of being attacked exists.
8. The method of claim 7, wherein matching each opcode of the first, second, and third sets of opcodes to a jump instruction opcode comprises:
and if the positioning values of the operation codes in the first operation code set, the second operation code set and the third operation code set are smaller than those of the jump instruction operation code, determining that the operation codes are not matched.
9. An electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory are in communication with each other through the communication bus;
the memory is used for storing a computer program;
the processor is configured to implement the method steps of any of claims 1-8 when executing a program stored on the memory.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored therein a computer program which, when executed by a processor, implements the method steps of any of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310594839.1A CN116861433A (en) | 2023-05-24 | 2023-05-24 | No GIL parallel-based intelligent Ethernet contract transaction defect detection method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310594839.1A CN116861433A (en) | 2023-05-24 | 2023-05-24 | No GIL parallel-based intelligent Ethernet contract transaction defect detection method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116861433A true CN116861433A (en) | 2023-10-10 |
Family
ID=88227429
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310594839.1A Pending CN116861433A (en) | 2023-05-24 | 2023-05-24 | No GIL parallel-based intelligent Ethernet contract transaction defect detection method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116861433A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118520506A (en) * | 2024-07-23 | 2024-08-20 | 浙江大学 | Intel SGX-based Ethernet privacy protection transaction pre-execution system |
-
2023
- 2023-05-24 CN CN202310594839.1A patent/CN116861433A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118520506A (en) * | 2024-07-23 | 2024-08-20 | 浙江大学 | Intel SGX-based Ethernet privacy protection transaction pre-execution system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Chen et al. | Dataether: Data exploration framework for ethereum | |
| US10353809B2 (en) | System and method for executing integration tests in multiuser environment | |
| CN102054149B (en) | Method for extracting malicious code behavior characteristic | |
| US20060143596A1 (en) | Program analyzing apparatus and testing apparatus, and analyzing method and program therefor | |
| CN111931179B (en) | Cloud malicious program detection system and method based on deep learning | |
| CN112527674B (en) | AI frame safety evaluation method, device, equipment and storage medium | |
| CN108628600B (en) | Software dynamic behavior modeling method and device based on control flow analysis | |
| CN116361810A (en) | Intelligent contract vulnerability detection method based on symbol execution | |
| CN112650688A (en) | Automated regression testing method, associated device and computer program product | |
| CN105630656A (en) | Log model based system robustness analysis method and apparatus | |
| US20200310952A1 (en) | Comparable user interface object identifications | |
| CN111919214B (en) | Method and system for automatically generating patches for security violations | |
| CN111177731A (en) | Software source code vulnerability detection method based on artificial neural network | |
| CN113919841A (en) | Block chain transaction monitoring method and system based on static characteristics and dynamic instrumentation | |
| CN116861433A (en) | No GIL parallel-based intelligent Ethernet contract transaction defect detection method and device | |
| US8412744B2 (en) | Visualization of runtime analysis across dynamic boundaries | |
| CN113468524A (en) | RASP-based machine learning model security detection method | |
| CN112464237A (en) | Static code safety diagnosis method and device | |
| CN116069650A (en) | Method and device for generating test cases | |
| Bernardi et al. | Improving Design Patterns Finder Precision Using a Model Checking Approach. | |
| CN111190813B (en) | Android application network behavior information extraction system and method based on automatic testing | |
| CN114444087A (en) | Unauthorized vulnerability detection method and device, electronic equipment and storage medium | |
| CN118171284B (en) | Kernel data competition detection method based on patch and concurrency behavior pattern analysis | |
| CN116318861A (en) | Ether-mill intelligent contract return value non-testing method based on dynamic transaction information | |
| Alvi et al. | Security pattern detection using ordered matrix matching |
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 |