WEBVTT 00:01.570 --> 00:05.170 Hey everyone, my name is Martin, thank you for having me. 00:05.210 --> 00:09.950 Today I will be talking about the seven phases of smart contract hacking. 00:10.030 --> 00:28.770 In this talk my idea is not to jump and dive into technical parts of what it means to hack smart contracts, but actually I want to give a little bit of perspective and try to talk about the bigger picture of what does it actually mean to hack smart contracts. 00:28.850 --> 00:46.490 So if you're a pentester, if you're a bug hunter, perhaps working in application security or other realms of information security, you can jump into the Ethereum ecosystem and start helping us secure the entire platform. 00:46.490 --> 00:56.430 So a little bit of background about myself, I'm Martin, I'm a security researcher at Open Zeppelin, one of the leading companies in smart contract audits in Ethereum. 00:56.830 --> 01:11.950 I'm a systems engineer, I'm doing a master's degree in cyber security and cyber defense at the University of Buenos Aires, and I used to work as a pentester mainly on application security, infrastructure, mobile applications, web applications at a big four. 01:12.290 --> 01:16.470 And then I jumped into being a security researcher here at Open Zeppelin. 01:16.910 --> 01:36.930 Well let's say again that you're a pentester, you might be a bug hunter, a white hat hacker, perhaps working in other realms of information security, but you're interested in blockchains and smart contracts, you have heard about them, because to be honest we have hit the headlines a couple of times. 01:37.150 --> 01:44.570 There has been many hacks in the latest months around smart contracts in Ethereum. 01:44.850 --> 01:54.350 So as you see, many hacks and in my opinion we need more and more security experts to jump into the field and to help us secure the entire ecosystem. 01:54.530 --> 01:56.890 So this talk is mainly aimed at you. 01:57.590 --> 02:00.690 And the question is if you can hack a smart contract, right? 02:00.730 --> 02:11.210 What knowledge do you have already that can help you out here in the smart contract world and that you can start applying today to start hacking smart contracts? 02:12.090 --> 02:21.150 And well the answer is yes, that you do have some knowledge, because you do know which are the seven phases, let's say, of a typical security engagement. 02:21.150 --> 02:26.690 And when I say seven, I don't mean to be strict with these phases that we will be talking about. 02:26.690 --> 02:48.530 It's just a way of organizing the talk, but perhaps when you do bug hunting, some phases you might skip them or you might do others, but the idea is to outline our work as security auditors or bug hunters or white hackers in these seven phases, so we can have a common language to talk about this. 02:49.310 --> 02:54.850 Well, these are the seven phases that I have, that we will be talking about. 02:54.850 --> 03:01.650 First, scoping, then reconnaissance, identification of vulnerabilities, exploiting these vulnerabilities that we have found. 03:01.650 --> 03:06.550 What does it actually mean to do post-exploitation in the smart contract world? 03:06.550 --> 03:10.610 And we'll be asking ourselves whether that's an actual thing or not. 03:10.690 --> 03:15.150 And then we'll be briefly covering reporting fixes and retests. 03:15.150 --> 03:17.370 So you might be already familiar with these phases. 03:17.370 --> 03:30.830 The idea of today is to see how these phases apply in the smart contract world and whether we can start drawing some parallels between these phases and the ones that you are used to applying. 03:31.110 --> 03:32.970 So let's get started. 03:33.450 --> 03:35.050 Let's talk about scoping. 03:36.110 --> 03:48.530 If you come from the, let's say, application security world or maybe doing pen testing for infrastructure exposed on the internet, you might be familiar with the fact that you have IP addresses, right? 03:49.330 --> 04:01.070 When you are scoping your work, you will be given IP addresses that will help you understand the systems that you are about to audit or to assess. 04:01.530 --> 04:04.330 In the Ethereum case, we also have addresses. 04:04.330 --> 04:06.430 In this case, we have Ethereum addresses. 04:06.450 --> 04:07.910 I know they are not the same. 04:07.910 --> 04:14.950 I know there are many differences between them, but the idea is to start drawing, as I said before, some parallels between the worlds. 04:16.050 --> 04:27.810 So we can think of these addresses as ways of allocating resources, let's say, in the first case on a network and in the other case on the blockchain. 04:29.290 --> 04:37.370 When you are working on smart contracts, you will not only have one Ethereum address, but you can have many Ethereum addresses that are related to each other. 04:37.370 --> 04:41.990 And you may not even have Ethereum addresses, but actually you can have domain names, right? 04:41.990 --> 04:50.830 As in the classic world, you have the DNS that will help you resolve from human readable names to actual IP addresses. 04:51.030 --> 05:02.150 In Ethereum, we have the Ethereum nice service, which will help you translate human readable domain names like johndoe.eth to Ethereum addresses, such as the one there. 05:03.250 --> 05:11.530 But sometimes, most times actually, you won't have... perhaps you won't have an Ethereum address or many addresses. 05:11.530 --> 05:14.410 You might only have Solidity source code. 05:14.410 --> 05:18.290 And Solidity is the smart contract language that we use nowadays. 05:18.290 --> 05:29.190 There might be others, but Solidity is the smart contract language that is high level and that can help you code smart contracts in an easy way, let's say. 05:29.190 --> 05:43.090 So you might be given a repository with these files or you can actually find that source code in Etherscan, which is the main explorer for the Ethereum blockchain. 05:43.150 --> 05:48.550 And at this point, engagement will become something like a white box engagement, right? 05:48.550 --> 05:59.230 You will have access to the source code, but there are ways, as we will see later, to actually deploy these contracts and to start poking around with them as a living program. 05:59.230 --> 06:05.210 So there are two ways, perhaps, of approaching the assessment. 06:06.350 --> 06:11.350 So if you want to go to Etherscan, you can find the verified source code there. 06:11.350 --> 06:17.050 This is, for instance, the source code for DAI, one of the main stable coins in the Ethereum ecosystem. 06:17.050 --> 06:20.830 And you can go to its address and retrieve the source code there. 06:20.830 --> 06:35.970 But if you don't have the code, you can actually decompile the EVM bytecode and try to read it in a nicer way using EVM, right? 06:35.970 --> 06:51.090 So this is a decompiler for Solidity code and will help you understand what's behind this sometimes difficult to parse EVM bytecode and will give you a more readable way to understand it. 06:52.650 --> 07:00.390 So again, you might have the source code, but if you don't and you only have an Ethereum address, you can use this decompiler that can help you out. 07:01.290 --> 07:06.710 Well, once we are done with this scoping phase, we move on to the second one, which is reconnaissance. 07:06.710 --> 07:12.270 In reconnaissance, we basically want to understand what's in there, right? 07:13.010 --> 07:17.310 So we might be given, as I said before, a list of files. 07:17.590 --> 07:23.730 And we are not only talking about one, two, three, but many, many and several files that you might be given. 07:23.730 --> 07:28.930 And sometimes the names of these files don't even make much sense at the beginning, right? 07:28.930 --> 07:33.270 So we see here like files named flap, flip, flop. 07:33.270 --> 07:37.070 And that is not so self-explanatory, to be honest. 07:37.170 --> 07:43.830 So we need to start looking deeper into the files and to actually understand what they are doing. 07:43.830 --> 07:48.470 But when we look deeper into the files, we will see Solidity code, right? 07:48.470 --> 07:52.230 This is what actual Solidity looks like. 07:52.390 --> 07:55.530 Just a brief example for those that are not familiar with it. 07:55.530 --> 07:59.270 It looks like another object-oriented language. 07:59.270 --> 08:02.110 At the beginning, the syntax is similar. 08:02.110 --> 08:09.050 As you go deeper and deeper into Solidity, you might start seeing several differences with other languages. 08:09.050 --> 08:15.190 But again, the first look of Solidity looks like another object-oriented language. 08:16.130 --> 08:33.190 But if you go to actual files, to actual Solidity files today being used in Ethereum, you will see that sometimes developers are not that clear with their intentions of the code, and you will see that functions have weird names, some variable names are not that clear, 08:33.190 --> 08:38.470 and you cannot make much sense out of the things that you are reading in the code, right? 08:38.470 --> 08:45.730 So it might be a bit disorganized or repetitive, or the function names might not be the best, as we see in these cases. 08:46.650 --> 08:57.230 But luckily, there are tools and there are things that we can start doing in this reconnaissance phase that can help us get more familiar with the code and understand what it's trying to do. 08:57.390 --> 09:14.090 So in this case, what we want is, we want to understand the architecture, the interactions between the contracts, we want to see where the contracts expose functions, because we need to use them as entry points for attacks, we need to see the inheritance chains of this contract, 09:14.090 --> 09:15.390 and many other things, right? 09:15.390 --> 09:19.010 But I want to make a special point on intention. 09:19.050 --> 09:29.350 We as, let's say, auditors or bug hunters looking at Ethereum smart contracts, we need to understand the intention of the code, right? 09:29.350 --> 09:41.730 Intention is not usually the same as implementation, so we need to find the differences between intention and implementation, and actually start digging bugs in that sense. 09:42.050 --> 09:49.770 So special attention to the intention of the code, not only what it's actually doing, but what it intends to do. 09:50.350 --> 10:07.290 For these three last points, for the roles of a system, the integration points, and intention, the work in reconnaissance becomes a bit of a manual work, and reading documentation, reading the code, reading pull requests, perhaps talking to developers, 10:07.290 --> 10:11.290 from those things we can start understanding these points, right? 10:11.290 --> 10:17.450 But for the others, there are tools that can actually help us in a really nice way, as we are about to see. 10:17.590 --> 10:38.030 So if you want to see some things about inheritance chains, for example, you can use EtherScan, we can use Surya, Slyther, which are tools that can help us print these kind of diagrams of inheritance, and can help us understand how do contracts relate to each other in a code base. 10:38.730 --> 11:02.010 Slyther, that is a static analyzer, can also help us see which are the exposed functions of a contract, so we can see whether it has many public functions, which are these public functions, to which contracts do they belong, and if there are private functions in those contracts related to these public functions. 11:02.030 --> 11:04.750 So Slyther can help us explore this. 11:05.610 --> 11:19.350 There are also IDE plugins, such as in Visual Studio Code you have the Solidity Auditor plugin, which is super useful, and as you see here in the GIF, it can help you track, for instance, function calls. 11:19.410 --> 11:30.790 Starting from a public function call, you can go all the way down to the private calls, and see whether in this way you can track different bugs in the code. 11:31.410 --> 11:37.570 And another thing that is super useful, that I at least myself find useful, are diagrams. 11:37.570 --> 11:48.230 So these diagrams are things that you can actually draw yourself, put together yourself, and can help you out really to find several bugs in the code. 11:48.230 --> 12:00.090 So give it a shot, try it out, please don't go so crazy on it, but again can help you understand the relationships between different contracts and functions and dynamics of the system. 12:02.090 --> 12:04.470 So that's about it with reconnaissance. 12:04.470 --> 12:17.010 We have seen tools, we have seen manual things that you can use, and now let's get on to one of the most interesting parts, I guess, which is vulnerability identification. 12:17.010 --> 12:23.790 So this is one of the main objectives of our assessment, is to actually find vulnerabilities in the code. 12:23.950 --> 12:32.470 And if you're a beginner with it, I wouldn't recommend you to start trying to hack smart contracts in crazy new ways. 12:32.470 --> 12:35.870 I would suggest that you start with the basics. 12:35.870 --> 12:49.950 So you might read the Mastering Ethereum book, you can read online databases of known attacks, we have the SWC registry which classifies vulnerabilities and with different test cases. 12:49.950 --> 13:02.250 Of course not all vulnerabilities, not all weaknesses in smart contracts, but the most common ones are there, and you can go ahead and read them and start learning which are the basics of smart contract security. 13:02.250 --> 13:24.050 But if you like learning as playing, like learning by doing, you can play the Ethernode by OpenZeppelin, which is a kind of a capture the flag challenge, a set of challenges actually, and it's super fun and can help you understand how to hack smart contracts and learn about security in that way. 13:24.450 --> 13:34.950 One thing that also always surfaces when we talk about vulnerability identification in smart contracts is this difference between automated and manual work, right? 13:34.950 --> 13:53.830 I think this also happens in, for instance, application security, where you might have scanners that can help you out identify vulnerabilities in an application, but also people or pen testers, hackers, tend to also do some manual work. 13:53.830 --> 13:58.490 So I guess it's always about complementing the automated and manual work. 13:58.490 --> 14:09.490 You shouldn't fully lean towards one or another, but doing both automated and manual work to find out these vulnerabilities. 14:10.510 --> 14:25.150 So in the automated realm, we find many tools that can help us out in Ethereum for smart contracts insolidity, or perhaps you don't even need for some of these tools, the source code, you can only have the EVM bytecode. 14:25.170 --> 14:29.510 We have Slyther, Manticore, Keyedna, Mithril, Veris, Solpacale, and many more. 14:29.710 --> 14:31.790 I won't dive deeper into this. 14:31.790 --> 14:37.790 The program analysis world is extremely interesting and it's a whole world on its own. 14:37.790 --> 14:41.670 The idea of this talk is just to briefly present them. 14:42.770 --> 14:49.370 And to also mention that, of course, the automated tools, while they are good, they might have bugs, right? 14:49.370 --> 14:57.350 They might not always work as expected, they might produce false positives, and they might not even find the most critical bugs. 14:57.750 --> 15:04.990 So last year, we ended up publishing a post when we found a critical vulnerability in the MakerDAO contracts. 15:05.110 --> 15:11.210 And we realized that many of the tools weren't capable of finding that type of bug. 15:11.210 --> 15:23.250 And the forum post became really interesting when the authors of these tools jumped in and started explaining the improvements that they were applying in the tools to actually find the bug. 15:23.250 --> 15:31.950 And I think that right now, many of these tools are already capable of finding this bug that we found at MakerDAO. 15:32.010 --> 15:40.070 So the automated tool world is always moving forward and coming up with new ways of finding vulnerabilities, and that's super cool. 15:40.290 --> 15:42.210 But also, we do manual work, right? 15:42.210 --> 15:46.830 In this case, we focus on the business logic and the intention of the code. 15:47.330 --> 16:03.510 And this actually means that, at least in my experience, most of the most critical bugs that I have found in smart contracts come actually from business logic and not from, let's say, solidity common patterns. 16:03.750 --> 16:16.190 So by understanding the business logic of the contracts, you can actually start highlighting these differences between implementation and intention and start coming up with different attack vectors to break the contract. 16:16.690 --> 16:20.790 Special care should be paid to sensitive functions. 16:20.790 --> 16:37.590 And when I say sensitive, I mean functions that may have convoluted and mixed logic, functions that, let's say, handle decimals, arise signatures, which are usually not so straightforward to do in solidity. 16:37.590 --> 16:44.790 So usually developers need to come up with different hacks to implement, let's say, handling decimals. 16:44.790 --> 16:46.750 So there might be bugs there. 16:46.750 --> 16:57.170 Dangerous math, functions making external calls to untrusted contracts is also something that we should be paying attention to. 16:57.310 --> 17:10.090 And uses of assembly or low-level calls in solidity is usually a good source of vulnerabilities that I have seen in my years doing smart contract audits. 17:10.090 --> 17:18.970 So again, some of these are really important things that we should be paying attention to when we are assessing smart contracts in a manual way. 17:19.010 --> 17:20.370 But there are more, right? 17:20.370 --> 17:24.650 So we can also pay attention to the interactions with external dependencies. 17:24.650 --> 17:43.810 And in this case, let's say, other protocols, price oracles, decentralized exchanges, are points of interaction that sometimes can trigger different dynamics, different functionalities or unexpected things in the system that we are trying to break. 17:45.030 --> 18:02.550 Another thing to pay attention to is the impact of these dynamics, of novel dynamics, extreme unexpected ones, that perhaps the developers didn't take into account when they were developing the system and we should be paying attention to. 18:02.550 --> 18:08.610 So for instance, flash loans have been the big new thing recently in DeFi and Ethereum. 18:08.610 --> 18:22.070 With the introduction of flash loans, we have found that many projects ended up having problems in their dynamics, in their incentives, just because flash loans were available to everyone in the ecosystem. 18:22.710 --> 18:27.790 Having a clogged network is also something to take into account when we are analyzing smart contracts. 18:27.790 --> 18:34.030 What happens if the network is highly congested and transactions cannot go through? 18:34.170 --> 18:44.670 What happens if the price of ETH goes down by half and how would this project that I'm analyzing would react to that? 18:44.670 --> 18:49.990 Another cool thing going on right now in Ethereum is front-running, back-running and transaction ordering. 18:49.990 --> 19:02.430 So there are lots of bots right now in mainnet playing with front-running and back-running and these are things, really interesting things, that we should also take into account if we are trying to find vulnerabilities. 19:02.430 --> 19:07.830 How would the project, the contract we are seeing, react to these kind of things? 19:10.280 --> 19:16.840 Well, once we have found vulnerabilities, it's time for us to exploit them. 19:16.920 --> 19:23.300 Another fun part of doing security research is actually exploit the things that we found. 19:23.680 --> 19:45.680 To do exploiting, what we want is first to have a reproducible attack vector and that means to have some way of sharing with the client, sharing with the bug bounty report that we are about to submit, that we have a reproducible attack vector and we are proving actually that there is a vulnerability and that can be exploited under a certain scenario. 19:46.020 --> 19:52.900 And we also need to understand the impact that actually exploiting this would have in the system. 19:53.760 --> 20:09.720 And for the impact, to be honest, we usually also need to see or to actually to understand how would the system work and how the system reacts to our exploit and what is the actual impact in the business logic of the system. 20:09.720 --> 20:16.700 So we need some knowledge, business logic related knowledge, to the system that we are assessing. 20:18.460 --> 20:24.060 To do exploiting, my recommendation is to also try your exploits in a local testing environment. 20:24.060 --> 20:26.580 You shouldn't do that at mainnet, of course. 20:26.580 --> 20:29.440 So you can first spin up a local node. 20:29.440 --> 20:32.100 You can do that with ganache or with geth. 20:32.120 --> 20:37.800 Geth allows you to have a development mode so your test will run faster. 20:37.800 --> 20:41.920 And with ganache, there is a cool feature that you can do is to actually fork mainnet. 20:41.920 --> 21:02.000 And so you can point ganache to a, let's say, a full node, fork mainnet into your local environment and actually run your exploits as if they were to be run on mainnet, but you will be like causing no damage to any project out there. 21:02.180 --> 21:12.400 To interact with nodes, you can use, if you are hacking on javascript, you can use web3js or ethers, but I think that web3 is also available for python. 21:12.400 --> 21:34.120 And if you are wanting to do bigger things that perhaps it would be too difficult to only do with web3js or with ethers, you can use biddler or truffle, which are kind of frameworks or task runners that can help you do more crazy and bigger things with your exploits. 21:34.720 --> 21:38.420 These are the ones that I personally use and the ones I recommend. 21:38.420 --> 21:42.240 But of course, there might be others out in the space that can help you out too. 21:42.520 --> 21:59.080 If you want to see some exploit examples actually using some of the tools that I just mentioned, we have published in the OpenSampling GitHub repository an exploit for the Uniswap vulnerability that was found by another auditing company, by Consensus Intelligence, 21:59.080 --> 22:10.320 last year, and that we ended up publishing a proof-of-concept exploit on how that vulnerability can be exploited for some kind of tokens in Uniswap pools. 22:10.640 --> 22:18.060 And the exploit is readily available there and is public and for you to see and run it in your local machines. 22:18.060 --> 22:28.900 Interestingly, this exploit was actually, I don't know if this particular exploit, but the vulnerability was later exploited in the wild in some real Uniswap pools. 22:29.540 --> 22:35.840 I have also published myself some exploits examples in my GitHub repository. 22:36.180 --> 22:47.880 And in February this year, for example, we also at OpenSampling published a way to backdoor non-c-safe wallets, one of the most popular wallets in the space, during deployment. 22:48.280 --> 23:01.780 And in this post, I'm leaving you the link there, in this post we are actually publishing the proof-of-concept exploit on how to backdoor non-c-safe wallets during deployment. 23:02.700 --> 23:08.700 But also we have the possibility to reproduce real exploits in Ethereum. 23:08.700 --> 23:20.860 So you can see here a transaction, an execution trace of a transaction that actually stole more than 24k USDC last week on a project in Ethereum. 23:20.860 --> 23:34.960 On mainnet this is real and the attack not only was made up of this single transaction but many transactions and caused a lot of fund losses in this project. 23:34.960 --> 23:39.140 So you can actually see these transactions because transactions are public in Ethereum. 23:39.140 --> 23:48.040 You can see the interactions between the contracts and you can even go ahead and reproduce these real exploits on your local environments. 23:48.040 --> 23:50.440 So that is something pretty cool. 23:51.660 --> 23:58.020 Well, moving on, after exploiting we can begin talking about post-exploitation, right? 23:58.020 --> 24:06.960 So the big question here that I've been asking myself when preparing this talk is if this is even a thing, right? 24:06.960 --> 24:30.540 So in the application security world perhaps you might be thinking of pivoting, opening a shell, moving to other systems, jumping around the network, but perhaps in the smart contract world that is not possible or it is not that easy to draw a parallel between the smart contract and other worlds. 24:30.580 --> 24:46.500 So again, we shouldn't think of having a shell here but perhaps we can start thinking about, when thinking about post-exploitation, we can try to extend or elevate access to the smart contracts. 24:46.500 --> 24:56.100 We can cause further consequences in our components or even in other protocols by going beyond the exploited system that we are assessing, right? 24:56.100 --> 25:03.580 So in that sense there might be some parallels between in this post-exploitation phase. 25:04.360 --> 25:11.240 So let's go to an example to better see what I mean by post-exploitation here. 25:11.240 --> 25:15.000 So let's see a compromised oracle case. 25:15.040 --> 25:26.460 In this case, let's imagine a platform that is selling collectibles, is selling these kitties and you pay ETH and it will give you away some kitties depending on how much ETH you have paid. 25:26.720 --> 25:37.900 But this platform actually uses the price in ETH of these kitties but uses a price oracle to fetch the price in ETH, right? 25:37.900 --> 25:45.000 The price oracle is basically another set of contracts where the price in ETH of these kitties is registered by someone. 25:47.620 --> 25:59.960 But in this case, if you can end up finding a vulnerability in the price oracle and you can compromise the price oracle, you can actually compromise the system that is relying on that oracle, right? 25:59.960 --> 26:09.440 Because you can set, for instance, the price in ETH of this collectible to zero, you can send a transaction to buy all kitties and you can steal away all kitties in this platform. 26:09.580 --> 26:18.820 And that is not also true for a single platform that relies on this oracle, but it's also true for all platforms that are actually relying on this price oracle. 26:18.820 --> 26:22.340 This is an actual problem that I think that we have nowadays in Ethereum. 26:22.340 --> 26:38.880 The more projects that are relying on a single oracle or just a small number of oracles, the greater the incentives, the economic incentives to attack a price oracle, to compromise it and to basically pound every single project depending on it. 26:38.900 --> 26:42.360 So this is basically what I mean with post exploitation. 26:42.360 --> 26:51.620 We can compromise an oracle and by doing that we can move on to other projects and execute attacks in them as well. 26:53.990 --> 27:10.310 Moving on, we have this last phases which is about reporting, doing fixes, retests and I believe that there are many similarities with other information security realms. 27:10.490 --> 27:13.410 So I don't think I should dive deeper into this. 27:13.830 --> 27:28.010 Of course we do reporting, of course we review the fixes for our clients, of course we do retests to make sure they haven't reintroduced the vulnerability and have actually fixed the things that we have reported. 27:28.010 --> 27:30.790 So we do all of that, that is basically the same. 27:30.790 --> 27:41.290 But one thing that we should be highlighting here is that in the Ethereum world most, if not all, but most security reports are public. 27:41.290 --> 27:43.450 That is something that you don't see in other worlds. 27:43.450 --> 27:55.570 That is something that, for instance, me working as a pen tester for banks in my previous job, I wouldn't have even imagined that I could at some point make public a report, right? 27:55.570 --> 28:11.870 But in the Ethereum world that is true, you can do that, of course agreeing that with the client, but I think everyone is encouraged to actually public their security reports because in that way we can all improve the ecosystem, we can all learn about the best security practices, 28:11.870 --> 28:30.490 which things might not be the best for some types of projects, and also to have perspectives of other security auditors in the space and learn from each other and make everything in the open and as transparent as possible. 28:30.490 --> 28:48.150 So we have public security reports and you can go to, for instance, our blog at OpenZeppelin and many other companies as well are publishing their reports and you can read them and learn tons about smart contract hacking and security and research just by reading those public security reports. 28:48.150 --> 28:52.890 So that is something that I wanted to highlight because I think it's super valuable in the space. 28:54.690 --> 29:01.150 Well, and to end this talk I wanted to leave you with a little surprise, right? 29:01.150 --> 29:17.690 I don't think today I have covered many things on the technical side just because I wanted to, as I told you at the beginning, I wanted to give you the bigger picture of what does it mean to hack smart contracts and how do we structure our engagements. 29:19.090 --> 29:30.110 But if you actually want to look at code and run some exploits and try to break smart contracts, I think you might find this super useful and entertaining. 29:30.110 --> 29:37.370 It's time for you to start hacking smart contracts so you can start applying all these learnings from these phases that I have been telling you about. 29:37.370 --> 29:54.550 You can go to my github repository, it's already public, and you can start hacking a set of smart contracts that is based on a governance system using flash loans and token snapshots, all things and features super popular nowadays in the FIFA space. 29:54.550 --> 30:02.870 And here you have an example on how that can be severely broken and you can be the one attacking it and breaking it. 30:02.870 --> 30:10.270 So please have fun with it and hope to get some feedback on that if you happen to play it. 30:10.670 --> 30:19.390 So thank you very much, you can contact me on telegram, on twitter, on github and all these platforms. 30:19.430 --> 30:28.810 You can find me as Tim Chavate and you can learn more about information security related to smart contracts in our forum, in our blog at Open Zeppelin. 30:29.670 --> 30:40.510 I'm happy to help you out with anything related to this and please ping me if you find this interesting. 30:40.510 --> 30:41.430 So thank you!