Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Softw 2020
DOI: 10.1145/3368089.3417064
|View full text |Cite
|
Sign up to set email alerts
|

Harvey: a greybox fuzzer for smart contracts

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
52
0

Year Published

2020
2020
2023
2023

Publication Types

Select...
3
3
1
1

Relationship

0
8

Authors

Journals

citations
Cited by 114 publications
(57 citation statements)
references
References 77 publications
0
52
0
Order By: Relevance
“…A more automated form of testing is fuzzing [149], which generates unexpected, undefined, random, or invalid inputs to trigger a crash or reveal defects and vulnerabilities. Fuzzers, like ContractFuzzer [150], Echidna, 16 and Harvey [151] can be used for automated smart contract testing as well. Another technique of dynamic analysis is symbolic execution [152], where a program is executed with symbolic values (i.e., logical expressions) that make it possible to explore all reachable paths of a program.…”
Section: ) Security Threats and Countermeasuresmentioning
confidence: 99%
“…A more automated form of testing is fuzzing [149], which generates unexpected, undefined, random, or invalid inputs to trigger a crash or reveal defects and vulnerabilities. Fuzzers, like ContractFuzzer [150], Echidna, 16 and Harvey [151] can be used for automated smart contract testing as well. Another technique of dynamic analysis is symbolic execution [152], where a program is executed with symbolic values (i.e., logical expressions) that make it possible to explore all reachable paths of a program.…”
Section: ) Security Threats and Countermeasuresmentioning
confidence: 99%
“…We further closely look at the test cases provided in smart contract projects. We select a benchmark dataset, built by Wustholz et al [27] for testing smart contracts, which includes 17 projects that are popular projects carefully picked from the Ethereum community and Github. Six of them do not contain any test cases, the remaining 11 projects shown in Table II (1) All of these 11 projects have tests with manually-specified inputs.…”
Section: A Smart Contractmentioning
confidence: 99%
“…In the literature, the generation of test inputs for smart contracts mainly relies on fuzzing and mutation [27], [28], [25], [29], [30], [31], [32], [33]. For example, Jiang et al [34] proposed to build seed inputs with the valid input domain and the inputs frequently used by some data types in smart contracts, to further fuzz inputs for testing ABI of smart contracts.…”
Section: Introductionmentioning
confidence: 99%
“…Existing smart contract fuzzers such as HARVEY [50] instrument the code and compute cost metrics for every branch to mutate the inputs. Our approach applies constraint solving to generate values for complex conditions on-demand.…”
Section: B Input Generationmentioning
confidence: 99%
“…ECHIDNA requires user-defined predicates in the form of Solidity assertions and does not automatically check for vulnerabilities. HARVEY [50] predicts new inputs based on instructiongranularity cost metrics. In contrast, CONFUZZIUS exploits lightweight symbolic execution when the population fitness does not increase (see Section IV-D).…”
Section: Related Workmentioning
confidence: 99%