 So I think introductions are done, me and Martin from the consensus diligence will be, I'll be talking for 20 minutes today about visualization of large code bases, but also framing it as to why we've built the tools that we did and how they play a role in securing large code bases, right? This is not only about visualization, this is about making your code secure when your code needs to be big, right? Because security and oftentimes as the security team to many products we advocate for small code, but sometimes it's just not possible, right? Some things are need to be complex and need to be sizable. So that's why we're talking about this today. And I'll let us start. If I may add to that, we have this unique, not problem, but challenge sometimes that new hires in your companies might have as well. So they get to see your code base and it's fairly large and how do they start understanding the whole code base? And for us all it does, this is kind of like a regular business. So with every new client, we get like a new more or less complex code base. And we wanna make sure that we spend as little time as possible in understanding the complete system and finding the right lines so that we can start auditing and finding any security issues in there. So that's why it's also an interesting take on what tools are available or how can we aid new hires that we wanna have in this ecosystem to be able to quickly write up code and quickly understand existing code bases and kind of also in the secure manner that's what we are going to talk about. So for the history of the tools, we'll give you a little bit of background on like why things happen and what happened and at what time. So this whole thing started, well, this whole thing obviously we have always been thinking about security, but this specific branch of our tooling started because of Aragon OS, right? Up until then, all the code bases that we had seen or me specifically had been related to tokens, simple implementation of VIPs, stuff like that, right? And then came Aragon OS and it was a beast of a code base, right? And I'm not saying that it was not well-written, which it was and very well documented too, right? Probably better than most of the projects that we have audited, but still the sheer size of the system made it so that it's really hard for you to create mental models, right? Even with threat modeling exercises, you always end up to do some sort of visualization, right? Be UML diagrams or something that helps your brain come to terms with such a high level of modularity and composability, right? So size is not the only factor that plays a big role in making the system complicated, modularity too, right? And this is why Surio was born, right? Surio is purely another abstraction on top of the ASD that actually maps it out, right? It's a call graph printer, nothing fancy that was born out of necessity. The main drivers for Surio to be built the way it was were portability and the low dependency tree, right? We wanted to make these tools so they could be run everywhere, right? And anywhere and also have a small footprint, right? So that we could run them everywhere and also we cross-platform. We just wanna make it easy to run these things, right? We don't wanna deal with versioning. We don't wanna do any of those things that end up complicating a tool like this because the tool's purpose to begin with was to make it easy for people to visualize and mental map something. So if we make it hard to run, then it's going backwards, right? So we went with the Federico's Awesome Tools on the ANTLR for Grammar and Parster that he had built for a long time already. And then came along the best part of the stack of this tooling branch that Martin wrote which is the Solidity Visual Auditor extension. Now, I'm now looking at the name in doing the presentation, I see how we could probably make it more receptive towards developers, because even though there's auditor in the name, it's only target audience for sure. And again, going back to what I was saying before, if our goal is to make it as easy as possible for people to visualize and map out systems, then using CLEED tools is not really the way to go, right? While you're developing, you don't want to interrupt flow by having to run a system on your terminal or in another terminal session if you use VIM, right? Or just like even going through the trouble of visualizing those things in another window is already too much. And so Martin brought us this beauty here. So basically like how this was born was, I was new to Solidity, but I didn't want to always have to keep everything in my mind about all the language specific things, like what parts of the language are actually considered insecure or not as secure as they should be. Or like, if you write your code, for example, in research studio code, which is the ID that I'm using, it wouldn't alert me on like certain things that I would want to see from a security perspective, which is passive information about what functions are actually publicly accessible. What are public interfaces? What are only internal functions? Or when I'm pasting like some piece of code from static exchange, because I want to do like a delegate called proxy. And I'm totally unaware what this is actually doing. It's pretty easy to mess it up, right? And if you paste it into the IDE and you have this extension enabled, it will like throw a whole lot of red flags at you by highlighting the delegate call itself in plain bold red, so that you know like, oh, I should probably read up on that thing. What is it doing? They can even like hover over that delegate call and we give you extra information about what the call is about and also what security concerns that might be around it. So it's initially, it was initially geared towards allowing new developers to develop code by getting passive security information while they are writing code. So it was starting out as a syntax highlighting, like as an extended syntax highlighting extension, but it got into that big beast of a lot of other nice tools that we kind of put into that at some point because they were always useful for us when we had to engage with new code bases. Hence the name for this talk. Yeah, so you can see a little bit of it, we'll show the tools in a minute, but you can see a little bit of it, like the syntax highlighting under the pragma and under the state variables. Also, this is like an accompanying thing that Martin Dilpec is basically in SVG interactive graph for VS code, which is like the frosting on top of the cake, honestly. What happened a little bit after, so like probably when you're into development is that we realized that we needed to own all of the dependencies for speed of development and support, right? So we took them up recently and thank you so much. I thought I wink at the team and thank you guys for doing that. We don't need to worry about the grammar anymore because the Solidity team actually took it under their wing. So we're free of that now. Also, with the whole corona thing and like our workload has been extreme these past few weeks. And so I know that there's another Oregon on GitHub Solidity parser that started a new fork of the Solidity parser that is more up-to-date than ours. We are very, very, very excited about contributing there, but thinking that we should probably still maintain our own in case in the future we need it again. Yeah, this is also like a recommendation from our side when you're developing a new language, always make sure that people have have grammars easily available to their tools. Like the Antel R grammar is nice because we can use it in a fussy way. It doesn't need to be as strict as the compiler will be afterwards because we are mainly using it for visualizations even though like there can be some unchartness in that case, but you have to be aware of that. But for most of the case it's fine if we find all the functions, all the state variables and stuff and we don't need to find like 100% of it all the time. But it's utterly important that if parsers are readily available like generic ones as the Antel R parser, then it's very easy to build a whole lot of tools or IDE integrations for all kinds of platforms and it makes it just easier for people to adapt the language. So thanks for taking it under your wings as well. Yeah. And yeah, since then a lot more tools have been built by Martin, all again with the same goal of building passive security as Martin has said, right? This might mean syntax highlighting, this might mean more information about the code that you're writing and keeping yourself up to date with it. Including as we just said, giving you tools that allow you to find that red line through a new, that is kind of like through and a new code base quickly. And that's kind of what we're also showing in a few seconds then in like a live example. Again, I have been talking about this throughout the whole presentation, but the reason why we're building these tools is because of these three main factors, right? We understand that everybody has deadlines and obviously this comes very much from an auditor's perspective. So this may be biased, but we try to put ourselves in the developer's shoes, right? And think what is important for them and what constraints they have, right? And what challenges they're facing. And we know that everybody has deadlines, right? Time passes, you don't have 200 years to write a code base. At most you have your whole lifetime, right? So good external support is important even when you have like straight timelines. And you also should understand your code before anyone else, right? Then other people will need to understand it too, hopefully, but you should be the first person to understand your code, right? I can't remember who said this, but code is made to be read by humans and then incidentally by machines. So you should make sure that you understand your code even before someone else does. And when you're new to a language, you learn by making mistakes, right? And our tools can help flatten that curve and hopefully the mistakes associated with it, right? Again, passive security. Okay, yeah, and just, again, borrowing very much from the preparedness mindset for an audit and this is actually very specific to audits, right? But we can also generalize it towards writing safe code. You should document your code, you should make it easy for everybody else to run, right? So understand it first, make everybody understand it and run it after that, clean it up, run preliminary tools like the linter, right? Run proper analysis tools and then release it to the world. As you might or might not know, we have a branch of toolings. The Diligent team has also started a branch of toolings that is now an entity needs some right methex that does dynamic analysis, right? Like it's a concocted execution engine static and fuzzer. But this part that we're talking about today is made to tackle the first, the second and third sections that you see here, right? So it basically helps you earlier in the development life cycle so that when you get to steps four and five, you already have both. Again, a good mental map of what's happening in your whole system. You have a good knowledge of where the danger areas lay in your code and hopefully just make everybody's job easier, right? Be developers, quality assurance, auditors, I don't know. Whatever is there, what stakeholders are there in the middle, we just wanna attack it, attack this problem super early in the development life cycle so that everybody can have like a merrier life. So let's see the lead tools in action. Do you wanna take on the screen, Martin, and share the, let's do it. We have a couple of minutes left, right? So let's quickly do that. So you should be able to see my Wishio Studio Code instance. And notice we're doing Aragon. We're doing Aragon because it all started out with Aragon and Gonzalo trying to make sense of the code base like years ago when he first had the glance on it. So this is Wishio Studio Code. Basically I tried a whole lot of IDEs and this is what I, like this is the last thing that actually basically work quite well and it is quite extensible. So that's why most of the things that I do are nowadays with VS Code. So that's like in the middle, you see the codes, the code editor. There's no window open right now. And on the left side, there's the code three or the file three with all the files. I'd like to show you like the metrics plugin first. You install it from the extension marketplace. It's all free. It's all open source. You can audit it and then just go ahead, click here on any folder where you wanna, like where you expect Solidity files. Click right click Solidity metrics and it will take a few seconds because it's now parsing. It's finding all the Solidity files in there and it's parsing all of them with the anti-law parser in the end. And then we do some nice number crunching on it. So you see like this is the workspace name, table of contents, let's skip to the scope. You see what is in scope or is out of scope or code base we were using. And then you get that view. And this is quite nice. Like the first time I see a code base I usually run this tool because it shows me how many Solidity files are in the code base, how many contracts are in total in the code base. These are all the logic contracts. And there's nine interfaces in the contract as well. Then you will see for each file you see what type of contract it is, whether it's a library or just an ordinary contract or even like an interface from this icon. You see the number of lines, normalized source code lines which is like normalizing the function signatures, comments that are in the file which is a good indicator of whether you need to spend a little bit more time on documenting stuff. You get even a complexities call which is not cyclomatic complexity but something is much more simpler. Basically we find anything that is risky and that is caught to it, even if it's a branch. Anything that adds complexity or security concern just adds something to this call. And the higher it is the more likely or like the higher should be probably your priority to look at things in here. And we also like watch out for any patterns or calls that we know that should be investigated. For example, this file is using hash function, basically catch up calculations. And this file is doing any assembly stuff. And then we have this file which is, to be honest, I prepared this so that it does show up with a lot of things. It's not really the Aragon code base that has all these stuff inside, but you see like there's payable function in there. The construct is destroyable. It's initiating ether transfers and stuff like that. It's even creating stuff. So you get a nice overview on where might be some risky points in that 60 files of code bases and it helps you to like dissect the interface and stuff that you don't need to look at in the beginning from the stuff that could be very critical in a code base. You got a summer review, you see everything that was excluded from it. We even have some experimental stuff in there which is kind of like our take on a bit on the risk chart. This is something that we feel like should be presented to Solidity developers so that they know like, the more often they use assembly code in there, the more complexity to the system and the more time it will take to actually also review that and make sure it's secure. You get a new, another overview on what type of contracts are instantiated and what versions were observed and also like anything you might wanna know like from the inner workings of this extension, we just printed out just for fun because we have the data and you also get like for everything, inheritance graphs and stuff. This is basically serial output. So this is the metrics plugin. I think are we already over time or do we have like two minutes or three minutes to also show up the auditor extension for a second? You guys are over time but we are running into the break. So it's okay. Okay, cool. Go for it. So I tried to be fast. So you can also install the Solidity, which will audit per extension, which basically this one. Once you installed it, it will show up a new icon in the panel on the left side. You can click on it to get like a quick overview. You can also hide it if you don't wanna have that because I know like I'm usually pretty, I don't wanna see all the icons in the left side. So what you can do to explore the code base, for example, is we can click on this view and it should update the workspace explorer view unless my machine is too slow today. Let me just quickly try that again. Okay. So it's now searching for all these Solidity files in the code base. The idea of this explorer is it should only show you anything related to Solidity files. You don't wanna see any JavaScript files or any other things. So that you can specifically focus on Solidity code. So you can browse around whatever you wanna see in there. You can right click and even find top level contracts. This is kind of something that I usually do in the beginning when I am exploring your code bases. I wanna see what is the main interfaces so that contract system. So this list that's now populated here will show all the contracts that are the most derived basically that are not inherited by any other contracts in the system anymore. And they are very likely to be deployed at the end for your smart contract system. You can also from this view on just flatten all the files if you wanna flatten stuff, but you can also graph, create graphs with basically Syria for certain folders or selected files or anything. So let's just try that. By the way, we always give you like the source code so that you can modify stuff because you might wanna use it in a different way. So this is basically what's going on in the whole Aragon OS system from a serious call graph view. And it's kind of a lot of things. If we just boil it down to like generating the graph for a couple of files, it might even be easier. So that's the view just for the APM part. What you can now do for example is some like simple taint analysis. If you wanna see like any calls that reach to root node, then you can even like visually trace that path or do any other thing in the code base however you wanna use that. Also, you can show the inheritance graph just for this part or what's also interesting, a lot of time is you wanna see for example, the UML chart for that file. And you can also just generate it. You can even do that for a flattened version of that file. So if you click here, flatten that file, it will flatten it down. And you can then just visualize that flattened file. This will take a little bit more time but it's worth the wait. So this is everything around the ACL flattened and how the contracts are derived from each other. And we even parse out which is kind of like an experimental feature bit. We parse our potential actors in the system. So whenever we see any addresses in the system, we denote them as possible actors to the system. Yeah, so that's basically the graphing functionality that we have in here. One thing that might also be interesting is, let's just go back to, for example, ACL for a second. If you- Just looking at the time, Martin, because we want to allow the people to have a little break at least, what I would like to do is already remind the people on the live stream, if you have questions, please put them in the chat now. And if you have questions in the room, please already raise your hand so that I can estimate whether we need to discuss stuff or whether Martin can go on. All right, I will come to an end. So one interesting feature we were working on recently is context sensitive information. That's why we call that view a cockpit view. So if you click into a method here, you get like context specific information in these views on the side. They will just, like this view just shows all the public state changing methods plus their modifiers. So you can see like whether create permission has an authentication modifier on it. Just quickly check if any of these are like missing modifiers and stuff. And the last feature I'm talking about is basically also from Syria, which is the call tracing function. So when you click into this method, for example, we will update the function call trace, which basically shows all the downstream calls that are happening within that method or even like somewhere in the layer below. And something that we might also integrate in the future is this into the other direction so that you can find all the callers to that function and other things. All right, so that's basically it from the demo side.