 Okay everybody looks like Roberto Martinez is about ready. Can you all please take your seats and let him get started. He's going to be talking about Kapow. I'm going to hit the button right now. Alright, it's all you. Hello everybody. I'm here to speak about Kapow. Let's begin. So first of all, there are two separate worlds. On the left we have the network world, which in habitants are web services, browsers, IoT devices, to name it. And they speak with several languages but the main one is HTTP. The other world is the command-line world. The citizens are the commands, files, file descriptors, and they communicate through pipes and redirections. So how we communicate these two worlds together. From the command-line world to the network is very easy because we have a lot of very good tools like Quir, Wgate, HTTP, you name it. Those tool can perform HTTP requests. The web services for example and output the responses to the cell and interact with them very easily. The other way around is more complicated because we have a lot of options but none is very good. We have for example the CGA approach in which we have a CGA server that can receive a HTTP request and make some transformation. First of all, the CGA server pollutes our cell environment with HTTP data and predates the standard input and standard output streams with HTTP data also. This is not my favorite approach because the commands that we are trying to interface with the network have to know how to deal with the HTTP request. Another approach is the so-called generic adapter approach in which we receive some HTTP request and our generic adapter makes some specific transformation which is particular to its implementation and called a command with the data. This is very similar to the CGA approach but is particular to the adapter that we are using. Another approach is to use a custom adapter. Maybe if it's not possible to use a generic adapter because it's not suitable for a command, we can use our favorite program language and make an HTTP server and when the server receives an HTTP request, it can execute our command, passing the data, everything is hanky dody. But this has some limitations because the command that we are interfacing is not part of the cell and it's very difficult to interact with other commands without modifying our custom adapter. The last one and the saddest one is just give up and make a new implementation of our command with an HTTP interface. But you know, we are losing decades of experience in command line commands. So isn't there a better way to interface the network world and the command line world? Just there is a better way and I'm going to show you. So let's see some demos. So first consider this scenario. We have an internal host that maybe is our database or a printer or something that is in an internal network and we have users on the internet that needs to know if the device is up or if the device is down. How we do this? Any clue? So the first that came to mind is SSH into the external host that we have. I'm just pinging the device. No? But this has some problems because we have to manage SSH accounts in the external host and maybe it's not very secure. Another way is using KappaO. Can you see this? So the first thing that we have to do is start the KappaO server. This enables an HTTP server in the host and now we have this file pin.pow that is not scary. It's just a script in which we are using another KappaO sub command, KappaO root, to instruct the KappaO server to add an HTTP endpoint that when called will execute this cell script. In this cell script we are just executing the ping command with just one ping to our server, internal server and we are directing the output of the ping command to another KappaO sub command, which is the KappaO set command that interacts with the incoming request and set the response body to the data that is the device. So we execute the script. Now KappaO knows how to deal with the ping endpoint and if we execute a cool, it just works. What can we do? Now, well, we have a lot of tools in the system to give more information to our users. So maybe it's time to make a nice API to let them inspect things that they are not capable of. For example, which processes are running in our server or maybe what type of CPU we have, you know anything that they need to know and they can't know because they are in another host. We execute the script again and that's it. So what just happened? A KappaO server works like this. We have the KappaO process which has two interfaces, a public interface which interacts with the user and a private interface that interacts with the cell. When a request from the user arrives to the user interface, a cell process is spawned and in that cell process maybe a script is executing some KappaO set commands that interact with the internal data interface. This is interacting in real time with the HTTP request that comes from the user. So in this example, KappaO set response body banana is set in a banana in the user response. Let's see another example. KappaO is also very useful for developers. I don't know if you have to work with Windows. I don't recommend it. But KappaO is also available for Windows and then here using KappaO for Windows from Siegwind which is a possible implementation but because KappaO interacts with the cell, you don't have to use it with bus. You can use it with the Windows command line if you want to but I don't recommend it. And here we are creating an endpoint in the KappaO server to use the Windows anti-virus software that comes with the operating system to scan a file that the user is uploading through a form. We are storing the file. We are using the anti-virus to scan it. We are formatting the output and finally giving the output to the HTTP response. So if we launch this, now KappaO is running and now from my Linux environment, I can upload a clean executable in the KappaO server is using the anti-virus software to scan it. There's no threads but if we use a virus, upload a virus, yay, it works. Finally, KappaO is very useful for security teams too. For example, if you have a network with sensitive data, you don't want to give access to that network to maybe to auditors or pentester in some situation. So KappaO can be very useful to convert or transform the pentester tools to APIs that can be deployed inside those sensitive networks and use it from the side. In this example, I'm using KappaO to create an API that uses the TCP-DOM software to scan the network of my laptop, sorry to sniff the package from the network of my laptop and create a stream, HTTP stream that can be used somewhere else. I'm using sudo here because I'm lazy and it's properly configured. So now the server is ready and we can use for another host a simple code and a kite with wordshark, use something from the internet. Here we are making a sniffing a network through an HTTP API. So finally, what's the KappaO approach? The KappaO approach is sitting in between those two worlds and speaking perfect HTTP with the network world and speaking perfect cell with the command line world. This way we can interact more seamlessly. KappaO is distributed, first of all, is an open-source project. It's distributed at a single study binary so you can start without any dependencies. It's multi-platform with distributed for Linux, Windows and Mac and it's available for several architectures. It's well documented and it's tested. But we need your help because we need users. So please, if you like what you've seen, try KappaO. Give us a star on GitHub please. Share with a friend or with somebody that maybe like it and join us. We need set users, developers and so on. And that's it. Thank you.