Skip to main content
Table of contents
Luna Tong

The Auditooor Grindset

Crash course on smart contract auditing for vulnerability researchers
Article heading

So, you want to become a smart contract auditor! You’ve spent the last few years of your life chasing bugs for Chromium and Linux kernel VDPs only to dupe on your $10,000 bug with 3 other researchers. I understand your pain. That’s why you should audit smart contracts instead.

TL;DR​

Why audit smart contracts?​

  • It’s lucrative. You will enjoy more money auditing than any sad public 0day VDP will ever pay out. Meanwhile, you also keep your conscience clean of selling your bugs to a broker (if you have a thing against that).
  • Your clients actually pay you. In fact, they’re eager to pay you, instead of coming up with some lame excuse to close your report as an internal duplicate.
  • The income is consistent. Currently (as of Feb 2022), business is booming! Unlike VR, where you might discover a nice bug every few months, you can depend on getting paid per audit.
  • It’s flexible, remote work. Like VR, you set your hours. If you get busy, you can just stop taking audits for a while and relax. It’s like freelancing, but not shit.
  • Easy on the resume. We all know how “bLoCkChAiN” is a big shit buzzword right now. You can get in on the industry while it’s still hot and fresh. Even if you leave blockchain, you can still probably leverage your experience to get paid more down the road.

“But I hate blockchain!”​

I find that many vulnerability researchers have serious compunctions about touching crypto. If that’s you, read on. Otherwise, if you’re just an opportunist looking to cash out, skip this section.

It’s okay. At some level, anyone with a brain recognizes that the ecosystem, or at least its current iteration, is pretty fucking broken in a myriad of ways. You can criticize Bitcoin and Ethereum for being bad for the environment; NFTs for being hyper-capitalistic and hyper-materalistic; DeFi for preying on unsophisticated retail investors; the entire space for generally just being a slimy and scammy place filled with used car salesmen. That is fine. You don’t have to participate in the charade, and doing audits doesn’t make you one of those crypto fucks you see on Twitter. You can simply moonlight as an auditor and get paid what you deserve for your valuable talents.

You may also have the misconception that the money you earn is ultimately coming from unfortunate retail investors. That is also not the case. Like any consulting industry, the quality of your potential clients falls on a spectrum from shady conmen to blue chip institutional folk. Since you are already a highly-skilled vulnerability researcher, it is clearly a waste of your time to take on low-quality clients. So of course, your clients will be mainly big protocols funded by institutional investors—VC, PE, IB, HF, etc. If you think dimly of finance, consider the following: you’re taking money away from Wall Street and putting it back elsewhere in the economy. Pretty good way to pay for art commissions yeah?

If you don’t want to deal with clients, that’s also fine. There are firms who will find and negotiate audits for you, as long as you have the skills to tackle them. The question is, then, who will compensate you best↗ 😉 And of course, how to skill up. That brings me to my next point.

The strategy for learning smart contracts​

Auditing smart contracts is much easier than you think. The core competency for auditing is being able to read, understand, and find bugs in code. As a security researcher you are already light years ahead of everyone else who is trying to break into this space. If you have exploited tricky memory corruptions in binaries, or excavated grotesque logic bugs in web apps, then you are already qualified. Let me put it this way: you are a Major League superstar, whereas right now the state of smart contract security is a Little League game filled with 10 year olds.

You should think of “smart contract” as just another genre of research targets. For example, you might know a guy who does browsers. They know V8 and Turbofan and JavaScriptCore inside out. They know all the JIT miscompilation bugs, bounds check elimination mistakes, ArrayBuffer tactics, etc. But this guy, at their core, is just a vulnerability researcher. I am sure if you told them “hey, we need you to do kernel PrivEsc for a bit,” it’s not like they suddenly no longer know what they are doing. So your task is basically to learn all the stupid little idiosyncrasies of “smart contract”. That will unlock all your existing intuition and experience, which you can then skill transfer over.

That’s the flowery high level overview. Now before I actually spoonfeed you what to study, let me give you the Quick Rundown of the absolute state of blockchain.

‍

A brief overview of the smart contract ecosystem​

As a consultant, you mustn’t only know the technical side of things. You need to grasp the broader context of the industry as a whole. Nobody wants a consultant that wastes time on shit that no one cares about. But your clients will love you, because you will “get it”. This is the Auditor Grindset. Thus, I am going to tell you how it is right now.

The best way I can describe smart contracts is: Imagine a regular legal contract, but instead of running on your local jurisdiction’s court system, it runs on a magical blockchain.

Suppose you go to the bank in real life and take out a loan. You would sign a legal document that is a contract between you and the bank. The contract stipulates various things like the loan period, the interest rate, the collateral, etc. Now suppose we translated the bank’s contract from legalese and into some computer code. Then this code would be what governs the relationship between you, your money, and the bank. This is essentially a smart contract. And right now, there are many decentralized lending pools that you can borrow from, such as Compound on Ethereum.

Now, are there problems? Of course! When lawyers find loopholes in legal contract, this is bad. It might need to go to court, which is expensive. When a hacker finds a bug in a smart contract, this is also bad. Except the difference is, given the current state of affairs in DeFi (decentralized finance), the hacker just sends all the stolen funds to Tornado.cash and will never be heard from again. This is why you are paid the big bucks. You are a smart contract lawyer now.

The idea of DeFi was that by providing decentralized alternatives to traditional institutions like investment banks, this would give power back to people and supposedly “democratize” finance. The hilarious irony is, of course, that the old-fashioned institutions like investment banks, private equity, venture capital, and hedge funds are the ones bankrolling crypto and DeFi now. When people tell you about some flowery goal like “democratizing finance”, just smile and nod your head. You are not here to “democratize finance”. You are here to find problems in smart contracts. That is the Auditor Grindset.

Onto more technical matters​

Now you know about the soft side of things. Why did I even waste your time with that? Well, let’s be honest—even when you are doing vulnerability research, you are already contextualizing your research in the broader circumstances of InfauxSec. For example, we all know that no one will really give a shit about a DoS bug in some random video game. Furthermore, you also know that game publishers’ bug bounties are usually pretty shit, so therefore this is not a worthwhile target for you to pursue. See how your industry soft knowledge plays a key role?

The EVM​

Right now, Ethereum (and its VM, the EVM) is pretty much the poster child of smart contracts and DeFi. There are some other new chains used by contrarian hipsters (like Solana), but EVM-compatible chains are going to be your bread and butter. So you will focus on Ethereum for now as you learn the ropes.

The way EVM works is that you compile your smart contract to EVM bytecode and this runs on all the Ethereum nodes. To deal with the Halting Problem, they bound the execution by making you pay for cpu cycles with gas. Once you upload (“deploy”) the smart contract on-chain, then you can interact with it by sending it transactions. Transactions are atomic and if it reverts at any point the whole thing reverts (with some caveats, like try/catch Lol). On chain, your contract has some persistent storage (“storage”) that lives on the chain, and temporary storage (“memory”) that is basically like local variables on the stack.

Web3, Dapps, and JavaScript & Solidity​

One thing you will also quickly notice is that everything uses JavaScript. Why this is will quickly become clear.

In DeFi, developers want to make it as frictionless as possible for users to ape into a new project. Building and onboarding users onto an actual honest-to-god native app is just way too expensive. Putting my money into a new rug mustn’t be any harder than clicking on a link. That is why everything is a goddamn web app, and likewise, why all of the UX is shit. This is referred to as “Web3”.

Anyways, if the frontend is written in JS, why not write the DevOps infrastructure in JS too? Fuck it. So everyone uses some development framework like Hardhat.js, which essentially provides a “Web3 API” that wraps Ethereum node RPC calls in a Javascript-y way. So you’ll write your smart contracts in Solidity, but the driver code that actually compiles, tests, and deploys them will all be written in Javascript using Hardhat. Lately, Foundry is another toolchain (written in RuSt) which has been gaining a lot of traction as well. But there is still a lot of Javascript.

(2024 update: Foundry is way less bad, everyone uses Foundry now. There’s still Javascript everywhere though; the ecosystem is essentially a mix of Golang, Typescript, and if you’re lucky, Rust. And Solidity.)

Luckily, you generally will not need to audit the JavaScript parts of a project. On Ethereum, the smart contracts themselves are written in a language called Solidity. Solidity is a funny little language that has a lot of dumb footguns, which they’ve tried to band-aid over time. Starting out, you will really be reading a lot of Solidity.

You can think of Web3, then, as basically web apps (“Dapps”) with frontends written in Javascript and backends that do all the business logic using smart contracts on the blockchain.

So anyways back to those footguns—Solidity has a lot of dumb idiosyncrasies. Part of them are due to technical limitations of the Ethereum blockchain, and the rest of them are just bad design decisions. Well, no programming language is perfect. But it’s your responsibility to know about all these dumb pitfalls so you can ding projects on them in your audit report. This is the Auditor Grindset.

I’m not going to enumerate all of the dumb shit, because that would be too long, so instead I will just link you later in the article to a bunch of documentation that details it all. Also, reading those will help you further understand the absolute state of the Ethereum ecosystem.

Also, very important note–if you ever feel dumb learning Solidity: You are not dumb. It is Solidity that is dumb. Don’t be afraid of asking a “dumb” question since chances are the answer is probably “oh yeah it’s really dumb, do it like this, yes it’s really like that.”

What kind of problems are there in smart contracts​

There are basically 4 major types of problems in smart contracts.

  1. Surface-level bugs. Stupid shit like integer overflow, use of dangerous functions, various anti-patterns, etc. A lot of these bugs can be caught by static analyzers like Slither↗. You should familiarize yourself with all the major anti-patterns and learn how to use Slither.
  2. Business logic. When the code doesn’t match the specification. Or when the design itself is flawed, such as game-theoretic or economical flaws. You should read write-ups on past famous arbitrage hacks (Links later in the article). Some of these bugs can be found with fuzzers like Echidna↗
  3. Fancy DeFi hacks. When someone hacks your contract through its interactions with the rest of the ecosystem. This is stuff like flash loan attacks, oracle manipulations, etc. You should consider if miners and MEV may be part of the threat model too. (Links later in the article).
  4. Code quality. When there isn’t test coverage. When there isn’t documentation. When the code is confusing. Yep, auditors really ding on these kinds of findings. That is the Auditor Grindset.

Every project is different. If you’re auditing a simple protocol with no external interactions, it is probably not going to have some fancy DeFi interaction vulnerability. But it might have some surface level mistakes.

I don’t know how to write reports!​

That is fine, if you are working with a firm they would probably have a template for you anyways, and oftentimes much of the language in there is boilerplate that is similar across multiple reports.

The best way to learn this quickly is to go and read like 10 Trail of Bits or Zellic reports. These firms do a great job. You will quickly recognize the patterns and see that really it’s quite boilerplate-y. So really as long as you can get the findings, it’s not that hard to do the report. It’s just time consuming, which is okay, because that is part of your billable work.

You should also read CertiK and Peckshield’s reports. They audit many projects and their volume is higher than Trail of Bits, so one can imagine they position themselves somewhat differently in the space. Study the kind of findings they make and learn to do that as well.

You need to be versatile. Your job is to find security issues, period. The client is paying you to feel assured about the project as a whole. Whether findings are from the smart contract, to the client’s key custody, think about it from the client’s perspective. If you don’t have enough scope in the audit, then go manufacture more scope. Bring shit into scope if you think that there’s buggy attack surface, and justify to the client why it ought to be in scope. That’s the Auditor Grindset.

What to study up on​

IMO, the best way to learn a new target is with pwnables. So go do these pwnables: Damn Vulnerable DeFi↗

It will be confusing at first so don’t feel bad if you need to cheat and look up solutions for the first 1 or 2 challenges, just to understand how to use Hardhat. Those challenges are baby challenges anyways.

You’ll want an understanding of how to write Solidity code, so it would be worthwhile to go through the Foundry Book↗ and make some basic “hello world” Dapps so you understand what things are like.

You’ll want to read up on common Solidity patterns and anti-patterns:

Read up on some famous DeFi hacks. Some noteworthy ones:

There’s also several newsletters and blogs by famous researchers that have high quality writeups.

More pwnables:

Once you finish the Damn Vulnerable DeFi challenges, you are more-or-less ready to tackle some simple audits in the real world. Yes, it’s really that straightforward. That’s the Auditor Grindset.

Conclusion​

I hope you enjoyed this fiery crash course full of hot takes and unfunny jokes. If you think the Auditor Grindset is for you, you should come work with us↗. Zellic is a blockchain security shop formed by researchers, for researchers. We pay very competitively and would love to have you on board. Please reach out: jobs[at]zellic.io.

About Us​

Zellic↗ is a smart contract auditing firm founded by hackers, for hackers. Our security researchers have uncovered vulnerabilities in the most valuable targets, from Fortune 500s to DeFi giants. Whether you’re developing or deploying smart contracts, Zellic’s experienced team can prevent you from being hacked.