 This is what happens when the math on speaking doesn't really all add up. Yeah, I'm ready to do this. Let's do it. Do you want me to stand up or...? Oh, absolutely. Hey, you know what? You're the boss. This is up to a vote! No, fuck you guys. This is my science. This is starting to really suck. I thought I liked it. I liked it for a little bit. Josh, you fucking suck. No, no, you gotta get the rest of it, man. No, no, no. Do you guys want me to finish this? Oh, he's my nice friend. All right, science time. End of spanking. All right, enough fucking around. We're going to do science now. All right? Yeah? Yeah? Oh, okay. Ow. Thank you. Anyone else? Oh, lord. Okay, science. So, I'm a Ph.D. student from Columbia University. And this is my research. It's my butt hurts. And this is terrible. Okay, so... The name of my talk is Stepping Pones, Adventurous and Full Spectrum Embedded Exploitation and Defense. So the defense part is really important. This is really what I want to talk to you guys about. And here's why. Oh, and by the way, the slides are not on the DVD. It's on our website and it's like 100 megs because unicorns are magical creatures which cannot be compressed at all. So sorry about that. And this is our typical talk. This is what I usually do. First, we say, hey, look, we find this bright, shiny thing that we want to play with. And be it a router, a car, or a phone, or a printer, whatever it is, we talk about our motivation for wanting to do this sort of thing. And then we spend a lot of time in failshack, figuring out all the different ways of not owning these devices. We fail when we fail. And after a while, we finally succeed. We find that one vulnerability. We built that one exploit that works. We're really excited. And we spend some time during the presentation talking about it. And then comes the bad news. The bad news is this thing is everywhere. The fix is really hard. This thing runs our lives and it could potentially have very big impact. That's terrible for the world. And then we feel bad for saying that. So we say, well, it's okay, actually. We have this thing called duct tape. So we're going to duct tape this thing up by unplugging it from the network. Or let's just not use it in the way that it's intended to. And hopefully your house won't fall down tomorrow. And then me, I usually have pictures of cats and things I find on Google Image Search like four o'clock in the morning for harmless copyright infringement. And during the last two minutes of the talk, we always have the slide that says, wouldn't it be great if we had a real solution? A solution that's not just duct tape that actually fixes the fundamental insecurities, the problems, the reasons why we have the problem that we present it on. And then we say, okay, goodbye, have a nice day. And we do it all over again. But the real solution is never really presented, usually. So I'm happy to say today we worked really hard to make this talk a little bit different. I'm going to spend about 47% of this talk on the offensive side of our work. You're going to see Poly-CC's malware propagation. And by that, I mean malware on embedded devices that propagate from one type of device to another like a printer to a phone, from a phone to a router and vice versa configuration. And then we're going to spend a lot of this time, as much time as I can, on the defensive technology that we've built at Columbia University that we're commercializing through a little company that is called Red Bulloon Security. The defense is called Software Symbiote and it's essentially the product of the five years of my PhD work you're about to see it live on stage in what amounts to basically your typical modern office. And then we're going to spend some time showing you pictures of unicorns that you can find on Google Image Search. So, human cast, this is my PhD advisor and co-founder of Red Bulloon Security, we haven't seen him since Black Hat. We don't know where he is. Michael Costello is a fantastically beautiful man, a designer by day and a scientist by night. This is Jadon Potteria, who is also a research scientist at Red Bulloon Security and here's me getting spanked on stage and such. And special guest appearance by my key drop tables who is the mayor of Pone Town, which is located between Quarth and New Jersey, so halfway between. And that's not all. So we have a lot of gear in front of you, we have the cast of machines and this is stuff that you probably use every single day. You may or may not see them on your desk, but we all use it in our modern offices. So we have the 2821 Cisco router. This is probably something you'll find in the closet somewhere, right? And you'll have one of my favorite phones, and the Cisco phone, right? The Cisco 7961. And today we're going to show you a zero day that we're going to drop at Black Hat, but we're going to show you here today. It's called the Cisco 8961, so this is a bright, new, shiny, sexy new Cisco phone that's almost twice as expensive, but it's really nice. It also has a zero day that's fun to talk about. And we're going to show you something on the 1841 Cisco router and we're going to talk very briefly about the work that we've done in the past. This is an image that we all know. You have your big, bad internet, you have this firewall and inside you have the internet where you're super safe. And Pontown is on the right side of the internet where Mikey Drafttable lives. So he doesn't really know anything about your internet. To him, this is a mystery because he can't really send any packets to recon through the firewall from outside in. This is how we always set things up. So this is what he does. He's going to make a fantastically impressive resume. And someone in your organization is going to be so compelled by this resume that they're going to print this out. And this is a vulnerability that we talked about a year and a half ago which has been patched by the vendor where a print job can change the entire firmware on the printer itself. And that's because you can pack firmware update files inside print jobs in the printer which has been patched in theory. But once you get onto the printer now he has a physical stepping point into your internet from the outside. And what he does is he will then out. So why am I talking about this vulnerability? It's been fixed. We talked about this a chaos two years ago. But it turns out we scanned IPv4 looking for publicly accessible vulnerable printer on the internet. And after 14 months after the virtual security patch was released by the vendor and I think they released something like three dozen patches for every single laser jet model they made, we found that only 7.5% of all the printers on the internet has been patched against this vulnerability. So if you find a zero day on something like Firefox or Chrome, you have maybe a week window where that vulnerability is actually useful. But on the embedded side this is absolutely not the case and it's because we don't have the same vulnerability that I found on this laser jet printer a year ago, year and a half ago, will still be something that your organization will probably be vulnerable to today. And that's just because people don't patch the firmware on the printers, it's difficult, it's cumbersome and nobody likes to do it. So with this vulnerability, what he's going to do is he's going to create a reverse IP tunnel out the firewall so that he can get command and control through this tunnel from outside, from the network to figure out what other embedded devices there are, and using what he knows about the vulnerabilities and exploits he has about those embedded devices, we're going to show how you can actually propagate through the network, compromising all of these embedded systems without ever touching a general purpose computer where you have host-based defense of any kind. So we've done a few of these, we looked at the printer, we looked at the router and we looked at some of the vulnerabilities, isn't really all that difficult and I have to put that in air quotes, I mean it's not easy, but you have the physical device, you have all the time in the world, you can take it apart, you can figure out how it works, so the idea was that, and this is the page I put in the first page of my candidacy document for Columbia, that my theory is that polyspecies malware propagation is certainly coming, we have the offensive one and own another one, but it turns out, you know, polyspecies malware propagation isn't just trivial, there are some challenges that has to be solved in order for this to really work in the real world, so my goal is again to own, let's say, the router and from there put malicious implants in every single one of these devices, embedded devices in the network and there's certainly some challenges and we're going to talk about the three that we really had to solve in order to get this to work. We have system machines, we have syscodes, we have HPs and we have vias, devices from different vendors, these are all proprietary devices, you're not going to get the source codes for any of this stuff, the hardware is obviously all specialized and on top of that, the architecture, we have MIPS, power PC, AVR, X86, all sorts of different ISAs and after that we have different operating systems, we have modified Linux, we have mystery operating systems that nobody really knows about, we have CNU that's kind of like Unix but not really and we have other things that are just complete mysteries, right? You know, look at the thing and say does this thing even have a kernel? Completely unknown in some cases. So what I want to say is take a step back, we're going to show you solutions to these problems, these challenges that we found for the offensive side, but really when you solve the offensive problem you're solving the dual of the technology software symbiote to apply this to build an offensive demo, so we're using the same type of technology for offense and defense in Yankat. So the very first challenge here is a generalized way of modifying binaries, right? So I mean once you have a device, how do I get the code that I want to run onto the thing in the first place, right? It's not like I can put, you know, install that EXE on a printer or a router, that's just not going to work, from a reverse analysis console that we presented here last year. I definitely recommend you check that out. We've been building on top of it and that seems to have worked quite well. So that challenge is more or less off for us. The next part gets a little tricky. And here is the generalized execution problem. So once you have modification you can put whatever binary you want in these devices. Now the question is what do you want to execute? And by execute I don't mean just single payload on environments that are vastly different. Things like Linux kernel on MIPS or VxWorks on ARM and have it all more or less do exactly the same thing without really a full understanding of the operating system at all, right? And I'm going to show you ways of doing that. Once you solve that there is an actually even trickier problem of getting input and output to these targets. So you have OS and hardware agnostic payload of some sort. How do you communicate to it? From this device without understanding how the network subsystem works, right? Typically you figure out, let's say, the Indis driver works this way. I'm going to hook the specific call and that's the way that I can see all the traffic that are coming in. But in operating systems that you really don't understand, this is very difficult. So let's talk about generalized execution first. Forget about everything you have ever learned about any operating system. That's why we have this black box that the memory is roughly organized in this way. You have some code and you have some data, dynamic data region, right? Somewhere in that dynamic data region you have what's generally referred to as IOMM, right? And inside this code it shouldn't surprise you, but embedded devices firmware is really bloated. It's got a whole bunch of code that really isn't necessary for the operation of that device. And by that, I mean, you know, debug strings, IGMP if you don't use that sort of thing, you're done in libraries that are linked in through the build process and what not. In fact, Mike and I looked at Cisco iOS and it turns out if we wanted to rip out BGP and the HTTP server, it looked like we were able to take out 40% of the iOS binary and still have that router come up and be fully functional. If you just didn't want to use the web server or BGP. So there's a lot of room to play with. And on the other hand, there are points inside the code that we know we have confidence, regardless of the operating system. And here's a really good example. The e-read instruction. Every time an exception comes up, the e-read instruction is called. So if you just map out all of the e-read instructions and hope that, we'll be guaranteed perpetual control of the CPU. And there are a bunch of other places where we can look. Popular functions that are called all the time, mem copy, et cetera. So put these two things together. We replace a dead code for a binary. This payload is capable of restoring state between itself and the host program. So think about this as a binary scheduler. We use some other dead code for dynamic memory region, stack, heap, scratch area. And the last thing we do is we hook a whole bunch of intercept points to guarantee that our payload is periodically invoked. And then that's really the solution to the generalized execution problem. You can compile the code for a list of the operating system that you're working inside. Now, how do we solve the input and output problem? And I'm going to say that we can actually take the solution from the generalized execution part of this and at least solve the generalized input problem. The output is still a bit more difficult. And this is what we do. The payload in this case that we choose to run is called the packet scrubber. We're doing an Easter hunt, essentially. We're going to put this piece of paper above the device, regardless of what the operating system is. We're going to hook a whole bunch of points that's going to guarantee that the packet scrubber will be hit periodically all the time. And as the device receives network traffic, packets are going to be copied into IO memory. And in that IO memory region, we're going to detect well-known patterns that we define ahead of time that we're just going to call command and control patterns. And as the device operates, we pick out and then we service them accordingly to our command and control scheme. And how do we get these patterns inside the IO memory range? It turns out it's really easy. Even if you send a malformed packet of some sort, as long as the device doesn't have a lot of hardware acceleration, the entire packet is usually copied into memory range of that device, and then the processor will analyze and decide whether it needs to discard it, quote unquote, or process it. And as long as the thing is copied into IO memory, we can send it through command and control through, let's say, an ICMP message, or we can send it through the content of a JPEG picture. As long as that is copied into IO memory, our packet scrubber will identify it. So take a step back and think, is this something that's specific to ARM? It's not. It'll work for MIPS. It'll work for AVR, X86, power PC, whatever architecture. Now, is this something that will only work for VX works? No. This is a little iOS, the Linux kernel inside a DSP program. This is really hardware and software agnostic. So for completeness, this is the command and control and the command and control acknowledgement packet that we defined for this demo. You have an envelope that starts with a predefined pattern, and in this case I use ACAC, because my initials, followed by some metadata, and then at the end we have magic pattern prefaced by how IO memory is manipulated. And inside that we have the command arguments, various payloads, and this is how both the offensive and defensive demo will work. You'll see in a little bit. So put that together. You have the packet scrubber running. You have CNC packets coming in and out of IO mem. And as these packets are hidden, we identify it, we service the command and control, and that's how it all works. And we have it working on MIPS, and I want to take a moment. We found out about Barnaby Jack a few days before making this presentation, and we were all super shocked. So we wanted to do something for him as a tribute in this presentation. So we've actually implemented the Barnaby function, and what the Barnaby function does is it takes arbitrary embedded devices as input, and it puts its face into the working memory of those devices. And we're not done. We made a modified Barnaby function Prime, which does exactly the same thing, but in a permanent way. So to show that not only can we do this through our command and control, we can actually affect real, permanent physical destruction of all these devices through our command and control. So here is a Cisco phone with Barnaby Jack's face right past the Linux loader. Here it is, physical destruction of Prime. So now I want to talk a little bit about how our demo array, iron the printer, owns the printer through this reverse IP tunnel or through this resume, establishes the reverse IP tunnel, sends command and control down to the printer to do recon. Recon will bring back active devices on the network. We're going to do a whole bunch of fingerprinting to figure out the devices you're actually looking at. And once we have, we figure out whether this is a Cisco router or an HP printer or a Cisco phone, et cetera. And using what we find there, we're going to find a control capability on all of these devices. And before we jump into the demo, I really have to say, I'm not allowed to say a lot about what we have done with Ivaia that's coming soon, but the JTagulator, I don't know if you guys saw the talk about it, is the super awesome sauce. This is the coolest piece of hardware I've seen in a while. If you see Joe, get him like a latte or something, but buy like ten of his boards. This is really cool. And his board made a brand. So now, without further ado, Michael is going to start writing the demo, the offensive demo. All right. I just want to say I really love this community. It's 1 o'clock, 1.30 now on a Sunday afternoon, the last day of the conference, and the room is packed. I mean, this is great. You should all give yourself a round of applause, please. And there's going to be a little bit, a very tiny bit of audience participation here. So what happens, please, everybody just shot out the obvious answer. All right. So we're going to Pone Town. Okay. So everything that we're doing here on stage right is Pone Town. So this is where we're going to put our offensive payloads, and then after that's done, then we're going to come to stage left over here and do defense. So I'm going to bring up my server. We've already sent our resume to the printer. It has been, it's rebooted, and it's going to build its reverse tunnel connection out through the firewall, out to where Mikey Drop Tables is living. So we've got our tunnel connected. So we can now bring up our offensive console and already we see that we have the printer in here. And so everything that we're going to be doing here, and all of you see this at the beginning, but every command that we're doing, or almost every command that we're doing is we're sending commands through the command and control tunnel to the system. So we're going to do the same thing, but we're going to do the same thing, and we're going to be instructed to do different things. And so what might be the first thing that we want to do. So we've got our printer, we know about this on the network, but we want to find, we want to do reconnaissance on the rest of the network. So we're going to do a SIN scan on the printer on port 23. And we're instructing the printer through the devices on the network. And right now we see we have a number of IP devices, and I apologize for the formatting for the screen size, but another thing that you're going to notice is that the printer now has a fingerprint. And this is a memory fingerprint. So when our root kit is on there, we can do a checksum over memory, and then use this fingerprint as a key into a database that we have pre-computed offline a bunch of information on these devices. And here we know that we have a 255DN running firmware from March of 2010. And this might be another good time to, or this might be a good time to note that this work that we're doing on the printer is nothing new. This is not a new exploit. This was presented at 28C3, print me if you dare. And there was an NDSS 2013 when firmware modifications attack paper. Please read that and watch that. We just were making the printer do a lot more work. So now the next thing that we want to do now that we have an idea of some devices on the network is that we want to find out a little bit more information. We have some layer 3 information and we want to get some layer 2 information because that's going to help us in the next stage of our attack. So we're going to ask the printer to give us an IP to MAC address mapping of these various devices, and then looking at the first six bytes of the MAC address we have a couple of Cisco's on here. And we also have one target on here, recon 4 which is the Cisco. For the purpose of the demo we know that this is an IP phone. So we're going to rename recon 4 to phone 2. And what we're going to do is we're going to try to SSH into this phone. And we're going to try to, because we know that the phone is going to be running on the network, we're going to try to log into the phone by guessing a username and a password. We're going to take advantage of a feature on these phones is that every single time you attempt to SSH into them, they ask their preconfigured TFTP server for an authorized keys file. So we can do key based authentication on this. What we're going to do though is instruct the printer to ARPSBOOF the phone, making it think that a device that we control and that's going to be the printer. So one of the things that the printer does in addition as part of the packet scrubber looking for these magic patterns of command and control packets is it looks for TFTP authorized keys request files and it already has in memory a nicely formed one packet TFTP response file of an authorized keys file. It just has to populate a couple of fields. Which key are we going to use, Mike? We're going to use a key that we built ourselves. So we would be able to use it. So we're going to poison phone 2 with the IP address of the TFTP server that we learned through reconnaissance. But first, before that, I need to bring up a proxy. I'm going to wait for the proxy already connected, very good. And we're going to so we're going to art poison it and do it again for good measure. So now Mike is going to SSH through the proxy through the printer to the phone and spoof the authorized keys file as it's being requested and then get console access to the phone from the internet through the printer. And if this works, we should get a shell login prompt and not an SSH password prompt. Yes. Wait, he's typing a super secret password. How do you know what the username and password is? Can you not just change that password? No, because if you change it then the checksum changes and the phone resets itself. And the password comes back to the way it was before. Oh, that sucks. Okay, so this we find out is a Cisco 8961. It's running 921 software. This is not the latest software on it. There has been a release or there will be forthcoming release that kind of puts epoxy and some of the holes on this but doesn't actually work today. But here we notice that this is a phone, this is a general purpose computer, this guy still looks like a phone that's running a Linux kernel on here. And we're not going to go over everything that we tried and failed to do to get root on this thing. We're going to cut right to the point. We found after looking at how the phone boots up that it uses NAND devices and one of the things that we noticed was just one of the devices. Does anybody see a problem with the permissions of this device? There you go. And we did this before seeing monks talk about NAND flash vulnerabilities so we could have done this in a lot more elegant way but he didn't send the slides before and we didn't know about it so we did this in the most monkey way possible. Yes, but if anybody didn't hear it MTD4 has world right permissions as an ordinary authenticated default non-privileged user, we could write to this device. In theory, right, but Mike, we don't have any tools to do that. We're going to have to compile it or download it. How are we going to do this? Actually, it's really convenient that Cisco had already packed for us a number of flash utilities so we could erase the device and find out if we could do that. Yeah, and there's not only flash erase and info but we also have a number of NAND tools. Wow, that's really useful. But okay, come on, this file system is going to be like megs and megs large. How are we going to ship it to the phone? How are we going to pack it? It sounds all very complicated. It really isn't. You can do all of this stuff offline and you could pack one file in a very small file system, fit into one 4K block and transfer it over the phone using TFTP. Which is also on the phone running and stuff. All the tools are there. So, there's the old day. When I found it, this was a little disappointing almost because we've gone from the CNU kernel, which is a proprietary thing that very people have looked at, to a much more secure environment, the Linux 2.6 kernel with all the security patches backdated to the thing. Yet owning this phone has become somehow easier. Something's wrong here. It's just human error, really. What would somebody want to pack into one of these files? Maybe a little root popping set UID root program. So, if we look at who I am now, I'm the fault. But I really don't type this slow. Everything's going over this proxy. We're root. So, that's all it took. You didn't even have to compile anything. You just log into the phone. You look around and build this 4K file system and there you go. You have it. And now we're going to switch over to our command and control demo. For good looks, you know, we promise that this is going to be a command and control infrastructure that, oh, by the way, I have to say, now that we're on a Linux operating system, we're home free. We can start doing all this stuff that we know how to do. So now going from a Linux phone to compromising the printer using the initial attack factor becomes all of a sudden very simple. Now we're going to load up all of the devices we have our command and control implanted on. And for good measures let's go 1841 router just to show that our command and control will work on phones, printers, and all sorts of different routers as well. So through the tunnel, the first thing we want to do is heartbeat all the devices, see if our root kit is listening. And of course we're also doing this again through the tunnel that the printers established. So a number of data gets back from it. Everything responds and says that we're here again with the memory fingerprints that we were able to do. So we have a bunch of info on these things pre-computed offline. So for instance, let's instead look at the 2021. And we see that we know that it's running MIPS 4 Big Endian. We could find the addresses of various functions. Here we've decided to redact it. So we've got lawyer phone and we couldn't show you any of the actual offsets, but they're there in our database. So now we can do read and write. So let's rock out the Barnaby function. Okay. So let's just go directly to reading and writing. So before running the Barnaby function, just so in case anybody does no typical Cisco router behavior, if you type in enable and you type in the password wrong three times, this is bad secrets and you're just a regular privileged user and if you do a show version, you just get to see the router is running. But if we run the Barnaby function this is doing a number of writes to memory. Let's do it on the 1841 as well. So now if we do enable bad secrets, but notice that the prompt has changed and if we do it as a privilege. That's not supposed to happen. Things are weird and terribly bad in these routers. Wait, that's not also we're going to do show version, right? Oh, look at that. We've got Barnaby's face in there. Ta-da. And it's in the 1841 as well. So we can do this on. And this is because all the command and control works the same way on different architectures, different operating systems. And we're just giving an arbitrary memory write command and we're writing it to the specific location. And the reason why we know the specific location of the string is because we actually have pre-computed this assembly of the specific iOS version that we found that we know this router running through the fingerprint that we've exfiltrated through the heartbeat. And we can do this at scale on all of the images from all the devices that we have under CNC. Let's do the defense demo. We're running a little bit short on time and as promised, I'm going to spend as much time as I can on the defensive side. So I want to say, well, okay, population in Pongtown without defense six. Terrible. Oh, another fun fact. It turns out the HP printer is really a quite capable piece of device. This thing can send about 15,000 packets per second, right? And it can send terrible things. It can just yack, yack, yack all day long. And it turns out if you want to DOS a 2821 router using a single printer, you can. You can peg it to 100 percent or 98 percent CPU utilization. And that's one printer. Imagine what I can do with two printers. And we'll show you that if we have some time, right? Wins all day. Okay, so now I want to show you the defense demo. And this is the thing that we're developing. This thing is called software symbiote. And it uses a lot of the same insight that you saw on the offensive side to develop dynamic firmware integrity attestation in arbitrary legacy embedded devices. We're showing you demos that run on ARM, on MIPS, on Cisco phones, on Cisco routers, and then on HP printers. This is really not something that, oh, and we require absolutely no vendor intellectual property. We take the binary that comes from the vendor. We require no source code. This is not a timing-based attestation method. This is not a static attestation method. This is not proof carrying code in any way or inline monitoring. This is something very new that is very flexible. And you're going to see a demo of this thing working right now on exactly the same hardware that you saw the offensive demo on. So we're going to get out of Pone Town and go somewhere else. And then as Mike is setting up, we're going to run through the first phone exploit that does memory modification. And we're going to bring up the symbiote alerting console that's going to show us dynamic updates to the check sums of the static regions of code inside all of these devices. So any piece of code that is modified within static code regions of these devices will be detected in approximately about 100 milliseconds of detection latency, depending on the speed of the CPU. So the routers will have 100 milliseconds or so. The phone actually has a much faster CPU, so we can actually detect it much, much faster. Okay, so we got in here. We added our routers in. Again, I apologize for the formatting. So right now we have the phone, the router. There's a printer at the bottom. We'll try to add that in individually at the end. But for right now we'll show you the phone and the routers. And so these are routers that are running our symbiote code. This is all work that's been funded by DARPA, IRPA, the DHS. All of these things are packed and funded by CFT. So thank you very much, Mudge, if you're in the audience or wherever you are. All right. So what we're going to do is we're going to go through exploits that we've demonstrated before, shown before. There's not much new here. So the first one, but what is new here is the symbiote, depending all of this stuff. So the first thing that we're going to try it on is the Cisco IP phone. We're going to SSH into SSH. And so the exploit that we're going to be showing here is the same one that we showed at 29C3 hacking Cisco phones. So if you want the details on that, please watch that video. You can find it on YouTube. And then the way that this demo works is that we have a file called PONBIN. What we do is we change the way that setUID responds so that we get root access. If you look over here, the Cisco XAM and the secure state is secure. But after we go to the phone and we run PONBIN, we can then log into the phone and we have root access. Again, please watch the video to see the details. But now we see that the secure state has changed the PON because the symbiote detected the change that we made in firmware. And the checks have changed. That's how we detected. And you can see the alarms coming periodically. We actually had to slow down the alarms coming from the demonstration. We had to slow down the refresh rate a little bit. And here we're just going to show the 2821 router because of the screen formatting. But we're not going to be demonstrating a Cisco IOS exploit today. Along with the symbiote, we made a small change to the show CDP neighbor command, which in addition to showing us our CDP neighbors, it also makes the memory modification change that was part of the Barnaby function to bypass enable authentication. So if we run it here, we could see that the router 2821 checks and it's changed state to PON as well. Let me see if I can bring up the printer quickly. To do the 2821? It's off the screen. It would be hard to see. What you're looking at here are functionally equivalent devices. But these are very unique devices in the sense that the phone and the printer and the routers you've seen are literally the only ones of their kind that actually has host-based defense in real time as the device is running that will allow you to have alerts that tell you whether the phone and the printer and the router has been exploited with approximately 100 millisecond latency. This is something that's never happened before. And you folks are well, the very first people to actually see something like this. And this is not something that we developed specifically for a specific model of a Cisco or a phone or something like that. This is something that you can see in a car. You can see in something that controls Predator drone or the Mars rover which also runs 3x works, by the way. The same operating system as the printer. So that is it. And with the printer that has a very small proof of concept symbiote running into it, we can use our command to control root kit that we demonstrated earlier in the demo. So we made a change in memory of the symbiote picked up on it. So that's it. That's our defensive demo. I just want to say, you know, so we've accepted host-based defense on desktop servers for a very long time now, right? And, you know, we haven't really started thinking about ways of seriously defending embedded systems against this type of attack. So I think that's one of the reasons why we've been defending embedded systems against this type of attack. So you've seen in the last few years that exploitation of these devices is no longer a myth, right? It's no longer that hard that people aren't looking at it. Now, hopefully you saw here that the polyspecies malware propagation part of this thing is also not a myth, right? You saw live on stage. You saw printer on the phone, right? And malicious implants on routers, on the defenses that we use every single day in our offices, right, in our defensive networks, et cetera. So we have a few more minutes. I'm going to take Q&A in the pool. So we're going to have some time for that, but before, can we run the DDoS, the Denial of Service demo? Who wants to see a printer peg a 2821 router? All right, let's do it. This is a lot of fun. So right now, Mike is going to send the Denial of Service attack command to the OSPF hello address in multicast. When the router sees that, it doesn't know what to do. It gets scared and the CPU goes all very high and bad things happen, right? Ta-da! So that's not good, right? You shouldn't have your router running at 98% CPU utilization. And this is all happening from a single printer. Imagine a printer and a phone. We'll show that next year. Okay, so that's our presentation. If you want to know more about Software Symbiote or our presentation, check out Red Balloon Security, we have all of the academic papers that discuss exactly how this works, the performance constraints, the security promises and limitations of our technology and some demo videos and of course the slide. I don't have time to take questions, but Q&A area in the pool, right? Yeah, about 30 minutes we'll pack up. We'll go to the pool. Thank you very much.