CN115017515A - Cross-contract reentry attack detection method and system - Google Patents
Cross-contract reentry attack detection method and system Download PDFInfo
- Publication number
- CN115017515A CN115017515A CN202210618214.XA CN202210618214A CN115017515A CN 115017515 A CN115017515 A CN 115017515A CN 202210618214 A CN202210618214 A CN 202210618214A CN 115017515 A CN115017515 A CN 115017515A
- Authority
- CN
- China
- Prior art keywords
- contract
- cross
- call graph
- function
- path
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
Abstract
The invention provides a method and a system for detecting cross-contract reentry attacks for a block chain intelligent contract, which aims to solve the problem that vulnerabilities are utilized due to the fact that intelligent contract codes are not rigorous, and the main scheme of the method comprises a contract processing module: analyzing the intelligent contract source code to construct a cross-contract call graph of the contract to be detected; a static analysis module: performing static taint analysis on the generated cross contract call graph to obtain a suspicious taint path; a path confirmation module: and (4) based on rules of pre-payment verification, payment address hard coding, transaction lock protection and the like, examining suspicious paths and finally outputting a re-entry vulnerability path detection result.
Description
Technical Field
The invention belongs to the field of block chain security, and provides a cross-contract reentry attack detection method and a cross-contract reentry attack detection system.
Background
As one of the most fierce technologies at present, the block chain is being adopted in the aspects of financial services and the like, and the transparency, traceability, non-tamper property and verifiability of the block chain are valuable in the aspects of multi-party business cooperation, such as supply chain management. Smart contracts are special protocols aimed at providing, validating and executing contracts that allow us to execute traceable, irreversible and secure transactions without the need for third parties. The smart contract contains all information about the transaction and only after the requirements are met will the resulting operation be performed. But due to the relative immaturity of blockchain technology and the advent of large numbers of rogue smart contracts, when a smart contract calls or utilizes the code of other external contracts, these external calls may be hijacked by an attacker, forcing the contracts to execute more code. An attacker can carefully build a contract at an external address that contains malicious code in the rollback function. So when a contract sends data to this address, malicious code will be activated. Often malicious code executes a function on a vulnerable contract, an operation that is not expected by the developer. The hacker in The notorious Dao incident utilized this attack, eventually resulting in a hard fork in The ether house.
There are some existing precautions against reentry attacks, i.e. programmers need to be more careful when writing and making constraints. The first method is to use a built-in transfer () function when sending the etherhouse to an external contract, which is not enough for the destination address contract to call another contract, since the function only forwards 2300Gas to the external call. The second technique is to ensure that all logic that changes state variables occurs before the ethernet currency is sent out of the contract or any external calls. Preferably, an external call to an unknown address will be the last operation of the local function or code. This is called check-effect-interaction mode in the etherhouse document. Another way is to introduce a mutex lock, i.e. add a state variable, to lock the contract during code execution, preventing calls from being re-entered.
The function call relational graph is usually a directed acyclic graph, analysis aiming at the call graph can be divided into static analysis and dynamic analysis, the static analysis refers to analysis under the premise of not running a program to be analyzed, and the analysis is usually source codes of a target or binary files; the dynamic analysis means recording the function calling condition when the program actually runs. The quality of the call graph resulting from analyzing the source code is generally related to the level of understanding of the programming language by the analysis tool. The analysis of the target binary file is typically performed by disassembling the file and then analyzing the resulting text file. The dynamic analysis is to record the calling of the function when the program runs and then to arrange and generate a call graph. Compared with static analysis, the method can obtain more information, such as the sequence and the times of function calling; however, there is a disadvantage in that some branches of statements in a program may not be executed, and the functions called in these branches cannot be recorded naturally.
Taint analysis can be abstracted to the form of a triplet < sources, sinks, sanizers >. The source is a pollution source and represents directly introducing untrusted data or confidential data into the system; sink, i.e. taint point of convergence, represents directly generating security sensitive operations (violating data integrity) or revealing private data to the outside (violating data confidentiality); sanizer is harmless processing, which means that data transmission does not harm information security of a software system any more by means of data encryption or harm removal operation, and taint analysis is to analyze whether data introduced from taint sources in a program can be directly transmitted to taint gathering points without harmless processing. If not, the system is indicated to be information flow safe; otherwise, the system generates security problems such as private data leakage or dangerous data operation.
Taint analysis techniques are also classified into static analysis techniques and dynamic analysis techniques. Static taint propagation analysis (static taint analysis for short) refers to detecting whether data can be propagated from taint sources to taint collection points or not by analyzing data dependency relations among program variables under the premise of not running and not modifying codes. The object of static taint analysis is generally the source code or intermediate representation of the program, and can convert the static analysis problem of explicit flow in taint propagation into the analysis of the dependence of static data in the program. Firstly, constructing a call graph according to a function call relation in a program; then, specific data stream propagation analysis is performed within or between functions according to different program characteristics. Common explicit stream taint propagation approaches include direct assignment propagation, propagation through function (procedure) calls, and propagation through aliases (pointers). The dynamic taint propagation analysis (dynamic taint analysis for short) is to detect whether data can be propagated from a taint source to a taint gathering point or not by monitoring the propagation of taint data of a program in a system program in real time in the program running process, the dynamic taint propagation analysis firstly needs to extend a taint mark label for the taint data and store the taint mark label in a storage unit (a memory, a register, a cache and the like), then a corresponding propagation logic propagation taint mark is designed according to an instruction type and an instruction operand, and the dynamic taint propagation analysis is divided into 3 types of taint propagation analysis based on hardware, software and a mixed type according to an implementation level.
Disclosure of Invention
The invention discloses a detection means for block chain cross contract call reentry attack based on static taint analysis. The smart contract reentry vulnerability, one of the most serious vulnerabilities of the current blockchain platform, often causes huge property loss. However, in a general reentrant attack detection tool, detection involving multiple contracts may result in a steep increase in the false alarm rate. There is therefore a need to investigate reentrant vulnerability detection schemes across contracts. The detection means of the invention solves the detection gap of the cross-contract reentry vulnerability in the current block chain platform intelligent contract, and can accurately and quickly detect the possible risks in the multi-contract calling so as to ensure the safety of each property of the user.
In order to solve the problems, the invention adopts the following technical scheme:
a cross-contract reentry attack detection system comprising the following modules:
a contract processing module: inputting a contract to be detected, analyzing a source code of the intelligent contract, and generating a cross-contract function call graph of the intelligent contract;
a static analysis module: processing the cross contract function call graph, and performing static taint analysis on the generated cross contract function call graph to obtain a suspicious taint path;
a path confirmation module: and comprehensively examining suspicious paths based on verification before payment, hard coding of payment addresses, lock protection execution, protection of self-defined modifiers and internal updating rules before transaction, and finally outputting a re-entry attack path detection result.
In the above technical solution, the input of the contract processing module is an intelligent contract written by Solidity, and all calls from an external function are collected, which specifically includes the following steps:
step 2.1, constructing a cross-contract call graph through a Solidity program, and generating a directed cross-contract call graph, wherein nodes of the cross-contract call graph are Solidity functions, and directed edges represent call relations;
step 2.2, adding a fallback function and an edge represented by a self-defined modifier to obtain a more accurate cross-contract call graph;
step 2.3, generating a contract internal function call graph after the function of an abstract syntax analyzer for each function in the cross-contract call graph;
and 2.4, combining the cross contract call graph obtained in the step 2.2 with the contract internal function call graph obtained in the step 2.3 to obtain a final needed cross contract function call graph, and obtaining a call chain according to the cross contract function call graph.
In the above technical solution, the static analysis module performs static taint analysis on the cross-contract function call graph, and the analysis aims at all call relations starting from a suspicious contract address and ending with external function call in the cross-contract function call graph, and in the cross-contract function call graph, if a path satisfies any one of the following conditions, the path is considered as a vulnerable path suffering from reentry attack:
(1) the contract object calls any public method thereof;
(2) the address variable calls any low-level function. 4. A cross-contract reentry attack detection system according to claim 3, characterized in that: the step 3 specifically comprises the following steps:
step 3.1, the fragile path means that the external input parameters can be read and eventually point to an insecure function that depends on the external input parameters. The module aims to obtain all key vulnerable paths which can cause reentry attacks in the cross contract function call graph, and some characteristics unique to the identity need to be considered for the key vulnerable paths.
And 3.2, enabling the taint source to comprise parameters of a public function and tx. Origin refers to the original external address from which the entire transaction was initiated, and msg. Assignment operation of data and return function can cause the propagation of taint data, and address binding operation in the identity program can cause the propagation of taint data.
Step 3.3, in the cross-contract function call graph, if a path meets any one of the following conditions, the path is considered as a vulnerable path which is possibly subjected to reentrant attack: (1) the contract object calls any of its public methods because it is likely that the method contains a fallback () function; (2) the address variable calls any low-level function.
In the technical scheme, the path confirmation module judges the suspicious path together based on the access control technology before payment, the payment address hard coding, the self-defined modifier protection, the execution lock protection and the internal upgrading technology before payment.
The invention also provides a cross-contract reentry attack detection method, which comprises the following steps:
contract processing steps: inputting a contract to be detected, analyzing a source code of the intelligent contract, and generating a cross-contract function call graph of the intelligent contract;
a static analysis step: processing the cross contract function call graph, and performing static taint analysis on the generated cross contract function call graph to obtain a suspicious taint path;
a path confirmation step: and comprehensively examining suspicious paths based on verification before payment, hard coding of payment addresses, lock protection execution, protection of self-defined modifiers and internal updating rules before transaction, and finally outputting a re-entry attack path detection result.
In the above technical solution, the input of the contract processing step is an intelligent contract written by Solidity, and all calls from an external function are collected, which specifically includes the following steps:
step 2.1, constructing a cross-contract call graph through a Solidity program, and generating a directed cross-contract call graph, wherein nodes of the cross-contract call graph are Solidity functions, and directed edges represent call relations;
step 2.2, adding a fallback function and an edge represented by a self-defined modifier to obtain a more accurate cross-contract call graph;
step 2.3, generating a contract internal function call graph after the function of an abstract syntax analyzer for each function in the cross-contract call graph;
and 2.4, combining the cross contract call graph obtained in the step 2.2 with the contract internal function call graph obtained in the step 2.3 to obtain a final needed cross contract function call graph, and obtaining a call chain according to the cross contract function call graph.
In the above technical solution, the static analysis module performs static taint analysis on the cross-contract function call graph, and the analysis aims at all call relations starting from a suspicious contract address and ending with external function call in the cross-contract function call graph, and in the cross-contract function call graph, if a path satisfies any one of the following conditions, the path is considered as a vulnerable path suffering from reentry attack:
(1) the contract object calls any public method thereof;
(2) the address variable calls any low-level function.
Due to the adoption of the technical scheme, the invention has the following beneficial effects:
1. compared with many mainstream detection means at present, the scheme can solve the problem of overhigh false alarm rate of cross-contract reentry vulnerability detection.
2. The scheme selects a lightweight symbol execution analysis tool and performs static analysis, so that excessive system resource overhead can be avoided.
3. When the participant calls the external contract or the operation of sending data to the address requires the contract to submit the external call, the method can ensure that whether the participant is possibly subjected to reentry attack or not is judged before the transaction is completed, so as to avoid the participant from suffering property loss. The method introduces the traditional software analysis method, reduces the false alarm rate, ensures the safety before transaction, and can enrich the application scene of the block chain.
Drawings
FIG. 1 contract analysis processing.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail with reference to the following embodiments. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.
The detailed description of the embodiments of the present invention is not intended to limit the scope of the invention as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present invention without making any creative effort, shall fall within the protection scope of the present invention.
It is noted that relational terms such as "first" and "second," and the like, may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
An implementation of a cross-contract reentry attack detection system, comprising:
a contract processing module: and inputting a contract to be detected, analyzing a source code of the intelligent contract, and generating a cross-contract function call graph of the intelligent contract so as to obtain a call chain.
A static analysis module: and processing the call graph, and performing static taint analysis on the generated cross contract call graph to obtain a suspicious taint path.
A path confirmation module: and comprehensively examining suspicious paths based on rules of verification before payment, hard coding of payment addresses, lock protection execution and the like, and finally outputting a reentry attack path detection result to reduce the false alarm rate of the system.
The main processes of the scheme for the three modules comprise:
A. the building process of the function call graph is similar to the building process of the program call graph of the common object-oriented language, and only a fallback function and a self-defined modifier need to be considered additionally. After the inter-contract call graph and the intra-contract function call graph are constructed, the inter-contract call graph and the intra-contract function call graph are combined to obtain a cross-contract function call graph and a call chain. Taint analysis can then be performed on the call graph and call chain.
B. Static taint analysis has many similar approaches to java, C + +, but takes into account the properties of the Solidity language. Firstly, a data dependency relationship is constructed according to variables in a contract, and then a suspicious path is obtained through static taint analysis.
C. And comprehensively judging the suspicious paths obtained in the stage B through the technology in the path confirmation module. In order to make the judgment result more accurate, the scheme also uses lightweight symbolic analysis to assist judgment. The specific implementation process comprises the following steps: and (3) giving a threshold h by a user, and circularly iterating for h times to perform circular analysis, namely taking a return value obtained by each function call as a new variable value of the next call. The step can ensure that the obtained path is accessible, namely, the judgment time of the path can be greatly reduced, and meanwhile, potential false alarm is avoided.
First, suspicious path acquisition
Constructing a call graph by a traditional means, and obtaining a suspicious path by the following means, specifically comprising the following steps:
a. through static taint analysis, vulnerable call paths in a cross-function call graph are identified.
b. And filtering the fragile call path obtained in the step a according to a pre-payment access control technology, a payment address hard code, a self-defined modifier protection, an execution lock protection and a pre-payment internal upgrading technology.
c. And outputting the path left after filtering.
Second, path screening
Traverse all call chains in the VC set if there are the following cases: access control technology before payment, payment address hard coding, self-defining modifier, execution lock, internal upgrade before payment, then delete the call chain from the vulnerable call chain, now analyze some cases that will actually be misreported, as follows:
1) pre-payment access control
The code first reads the state of the artifacts _ pepeID, then calls the external function through peContract. In some detection rules of the detection tool, the write of the public variable after the external call is performed is considered to be possible to cause the reentrant attack. But in fact, since the code has already performed the necessary check for require (address (pepcontract) ═ msg. Sender will detect whether it meets certain conditions (whether it has good reputation or has transaction history) before paying, and it needs to check that statements and statements that may trigger reentry attacks exist in the same function called externally to ensure that there is no false alarm.
2) Payment address hard-coding
The above code is reported as a reentrant vulnerability by the partial detection tool because the balance check is performed and the transaction is performed through low-level calls, and the public variable rID [ rNumber ] is written after the external call, as in the example of 1). In fact, however, since the code is hard-coded with a payment address of 20 bytes, it cannot be modified to any other address, and thus a reentry attack is not triggered.
3) Custom garnish protection
Some detection tools detect that the buy () function may be recursively called by an external caller, causing a reentrant attack, thus falsifying the code as risky. But in fact this code takes security into account, adding a modifier OnlyHuman () before the function buy () that may encounter a reentry attack, which ensures that the transaction address can only be made through the keyword extcodesize, if this modifier is called by the creator of the contract, its return value is 0, which ensures that the buy () function is not called by an external attacker.
4) Execution lock protection
In the above codes, some detection tools may consider that zthktn. buyandsetdiv permission. value () may be maliciously called by an external attacker, and thus may be attacked. But the local variable reEntered is checked before the transaction is executed, no other function calls are allowed before the transaction is completed, and the relevant variable is released after the transaction is completed, so that the local variable reEntered is not maliciously called by an external attacker. The execution lock is similar to the semaphore in an operating system, and the reentry attack is fundamentally prevented by strictly controlling the access to the function.
5) Pre-transaction internal updates
According to CONSENSYSIS, a code writing mode in which no reentry attacks occur should contain three steps:
a) the necessary checks are done before the transaction function;
b) the middle part of the code is the state update of the Boolean variable and the digital variable;
c) the code is finally called by an external contract or address to a payment function.
Among the detection rules of some detection tools, if a transaction simultaneously satisfies the conditions: reading the public variable var, wherein the transaction gas consumption is more than 2300 and the transaction amount is more than the balance amount, and reading the public variable var before external invocation is considered to be possibly subjected to reentry attack. Although the code meets the condition, the code obeys a safe code mode in writing, so that the reentrant attack cannot occur.
The scheme is based on a general detection tool, whether necessary check before payment is carried out on the code possibly suffering from the reentry attack is checked, whether hard coding is carried out on a payment address, whether a self-defined modifier is added or not, whether an execution lock is considered or not, whether a safe code writing mode is met or not is judged comprehensively, and finally an accurate result possibly suffering from the reentry attack is output.
Claims (7)
1. A cross-contract reentry attack detection system characterized by:
a contract processing module: inputting a contract to be detected, analyzing a source code of the intelligent contract, and generating a cross-contract function call graph of the intelligent contract;
a static analysis module: processing the cross contract function call graph, and performing static taint analysis on the generated cross contract function call graph to obtain a suspicious taint path;
a path confirmation module: and comprehensively examining suspicious paths based on verification before payment, hard coding of payment addresses, lock protection execution, protection of a self-defined modifier and internal updating rules before transaction, and finally outputting a re-entry attack path detection result.
2. A cross-contract reentry attack detection system according to claim 1, characterized in that: the input of the contract processing module is an intelligent contract written by identity, and all calls from external functions are collected, and the method specifically comprises the following steps:
step 2.1, constructing a cross-contract call graph through a Solidity program, and generating a directed cross-contract call graph, wherein nodes of the cross-contract call graph are Solidity functions, and directed edges represent call relations;
step 2.2, adding a fallback function and an edge represented by a self-defined modifier to obtain a more accurate cross-contract call graph;
step 2.3, generating a contract internal function call graph after the function of an abstract syntax analyzer for each function in the cross-contract call graph;
and 2.4, combining the cross contract call graph obtained in the step 2.2 with the contract internal function call graph obtained in the step 2.3 to obtain a final needed cross contract function call graph, and obtaining a call chain according to the cross contract function call graph.
3. A cross-contract reentry attack detection system according to claim 1, characterized in that: the static analysis module performs static taint analysis on the cross-contract function call graph, wherein the analysis aims at all call relations starting from suspicious contract addresses and ending external function calls in the cross-contract function call graph, and in the cross-contract function call graph, if a path meets any one of the following conditions, the path is considered as a vulnerable path suffering from reentry attacks:
(1) the contract object calls any public method thereof;
(2) the address variable calls any low-level function.
4. A cross-contract reentry attack detection system according to claim 1, characterized in that: the path confirmation module judges suspicious paths together based on a pre-payment access control technology, a payment address hard code, a self-defined modifier protection, an execution lock protection and a pre-payment internal upgrading technology.
5. A cross-contract reentry attack detection method is characterized in that: the method comprises the following steps:
contract processing steps: inputting a contract to be detected, analyzing a source code of the intelligent contract, and generating a cross-contract function call graph of the intelligent contract;
a static analysis step: processing the cross contract function call graph, and performing static taint analysis on the generated cross contract function call graph to obtain a suspicious taint path;
a path confirmation step: and comprehensively examining suspicious paths based on verification before payment, hard coding of payment addresses, lock protection execution, protection of self-defined modifiers and internal updating rules before transaction, and finally outputting a re-entry attack path detection result.
6. A cross-contract reentry attack detection method according to claim 1, characterized in that: the input of the contract processing step is an intelligent contract written by identity, and all calls from external functions are collected, and the method specifically comprises the following steps:
step 2.1, constructing a cross-contract call graph through a Solidity program, and generating a directed cross-contract call graph, wherein nodes of the cross-contract call graph are Solidity functions, and directed edges represent call relations;
step 2.2, adding a fallback function and an edge represented by a self-defined modifier to obtain a more accurate cross-contract call graph;
step 2.3, generating a contract internal function call graph after the function of an abstract syntax analyzer for each function in the cross-contract call graph;
and 2.4, combining the cross contract call graph obtained in the step 2.2 with the contract internal function call graph obtained in the step 2.3 to obtain a final needed cross contract function call graph, and obtaining a call chain according to the cross contract function call graph.
7. A cross-contract reentry attack detection approach method according to claim 1, characterized by: the static analysis module performs static taint analysis on the cross-contract function call graph, wherein the analysis aims at all call relations starting from suspicious contract addresses and ending external function calls in the cross-contract function call graph, and in the cross-contract function call graph, if a path meets any one of the following conditions, the path is considered as a vulnerable path suffering from reentry attacks:
(1) the contract object calls any public method thereof;
(2) the address variable calls any low-level function.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210618214.XA CN115017515A (en) | 2022-06-01 | 2022-06-01 | Cross-contract reentry attack detection method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210618214.XA CN115017515A (en) | 2022-06-01 | 2022-06-01 | Cross-contract reentry attack detection method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115017515A true CN115017515A (en) | 2022-09-06 |
Family
ID=83073524
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210618214.XA Pending CN115017515A (en) | 2022-06-01 | 2022-06-01 | Cross-contract reentry attack detection method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115017515A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116663012A (en) * | 2023-05-31 | 2023-08-29 | 烟台大学 | Cross-contract vulnerability detection method, system and equipment |
| CN116894672A (en) * | 2023-07-12 | 2023-10-17 | 暨南大学 | Data transaction platform implementation method based on blockchain and payment channel network |
-
2022
- 2022-06-01 CN CN202210618214.XA patent/CN115017515A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116663012A (en) * | 2023-05-31 | 2023-08-29 | 烟台大学 | Cross-contract vulnerability detection method, system and equipment |
| CN116663012B (en) * | 2023-05-31 | 2023-11-03 | 烟台大学 | Cross-contract vulnerability detection method, system and equipment |
| CN116894672A (en) * | 2023-07-12 | 2023-10-17 | 暨南大学 | Data transaction platform implementation method based on blockchain and payment channel network |
| CN116894672B (en) * | 2023-07-12 | 2024-04-16 | 暨南大学 | Data transaction platform implementation method based on blockchain and payment channel network |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20040205411A1 (en) | Method of detecting malicious scripts using code insertion technique | |
| CN115017515A (en) | Cross-contract reentry attack detection method and system | |
| Xu et al. | A novel machine learning-based analysis model for smart contract vulnerability | |
| US20090158385A1 (en) | Apparatus and method for automatically generating SELinux security policy based on selt | |
| US8990116B2 (en) | Preventing execution of tampered application code in a computer system | |
| US20210334371A1 (en) | Malicious File Detection Technology Based on Random Forest Algorithm | |
| Liao et al. | Smartdagger: a bytecode-based static analysis approach for detecting cross-contract vulnerability | |
| Alkhalifah et al. | A mechanism to detect and prevent Ethereum blockchain smart contract reentrancy attacks | |
| CN112202704A (en) | Block chain intelligent contract safety protection system | |
| WO2023035751A1 (en) | Intelligent confusion for mobile terminal application | |
| Staderini et al. | Classification of ethereum vulnerabilities and their propagations | |
| CN114047928B (en) | Intelligent contract formal verification method and system suitable for combined transaction | |
| Gupta et al. | An insecurity study of ethereum smart contracts | |
| Sifra | Security vulnerabilities and countermeasures of smart contracts: A survey | |
| Ye et al. | Vulpedia: Detecting vulnerable ethereum smart contracts via abstracted vulnerability signatures | |
| Ali et al. | SESCon: Secure Ethereum smart contracts by vulnerable patterns’ detection | |
| Liu et al. | A smart contract vulnerability detection mechanism based on deep learning and expert rules | |
| CN113051624B (en) | Intelligent contract information flow integrity verification method and system based on type detection | |
| Zhang et al. | Your exploit is mine: Instantly synthesizing counterattack smart contract | |
| Qin et al. | Towards automated security analysis of smart contracts based on execution property graph | |
| CN109165509B (en) | Method, device, system and storage medium for measuring real-time credibility of software | |
| Zhong et al. | Privilege escalation detecting in android applications | |
| US11949696B2 (en) | Data security system with dynamic intervention response | |
| Jain et al. | Sniffdroid: Detection of inter-app privacy leaks in android | |
| CN114358934A (en) | Verification method of intelligent contract and related equipment |
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 |