Speedrunning Web3 Bug Hunts

What is bug hunting?

Bug hunting is when a user submits indepedent audits of a designated codebase to a website, such as Code4rena or Immunefi, where teams publish their code up for review, give a scope of the files they want audited and offer varying reward bounties. The bounties rewards are dependent on the finding’s severity.

The terrific thing is that anyone is able to submit a report/finding and is able to claim some quick cash!

The more efficient and creative you are at discovering bugs the less time you need to spend on scanning them (in these environments) and the more lucrative it becomes!

The high-class auditors are able to make ridiculous money:

• Junior: 100$/h
• Experienced: 100$-250$/h
• Top Auditors: 250$-1000$/h

(Data from Cmichel’s How to become a smart contract auditor)

What is speedrunning?

In this context, speedrunning is spending the least amount of time (< 5ish hours) on a codebase by scanning key attack points on a smart contract, identifiying common vulnerabilities and simple errors that may have been overlooked.

Since we don’t want to spend hours-on-hours staring at a single codebase we will devise an efficient strategy to cover as much as we can in the smallest amount of time.

We’re basically using statistics to target where things happen and the chances of it occurring to know what to look for in a certain piece of code.

Preperation

In order to speedrun, we need to know how to dissect a smart contract into a few parts:

1. Who can access what functions?
2. What are the external and public functions and do they have payable?
3. Where do transfers occur?
4. Where do external calls happen and what is changed because of it?

Then we need to understand the most common vulnerabilities, e.g:

1. Access control.
2. Re-entrancy (w/ payable, flashloans, fallbacks).
3. Arithmetic miscalculations (inc. low-level code).
4. Custom logic errors.

To crunch the numbers a bit more we can read a sh*t ton of reports from various companies/daos (Certik, Trail of Bits, Code4rena, Solidity Finance, Rekt.news, Spearbit, etc)

To make our strategy even more efficient we can create/use tools to quickly create an enviornment to test the codebase, for example:

• Slither, for static analysis.
• Create a Foundry template for fuzzing + PoC exploits.
• Building a hybrid tool that incorporates both fuzzing + static analysis.
• Build something that highlghts things and graphs it.

How 2 Speedrun

Lets break down an efficient scanning approach to detect smart contract flaws:

1. Check all the functions that should be only accessed by a specific person.
2. Is there anything the codebase relies on? Focus on that first.
3. Check all the functions that perform transfers, balance setting or external calls - is there any way to game these? (here’s where you use your big brain for creative solutions).
4. Do these critical functions have any ordering errors, miscalculations, or edge-cases (logic errors that haven’t been delt with - think of past exploits)?
5. If the codebase is a fork of another, do they have any past exploitable code in it? If it’s unique, think of ways an attacker would attempt to use oracles, AMM manipulation, flashloans, external contracts/other protocols to try and change something that shouldn’t be changed.

After you’ve gone through these, you would have covered majority of the potential flaws 👏

Now it’s time to do the same thing for another codebase!

Why speedrun?

If you’re like me, you may have tons of things you want to work on. Speedrunning can help manage your time by gaining experience + intuition for bug hunting while also giving you the time to work on other endevours, since you’re not spending hours on a single codebase.

I like to think of speedrunning in a statistical sense. If you can cover as much ground as possible with an efficient strategy the chances of finding bugs becomes quite high, given you have a large enough sample size. You could build out tools to formulate quite a strong strategy to find bugs due to smart contracts not being too complex - just a bunch of functions interacting with each other in the same language - no external environments programs/tools, aside from oracles for price feeds which use smart contracts anyway.

Next steps

Try to refine your strategy to make it as efficient as possible. Build tools to aid you and automate the process a bit more. Target the “common” things you start to notice in vulnerable contracts and establish some statistics on what you find, where it’s found and what causes it. If you get enough data you should be able to construct some type of automation for it. Then you can get more advanced with it and do the same with that :P

I think everyone should try to do it at least once, to experience it.

If you’re already a solidity dev, give it a go! You’ll gain a new perspective into the PvP side of smart contracts from the traditional PvE builder side.

If you’re not an exisiting solidity dev, bug hunting is a great way to learn about a ton of protocols while simultaneously learning solidity and security! You really can’t go wrong!

I appreciate you for taking the time to read this article. I hope you found value in this, anon!