Mythril is an automated static analysis tool for detecting security vulnerabilities in Ethereum smart contracts written in Solidity, capable of identifying common issues such as integer overflow/underflow, reentrancy vulnerabilities, and dependencies on predictable environment variables like block.timestamp, enabling developers to quickly identify and fix security flaws in their smart contracts.
Ethereum Smart Contract Audit with Mythril: Solidity Security Analysis
Added:hi guys so today we're going to continue the blockchain security series of video and i noticed that last week with the fuzzing atram smart contract video a lot of you are really interested about this subject so today i decided to speak about smart contract analyzer and especially we're going to play with mithril that is one of the most famous one and was one of the most efficient so the reason i want to discuss about analyzer it's mainly because last week i mentioned that for fuzzying with etching lights complicated because you need to create your own invariant and so on so you need to have some manual work to be done and i want to show you uh kind of the opposite where you basically have nothing to do except just run the tools and after that um try to understand what's the issue um and how you can fix them so for that we're going to use this example the store dot sol so i will let you um if you want you can pause the video and try to find where is the vulnerability and i mean it's a really classical venability and basically we're going to use that as an example so we're going to use for that metric that is a tool developed by consensus diligence and basically this tool will analyze the evm by code in order to find some security venability so it will be some static analysis in that case and it will be really easy to use and really easy to install so for the installation you just need to do like pip3 installed material and after that you will be able to use like mid analyze and you are providing your file you can even provide some uh some evm bytecode directly so doing some analysis on the at the bytecode level and so on so that's the contract um so that's uh oh but and by the way this contract comes from one awesome um blog post and content created by my friend from sigma prime so solidity security blog and basically you have a bunch of vulnerabilities that are described with some real world example and so on so really i know some resources if you are starting with that i mean you have all the link on the description as usual so that's the target and right now what we're gonna do is actually to learn to to launch mithril uh directly on it so meet analyze ether stor sol so that's the command line and basically if you are running that you will get something like that so let me put that right there and um i launched the command right there and as you can see i'm getting some results and some stuff so let me show you more uh in deep uh what are the results and why um we are getting this research we're going to put that on the side like that so let's take a look as you can see i just launched the material tool and basically i'm getting a multiple result multiple potential vulnerability so in that case the first one is an integer arithmetic bug so you have the contract you have the service your severity you also have the swc id uh so that's um kind of like a database of um classical invulnerability in in reality um so uh it's really uh interesting then you have like the guest usage and so on and you have the description of the vulnerability so in that case there is some arithmetic operations that can overflow and an overflow and underflow can be um a real issue especially when you are dealing with like um amount of money and so on and balance in general you have which where it is and where which line exactly and as you can see last withdraw time of the message sanders so we are getting some previously stored value and we are adding plus one weeks so that's the keyword to to simplify the the stuff um it's actually this specific line right there i think yeah this one okay what is interesting uh after that is you uh material will give you all the requisite i mean all the um the basic state uh the initial state and the transaction sequence needed in order to trigger this arithmetic bug so in that case as an initial state we have a creator with a certain balance um and then we have the attacker with a balance and so on and we have another guy some guy with nothing on the balance and nothing on the storage okay what you can see is the transaction sequence is the following first of all we have the creator that will uh hold the stuff create the contract and so on and then we have um the color the some guy that will withdraw the phone and provide you in 256 with uh and it will be this specific transaction data so this transaction data i don't know if you are familiar with actually or smart contract work by the way let me know if you want to learn more about oh it worked internally and so on i'm planning to do like a video about um reverse engineering of evm bytecode so you will understand exactly how it works under the hood um so basically the tx data right there will be the address of the function you want to called so in that case it will be withdraw fund and as you can see withdraw from is this one and is taking an argument after that you have some value so in that case it seems that it doesn't really matter the main idea is if you are calling that twice potentially you can trigger the bug so let's take a look at the potential bug what you will see is that um this last withdrawal time with the message thunder with i will be actually a value that will be set right there so when you are doing the first call you will initialize the last result time with your message standard will be your own address so basically you will put some value right there and it will be no that's mean it will be the timestamp of the transaction um and basically what will happen is that this value will be stored and later when you are calling a second time withdraw fund you will get access to this value and you're going to do an addition on top of that so in that case the only way to trigger this integral arithmetic bug is if basically the return value of no that is basically blockchain times trump you need to take a look at what is this value will be star at this point and if you are doing that plus one week and you will and you are at like the maximum value it will overflow so in that case is it possible it's only possible if basically no will return like something really close to the maximum value of you in 256.
so in that case um we need to check what is basically the the range and type of value returned by this one but yeah it's pretty particular it can be checked something that you can do in every case is just to be sure in that case will be a potentially to use like a safe function for the addition you have for for example the safe mat library from open zipline that he's doing uh that is really useful if you want to do like a safe mathematical operation and prevent any overflow so that could be something to to fix potentially there is no vulnerability but at least we understand why mithril gave us this message and um and we know what we need to check just to be sure we are there is no way to trigger this vulnerability so that was the first one it was interesting let's take a look at the second one dependence on predictable environment variable so uh that's uh what i was telling you regarding the no and the no keyword basically no will give us the value of block times trump and as you can see the control flow decision is based on the block timestamp it's especially right there since we are asking to get the no timestamp metric is not able to know exactly what we're going to do with that and in that case since we have a require if we are we are getting access to this value this time term timestamp sorry and uh depending of the case either we will revert the execution if the require is actually failing and if the require is not failing everything is fine we will continue the the execution of the rest of the smart contract so it's clear in that case in one case based on the value we will either go in one side revert the smart contract cancel the execution or in the other side we will continue the execution so that's exactly what the this vulnerability description is mentioning the control flow the where you are going um in the in the smart contract the decision of that is based on some block timestamps some environment variable provided by the ethereum blockchain so that's really interesting that's the reason why we have this vulnerability and why it could be an issue it's basically um when you have it's something that was really common in like earlier smart contracts regarding um gambling and basically a lot of them was using the block stamp strum to basically generate the do the randomness generation and of course you can determine that in advance and you can in that case make sure you you're gonna win all the time so that's why we absolutely don't want to use any environment variable for randomness or something really critical in that case it's not an issue um since we we are checking some some stuff and at least it makes sense uh since we have some some limitation time of withdraw so we need to get this information but at least we know why we are getting what could be an issue and as you can see we are learning more and more about the potential vulnerabilities that can be involved in it in in evm smart contract we have another one external call to user supplied address and this one is actually really really interesting and that's one of the vulnerability uh i mean the main vulnerability of this smart contract so basically we have a call to a user supplied address so that's this one message sender call value and we are providing some data basically this stuff right there will be in charge to send the money back to the sender and the main issue with that is as the name suggests when we have an external message call to an address specified by the caller it's possible it will actually execute some arbitrary call on the other side so if your account the message sender is actually a user it's not an issue like a personal account but if it's a smart contract you can perfectly define some piece of code that will be executed by the smart contract and in that case it's the classical example of a re-entrancing venability because when we are going right there we're gonna withdraw some money we're gonna get some money back from this smart contract if it's called by another smart contract we're gonna get the money and we can perfectly say okay when we are getting the money i want you to call back this withdraw function and by doing that we will go at this point we're gonna call again this piece of code so we're going to go again on this piece of solidity code and again and again and again and we're going to loop forever right there without doing any modification on the balance of the thunder and that's the the round transceived normality so in that case he is not telling us okay that's a real entrance debug there is a real bug and so on is just telling us okay right there we are calling an external function and it's something to to take care of because potentially some piece of code will be executed on the other side so really important to take a look at that and if you have this stuff combined with this one um basically uh sorry it this one state accessed after external call that's basically this one that is like maybe more um that will define more specifically that it's around transit bug but this one is basically telling you we are modifying the state of the smart contract after uh doing uh an external call so uh that's a classical pattern of uh really intensive anomaly so we are getting the the definition to prematurance on the issue consider accessing the state only before the call especially if the cody is unjusted alternatively around round redundancy lock can be used to prevent untrusted codies from around trans re-entering the contract in an intermediate state so that's the kind of solution you have and basically we are modifying the set right there and the last venability is basically the same but for this specific line right there okay so that's all as you can see we are getting i don't know like one two three four five five vulnerability i think that have been detected by material some of them are false positive uh in all cases uh but still interesting to uh understand them and maybe uh there is some way to prevent uh having this this questioning regarding the security of this one and of course uh some of them was completely legit because there is a real transcendability in this smart contract so i hope it was like an interesting example for you and you learn some some stuff of course take a look at definitely all these blog posts and different vulnerabilities you have a bunch of resources i will maybe also do another video dedicated to like what are the best resources if you want to learn more regarding solidity and ability you can also take a look at the material documentation you will get a lot of stuff especially regarding like the different command line and usage you you can use and exploit in terms of arguments that are really interesting in material and finally if you want to have all the code resources and so on and also the the other one please consider enroll on my free courses and basically each time i will add some new stuff regarding a term security you will be aware and i will send you an email to let you know let me know if you have any question regarding that and any other proposal of tool or a smart contract and so on i'm really looking forward and yeah subscribe and see you in another video bye
Up Next

Fuzzing Solidity Smart Contracts Using Foundry: A Practical Guide
@fuzzinglabs
4.7K views•2023-02-10

Torrent File Format & Bencoding: A Technical Deep Dive
@AsliEngineering
12.5K views•2022-08-08

Ethereum Smart Contract Auditing with Slither: Solidity Security Analysis
@fuzzinglabs
6.4K views•2022-06-16

Understanding Ethereum: A Comprehensive Beginner's Overview
@99Bitcoins
3.1M views•2018-06-26
Related Study Plans & Knowledge Roadmaps
Structured learning paths in Blockchain & Crypto




![Solidity, a Smart Contract Language - Blockchain for Developers [Lab 01]](https://i.ytimg.com/vi/rwfENZJT-i0/maxresdefault.jpg)





















![[Fall 23] Lec10: Fuzzing and Symbolic Execution](https://i.ytimg.com/vi/0s19NUvhpPs/maxresdefault.jpg)











