 I literally finished these slides 10 seconds ago and, oh. Taste, yeah, yeah. And I'm kind of still chat-less and I have this really weird headache that's dropping on the top of my head. I never had this before. So it might be a little less enthusiastic than normal, but I did my best. So, I'm going to talk about smart complex security bug. This is the definition of a security bug from Wikipedia. And a security bug is an error in a user-programmed system that causes it to produce an incorrect and unexpected result for what to behave in unintended breaks, right? This can take a lot of forms. I'll come to that a bit later. How can tools help you to develop more secure smart complex? So first of all, tools can never completely replace your own expertise. We always meet people to look at the code, understand the business logic, write custom tests. So there's a lot of ground that you can cover just using automated tools, but I don't think there are no simple tools. You have to use them correctly. If you use them properly, they can do a lot of nice stuff. On the one hand, they can prevent a lot of complex during development, where we know these are bad patterns that you shouldn't use or, at some point, the complex is really, really broken. It's really obvious when tools can detect it, isn't it? And they can also verify that your code behaves correctly if you know how your code is supposed to behave. But for that, you will need some specifications or more detailed configuration. And there's a lot of tools on the open source. There are analysis with a smart jack. Then there are analysis and body execution. I'm not going into too much detail here. So in this talk, we're going to talk about X, which is the smart contract verification service that we've been focused on building for the past year. And the goal with X was to combine some of the best ideas and techniques into a system that makes it easy to use this powerful stuff for normal people. And tiny to common development environments like traffic, gimmicks, and command-rank lines. So the way it works, this is a very smart contract to the HDI. And we will split up and send it to several microservices that all perform different tasks. We have a symbolic analyzer for a new field that's also available in the open source. And we have a couple of new tools that we have built internally that complement the analysis. And we can also do a lot of post-processing with that and by combining the tools results, improve the results overall. Let's start with an easy to detect fast. There are some behaviors that almost always are best. For instance, if anybody can go and kill your contract without any authentication, it's most likely death, right? Another thing would be, for instance, anybody with arbitrary address can withdraw all the user from their contract. So if the tools detect something like this, you can have high confidence that's something you don't want. It might still be wrong, but it's right in 99% of the cases. And this is the classic example from parity for an algorithm. So as you know, this was killed in 2007, I think, and got $150 million worth of ETH stuck in it, which is still stuck very well and causes a lot of contention in the community. So what happened here is, it's basically a mix of different things, right? So it's generally not good architecture to build a library like this. And on top of that, it's difficult to initialize an important variable in set component for the library. And they have a kill function in there. So because the wallet was not initialized correctly, it was possible to make oneself the owner and kill the company. And some did it and destroyed all the contracts and I rely on the codes of that library to be available. So one technique that works very well with this type of back-to-the-year, but you can just symbolize execution. So if you look at this solidity code, usually when the end executes this code, you get something called a concrete execution trace. So there's one variable in this variable and it's either true or false. You can add two possible outcomes and in one outcome the cat dies and I want the cat gives you. So what we're doing in symbolic execution is we look at all the possible states. And you can see here, when the area looks at the state of the call data, the percentage of function, the possibility is split into two possibilities, but our engine will know both of these. And the awesome thing is that you get propositional formulas that tell you exactly what values the variable need to have to reach the state. If you can just solve the formula. So in this case, the symbolic execution engine can determine that if this variable is set to false, then you get the scheme. So limit X API itself is just an API. We need to still need a frontend to use it and we have tons of frontends, little ready. Many of them are listed on our website. There's also an awesome list somewhere and they were at this really long. Let me just pick that. Yeah, right, so that's here on GitHub. You just pull before that you will find it, easily. So we have integration for remakes, truffle, visual studio code, native integration with Browning, which is a really awesome Python framework. We simply reached 0.0. Yeah, and we also have standalone command rank lines. This is basically an official one and then there's a couple of parts on it once. And if you want to build your own tools on top of your tool, we have language bindings for different environments. All right, I'm just gonna show you a quick demo. Table is a command line line that I prefer to use because I wrote it and I know how to use it and I just made it on a switch to the other platform. So this should take probably a couple of minutes. Just run in the background. Yeah, in the meantime, so some of the most challenges we had to solve over the past year was to find out which of the issues we detect are actually relevant for developers to know about because we just run the tools and blindly return the results. Then we were able to explore these issues or issues that are not really relevant even though they look like they are relevant. And this is an example from Bachelor of Law, which was a pretty well known vulnerability that was expected last year in a smart compact called UliChain. And here it was possible because of this modification here with no overflow check to meet a huge amount of problems for yourself. So you would just overflow this to exactly zero and then you get basically unlimited tokens for free. So this is something that you would probably be interested in knowing as a developer, right? Because you don't want to be in there. On the other hand, if you look at SafeMath, there are sometimes places where stuff overflows intentionally and gets caught after it overflows and that's not a big thing. I'm not that interested in that. In some places, SoC generates quite real code. So for instance, in your version, you turn on the optimizer and you do a subtraction by one. Then SoC would actually generate code that overflows the variable by maxint. So it kind of uses this on campus to slowly make to safe gas, which it doesn't. So I'm not exactly sure why it does that. But you can filter a lot of this out of the process of that. If you look at the code, you can see it as a subtraction. So if there was an integer arithmetic problem, it would probably be an underflow and not a overflow. So you can do that. All right, so that's the output from the analysis on the slightly simplified wallet library because if I use the real one, it would take really long. And what you get here is, if it's detected that the contract can be killed by anyone, and it will also give you the transaction sequence that you have to send. So if you look back at the code, you need wallet function with any address, in fact, because it just makes the transaction send to the owner automatically and followed by the key function. And you will put your own address there. This is what we call the stacker address. And then you get all the ether from the compute on practice. All right, so this integer overflow stuff is pretty much solved. So we deal with them pretty well now. There should be just some situations where it was positive. Yeah, there are a lot of other calling patterns that are bad most of the time. Sometimes it's a bit ambivalent. Sometimes just think that you shouldn't do, but that are not necessarily level of ability. Like, for example, changing states after the time extended call, and not checking return values and things like that. So these are more like quotes now, but still relevant to address this issue of not exactly knowing what is relevant for people to know about. We started this registry, which is inspired by the CWE, and which is all the generic active patterns and facts that we currently know about, and is constantly expanded. And what we also add here is a lot of samples for, for instance, integer overflow points. We have a lot of that. So this connects both things that are valid integer overflows and also things that are invalid integer overflows and regrangements and all the stuff that we write against this. Yeah, this is kind of meant to be industry-consentable, so anybody can contribute to that and use samples, and then we can continually refine the tools to be more accurate. So currently we have 32 classes in there, and with X detects 26 of them. Yeah, so we get a lot of advanced stuff which are concrete-specific issues. And that means verifying that your contract behaves correctly with respect to how you are expecting it to behave. And that involves having functional specifications. So you don't need to know what exactly the behavior should be, otherwise you cannot find any depression-forming behavior. You can check for those with X by using extended-slivity asserts and especially rents that we added. It's called assertion phase, so if you throw that event, the industry knows that something happened between them. So let's say you're directing a function of the ESC-20 interface, in this case, the transfer function, and you have code like this. It's probably not immediately visible. If there's a bug in that or not, does anybody want to make a guess? Yeah, you shouldn't actually do this, ever, because there are already recommendations that have been shown to correct and have to know whether it needs. So there's no reason to do this. But it's still a nice example. So if you wanted to create a verifier for that, you could start creating some assumptions and assert them after every transaction. So, for instance, it should always be the case if one token voter transfers points to another token voter that the sum of the balances of the two gets up to the same because otherwise it would mean that some tokens were lost. That should never happen. So what we can do is to create a modifier and you wrap the actual function into this setup code and assertions that you write at the end. So what we actually do is we run the function and check the condition over and over again for all possible path to the program and it will find any violations to that. So here you're going to find a violation actually there's one back where the sender can send points to himself. Okay, training himself. Yeah, there's a couple of other examples for that. This was an interesting one that's a little bit more. One is that we recently wrote for a customer that wrote a signed fixed point in the library so we wrote this over for a check that also found some nice things. So we have some nice stuff coming to the API as well. For instance, we are working a lot on reporting and want to give you more better information to understand the actual flaws that are happening. If you look at this example this is a conflict that can the area that can be violated but we need to call a very specific sequence of functions. And with this new feature not only will the transaction data be required so we will test or reproduce the issue it will also give you the exact parameters and decoded forms so it makes it easier to understand. For this case here we will call this function and the sum of those integers should add up to exactly 0x1.3.7 I hope that's true and a bunch of other functions let's keep a little bit over that. We also added a nice web dashboard and we would like to make the reporting much more interactive so that we can run it over huge projects and get like a compiled report which is a nice stat and things like that. Integration with relinks you can check it out just by going to remix and it's already in the default settings so just activate it and final advice I'll never accept investment advice from random people especially this guy so he really always gets it wrong for any more questions you can give us up on the consensus there's a remix office house on October 10th and we also have a workshop together with consensus diligence which I don't do the time in order to be there. Alright, thanks.