 Alright, I am David Murdoch, I am the lead on Ganache at Truffle, and this here is Nick Paterno. Blockchain engine, or engineer, can 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. 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 depth as comfortably as possible. So I think sums up our goal pretty well. So we have three, kind of four, but 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. Who is aware of UI and CLI and Core? So who hasn't heard of one of those things? Which one? Core. Core, okay. Anyone else? Yeah, I don't know. Okay, so Core is the part of Ganache that does all of the heavy lifting. And so Ganache Core is a separate NPM project that CLI actually just wraps around. So if you do, like, 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. Yeah, just assume that your computer is compromised. Don't put that on mainnet. Please, yeah. So this is a trouble contract integration. So if you have a trouble 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, et cetera. That would be useful. And new as of yesterday, Ganache forking. Does anyone know what Ganache forking is? Nobody. All right, that's fine. Ganache CLI and fork mode. Has anyone seen that? You do? Right. All right, you come out and teach. Good. So Ganache forking is a really hidden feature of Ganache. It's now on UI. And the Apple version, you guys can download it when you know if it breaks or not. I literally published it yesterday, so it might not be too stable. But Ganache forking lets you easily 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 the gas used for them. 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 before writing it all? Yeah, so we actually just... So the accounts that you saw go slides back. So you actually... The way that works is we just lied 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. You 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 an 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. And 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 are that your byte code is public, so you can't hide your source code. So, you know, you shouldn't use security by security, 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 zero recourse. So some key concepts we're going to go over real quick. Gas fallback functions and re-entrance C. Sorry, I can't actually see that slide. To transact on Ethereum, you must pay a fee. This fee is paid in 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 state changes are persisted. So now fallback functions. These are functions that can execute operations as long as there's enough gas for it 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-existent contract function is called. Who hasn't heard of fallback functions? Okay. All right, I'll just won't go through this. Let's give up with that. And re-entrance C vulnerability. Does anyone know what that is already? You do? Yeah. Cool. Yeah, I'll 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 the most basic way I can define a range of C vulnerability for smart contracts is when a contract commits unintended re-invocation of any of its methods after calling an external contract during a single transaction. It was pretty intense. So I'll say it one more time. When a contract commits unintended re-invocation of any of its methods after calling an external contract during a single transaction. So another way of saying that smart contract re-entrance C allows for multiple invocations of other contracts and methods during the single transaction usually caused by forwarding excess gas to a malicious contract's fallback function without proper re-entrance C protection. So that's, there's a lot to take in there. And we're going to get into much more of this. So, a re-entrance to vulnerability example. Does anyone know actually where the vulnerability is in this code? We don't say, they say the balance is zero every single time. These are their methods and the contract and the contract. Yeah, so this right here? So, this line right here is a re-entrance to 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 withdrawal. And now the problem with that is that this line will execute I think I have all this set up here. Oh, wait. But I'm getting ahead of myself. We'll get there. Where am I? Too fast, too far. Right? Where's that right? Ah, it's good. The, uh, this thing right here. Call.value. So I'll just read this slide out. We'll skip for the rest of the time. 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 export together to 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 topic how to steal from people. 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 a 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, wine and ether into the victim, which is like 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 B-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 the support contract. So all you need to do is run Truffle test. So it looks like this. So this is, this is how you would deploy. So we're seeding into the one ether here, deploying it there and 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-entrance C, 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-entrance C. It was a re-entrance C 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. Well, questions? Anyone have any? Are we good? Can I skip a slide? So there's a bunch of ways to do re-entrance C protection in your contracts and methods. So one is this thing called 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 opens up ones like re-entrance C guard. And this basically is you have a voting value. You can call it lock or whatever you want, which would be true or false. And so when you come here 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 I just send and I just transfer and why those were added? Or one of the reasons why. Does anyone know? They added because of the address that call sending all of the remaining gas by default. And so that was seen as a vulnerability and that it wasn't clear that that would enable re-entrance C. And so what they did is they came up with either send and just transfer, which will automatically limit the amount of gas that's passed to 2,300-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-entrance C. And so now if you use add to send or add to set transfer and 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'm going to put in 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 terms of situation. Right, ish, again, complicated. So when that would happen, fallback functions could now call back in and perform re-entrance C because of Constantinople. We only caught this a couple of days before it was going to go live, which is crazy. So we're lucky 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 cannot, that will no longer work. So this is actually probably based from a contract that will be fixed before Istanbul goes live. But these three parts, or specifically the total, that would actually do like two S-loads or one S-load. And because of increased costs in the S-loads and a couple of other op-codes, 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-entrance C. So just remember that, that's the only thing. Just always be aware of that. So the honeypot. 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 we name things the way we want. So a honeypot is a way to trick the bat guy into becoming a vapor. And I forgot I wanted to tongue that. So there are several types of honeypots. This is you. You can go. You can go for this. There are three different sort of general types, actually that are really well laid out at a kidney after this. We'll be finding this link. But in general, it's sort of honeypots are the three main classes. We have a class of honeypots that interact with the Ethereum 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 EBM is actually just a well-defined set of rules and everyone should be sort of 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 days though. And then, for example, you have some things in blocking explorers. 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 truffle.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. We'll go ahead and skip it. It's a trace buster buster. So far, we've covered truffle, ganache, ganache forking, gas, fallback functions, redundancy, exploit, testing, and a DAO, Constantinople in Istanbul, redundancy, protection, and honey pots. 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 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 double check it. Okay. Any other questions? It's the same frequency of the year. If the transfer is same frequency of the year and transfer directly, where is next change? Okay, so same will be returnable and yes or no, it didn't. And then transfer will... Okay, so like revert? Okay, here we go. I think you had a point about honey pots. So honey pots is the contract that you deploy that you... Right, yeah. So a honey pot is kind of like an idea. You can have like lots of different types of honey pots. So in InfoSec, it would be called like a mouse trap. So like a honey pot in InfoSec 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 and try that way you can learn from them. So in InfoSec, a mouse trap is a way of trying to convince the attacker to come in to your network and give something up somehow. That way you can catch them and win that way. So we're actually... So an Ethereum number calls a honey pot or a mouse trap honey pot. So a honey pot is a contract that fools somebody an attacker into giving something up. And usually that's going to be easier. So you have transfer throws and send returns false So workshop time. We're going to take all of that and we're going to exploit or attempt to exploit a known honey pot on mainnet. 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 who don't know they uploaded their contract with a code to EtherScan except it wasn't their contract code. So even though EtherScan can verify 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 the Ether stored in the contract it would fail. So we're going to run this conash and we're going to see that it fails. And then we're going to run it locally in conash with forking enabled off of mainnet. And 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 just get 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 Ethereum tooling doesn't work on V12. If you want to use UIs because you're more comfortable in the UI try to download conash 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 from my laptop network if we have to. Or install conash CLI and you can use the global flag here. If anyone needs help with Node or NPM as known and then you will want to clone this link so that's where come going to this website will help you'll get this link pretty easily so clone this if you need help with that let us know and then run NPM install here again to workshop so ask your neighbor ask us and we'll help you stay with Clark.