FULL Smart contract audit Methodology [2023]
In this article, I’ll show you the different steps in how to audit a smart contract.
Contrary to beliefs, auditing smart contracts is not that hard. (not harder than auditing simple web2 websites)
This is due to the fact that solidity is very easy to learn and is very limited as a programming language, thus hacking possibilities are also quite limited.
But in case of an attack, the losses can be 1000x more heavy, therefore the security of a smart contract need to be reviewed cautiously.
Notice also that in an audit, it’s possible to include several different things.
- Finding the smart contract flaws.
- Optimizing smart contract gas.
- Auditing and Improving the Tokenomics.
- Decentralization checking. (assessing if the owner have to much rights)
- Remove any MEV opportunities to exploit the smart contract.
1. Preparation
Let’s say you’re a freelancer, you’ve received a security audit request from a project. I advise you to look at first:
- What the project is talking about (and if you want to work for this type of project)
- Test if the smart contract compile. (if provided/open-source)
- See, if the developer documented the code and made it readable. (Otherwise ask them)
After that, give a quote to your client. (and require a percentage to be paid in advance)
At this point, let’s say you’ve got the contract (and hopefully got some payment upfront), now we can start the true work.
2. Understand the CODE
If you need to remember only one phrase in the field of hacking: You can’t hack what you don’t understand.
At first, you absolutely need to understand how the different functions of the smart contract works and how they interact.
Do this, BEFORE searching for any flaws.
You need to spend a least several hours in order to obtain a good grasp of the smart contract’s architecture.
You may already find some smart contract logical flaws.
3. Run Automated smart contract tools
The smart contract may be very long, maybe you don’t know where to start, in this case, it can be useful to run some automated smart contract tools to spot easy to find vulnerabilities.
You can use Mythx, Slither, Mythril and a lot of others.
But in most cases the developer (if he’s competent) already run these kinds of tools and (already) corrected the flaws.
Don’t rely on these tools too, they are not very powerful and sometimes they yield false positives, so make sure to verify every finding before including them in the report.
4. Testing/fuzzing functions
Once you’ve understood how the smart contract work.
You need to test each functions separately by deploying them on your own private Network. (this is more efficient, you don’t need a ton of ether, you don’t need to wait for each transaction…)
The goal is to fuzz each function (submit a lot of “unexpected” input into each argument of each function.) to spot some unexpected behavior of the smart contract.
For each functions you can test each flaws in the SWC-classification too, which covers most of the flaws.
5. Provide recommendations
When you’ve got a good understanding of the smart contract (in a way where you can re-implement it yourself) and when you’ve tested each function separately, you can view the searching of flaws as done.
BUT, your job isn’t only finding the issues of a smart contract but also thinking about a secure and efficient way to correct them.
Don’t forget to note every issue you found, and for each of them provide:
- The location in the code. (in the following format: file.sol:999)
- A number (usually between 1 and 10) describing the severity of the flaw.
- The recommendation on how to protect the smart contract.
Sometimes, this is pretty “easy”, there is only 2 or 3 lines of code to change.
But in rare cases, it may be harder, more time consuming and require to rebuild one part of the smart contract architecture.
6. Create the report
- Write a user friendly report, don’t forget that people which will read the report will be normal people without as much technical skills as you.
- Show clearly your methodology, how you audited the smart contract and what is the scope of the audit (Which files where audited and the commit id on Github if needed.)
- Don’t forget to include legal disclaimers
This is not exhaustive, you can add a lot of different things.
See you next time :)
