 Alright, I am David Murdoch, I am the lead on Ganache at Truffle, and this here is Nick Paterno. Blockchain engine, or engineer, could sit in the slide, so it's short. And we're going to Ganache and Truffle teams. Yup, so if you have Ganache questions, we are the people at Truffle to ask. Let me move this a little closer. So you all probably know who Truffle is, I don't know if that's new to anyone, but if you don't. So Truffle is a company whose goal is to build tools to get developers from idea to gap as comfortably as possible. So I think sums up our goal pretty well. So we have three main open source tools, so one is Truffle, which is a dev environment testing chamber in asset pipeline for blockchains, Drizzle is a front end library for gaps, and then of course Ganache, which is your one-click blockchain. So what is Ganache? So Ganache actually comes in three variants, and most people think of Ganache as a UI. What do you guys think? Who is aware of UI and CLI and Core? So who hasn't heard of one of those things? Which one? Core. Okay. Anyone else? Yeah, actually I don't know about Core. So Core is the part of Ganache that does all of the heavy lifting. And so Ganache Core is a separate MPM project that CLI actually just wraps around. So if you do like a require Ganache Core in your project, then you will get the provider and the server that CLI give you and you can access it through programmatic access rather than on the CLI. So this is what Ganache UI looks like. This is the main account screen that starts up. You get 10 accounts by default. You have a mnemonic. Don't put that on mainnet, please. Just assume that your computer is compromised. Don't put that on mainnet. Please. Yeah. So this is a truffle contract integration. So if you have a truffle project, you can add that to Ganache UI and you can actually see all of your deployed to your local testnet Ganache contracts there, how many transactions there are, etc. That would be useful. And new as of yesterday, we have Ganache forking. Does anyone know what Ganache forking is? Nobody. All right. That's fine. Well, Ganache CLI and fork mode. Has anyone seen that? You do? You're right. Okay. All right. You come out and teach. All right. Good. So Ganache forking is a really hidden feature of Ganache. It's now on UI and the alpha version, you guys can download it. Let me know if it breaks or not. I literally published it yesterday, so it might not be too stable. Ganache forking lets you easily, easy mainnet testing without the cost. So what that means is inside of Ganache UI, you can now select mainnet like from Amfura as provider, or you can put your own provider in. And Ganache will then fork at a specific block number that you specify or latest. And so when you start up Ganache, you will actually get instantly, well a couple seconds, these are mainnet block numbers right here. And the dates that they remind, and they got used for that. And all of the transactions are here without syncing. And additionally, when you now run your contracts against your local Ganache, it actually emulates being on mainnet. Does that sound good? So risk-free. No cost, so you can deploy your contracts to mainnet using other contracts that are deployed on mainnet. So sorry, to Ganache UI, like it was on mainnet, so it's like fully emulating mainnet. So it's like you fork right at this block number here, 4 o'clock. And all the data that is on mainnet is now available to your contracts on your local machine. Pretty great feature. Any new transactions will then go on the fork, so you're sort of risk-free access. And then if you had to access some state or data that was previously on the chain, we'll just request it from your provider. Questions for that? So how do you get this on mainnet to help you? Do you initialize a new client or write it off? Yeah, so we actually just... So the accounts that you saw from slides back, so you actually... The way that works is we just lie to the state and we just say each of these has 100 eighths. So that's just the default. And so we do the same thing with forking. As soon as we fork, the very next block number is an empty block that basically just changes the state. We just kind of force it to happen. In addition on that note, actually, we also allow you to sort of pretend to be any account that you want. So if you want it to be issue transactions on behalf of an account that you have... Yeah, you could be account zero if you wanted. Right. So... Yeah. So technically you could use mainnet accounts? Yeah. Right, so you can emulate that. So you can unlock those accounts if you wanted to in your local instance and test for those. So you could pretend to be the Dow hacker and hack the Dow. So, excuse me, Ethereum development is kind of high risk. Actually, earlier today we burned some Ether trying to deploy and it failed. And, you know, we shouldn't have, but we did. And other issues, your byte code is public, so you can't hide your source code. So, you know, you shouldn't use security by obscurity, but in a way we all kind of do in normal development. But Ethereum's a little different. All your contracts are public, so anyone can run their software. And I think you all know this, but meanwhile the hackers are private and anonymous, and there's no recourse for if your contract gets strained. You don't know who that is and there's no jurisdiction that can come after those people. So if you mess up, you or your users lose big. It's your recourse. So some key concepts we're going to go over real quick. Gas, fallback functions, and re-entrant C. Sorry, I can't actually see that slide. To transact on Ethereum, you must pay a fee. This fee is paid with gas. Gas is paid for in Ether. Operations on Ethereum, like sorting and treating data, transferring funds, amount of operations, looping. All that requires some amount of gas. Generally, if a transaction attempts to use more gas than it is given, the transaction fails and those fake changes persisted. So now fallback functions. These are functions that can execute operations as long as there's enough gas for you to it. A fallback function must be external, and it is the unnamed function in your contract. It is called when a contract's address is sent Ether, or a non-existing contract function is called. Who hasn't heard of fallback functions? All right, I'll just won't go through this. Just skip over that. And re-entrancy vulnerability. Does anyone know what that is? Already? You do? Yeah. Cool. Yeah, call with you. So this will be fun. So, I don't know, we spent like an hour trying to come up with this line. We tried to get it down to one, but it couldn't. So the kind of most basic way I can define a re-entrancy vulnerability for smart contracts is when a contract permits unintended re-invocation of any of its methods after calling an external contract during a single transaction. It was pretty dense. So I'll say it one more time. When a contract permits unintended re-invocation of any of its methods after calling an external contract during a single transaction. So another way of saying a smart contract re-entrancy allows for multiple invocations of other contracts and methods during a single transaction usually caused by forwarding excess gas to a malicious contract's fallback function without proper re-entrancy protection. So there's a lot to take in there. And we're going to get into much more of this. So, a re-entrant vulnerability example. Does anyone know actually where the vulnerability is in this code? It's in the balance you see off every single time. These are the methods in the contract. So this line right here is a re-entrancy vulnerability. And the reason for that is sender.call.value will pass all of the remaining gas that's left for this transaction into the sender. And so if sender is a contract with a fallback function that is payable then this sender will be able to execute additional transactions after the fallback function is called. And so one of those transactions may be to recall what's drawn. And now the problem with that is that this line will execute. I think I have all this set up here. Oh, wait. I'm getting ahead of myself. We'll get there. All right. Too fast. Too far. All right. Where's everybody? Oh, it's good. This slender. So before we get started, I'll teach you guys how to do this. Just remember, just because you can, doesn't mean you should. The intent of this workshop is to teach you how to protect your contracts. It is not to teach you how to exploit other contracts. So don't steal. Be legal. Be nice to people. This is for testing your own contracts in a real-world scenario. Yeah. So don't say a truffle talking how to steal from people. Yeah. So I was getting ahead of myself there. I really wanted to start on this. So it would be an example of an attacker's contract that they upload in order to meet that. So this down here is the fallback function. And so we saw that in that contract earlier that it could be re-entered. And so I'll show you how that works here. So what happens is, initially, one of the cases in the contract is to seed it with some amount of value. And so what it's doing here is it's depositing, let's say, one of these are into the victim, which is the contract we saw just a couple slides ago, into that contract. So they now own that ether as their own balance in that contract. So the attacker then would call the be-back function, which would then call withdrawal. And now this would all work wonderfully. So this withdrawal would then just withdraw this one amount of value. But because of this hacker being a little bit clever, they implemented this fallback function. And what this function is going to do is after the original contract gets this amount from the caller, from this contract here, it'll get their balance and it will record that and then send that amount back to the contract. And at which point the contract will then be able to go into this fallback function and call withdrawal again. And so what this then does is re-enters and checks the balance. But we haven't zeroed out the balance yet in the original contract. So this balance is still the full one ether. And so this is the second time we've been here. And so the next line is going to be to call that fallback function again. And so we're back into the bad guys contract and what are they going to do? They're going to withdraw yet again. And they can do that as long as they have enough gas. So that's what this little check here is. It just checks gas to make sure that the transaction won't fail. So pretty crazy. It happens in the real world. So this is an example of how you would execute this sort of attack. Using Truffle to run your test. So the attacker would deploy their contract to mainnet and execute the attack in its third contract. So all you need to do is run Truffle test. So it looks like this. So this is how you would deploy. So we're seating it with the one ether here. Deploying it there. It's executing the attack. That's it. That's all it would take. So what we've covered so far. Truffle, Gnash, Gnash forking, gas, fallback functions, re-entrancy, the exploit, and a little bit about Truffle test. Any questions so far? Someone else. So we've all heard of the Dow hack. And the Dow hack was a hack that was based on re-entrancy. It was a re-entrancy vulnerability in this function right here. So they are in this function here. They are sending all of the remaining gas to the recipient. And that enabled the recipient to call back into this function. It was actually much more complicated than this. There was several methods that they had to go through and kind of configure in order to get this payout to be called again. But this is how they did it. Any questions on that? I'll leave it open for a second. Questions? Anyone have any? Can I skip a slide? So there's a bunch of ways to do re-entrancy protection in your contracts and methods. So one is this thing called check-effects interaction pattern. And so where first you do a check. So you see that their balance is greater than zero, for instance. And then you perform the effect that an interaction will have. So this is you zero out the balance before you send it, which is what you were saying earlier. And then once you do the effect, then you finally run the interaction. Another way is using locking or mutex or open zeppelins like re-entrancy guard. And this basically is you have a volume value. You can call it lock or whatever you want, which would be true or false. And so when you come into the first time, this requires them to pass. And then you would immediately lock it. So now if anything happens when you do the things, this condition will fail because lock is now true. And then when you're done, just make sure that you unlock your contract. If you don't, if there's an error and this lock doesn't unlock, then you can effectively lock your contract preventing you from interacting with it. Okay, got to have myself. And this is really important. Who has heard of address send and address transfer and why those were added? Or one of the reasons why. Does anyone know? So these were added because of the address that calls sending all of the remaining gas by default. And so that was seen as a vulnerability in that it wasn't clear that that would enable re-entrancy. And so what they did is they come up with address send and address transfer, which will automatically limit the amount of gas that's passed to 2300-ish. It's complicated, but what that did was effectively make it so that it was too expensive to do anything in a fallback function that could possibly result in re-entrancy. And so now if you use address send or address that transfer to send that ether, the fallback function would be stuck there. It wouldn't be able to get back out into your contract, which sounds great. It sounds like that would fix everything. And it did. But the problem was... I pointed two slides again. Constantinople. Everyone knows about Constantinople, I'm guessing. It's great. So Constantinople had an EIP that actually lowered the minimum gas cost for storage from 5,000 to 200 gas in certain situations. Right. Again, it's complicated. So when that would happen, fallback functions could now call back in and perform re-entrancy because of Constantinople. We only caught this a couple of days before it was going to go live, which is crazy. So luckily we caught it. It was removed and never made it to Mainnet, also ish. Because it actually is active on Mainnet, which is a fun fact. And then there is Istanbul. Istanbul's increased gas costs actually kind of do the opposite as Constantinople's decreases were doing, and that there are now functions on live contracts that will no longer work. So this is actually a copy-pasted form of contract that will be fixed before Istanbul goes live. But these three parts, or specifically the total, that would actually do two S-loads or one S-load. And because of increased costs in the S-loads and a couple of other op-dodes, this will now fail every single time. There's no way for this to pass under Istanbul. So the point being that you cannot rely on gas costs to protect against re-entrancy. So just remember that, that's the only thing. Just always be aware of that. So the honeypots, honeypot is fun. Has anyone heard of a honeypot in infosec? Yeah, so honeypots in infosec are actually a little bit different than what we call honeypots in Ethereum, but we're going to keep calling it honeypot because that's just meaning the story we want. So a honeypot is a way to trick the bad guy into becoming a vapor. And I wonder the time that. So there are several types of honeypots. This is you. You can go. You can go for this. Sure. There are three different sort of general types actually that are really well laid out at a KNDF area that you can find at this link. But in general, the sort of taxonomy of honeypots are the three main classes. We have a class of honeypots that interact with Ethereum and virtual machine, some that happen during compilation, and some that are actually just due to misleading or missing information on a blocking explorer. So for example, like EVM is actually just a well-defined set of rules, and everyone should be sort of or has access to those rules. However, given the implementation of some contracts, they could look sort of non-intuitive and therefore would be able to trick you. Some bugs actually exist in the Solidity Compiler. They're actually usually very well documented, but there can be some that have not been discovered yet or that are sort of zero-day sold. And then, for example, you have some things in blocking explorers. For example, there was a time where Peter Scan only showed you 80 characters wide, and if you were to upload a contract that had something outside of that, you wouldn't be able to see, say, that there was a send or a transfer or something. So that's the general gist, and we'll go into some of these later. So this next slide is fun, but you're not going to hear it. So just load the slides up. Oh, some people came in. So make sure you go to these slides at trouble.co.com. So this next slide I'm going to skip over, but it's fun, and I spent too much time on it, so you guys should check it out. Just tell me if you liked it. It's a trace buster buster. So far we've covered truffle, ganache, ganache forking, gas, fallback functions, re-intensity, exploit, testing, and a dow, Constantinople and the Istanbul re-intensity protection, and honeypots. Questions about any of that? Yes. Do you remember the difference to something about the way it fails, right? If I recall correctly, it's... I believe it's what is passed along as your message.sender and sort of like a context of news calling. Yeah, I think it is just the way that it fails. There's actually a really excellent answer for it on Stack Overflow. I just can't remember which one does what. I'm going to do a little check. Any other questions? It's sand, re-intensity of the year. So if the transfer is sand, re-intensity of the year, you can transfer directly the words in exchange. Okay, so sand will return a Boolean, guess it works or no, it didn't, and then transfer will... Okay, so like re-mark. Okay, here we go. I think you had a point about honeypots. So honeypots is the contract that you deploy that you get. Right, yeah. So a honeypot is kind of like an idea. So it's like... You can have like lots of different types of honeypots. So in an info set, it would be called like a mousetrap. So like a honeypot in an info set is just like a deterrent or a way to learn about your attacker. So you set up a network that looks open and see what the attacker does if they try. That way you can learn from them. So in an info set, mousetrap is a way of trying to convince the attacker to come into your network and give something up somehow. That way you can catch them and win that way. So we're actually... So in a period of calls, a honeypot or a mousetrap honeypot. So a honeypot is a contract that fools somebody and attack her into giving something up. And usually that's going to be easier. So yeah, transfer throws and send returns false on failure. Alright, so workshop time. We're going to take all of that and we're going to exploit or attempt to exploit a known honeypot on magnet. And so as an overview, what we'll be doing is taking the code that we see on EtherScan so that this person that uploaded this contract, maybe it's one of you, if you don't know, they uploaded their contract code to EtherScan except it wasn't their contract code. So even though EtherScan can verify this right by code, there's some tricks in there that make it actually behave differently than what you see in the code. And so we're going to see how, if you just wanted to exploit this because you're a bad guy and you wanted to steal EtherScan stored in the contract, it would fail. So we're going to do that. We're going to run this and we're going to run it locally in Gnash. And we're going to see that it fails. And then we're going to run it locally in Gnash with forking enabled off of main network. The conference Wi-Fi is a little rough, but we're going to try anyway. And yeah, it'll be fun. So everyone needs to go to Workshop. We'll go to this slide. Make sure you download Node.js. I just put 10 there. It should work on 8. It will likely work on 12. I found a lot of theory and tooling doesn't work well on V12. If you want to use UIs because you're more comfortable in the UI than trying to download Gnash UI Alpha, I can also try to set up... I have all the versions for Mac, Windows, and Linux on my laptop. And so I can give you links to try to download them direct from my laptop network if we have to. Or install Gnash CLI. And you can use the global flag here. If anyone needs help with Node or NPM, it's no. And then you will want to clone this link. So that's where... Come join to this website. We'll help you get this link pretty easily. So clone this. If you need help with that, let us know. And then run NPM install here again. It's Workshop. So ask your neighbor. Ask us and we'll help you. David Clark.