What up, coder frogs? How to audit a smart contract, and can you spot the vulnerabilities before we do? This is a modified excerpt from that 32-hour monstrosity full stack Solidity free code camp video, which by the way you should 100% watch no matter your experience level. But in this video, we're going to go through what a smart contract audit is, what's the process that auditors take, and then give you a chance to spot the vulnerabilities in these contracts before we do. This is going to be an introductory video to auditing and security in your smart contracts, and anybody who wants to become an auditor eventually or deploy their code to a mainnet should 100% know all the points in this video. We'll be using Hardhat as our smart contract framework, but all the security tools that we're going to be showing you will work no matter what framework you're working with. So buckle up for security purposes, and let's get froggy. Now we have a link in the description that has both this GitHub repository and

the article that we're writing on this topic. If you want to follow along, feel free to git clone this topic as well. Well, an audit is going to be a security-focused code review, looking for issues with your code. So, for example, let's say we have some code that looks like this. Our code withdraws, goes and sends ether, and then updates the balances. This code is clearly vulnerable to a reentrancy attack here, and this is something that an auditor would catch. Since when we deploy our code, that code is immutable, and that code will always be there, it's really important to have these security reviews done before we deploy our code to a mainnet and before we go live. So, if you're going to deploy some crazy massive DeFi protocol, and you're going to have billions of dollars of people's money locked into your protocol, you probably want to make sure that the money is going to go to the correct places. So, audits are incredibly important for the life cycle of our projects, and we want people to peer review. We want people to review our code.

to make sure that everything looks good. Auditors also don't make sure that your code is bug-free. I'm leaving another link in the description to the Securium Substack. Securium is a great platform for learning more about audits and security in our smart contracts. They even have this audit techniques and tools 101, and one of the main things that they talk about as well is that audit is not a security guarantee of bug-free code. It is a best effort endeavor by trained security experts operating with reasonable constraints on time, understanding, expertise, and of course, decidability. And you can learn more about different audit types, audit scope, kind of all these differences in very specific audits, and the limitations. Feel free to pause the video and read this to learn some more. Getting an audit does not guarantee that your code is spotless. It is a best effort attempt. Like I said, audits are security-focused peer reviews for your code base. Now, when we send our code to audit though, we shouldn't just say, Hey, here's our code. Can you check to make sure it's

good. That's not going to give an auditor enough information they need to be able to very easily know what your code does, how to work with it, and what you're looking for because auditors aren't going to be kind of this fail-safe where if your code is terrible, they're going to catch everything. Auditors are human beings too; they can miss things as well. And when you do send your code to audit, you want to make sure you help out your auditors as much as possible. There's an amazing tweet thread from Tincho, who previously was an OpenZeppelin auditor, with a ton of tips and tricks for working with auditors. I highly recommend you pause the video, you click this link, and you read through his tweets because they are fantastic. OpenZeppelin has a readiness guide to try to help you make sure that you're even ready for an audit in the first place, and we've got a link to this readiness guide in the GitHub repository. The summary of them is to add comments to your code, use NatSpec, which we learned

about to document your functions. Document your functions. Document your functions. Test. Be ready to talk to your auditors and be prepared to give them plenty of time. They are literally pouring themselves over your code for weeks on end to make sure there's nothing wrong. If you rush your auditors, you're going to get a rushed audit, and they're going to miss things. If you want to, before we even start, jump into the contracts folder, because in here we have one, two, three, four, five different contracts with some vulnerability that an auditor should either catch or at least call out in their report. If you want to, maybe pause the video and see if you can spot the issues with these five contracts before we talk about them. Now, some of the names are dead giveaways, so maybe use those as a hint. So, let's talk about the auditing process. An auditing process is gonna look like this. First, they're gonna run your tests. That's the first step an auditor is always gonna take, and right there, they're going to find, Okay, do they have

enough code coverage is everything passing. What do the tests do? What is the optimal functionality? After an auditor runs tests, they're going to read specs or run your docs, and then they're going to run some fast tools like slither, linters, and static analysis, and that's going to be one of the first things we're going to talk about: slither and static analysis. So, static analysis is the process of just running some program to read over all your code and look for commonly known bugs. One of the most popular static analysis tools is going to be this tool called slither, and that's going to be one of the first things we're going to do here. So, let's go ahead and open up our VS Code now, and we'll make a new directory called hard hat security FCC. We'll CD into it, we'll do code period, and we'll open this up now. What I want you to do instead of starting a new folder and everything is we're going to get clone my hardhead security FCC. So, we'll do git.

clone our.securityfcc space and then put a period to clone it into this directory, and we'll get everything like this now in here. This comes with a couple of different contracts for us already that each have a different vulnerability. One of them is going to be bad RNG. This is a contract that picks a random winner of a raffle using block difficulty and message.sender. This isn't truly random as the miners can influence the block.difficulty, and people can cancel transactions, and there's a ton of different vulnerabilities with creating randomness in this way. We also have this liquid pool as an oracle in this contract. Here, we're using a liquidity pool as an oracle, and this is kind of some advanced DeFi stuff here. This is a minimalistic decentralized exchange example where people can buy and sell and swap different assets. Now, using this singular exchange to get the swap price is a terrible idea because this is a single protocol for a single price. The price from this protocol is a single centralized location, and we don't want to get our price from a single

centralized exchange. We want to get it from many exchanges. Getting the price of any asset from a single decentralized exchange is not decentralized. If somebody manipulates the market, doing some crazy advanced DeFi things, that will ruin the price of your assets. So, getting the price of your assets from a centralized location is a terrible idea. We have a metamorphic proxy here. The issue here is that it's initializable, and we don't guarantee that the contract has been initialized. We have a classic reentrancy issue here. And then we have a vault here where some password is stored on-chain, and we're crossing our fingers that nobody reads this password to unlock it. So, we're going to run some static analysis on these contracts, see if that static analysis can spot some of the bad things in here. To get started, we're going to use a tool, like I said, called Slither. This Slither tool was created by this Crytek team, aka the Trail of Bits team. Now, Trail of Bits is one of my absolute favorite auditors in the space, and I absolutely love all

the tools that this team puts out. They put out open-source security tools for any of us to use, such as Slither. Now, to get started with Slither, we actually need to install Python first. So, you can also run it with Docker, but I'm going to show you how to work with Python first. So, if you haven't worked with Python before, you can come to python.org downloads and download Python right from the website. You'll know you've done it right, and you can run python3 --version like this, or if you have an older version of Python, you can run python version. Once you install Python, you should also have this tool called pip3 installed, and you can check by running pip3 version or pip --version. Now, we also want to install this solc-select package just in case we're using weird versions of Solidity. To install solc-select, we run pip3 install solc-select like that, and then we can do solc-select use, and then we can choose a version of Solidity for Slither to work with.

once you have those tools, you can just run pip3 install slither analyzer like so, and you can install slither into your Python environment. I'm not going to run it because I already have. You can also learn how to do this all with Docker. We'll learn how to do this with Docker in a little bit. Now in our package.json, we actually have command script in our package.json for running slither. You'll know you've installed slither correctly if you can run slither --help, and you get an output like this. Now we can use slither to run it on our contracts folder by running this big command here. So we'll say slither, and we want to run it on ./contracts. We would need to tell it that it has some sulk remappings, and every time it sees Open Zeppelin, it should use node module Open Zeppelin, and every time it sees Chainlink, it should use node modules Chainlink. And I'm just going to read from our package.json, and we're excluding a couple of functions that it

runs and excluding build or ignore, but don't worry too much about that. We can actually just run that by first running yarn to install all of our packages, and after we've installed all of our packages, we can run yarn slither, or you can copy-paste that slither command and run it directly. Now, we'll get this massive output that looks like this, with some red and some green. Let's go through what's actually happening here. The way that we can read slither, it'll list out a number of lines that have an issue and then a reference to that issue, and each one of these is separated by a new line, so that's a section, that's exception, etc. So, if we get a red here, that means that there is a high-impact issue that we definitely should address, and it even comes with a reference link that we can copy-paste and put into our browser and see what the issue is and more information from the slither tool about what that issue is and how to correct it. We can see it catches our metamorphic.

contract issue. It says the metamorphic contract is never initialized. It is used here in metamorphic.kill. The reason that this is a massive issue, if we go to our metamorphic contract.sol, is that if we deploy this contract, somebody else could initialize this code, become the owner, and then automatically kill it before we even have a chance. This is actually something that has happened in the past and has caused a ton of issues. So, if we see red in the terminal, this means, Hey, massive issue. We should absolutely check it out. Now, there's going to be a ton of green in here. These are detectors that are probably low impact and they're probably okay. And in fact, we can see it's even just calling out some opens up on stuff here saying, Hey, we see some in-line assembly. Inline assembly is kind of scary, maybe don't use that. So, you can think of green as kind of a warning that there's a low likelihood that this will impact anything, but you might want to check it out. We get this different versions of solidity used, which is just

saying hey, there's a couple of different versions of Solidity that might be something you want to keep in mind. Maybe you should use the same versions of Solidity we have. This allows old versions, and this is actually why throughout this whole course we've been using 0.8.7, because 0.8.4 and 0.8.7 are considered more stable versions of Solidity. So, if you're using versions outside of there, Slither will say, Hey, maybe you want to work with a different version. We have some flags in here about maybe, Hey, you should make a variable constant because it never changes, which is great. Uses literal with too many digits, saying, Hey, this is kind of hard to read. Maybe you screwed up some of the zeros. Loud old versions, and What's this reentrancy in Etherstore.withdraw? So, just by running this Slither tool, we can catch a reentrancy vulnerability in one of our contracts, which is fantastic. So, running this static analysis caught at least two huge vulnerabilities in our metamorphic contract.

and in our reentrancy contract, it didn't catch the issues in vault outsole liquidity pool or bad rng though, which is why we don't only want to rely on slither because it's not going to catch everything, but it will catch a lot of major vulnerabilities. So, that's how we can use slither, at least from a minimalistic point, to get started. So, great, we just learned how to work with slither. That's one of the first tools that are really fantastic in our audit process, and that's going to be considered a fast tool for static analysis. Running tests, linters, etc., are also types of static analysis. After we run a tool like that, we enter some manual analysis where we walk through the code ourselves manually. And it's in this manual review, though, that we might want to say, Oh, um, probably shouldn't get the swap price from a single dex because that could be oracle manipulated attack, or we might go, Uh, this randomness method that you have isn't that random. Auditors will

literally pour over every single line of a smart contract to make sure it's doing exactly what we want it to be doing. And maybe we do it in tangent with running some slower tools like Echidna, Manticore, and other symbolic execution tools. Symbolic execution is where we simulate executing transactions on the blockchain, and one of these symbolic execution tools that we're going to work with is this Echidna tool. Again, this is a Trail of Bits tool for doing something called fuzz testing. Now, in programming, fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. In a lot of our code, oftentimes, we're going to get people interacting with them in ways that we will never think about. So, we want to be able to provide random data and random information to our test to see if something weird happens that we weren't expecting. So, we can actually build our own fuzz tests in our Hardhat projects and run these fuzz tests. I've

actually created a sample fuzz test. We write our fuzz tests in Solidity, actually, as opposed to writing our tests in JavaScript. So, let's say, for example, we've built this vault contract, and we think that at first glance, Hey, nobody should ever be able to know the password, and no one should ever be able to unlock this contract, which obviously we know is ridiculous because we know that anybody can read anything in a storage variable. So, we know that this should fail, but it might be hard to write a test to catch that this actually would fail. A good approach to testing this would be to just send a ton of random bytes32 objects to this unlock function to see if we can unlock it. We can write a fuzz test to do exactly that. So, in my vault fuzz test.soul, we're importing vault.soul, and so we're saying vault fuzz test is vault, and we have a password of 123 asd 123. And now we have a function called echidna test find password where it's gonna send a ton of random data into vault to try to

make s locked equal false so we just say s locked equals true here, and our fuzz test will try to make s-locked equals false. Now we could install just echidna, but at this point, it's a good idea to bring up our the security toolbox from trail of bits. So trailer bits has a package called the eth security toolbox, which has all their security tools in one single container: echidna, etherno, manticore, slither, rattle, and not so smart contracts. It has all these in the same exact package. Now to work with this toolbox, we're going to need docker installed, so we're going to do a little bit of installation here, and again, sometimes this can be the hardest part of the course, it's just installing these packages. So we've left a link to docs.docker.com/getdocker to install docker. To actually work with these tools, you're just going to come, you're going to click whichever one of these is appropriate for you to install docker. Once we have docker installed, we can run the e-security toolbox by pulling it.

down from the docker equivalent of github, and we're going to use a whole bunch of docker commands that I'm not going to explain here because this isn't a docker course. If you're looking to get into the security stuff, I would definitely recommend reading up on all these commands afterwards, and we're going to leave a ton of links for you to learn more. In the package.json associated with this lesson, we even have the command to get set up right in here, so we can just run yarn toolbox, which will run our docker command like this. So I'm just going to run yarn toolbox, and if you get something like this saying cannot connect to the docker daemon, is the docker daemon running? Because I need to have my docker daemon running. Since I installed docker desktop, I need to have my docker engine started and running for it to actually be working again to work with this. There's a lot of docker setup and configuration that needs to happen, which I'm going to leave a ton of instructions on how to

get started with Docker. Once we have Docker set up, now we can run Yarn toolbox, which will stick us into a new shell to work with any of these tools that Trailer Bits has out of the box. Now our vault fuzz test comes with a config as well. This is in a YAML file with all our arguments for running Echidna. So it has a test limit, which is how many different runs we should do, a time delay, block delay, and then of course some remappings in here. This Docker shell will already have these security tools already installed, like Echidna test. So we'll run an Echidna test on src/contracts/test/fuzzing/vault_fuzz_test.sol --contract will be vault_fuzz_test --config will be src/contracts/test/buzzing/config.yaml. And we'll go ahead and we'll hit enter here, and it'll say analyze and contract, and will give us an output that looks like this. What it's saying is it found a use case where it could make s-locked.

equal false, and the use case was one, two, three, asd, one, two, three. So when what seemed like almost seconds, it found the password to unlock our contract. And this is why running a fuzz tester can be so powerful. We thought our contract was secure, but it immediately found the password, which means anybody else could immediately find the password. And this would be an indicator that what we're doing there is not a good setup. So we'll hit ctrl c to escape and to leave our docker setup here. We'll just write exit. Now again, I'm going to leave a ton of links to work with echidna and work with this fuzz tester in the GitHub repo associated with this lesson so that you can go ahead and learn more. Now if you take anything away from this whole section, it should be this right here. The two most common attacks are reentrancy and oracle manipulation. So if you're not going to be an auditor and you just want to deploy things to mainnet, always, always before you deploy anything, the absolute minimum that you should be doing is always running

slither and then looking manually for oracle manipulation and reentrancy attacks. So please keep these in mind before you deploy anything to mainnet with any type of security guarantees. Okay, great. So we've learned about the fast tools. We've learned about some of the slow tools. We didn't look into Mantacore or MythX, but these are also tools that you can use. Mantacore is going to be another tool from the TrailerBits team. Mythics is actually a smart contract security service from the ConsenSys team. You basically send a bot that they have running in the cloud your contracts, and it'll do some automated process to check for security vulnerabilities. This is a paid service, but if you're going to be deploying a protocol that's worth millions of dollars, spending a few thousand dollars to make sure it actually does what it says is going to do correctly is definitely something that you want to invest in. After you run through this whole process, you, the smart contract developers, and the audits should discuss their findings, and if

there's any issues. Repeat the steps, repeat all these steps again after changes are made, so this audit process and making sure your contracts are secure is a long process. And then afterwards, an auditor will finally write you a report with all security vulnerabilities and everything that they found in your contracts. Typically, you'll organize reports in a chart that'll look something like this. You'll label issues that have a high chance of happening and have a high impact as critical, things that have a high impact but a low likelihood as medium, and etc. I'm also going to leave some examples of audits that have been done in the past so that you can take a look at them and you can see what a full audit looks like on certain code. We'll be looking at Open Zeppelin, Sigma Prime, and Trail of Bits because these are three of what I think are some of the best auditors in the space. Now in the GitHub repo, we also have a ton of other tools that you can use: MythX, Mythril, Ethersplay, and Consensus Security Tools.

If you want to learn more about security in auditing, I highly recommend that after this course, you play the Ethernaut game and Damn Vulnerable DeFi. These are two games that will teach you a ton about security and will test the chops and will test everything that you've learned in this course. There's also a couple of security-focused blogs that I really like. One of them in particular is rect.news. They keep a running list of some of the largest hacks that have ever happened in the space and then retrospectives on why those actually happened, and they usually make it very entertaining as well. We have some articles in here as well. One of the best places to look at is this known attacks section where they talk about reentrancy, oracle manipulation, front-running, and a ton of other attacks that you should absolutely be aware of when writing your smart contracts. We're not going to go over them here because they do a great job in these resources explaining them. You should also check out this article because I helped write it, so definitely.

check that out, and then we've got a list to even more sections. Security is something that is always going to be on your mind, and there's always going to be new tools to help with security, and there's always going to be new things to think about. So even though we went through this very quickly, I 100% want you to pause this video and work with and try out some of the tools we tried here, and then maybe even try coming up with your own vulnerabilities as well. We've got a lot more content like this coming out, so please like, subscribe, tell your friends to subscribe, and let me know what you want to see next in the comment section. And definitely tell your friends to subscribe, because at 100,000 subscribers, we're gonna do something crazy. We have one thing that we're definitely already gonna do, but let me know if you want to see something else crazy for our 100,000 subscriber celebration. Take care, everybody, and we'll see you next time. [Music] [Music]

How to Audit a Smart Contract | Can you find the Solidity Security Vulnerabilities?

How to Audit a Smart Contract | Can you find the Solidity Security Vulnerabilities?