CN116663012A - Cross-contract vulnerability detection method, system and equipment - Google Patents
Cross-contract vulnerability detection method, system and equipment Download PDFInfo
- Publication number
- CN116663012A CN116663012A CN202310627115.2A CN202310627115A CN116663012A CN 116663012 A CN116663012 A CN 116663012A CN 202310627115 A CN202310627115 A CN 202310627115A CN 116663012 A CN116663012 A CN 116663012A
- Authority
- CN
- China
- Prior art keywords
- attack
- contract
- function
- cross
- candidate
- 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.)
- Granted
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 128
- 238000000034 method Methods 0.000 claims abstract description 26
- 230000006870 function Effects 0.000 claims description 119
- 238000004590 computer program Methods 0.000 claims description 9
- 238000011156 evaluation Methods 0.000 abstract description 4
- RTZKZFJDLAIYFH-UHFFFAOYSA-N Diethyl ether Chemical compound CCOCC RTZKZFJDLAIYFH-UHFFFAOYSA-N 0.000 description 20
- 238000004458 analytical method Methods 0.000 description 15
- 238000002474 experimental method Methods 0.000 description 11
- 230000003068 static effect Effects 0.000 description 11
- 238000012360 testing method Methods 0.000 description 10
- 238000004422 calculation algorithm Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 9
- 208000020990 adrenal cortex carcinoma Diseases 0.000 description 7
- 150000002170 ethers Chemical class 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 239000003607 modifier Substances 0.000 description 4
- 238000010801 machine learning Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 206010010144 Completed suicide Diseases 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000003556 assay Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013135 deep learning Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000036962 time dependent Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1433—Vulnerability analysis
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
-
- 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
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
- Y04S40/20—Information technology specific aspects, e.g. CAD, simulation, modelling, system security
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
The application relates to the technical field of network security, in particular to a method, a system and equipment for detecting cross-contract vulnerabilities, which are used for statically abstracting main information of intelligent contracts, acquiring candidate attack pairs capable of specifying attack directions, combining the candidate attack pairs with template contracts with aggressiveness to generate attack contracts, dynamically attacking the intelligent contracts by using the attack contracts, and detecting the cross-contract vulnerabilities in the intelligent contracts according to different attack results. Experimental results show that the detection method has high accuracy, comprehensive evaluation rate, 0 false alarm rate and low time cost.
Description
Technical Field
The application relates to the technical field of network security, in particular to a method, a system and equipment for detecting cross-contract loopholes.
Background
Security of smart contracts is particularly important because of the non-tamper-ability of smart contracts and the large amount of funds flowing involved. In recent years, events utilized by attackers for smart contract vulnerabilities are frequent, resulting in significant economic loss for many enterprises. If the existing loopholes can be found before the intelligent contracts are deployed, the method can help developers to correct the loopholes existing in the contracts in time and avoid economic loss caused by the loopholes. For this reason, a large number of researchers have explored the principles of smart contract vulnerabilities. Up to now, developers designed over 70 intelligent contract detection methods.
The static intelligent contract detection method mainly comprises the following steps: symbol execution, formal proof, intermediate representation, and deep learning. Symbolic execution is the hottest method in the current intelligent contract detection method, and the core idea is to perform constraint solving by constructing constraint paths. The oynte is an intelligent contract vulnerability detection method based on symbolic execution development, which can detect integer overflow vulnerability, stack overflow vulnerability, transaction sequence dependency vulnerability and reentry vulnerability. But has the disadvantages that: path explosion, i.e., an excessive number of paths are generated, causes an exponential increase in space and time overhead, ultimately resulting in a workspace being unable to support the overhead. Theoretically, formalization proves to be the detection method with the highest accuracy. There are some formal proof frameworks for smart contract vulnerability detection such as F and isable/HOL. However, the biggest problem of formal proof is the complex logic, which generally requires the participation of specific experts for modeling. The disadvantage of intermediate representation is that the conversion from intelligent contracts to intermediate languages brings about a lack of information, usually with low logic. The machine learning method has been widely used as a new method in recent years, which can greatly improve the time efficiency of intelligent contract vulnerability detection. However, the machine learning method has a certain upper limit because it depends on the result of classification by other detection methods.
Dynamic smart contract detection methods are much less common than static smart contract detection methods. The main dynamic intelligent contract detection method comprises the following steps: stain analysis and blur testing. The stain analysis method refers to marking the problem and then exploring the distribution of the stain points. Esayflow is an open-source dynamic intelligent contract detection method using a stain analysis technique, which takes the input of a function as a stain, and detects integer overflow loopholes by researching the diffusion characteristics of the stain. However, for some logical vulnerabilities, the techniques of spot analysis are difficult to apply.
Fuzzy testing is a dynamic intelligent contract vulnerability detection method that focuses on large-scale testing of contracts by generating a large number of test cases. High time overhead and low path coverage are major problems and are also major concerns for fuzzy test research.
The above methods can be used for intelligent contract detection. However, these detection methods. These rules may be applicable to vulnerabilities with simple logic or obvious keywords, but have limited detection capabilities and high false positive rates when used to detect vulnerabilities with complex logic, particularly cross-contract vulnerabilities. For example, after the mythrel et al detection method analyzes 139,424 smart contracts to detect re-entry vulnerabilities, only 34 contracts are found to exist with re-entry vulnerabilities, but 21,212 re-entry contracts exist in the test report, wherein 21,178 contracts are false positives, i.e., those non-vulnerability contracts are falsely reported as vulnerability contracts. This means that many existing detection methods cannot reliably detect increasingly complex smart contracts that have emerged in recent years.
Disclosure of Invention
The application provides a method, a system and equipment for detecting cross-contract vulnerabilities.
The technical scheme of the application is as follows:
a method for detecting cross-contract vulnerabilities comprises the following operations:
s1, acquiring a function for receiving other address Ethernet coins in an intelligent contract and an objective function, combining the function for receiving other address Ethernet coins with the objective function, assigning the function to a sequence, and obtaining candidate attack order;
s2, combining the candidate attack order with a template contract to obtain an attack contract;
s3, attacking the intelligent contract by using the attack contract;
if the attack is successful, the intelligent contract has cross-contract loopholes;
if the attack is unsuccessful, the intelligent contract does not have cross-contract vulnerabilities.
The detection method as described above, wherein the operation of combining in S1 specifically includes:
and respectively acquiring functions and objective functions of all the received Ethernet coins with other addresses in the intelligent contract to form a receiving function sequence and an objective function sequence, obtaining function pairs after double circulation, assigning the function pairs to the sequences, and obtaining the candidate attack sequences.
The objective function is a function for transferring the Ethernet coin to other addresses;
combining the function of transferring the Ethernet coin to other addresses with the function of receiving the Ethernet coin of other addresses, assigning the function to the sequence, and obtaining a first candidate attack order;
the first candidate attack pair sequentially executes the S2 and the S3,
if the attack is successful, the intelligent contract has a reentrant vulnerability in the cross-contract vulnerabilities;
if the attack is unsuccessful, the intelligent contract does not have a reentrant vulnerability in the cross-contract vulnerabilities.
The attack succeeds in: the balance after attack of the attack contract is larger than the balance before attack;
the attack is unsuccessful: the post-attack balance of the attack contract is not greater than the pre-attack balance.
And after the S2 is executed by the first candidate attack pair sequence, a first attack contract is obtained, ethernet is deployed in the first attack contract, and the S3 operation is continuously executed.
The detection method as described above, wherein the objective function is a function for detecting the presence or absence of a keyword delete detect;
combining the function for detecting whether the keyword delete detect exists with the function for receiving other address Ethernet coins, assigning the function to the sequence, and obtaining a second candidate attack order;
the second candidate attack pair sequentially executes the S2 and the S3,
if the attack is successful, the intelligent contract has a delegated call vulnerability in the cross-contract vulnerabilities;
if the attack is unsuccessful, the intelligent contract does not have a delegated call vulnerability in the cross-contract vulnerabilities.
The attack succeeds in: the second candidate attack order executes the second attack contract obtained by the S2 to have balance;
the attack was unsuccessful: and (2) the second candidate attack order executes the second attack contract obtained by the S2, and the balance does not exist in the second attack contract.
A system for detecting vulnerabilities across contracts, comprising:
the candidate attack matching sequence generation module is used for acquiring a function for receiving the other address Ethernet coins in the intelligent contract and an objective function, combining the function for receiving the other address Ethernet coins with the objective function, assigning the combined function to the sequence, and obtaining the candidate attack matching sequence;
the attack contract generation module is used for combining the candidate attack order with the template contract to obtain an attack contract;
an attack detection module for attacking the intelligent contract using the attack contract; if the attack is successful, the intelligent contract has cross-contract loopholes; if the attack is unsuccessful, the intelligent contract does not have cross-contract vulnerabilities.
A cross-contract vulnerability detection device comprises a processor and a memory, wherein the processor realizes the cross-contract vulnerability detection method when executing a computer program stored in the memory.
A computer readable storage medium for storing a computer program, wherein the computer program when executed by a processor implements a method of cross-contract vulnerability detection as described above.
The application has the beneficial effects that:
the application provides a cross-contract vulnerability detection method, which is characterized in that main information of an intelligent contract is abstracted statically, candidate attack pairs in an attack direction can be appointed, the candidate attack pairs are combined with template contracts with aggressiveness to generate attack contracts, the intelligent contracts are dynamically attacked by the attack contracts, and cross-contract vulnerabilities in the intelligent contracts are detected according to different attack results. Experimental results show that the detection method has high accuracy, comprehensive evaluation rate, 0 false alarm rate and low time cost.
Drawings
The aspects and advantages of the present application will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the application.
In the drawings:
FIG. 1 is a flow chart of a detection method in an embodiment;
FIG. 2 is a block diagram of an overall algorithm of the detection method in the embodiment;
FIG. 3 is a diagram of a re-entry detection algorithm in an embodiment;
FIG. 4 is a schematic diagram of the cause of a failure to transfer to a deployed attack contract in an embodiment;
FIG. 5 is a diagram of a delegated call detection algorithm in an embodiment;
FIG. 6 is a diagram of a re-entry vulnerability detection result of data set 1 according to an embodiment;
FIG. 7 is a diagram of a particular reentrant vulnerability contract algorithm in an embodiment;
FIG. 8 is a diagram of a result of a delegated invocation of vulnerability detection by dataset 1 in an embodiment;
FIG. 9 is a statistical chart of the accuracy and the comprehensive evaluation rate of the four detection methods in the embodiment;
FIG. 10 is a schematic diagram of a detection system according to an embodiment;
fig. 11 is a schematic structural diagram of a detection apparatus in the embodiment.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings.
The embodiment provides a method for detecting cross-contract vulnerabilities, referring to fig. 1, including the following operations:
s1, acquiring a function for receiving other address Ethernet coins in an intelligent contract and an objective function, combining the function for receiving other address Ethernet coins with the objective function, assigning the function to a sequence, and obtaining candidate attack order;
s2, combining the candidate attack order with a template contract to obtain an attack contract;
s3, attacking the intelligent contract by using the attack contract;
if the attack is successful, the intelligent contract has cross-contract loopholes;
if the attack is unsuccessful, the intelligent contract does not have cross-contract vulnerabilities.
The method comprises the following steps:
s1, acquiring a function for receiving the other address Ethernet coins in the intelligent contract and an objective function, combining the function for receiving the other address Ethernet coins with the objective function, assigning the function to the sequence, and obtaining the candidate attack order.
A language model. To better study the information in the solubility (one-door high-level programming language), part of its content is formalized, and the formalized syntax is defined as follows:
c:＝(cname,funs,add,bal) (1)
f:＝(fname,p,s,d,x) (2)
x:＝add·x|uint·x|else·x|null (3)
equation (1) abstracts an intelligent contract c consisting of a contract name cname, a function sequence funs, a deployment address add of the contract, and an intelligent contract balance bal. The former two are built-in attributes of the contract, and the latter two are deployment state attributes. As shown in equation (2), the function in the smart contract consists of a function name fmame, three predicates p, s, and d, and a parameter x. p, s and d are modifiers specific to the solubility, where p checks if f is declared using the keyword payable, s checks if the function sends an ethernet token using the keyword call, and d checks if the function uses the keyword degatecal. In transferring funds, the two most important parameters are the current and address, so the parameters of the function are recursively defined in equation (3), of course, since the form of function definition is varied, other types of parameters are defined as else. Finally, null represents the cut-off of the recursive definition.
For a better description of the content in the smart contract c, the symbols appearing are summarized in Table 1.
TABLE 1 meaning of symbols in Smart contract c
The combined operation is specifically as follows: and respectively acquiring all functions and objective functions of the intelligent contract for receiving other address Ethernet coins to form a receiving function sequence and an objective function sequence, obtaining function pairs after double circulation, assigning the function pairs to the sequences, and obtaining candidate attack sequences.
S2, combining the candidate attack pairs with the template contracts to obtain attack contracts.
The operation of combining in S2 is specifically: and obtaining a template contract with the attack capability, combining the template contract with the candidate attack opposite sequence, and directing the candidate attack opposite sequence to an attack target of the template contract to obtain the attack contract.
Referring to fig. 2, the whole framework of the detection method provided in this embodiment is that the input is a solution intelligent contract c, the output is a report R, and the report shows whether the intelligent contract is a vulnerability contract. The detection method consists of static analysis steps (see lines 1-9 in fig. 2) and dynamic attack phases (see lines 10-12 in fig. 2).
Static analysis stage. To obtain key information about the smart contract, the smart contract is scanned (see line 1 in FIG. 2) and the function f is abstracted from c (see line 2 in FIG. 2). Use fp to determine if a contract can receive an ethernet token (hereafter Ether) through this function, s in f to describe if the function can transfer tokens to other functions. Obtaining a function f for receiving other addresses Ether payable In the form of (True,) and can be combined with f payable An objective function, in the form of (_true ), which combines and is used to limit different types of vulnerability detection conditions, will receive a function f of other addresses Ether payable And the target function is combined, lines 6-7 in fig. 2 enter a two-stage cycle to obtain function pairs, then the function pairs are assigned to a sequence (see line 8 in fig. 2), a candidate attack pair sequence A is obtained, a template contract c 'with an attack function is given, and after the candidate attack pair sequence A is combined with the template contract c', an attack contract c which can attack the intelligent contract is generated (see line 9 in fig. 2).
Dynamic attack stage. And successfully generating attack contracts c through static analysis. Deployment of smart contract c and attack contract c through web3, and on line 10, vulnerability in smart c is detected using attack contract c. Wherein RDA (), reentrancy DetectionAlgorithm, is a reentrant detection algorithm, see fig. 3, for detecting reentrant vulnerabilities in the smart contracts; DDA (), delegatecall Detection Algorithm, is a delegated call detection algorithm, see fig. 5 for specific algorithms for detecting delegated calls in smart contracts. The outcome of the attack r' is then recorded and appended to the report r (see lines 11-12 in fig. 2). Thus, r is a sequence containing all test results of the contract generated by A. All elements in R are checked and a final detection report R of the reentrant vulnerability is obtained (see lines 15-16 in fig. 2).
And evaluating the whole framework. Let m and n denote fun respectively payable And fun call The number of a can be expressed as m x n. Therefore, the detection method generates m×n attack contracts c to attack the smart contract c, and thus the time complexity of the detection method is O (m×n). The detection method can check re-entry loopholes (including simple re-entry, modifier re-entry and fault state lock re-entry) and delegated call loopholes, because the detection method simulates a real re-entry attack, simple re-entryThe difference between the loophole and the bug locked reentrant loophole has no effect on the detection result. As for the modifier re-entry, the detection method only needs to consider the modifier function as a normal function.
S3, attacking the intelligent contract by using the attack contract; if the attack is successful, the intelligent contract has cross-contract loopholes; if the attack is unsuccessful, the intelligent contract does not have cross-contract vulnerabilities.
The above detection method is explained in further detail below in connection with classical reentry loopholes and delegated call loopholes in cross-contract loopholes.
Reentrant vulnerability detection. In order to detect reentrant vulnerabilities in intelligent contracts, the objective function is a function of transferring Ether to other addresses; combining the function of transferring the Ether to other addresses with the function of receiving the other addresses, assigning the function to the sequence, and obtaining a first candidate attack order; s2 and S3 are sequentially executed by the first candidate attack pair, and if the attack is successful, the intelligent contract has a reentrant vulnerability in the cross-contract vulnerability; if the attack is unsuccessful, the intelligent contract does not have a reentrant vulnerability in the cross-contract vulnerabilities. The attack succeeds in: the balance after attack of the attack contract is larger than the balance before attack; the attack was unsuccessful: the post-attack balance of the attack contract is not greater than the pre-attack balance. And after the first candidate attack is executed for the sequence S2, a first attack contract is obtained, the Ethernet is deployed in the first attack contract, and the operation of the S3 is continuously executed. The specific contents are as follows.
And (5) static analysis. Obtaining function f of receiving other address Ether in intelligent contract payable In the form of (_true ), and a function f that transfers Ether to other addresses call In the form of (_true ), although reentrant holes appear only at f call But f is call Provided that f is the same as payable Related to each other. Therefore, it is necessary to combine f payable And f call In order to enumerate all possible scenarios that can be re-entered. Collect all f payable Arrange it into a payable function sequence fun payable And collect all f call To generate a call function sequence fun call (see lines 3-4 in figure 2),fun is to payable And fun call After performing a two-stage cycle (see lines 6-7 in fig. 2), assigning the two-stage cycle to the sequence to obtain a first candidate attack pair sequence a (see line 8 in fig. 2), giving a template contract c 'with an attack function, and combining the first candidate attack pair sequence a with the template contract c' to generate a first attack contract c which can attack the intelligent contract.
Dynamic attacks. Successfully generating a first attack contract c through static analysis, deploying a smart contract c' and the first attack contract c through web3, and detecting a vulnerability in the smart contract using the first attack contract c (see RDA (). Connected to an ethernet test network to dynamically detect a re-entry vulnerability in the smart contract c (see line 1 in fig. 3), then creating a transaction to deploy the smart contract c (see line 2 in fig. 3), whereby an initialization state of the smart contract c is (, 0). As shown in fig. 4, the first attack contract c cannot be deployed first, and then Ether is moved to the first attack contract c because, upon execution of the transaction due to the transfer operation, a fallback function of the first attack contract c is non-null and points to f in the smart contract call . However, f call The assertion in (a) prevents the transaction and throws the exception, which will result in rollback of the entire transaction. Thus, when deploying the first attack contract c (see line 3 in fig. 3), ethernet must be carried along in the transaction into the first attack contract c in fig. 3, so the first attack contract c is initialized to (_, _n). To ensure a normal attack of reentry, 2*n ethers are transmitted into the smart contract c (see line 4 in fig. 3). Too many ethers may cause the transaction to rollback due to gas exhaustion in a re-entry attack, but too few ethers may fail to detect the re-entry attack due to insufficient funds in the contract. After this, the first attack contract c is created by calling f in the smart contract c payable Ether is transferred to c (see line 5 of FIG. 3), so that the local variable in the smart contract c will record the information of the first attack contract c, avoiding f in the smart contract c call Failure to assert results in a transaction rollback. At this time, smart contract cThe state of (a, 3*n), the first attack contract c becomes (_0). Finally, a transaction is created, line 6 in fig. 3 attacking smart contract c from first attack contract c. In lines 7 to 11, the attack results of the reentrant attack are analyzed. If the balance of the attack contract is larger than the balance before attack after the first attack contract c attacks the intelligent contract c, the reentrant vulnerability exists in the intelligent contract; if the balance of the attack contract is not greater than the balance before the attack after the attack is completed, no reentrant vulnerability exists in the intelligent contract.
Theoretically, the method can accurately detect re-entry vulnerabilities in smart contracts because it mimics the process of hacking victim contracts. In other words, a flawless contract cannot be mistaken as a flawless contract because a flawless contract is unlikely to be successfully attacked.
Entrust call vulnerability detection. In order to detect the entrusted call vulnerability in the intelligent contract, the objective function is a function for detecting whether a keyword delete exists or not; combining a function for detecting whether the keyword delete detect exists with a function for receiving other addresses Ether, assigning the function to the sequence, and obtaining a second candidate attack order; s2 and S3 are sequentially executed by the second candidate attack pair, and if the attack is successful, the intelligent contract has a delegated call vulnerability in the cross-contract vulnerability; if the attack is unsuccessful, the intelligent contract does not have a delegated call vulnerability in the cross-contract vulnerabilities. The attack succeeds in: the balance exists in a second attack contract obtained by executing S2 on the sequence of the second candidate attack; the attack was unsuccessful: the balance does not exist in the second attack contract obtained by the second candidate attack pair sequence execution S2. The specific contents are as follows.
Delegated call loopholes are an abnormally high risk loopholes. To detect the delegated call vulnerability, a variable d is introduced to indicate whether the key delete detect exists in the function. Equations (4) and (5) are the main functional forms that contain the delegation-holes. Equation (4) is a class of delegated call functions that does not contain the target contract address, meaning that the information of the target contract is already fixed in the contract. In this case, due to the certainty of the target contract, whether the delegated call vulnerability exists depends on whether the target contract is secure. In fact, the keyword delegatechill should only be used when the contract developer considers the target contract to be absolutely safe. In addition, the presence of vulnerabilities does not always mean that they may be exploited by hackers. Thus, there is no delegated invocation vulnerability in this case. Equation (5) is another delegated call function with an unknown target contract. In other words, the information of the target contract is transferred into the function in the form of function parameters. In this case, the hacker can do anything he wants, as long as the function is successfully called with the key delete. If a hacker attacks smart c using a contract containing self-destructing functionality, this will cause smart contract c to suicide and steal all ethers in smart contract c.
Type1:f dcall ＝f(f name ,p,s,d,else·x) (4)
Type2:f dcall ＝f(f name ,p,s,d,add·else·x) (5)
And (5) static analysis. The overall flow of static analysis and the static analysis process of reentrant vulnerability detection are described herein simply to detect the function f of keyword delete detect existence for the sake of space dcall In the form of (, true,), and f dcall Generating a call function sequence fun dcall F in the reentrant vulnerability detection is replaced respectively call And fun call A second attack contract c is ultimately generated.
Dynamic attacks. Through static analysis, a second attack contract c is successfully generated, an intelligent contract c' and the second attack contract c are deployed through the web3, and a vulnerability in the intelligent contract is detected by using the second attack contract c (see DDA ()) in line 10 in fig. 2). First connect to ethernet test network and deploy smart contract c and second attack contract c (see lines 1-2 in fig. 5). N ethers are then transferred from the default account (see line 3 in fig. 5) and the smart contract c is self-destructed using a second attack contract c (see line 4 in fig. 5). If the smart contract c is successfully self-destructed, all Ethers in the smart contract c will migrate to the second attack contract c. Therefore, checking the balance in the second attack contract c, if the balance exists in the second attack contract c, the attack is successful, and the entrusted call vulnerability exists in the intelligent contract c; if there is no balance in the second attack contract c, the attack fails, no delegated call vulnerability is present in the smart contract c (see lines 5-9 of fig. 5), and the results are reported (see line 10 of fig. 5). Essentially, the delegated call detection algorithm is a typical delegated call vulnerability shown in equation (5). The framework simulates the delegated call attack and can accurately detect delegated call loopholes. Although the previous reentry detection framework has been extended to detect delegated call vulnerabilities, the temporal complexity is still O (m x n).
In order to verify the reliability of the detection method provided in this embodiment, a related experiment was performed on the detection method. Including results of the experiments and Research Questions (RQ) listed below.
RQ1: can the detection method provided in this embodiment accurately distinguish between what is seemingly vulnerable and truly vulnerable contracts?
RQ2: is the detection method provided in this embodiment able to correctly detect real world vulnerability contracts?
RQ3: is the detection method provided in this embodiment more time-saving than other intelligent contract detection methods?
RQ4: is the detection method provided by the present embodiment to support detecting the latest version of the smart contract?
Experimental setup. All experiments were performed on a PC running Ubuntu 22.04, which was equipped with an Intel i54 core CPU and 8GB memory. Victim contracts and attack contracts were deployed using web3.py 5.30.0, and private blockchains were built using ganche. The experimental environment is shown in table 2.
TABLE 2 environmental configuration of experiments
Data set of experiment. To evaluate the performance of the detection method provided in this example, two data sets were used for testing, see tables 3 and 4 for data set details.
Table 3 data set 1
Table 4 dataset 2
The first data set consists of 25 contracts with reentrant vulnerabilities, 25 contracts that appear to have reentrant vulnerabilities but are secure, 5 contracts with degluttecall vulnerabilities, and 5 flawless contracts with keywords degtecall.
The second dataset was 2177 random real smart contracts from ethernet, which have been validated. These contracts are reliable, authoritative, and understandable. In dataset 2, only 7 contracts exist with reentrant vulnerabilities, and no contracts exist with delegated invocation vulnerabilities.
From the data set 2, it can be observed that both reentrant and delegated invocation vulnerabilities occur very low in real-world smart contracts, but both are very dangerous when present. Thus, from Smartbugs, etc., the collected data set 1 can better estimate the accuracy of the smart contract detection method. The contracts in data set 2 are all real contracts from ethernet, so data set 2 is used to evaluate the correctness of the intelligent contract checking method in checking real contracts.
Index of experiment. Four indicators are used to compare the performance of different smart contract detection methods. In the experiment, four measurements were collected, true Positive (TP), true Negative (TN), false Positive (FP) and False Negative (FN). The number of vulnerability contracts that the detection method can correctly detect is denoted by TP. The number of flawless contracts that the detection method can correctly detect is denoted by TN. FP is the number of security contracts that are falsely judged as being a security contract by the detection method, and FN is the number of security contracts that are falsely judged as being a security contract. Based on these measurements, four metrics can be calculated to evaluate the effectiveness of the detection method:
equation (6) defines ACC, which measures the correctness of the result. The FPR in equation (7) represents the accuracy of the detection method to detect fragile (vulnerability) contracts, while the FNR in equation (8) represents the probability of falsely detecting security contracts as vulnerability contracts. Considering the imbalance of the data in data set 2, it is important to evaluate the experimental results by F1. The corresponding detection method is better when F1 is higher and FPR and FNR are lower.
Accuracy. Since oynte cannot detect the delegated call vulnerability, the first dataset is split into two parts. Some are used for reentrant vulnerability detection as shown in fig. 6. The other part is used for delegatechill vulnerability detection, as shown in fig. 7.
Reentrant vulnerability detection results: as can be seen from fig. 7, the detection method provided by the present embodiment detects only 1 FN and 0 FP in 50 contracts, which is much less than other detection methods. Although both oynte and Mythril are symbolic execution detection methods, mythril performs slightly better than oynte. Smartcheck FP is 25, meaning that Smartcheck cannot distinguish between reentrant and camouflaged reentrant contracts.
Smartcheck detects the intelligent contract's Solidity source code. The rules defined in Smartcheck mean that whenever a key call appears in the stability source code, there is a reentrant hole. Obviously, this determination is too coarse, since the occurrence of a key call only means an external call operation, not necessarily a reentrant vulnerability. Some reentry protection measures may proliferate the FP of Smartcheck. The oynte and mythrel detect bytecodes of smart contracts that detect reentrant vulnerabilities by two criteria:
gas_limit >2300 for call opcode
2. It is possible to re-execute the call command on the stack.
The reason behind the first criterion is that if gas limit is less than 2300, no reentry will occur, as 2300gas can only withstand one ethernet transfer. The second criterion is ambiguous, which is why a security contract with a state lock may be mistaken for a vulnerability contract. Unlike other detection methods, the detection method provided in this embodiment actually attacks the original contract by deploying a contract, so as to identify the reentrant vulnerability, and make FP of the reentrant vulnerability be 0.
Because of the complexity and diversity of contract reentry holes, the detection method provided in this embodiment inevitably has one FN. FIG. 7 shows a special contract with reentrant holes whose reentrant conditions are time dependent. On line 10, the use of keywords now defines a time criterion. This standard restricts transfer at a specific time, preventing attack by the detection method provided in the present embodiment, resulting in one FN.
Entrustly calling the vulnerability detection result. As shown in fig. 8, the detection method provided in this embodiment obtains 2 FNs and 0 FPs by detecting a degatetech vulnerability, and all other detection methods obtain 5 FPs and 0 FNs. This is because the detection method provided by the present embodiment only checks for one instance of delegated invocation vulnerability, i.e., information about the target contract must be entered as a function variable rather than as a local variable in the victim contract. Whether a contract containing a keyword of degatecal has a vulnerability depends on whether the target contract is secure. Thus, analyzing only the victim contract does not directly determine its security. However, mythrel and Smartcheck consider the contract with the keyword degatecal to be a vulnerability contract, which results in 5FP in the experimental results.
Comprehensive analysis of experiment one. Table 5 is a summary for experiment one on dataset 1. In the first experiment, the FPR of the detection method provided in this embodiment is 0, which means that the detection method provided in this embodiment can completely distinguish between a vulnerability contract and a security contract that appears to be vulnerable. Mythril can distinguish a partial vulnerability contract from a security contract that looks like a vulnerability, but Smartcheck cannot distinguish it at all. When FNR was analyzed, it was found that all three detection methods had false negatives and that FNR was very low. Therefore, this embodiment with FPR of 0 is superior to other detection methods in the case of similar FNR approaches.
Table 5 experimental results based on dataset 1
Correctness. This section answers RQ2 with the experiment on dataset 2. In order to verify the correctness of the detection method provided by the present embodiment, 2177 real world contracts were analyzed, and ACC and F1 were compared with other detection methods.
Table 6 experimental results based on dataset 2
The results of dataset 2 are shown in table 6, and fig. 6 shows the calculation of ACC and F1 for these four detection methods from table 6. In table 6, it can be seen that the highest TN is achieved by the detection method provided by the present embodiment. The oynte behaves like mythrel, which has only 5 FPs in 2177 contracts. Of the four methods, sarmtcheck has the highest FP. When analyzing the ACCs of these four detection methods, it was found that the ACCs of these detection methods were all very high. The lowest Smartcheck is 99.993%. This means that all four detection methods have the ability to detect vulnerabilities in real world contracts. However, the ACC differences between the four detection methods are very small, F1 being better than ACC when facing an unbalanced dataset. Smartcheck has an F1 of only 0.3. Both oynte and Mythil are below 0.8. The detection method provided in this embodiment has an F1 exceeding 0.9, so that it is enough to be trustworthy to use the detection method provided in this embodiment to detect a real contract on an ethernet.
High efficiency. In this section, dataset 2 was used to further evaluate the detection method provided by this embodiment and answer RQ3. The time taken to detect 2177 real smart contracts using various detection methods was measured and their efficiency was evaluated.
Table 7 time overhead for four detection methods
The time used for each assay is shown in table 7. The oynte analysis dataset 2 required more than 16 hours, with an average detection time of 27.63 seconds for a single contract. Mythrel has the highest detection time consumption, with total time exceeding 20 hours, and an average detection time of 34.06 seconds for a single contract. Both oynte and mythori are popular symbol execution detection methods. Because symbol execution requires high path coverage to ensure reliability, time consumption is highest. Smartcheck's speed is the fastest of the four, but it sacrifices accuracy. The detection method provided in this embodiment checks that the average time of one contract is 0.38 seconds, the longest is 71.30 seconds, and the shortest is 0.10 seconds. For the entire dataset 2, the detection method provided in this example was only 823.21s, slower than Smartcheck, but faster than oynte and Mythorl. Therefore, the detection method provided by the embodiment is more efficient than other detection methods while maintaining high accuracy.
Flexibility. This section answers the question RQ4 and demonstrates the flexibility of this embodiment to cope with the update of the resolution version.
TABLE 8 degree of support for the latest version
Frequent updates of smart contract versions can result in significant differences in compilation results when different versions of compilers are used. In particular, a new version using a resolution compiler may be incompatible with an old contract, resulting in a compilation failure. Therefore, the impact of contract version upgrades on the detection method is an unavoidable issue.
As shown in table 8, oynte does not support the latest version of contracts, but the detection method provided by the present embodiment supports. The detection method provided by the present embodiment depends on the result of the compiler, so a compiler matching the contract version is the only requirement. Theoretically, the detection method provided by the present embodiment can detect contracts as long as it is properly compiled. Therefore, the detection method provided by the embodiment can adapt to the rapid update of the resolution version.
The embodiment provides a system for detecting cross-contract vulnerabilities, which comprises:
the candidate attack order generation module is used for acquiring a function for receiving the other address Ethernet coins in the intelligent contract and an objective function, combining the function for receiving the other address Ethernet coins with the objective function, assigning the combined function to the sequence, and obtaining the candidate attack order;
the attack contract generation module is used for combining the candidate attack order with the template contract to obtain an attack contract;
an attack detection module for attacking the intelligent contract using the attack contract; if the attack is successful, the intelligent contract has cross-contract loopholes; if the attack is unsuccessful, the intelligent contract does not have cross-contract vulnerabilities.
The embodiment provides a device for detecting cross-contract vulnerabilities, which comprises a processor and a memory, wherein the processor realizes the method for detecting cross-contract vulnerabilities when executing a computer program stored in the memory.
The present embodiment provides a computer readable storage medium for storing a computer program, where the computer program when executed by a processor implements a method for detecting a cross-contract vulnerability as described above.
The embodiment provides a cross-contract vulnerability detection method, which is characterized in that main information of an intelligent contract is abstracted statically, candidate attack pairs capable of specifying attack directions are obtained, the candidate attack pairs are combined with template contracts with aggressiveness to generate attack contracts, the intelligent contracts are dynamically attacked by the attack contracts, cross-contract vulnerabilities in the intelligent contracts are detected according to different attack results, and whether the reentrant vulnerabilities or entrusted calling vulnerabilities exist in the intelligent contracts can be effectively detected by the detection method. Experimental results show that the detection method has high accuracy, comprehensive evaluation rate, 0 false alarm rate and low time cost.
Claims (10)
1. The method for detecting the cross-contract loopholes is characterized by comprising the following operations:
s1, acquiring a function for receiving other address Ethernet coins in an intelligent contract and an objective function, combining the function for receiving other address Ethernet coins with the objective function, assigning the function to a sequence, and obtaining candidate attack order;
s2, combining the candidate attack order with a template contract to obtain an attack contract;
s3, attacking the intelligent contract by using the attack contract;
if the attack is successful, the intelligent contract has cross-contract loopholes;
if the attack is unsuccessful, the intelligent contract does not have cross-contract vulnerabilities.
2. The method according to claim 1, wherein the operation of combining in S1 is specifically:
and respectively acquiring functions and objective functions of all the received Ethernet coins with other addresses in the intelligent contract to form a receiving function sequence and an objective function sequence, obtaining function pairs after double circulation, assigning the function pairs to the sequences, and obtaining the candidate attack sequences.
3. The detection method according to claim 1 or 2, wherein the objective function is a function of transferring ethernet coin to other addresses;
combining the function of transferring the Ethernet coin to other addresses with the function of receiving the Ethernet coin of other addresses, assigning the function to the sequence, and obtaining a first candidate attack order;
the first candidate attack pair sequentially executes the S2 and the S3,
if the attack is successful, the intelligent contract has a reentrant vulnerability in the cross-contract vulnerabilities;
if the attack is unsuccessful, the intelligent contract does not have a reentrant vulnerability in the cross-contract vulnerabilities.
4. The method according to claim 3, wherein,
the attack succeeds in: the balance after attack of the attack contract is larger than the balance before attack;
the attack is unsuccessful: the post-attack balance of the attack contract is not greater than the pre-attack balance.
5. The method according to claim 3, wherein after the first candidate attack pair sequence executes the step S2, a first attack contract is obtained, an ethernet token is deployed in the first attack contract, and the step S3 is continued to be executed.
6. The detection method according to claim 1 or 2, wherein the objective function is a function of detecting the presence or absence of a keyword delegatechill;
combining the function for detecting whether the keyword delete detect exists with the function for receiving other address Ethernet coins, assigning the function to the sequence, and obtaining a second candidate attack order;
the second candidate attack pair sequentially executes the S2 and the S3,
if the attack is successful, the intelligent contract has a delegated call vulnerability in the cross-contract vulnerabilities;
if the attack is unsuccessful, the intelligent contract does not have a delegated call vulnerability in the cross-contract vulnerabilities.
7. The method according to claim 6, wherein,
the attack succeeds in: the second candidate attack order executes the second attack contract obtained by the S2 to have balance;
the attack was unsuccessful: and (2) the second candidate attack order executes the second attack contract obtained by the S2, and the balance does not exist in the second attack contract.
8. A system for detecting a cross-contract vulnerability, comprising:
the candidate attack matching sequence generation module is used for acquiring a function for receiving the other address Ethernet coins in the intelligent contract and an objective function, combining the function for receiving the other address Ethernet coins with the objective function, assigning the combined function to the sequence, and obtaining the candidate attack matching sequence;
the attack contract generation module is used for combining the candidate attack order with the template contract to obtain an attack contract;
an attack detection module for attacking the intelligent contract using the attack contract; if the attack is successful, the intelligent contract has cross-contract loopholes; if the attack is unsuccessful, the intelligent contract does not have cross-contract vulnerabilities.
9. A cross-contract vulnerability detection apparatus, comprising a processor and a memory, wherein the processor implements the cross-contract vulnerability detection method of any one of claims 1-7 when executing a computer program stored in the memory.
10. A computer readable storage medium for storing a computer program, wherein the computer program when executed by a processor implements a method of cross-contract vulnerability detection as claimed in any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310627115.2A CN116663012B (en) | 2023-05-31 | 2023-05-31 | Cross-contract vulnerability detection method, system and equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310627115.2A CN116663012B (en) | 2023-05-31 | 2023-05-31 | Cross-contract vulnerability detection method, system and equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116663012A true CN116663012A (en) | 2023-08-29 |
| CN116663012B CN116663012B (en) | 2023-11-03 |
Family
ID=87716585
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310627115.2A Active CN116663012B (en) | 2023-05-31 | 2023-05-31 | Cross-contract vulnerability detection method, system and equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116663012B (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109800175A (en) * | 2019-02-20 | 2019-05-24 | 河海大学 | A kind of ether mill intelligence contract reentry leak detection method based on code pitching pile |
| CN109948345A (en) * | 2019-03-20 | 2019-06-28 | 杭州拜思科技有限公司 | A kind of method, the system of intelligence contract Hole Detection |
| CN111177730A (en) * | 2019-12-19 | 2020-05-19 | 河海大学 | Method and device for detecting and preventing problems of intelligent contracts of Etheng |
| CN111787017A (en) * | 2020-07-02 | 2020-10-16 | 电子科技大学 | Block chain attack tracing system and method |
| US20220101326A1 (en) * | 2019-01-18 | 2022-03-31 | Uppsala Pte. Ltd. | Apparatus and method for cybersecurity |
| CN115017515A (en) * | 2022-06-01 | 2022-09-06 | 电子科技大学 | Cross-contract reentry attack detection method and system |
| CN115098863A (en) * | 2022-06-08 | 2022-09-23 | 成都安恒信息技术有限公司 | Intelligent contract reentry vulnerability detection method based on static and dynamic analysis |
| CN115442380A (en) * | 2022-09-14 | 2022-12-06 | 杭州安碣信息安全科技有限公司 | Transaction blocking method and device for intelligent contract vulnerability attack |
-
2023
- 2023-05-31 CN CN202310627115.2A patent/CN116663012B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20220101326A1 (en) * | 2019-01-18 | 2022-03-31 | Uppsala Pte. Ltd. | Apparatus and method for cybersecurity |
| CN109800175A (en) * | 2019-02-20 | 2019-05-24 | 河海大学 | A kind of ether mill intelligence contract reentry leak detection method based on code pitching pile |
| CN109948345A (en) * | 2019-03-20 | 2019-06-28 | 杭州拜思科技有限公司 | A kind of method, the system of intelligence contract Hole Detection |
| CN111177730A (en) * | 2019-12-19 | 2020-05-19 | 河海大学 | Method and device for detecting and preventing problems of intelligent contracts of Etheng |
| CN111787017A (en) * | 2020-07-02 | 2020-10-16 | 电子科技大学 | Block chain attack tracing system and method |
| CN115017515A (en) * | 2022-06-01 | 2022-09-06 | 电子科技大学 | Cross-contract reentry attack detection method and system |
| CN115098863A (en) * | 2022-06-08 | 2022-09-23 | 成都安恒信息技术有限公司 | Intelligent contract reentry vulnerability detection method based on static and dynamic analysis |
| CN115442380A (en) * | 2022-09-14 | 2022-12-06 | 杭州安碣信息安全科技有限公司 | Transaction blocking method and device for intelligent contract vulnerability attack |
Non-Patent Citations (9)
| Title |
|---|
| GIUSEPPE DESTEFANIS等: "Smart contracts vulnerabilities: a call for blockchain software engineering?", 《2018 INTERNATIONAL WORKSHOP ON BLOCKCHAIN ORIENTED SOFTWARE ENGINEERING (IWBOSE)》, pages 19 - 25 * |
| MAX_XBW: "智能合约的常见漏洞", Retrieved from the Internet <URL:https://www.cnblogs.com/XBWer/p/9697361.html> * |
| XIANGFU ZHAO等: "The DAO attack paradoxes in propositional logic", 《2017 4TH INTERNATIONAL CONFERENCE ON SYSTEMS AND INFORMATICS (ICSAI)》, pages 1743 - 1746 * |
| 周镇等: "基于节点贡献值和信誉度的DPoS共识算法改进", 《烟台大学学报(自然科学与工程版)》, pages 1 - 16 * |
| 张星娜: "基于深度学习的智能合约漏洞检测与分析方法研究", 《中国优秀硕士学位论文全文数据库》, pages 138 - 26 * |
| 李永强等: "基于区块链的车联网安全信息共享机制设计", 《郑州大学学报(工学版)》, vol. 43, no. 1, pages 103 - 110 * |
| 赵伟等: "基于符号执行的智能合约漏洞检测方案", 《计算机应用》, vol. 40, no. 04, pages 947 - 953 * |
| 郑忠斌等: "智能合约的安全研究现状与检测方法分析综述", 《信息安全与通信保密》, no. 07, pages 93 - 105 * |
| 陈霄汉等: "SlightDetection：一种以太坊智能合约安全漏洞的静态分析工具", 《应用科学学报》, vol. 40, no. 4, pages 695 - 712 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116663012B (en) | 2023-11-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Chen et al. | SODA: A Generic Online Detection Framework for Smart Contracts. | |
| Samreen et al. | Reentrancy vulnerability identification in ethereum smart contracts | |
| Chen et al. | Defectchecker: Automated smart contract defect detection by analyzing evm bytecode | |
| US11922149B2 (en) | Method for controlling the flow execution of a generated script of a blockchain transaction | |
| Yu et al. | Deescvhunter: A deep learning-based framework for smart contract vulnerability detection | |
| Xu et al. | A novel machine learning-based analysis model for smart contract vulnerability | |
| Lee et al. | Design and implementation of the secure compiler and virtual machine for developing secure IoT services | |
| CN109948338B (en) | Android application sensitive path triggering method based on static analysis | |
| CN115098863A (en) | Intelligent contract reentry vulnerability detection method based on static and dynamic analysis | |
| Lin et al. | Graph-based seed object synthesis for search-based unit testing | |
| Xu et al. | A survey on vulnerability detection tools of smart contract bytecode | |
| CN113609489B (en) | Distributed detection method for intelligent contract conflict in industrial block chain | |
| CN116663012B (en) | Cross-contract vulnerability detection method, system and equipment | |
| Li et al. | Eosioanalyzer: An effective static analysis vulnerability detection framework for eosio smart contracts | |
| US20230141948A1 (en) | Analysis and Testing of Embedded Code | |
| Xing et al. | The devil is in the detail: Generating system call whitelist for Linux seccomp | |
| Huang | An empirical study on real bug fixes in smart contracts projects | |
| Zhou et al. | WASMOD: Detecting vulnerabilities in Wasm smart contracts | |
| Xiang et al. | Ghost in the binder: Binder transaction redirection attacks in Android system services | |
| CN113779589A (en) | Android smart phone application misconfiguration detection method | |
| Meng et al. | Wemint: Tainting Sensitive Data Leaks in WeChat Mini-Programs | |
| Qin et al. | Automatically refining partial specifications for heap-manipulating programs | |
| Bhardwaj et al. | Fuzz testing in stack-based buffer overflow | |
| Ru et al. | The side-channel vulnerability in network protocol | |
| Letychevskyi | Algebraic methods for detection of vulnerabilities in software systems |
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 |