 Let's start off with the most common question I get. Why is all your work Cisco centric? Well, they do have quite some market share. 92% of all routers, about $1,500, which I think nowadays is about like 500 euros, is actually Cisco equipment. And the other stuff in this area, like Juniper, like from a hacker perspective, Juniper is just like a really fucked up free BSD. So there is actually nothing interesting about it, neither from an exploitation nor from a forensics point of view. The same actually holds true for your arbitrary cheap home router because if you actually get off and unscrew the device and look at it and find out what it is, it is all Linux. So this is why I keep doing Cisco stuff. Why the actual, we actually do a network equipment forensics? By definition, the goal of the whole forensics deal is to explain the current state of a device, which means we acquire evidence, we recover information from the evidence because the evidence is actually gonna be raw data. And then we actually do some analysis on this information and find out what actually happened. For common operating systems, methods and tools actually exist. So if you own a Windows box, some certified forensics dude is gonna take this apart and find out who you are and then bust you. For network equipment, there is nothing of this. We don't have a way to tell if a Cisco box actually crashed because it felt like it, which they do a lot, or if it actually crashed because some dude tried a buffer overflow attack on it. This is the most frequent asked question that I get since I would say about eight years. People go like, this is all cool and stuff, but who the fuck would heck a router? Like, why would you actually do this? There is no porn on it. So this is my reasoning for this. If you compromise a single machine, you get all the porn that's on the single machine. If you compromise an important machine, you get all the porn on this machine and all the others that trust this machine. If you compromise the switch that connects those machines, like a workgroup switch, you can actually make those people watch different porn than they wanted to watch. And it's really hard for them to tell why. And if you actually compromise the router, then you own the entire network and you can essentially stream your porn everywhere you want. And yeah, inspired by the buzzword survivor, here's some PowerPoint buzzword pictures. So just to explain that to the really slow plea bill of you, if you own a single system in today's networks, that actually does not give you a significant advantage. It certainly does give you an advantage, but it doesn't give you a significant advantage. So from the attacker point of view, owning a single system actually doesn't get you higher chances to get into the other systems next to it because the switch is gonna block things like your op games and stuff. However, if you're actually owning the switch, all the separation is broken, you get to modify their communication streams and it's actually really hard to recognize from the host. Like try to find out, connect to a switch anywhere in the world and then try to find out if this switch is compromised. There just is no reverse knack like network access control. Like the network is trying to access control you, but there is actually no way for you telling if the network is fucked up or not. And of course, if you actually own the router, that means you have control over the entire network and you can actually added bonus impersonate this network to the internet. So I wanted to do a slide on how this looks on the internet, but they're just way fucking too many routers on the internet, so that doesn't work. So we're back to Cisco style, corporate network graphics. So this is what a regular network looks like. Raise your hand if you have ever heard the term autonomous system in terms of routing. That actually improved. Good you guys are learning shit. So what I'm trying to show here is multiple autonomous systems connected together with a core network and then having government and business and shit. Do your top right. If you have seen other presentations from me, you know this, it's the international ASCII symbol of an asshole, so he's gonna try to fuck with the network. The thing about those networks is this. On the border of the local network to the actual large parts, to the actual autonomous systems, we do have firewalls. We do actually have IDS, IPS. It's not like anyone is watching them, but we do have them. And whatever your civil ballad for security of the day is. When you look further into the core, you actually have routers that border the different autonomous systems. They do the route distribution. They care about your local network talking to the core and stuff. They have Ingress and Egress filtering. They do anti-spoofing. They actually try to keep that core clean and try to prevent the asshole from actually injecting evil routing message into the core. However, in the core, we actually do have full trust. And this is because it wouldn't work otherwise. Like this core is actually exchanging information about the routing tables and about how the network is supposed to behave with each other. There is no other choice for the routers than to trust each other. There is no other way to do it. So that means network security is actually a hierarchical thing. Defending against your downstream is a very common thing. Otherwise all the ISPs will get owned by you guys with the DSL or cable modems all the time. So they do not accept routing updates. They do not accept route advertisements for the 192.168 network from your fucking DSL connection. However, the other way around upstream is really, really bad. I mean, what are you gonna do? If your upstream provider says the internet just moved, you have two choices. Either accept that message and like go along with it or have no internet. Defending against your peers in those networks is also very, very rare and common. As I said, it's really hard because you actually have to trust them. Otherwise the shit is not gonna work. If you control anything in this hierarchy, you control everything below. That means if you control anything in this core, then you control everything around it. So let's assume this, our little guy up there compromises this one router. He gets actually have to have a say in the autonomous system to the top right. If he actually compromises another router, just like one other router that happens to be peer to the core, he actually does compromise the entire network. So some of you might actually say, yeah, this is all cool, but I got SSL and I got my DBA nice keys and I got SSH and secure whatnot. The thing is this, those protocols actually work. Like there are people with actual brains compared to me that actually work on those protocols. However, they can only guarantee that your protocol messages are not modified, they're not fucked with, they're not spoofed, and they're not replayed. However, if anyone is actually going to do exactly that, like if anyone is fucking with your protocol, what are you gonna do? Like what are your options? Your SSL breaks, your SSL doesn't work anymore, your SSL bitches about someone doing man in the middle. Yeah, right, you know that now, but you can't actually get where you wanted to go with the SSL connection. So at some point in time, if someone compromises the network, the question becomes availability or security, like one of the two. Like if your home banking doesn't work for about a week, then your choice is get off your lazy ass and actually walk up to the bank and like do the transaction manually. Or seriously, most people are gonna click on fuck it, even if they know. Because they don't feel like leaving the room and they will miss the next episode of like, ooh, my bots. So this is actually what happens. And in a business context, this is actually worse because like there is nothing to click on, those are automated systems. And at some point, they will simply turn off all like certificate validation because yeah, they need to keep running. The reason for that is if the user detects someone like fucking in the network, if he actually called choose a different traffic path, that is what we call source routing. And that is actually, there is a very good reason this is not in the internet anymore because that would mean the user has control over the network. The user can decide where the actual protocol messages go, what path they take. And this is really, really bad for networks. So we turned that off like about 30 years ago on the internet, so that doesn't work. And what I'm trying to say with all those ramblings here is all this is actually by design. Like IP by design has dump leaf nodes like stupid end users. And intelligent core nodes. If you compromise an intelligent core node, you actually compromise the entire network. This is by design, we can't do shit about this. So this is why we try to do network equipment forensics. Do I make sense? Good. So what types of attacks do we have? Like when we wanna do forensics, we can do forensics the way that like the certified forensics expert do it. Or we can actually care about what we're trying to detect first. So we're gonna take the second route. So this is essentially like the three classes you can do to a router. You can have protocol-based attacks. You can actually have attacks on the functionality point. Or you can have binary exploitation. Protocol-based attacks. So I've given my very first talk here at DEF CON 9 on protocol-based attacks. Essentially the whole idea is you inject control messages into the network. Like you participate in a routing protocol for example. And you tell the network that the routing should be different now. Let's say it goes over your machine and you can inject your gate point. The attacker just becomes part of the normal network communication. Types like typical examples of that type include well-known things, R-poisoning, Kaminski DNS games, interior routing protocol injections. Like you just be part of an OSPF cloud and like announce your routes. Or exterior routing hijacking BGP. There's very good talk. This is the speaker over there standing wave. There's a very good talk on Sunday. If you actually wanna watch someone who knows really what happens with Cisco, go to his talk. Like you are in the wrong talk. That's what I'm saying. So on a functionality side, we actually do see a lot of configuration-based problems. Like the people, you have to realize this. Anyone here has a CCIE certification? Like raise your hand if you're a CCIE. There are two. Have they taught you to change passwords? Like you studied for two years lab exam and then all the lab has Cisco as a password. So Cisco actually teaches people to have Cisco as a password. Even the highest qualified. Which is really bad because some people actually don't realize that in real world they should not use Cisco as a password. So you still find a lot of routers with that problem. Then we have weak SNMP communities which pretty much is the same thing. And we have people posting their configurations on the internet forums because they can't figure the shit out themselves and then someone else goes and decodes their passwords. We also have access check vulnerabilities which fall into the same class for me. There is the Cisco HTTP vulnerability from like six years back and you still see people scanning for this. Like people actually scan for Cisco routers that have that vulnerability. The thing is this. Blackheads are actually really good at telling you what actually works. So if people are still scanning for it it means they actually find stuff. So they wouldn't scan for stuff that's patched all over the internet. And then we have like the most beautiful vulnerability from my point of view because I'm like more a runner guy. The SNMPv3 vulnerability. Most people have actually not noticed it in all the noise that other vulnerabilities made this year. So here's the deal. SNMP is the absolute standard in how to manage routers. Like people do not use anything else. The thing is SNMPv3 means version three. The reason for this version, the entire reason for this version actually was that in version one and two everyone was sending a clear tax password called the community string over the network and so it was really easy to like sniff this off the network and then own all the routers. So in v3, they actually introduced crypto. I'm not making enough sense so I'm drinking beer. So they introduced crypto and we all know crypto, hey, right, you put it in, it's all good. Civil bullet, actually not. And then like SNMP, the people who designed SNMP are the same people that try to carve off single bits of messages and then instead of like putting a message plain into a packet, they invent it like ASN one and like everyone gets owned because nobody actually managed to implement that correctly and nobody told them that there are actually compilers for ASN one. So we end up having those same people think, hmm, we have a new authentication mechanism but HMEX, cryptographic hashes, keyed hashes with a secret, this is what they use. So HMEX, they're really long, like 160 bits. Wow, that's like, saturate our network. So let's go talk to the crypto guys and see if we can make this like a bit smarter. So what they actually did was they talked to the crypto guys and the crypto guys told them from a theoretical point of view, taking half of the hash is actually as much proof as taking the full hash. And you can talk to Bruins over here, the guy with the yellow shirt, if you don't understand why that is correct. So the thing is this, they thought okay, we can take half of a hash, that's really cool. Now let's make this dynamic and let's specify that we can actually take like an arbitrary subset of the hash in a packet for authentication. So what people implement is they do a mem compare between like the hash they have on the router, the hash to get in a packet and the length that was advertised in a packet. Does anyone see a problem here? If you advertise a length of one, you actually do have 256 tries until you own the router. And it actually took like several years for people to realize that. And then like the net SNMP guys, like the guys who write the open source version, said oops, we kind of barfed up here. So like they went to CERN and I said like, sorry, like if you're running net SNMP, please patch. And then all the vendors crawl out of their holds and go like, yeah, we copied that code. This is like the biggest vulnerability in network terms that we had for many, many years. Added bonus, all lawful interception equipment is controlled by SNMP V3. I leave it up to the audience as a home exercise to become a lawful entity in your country. We do actually have routers that do SSH and we do actually have routers that do SSH with Debianized Keys. So that's also a way to like get on your router. Then there's another buck class that I call the queuing bucks. They essentially, well the reason they exist is because Cisco doesn't know software architecture but like we knew that. Essentially the problem is you have a router and interfaces have queues. Like when packets come in, they get queued up. And then someone has to take the packet and say I'm responsible for it, I'm gonna process it, I take it off the queue. If nobody does that, the packet is stuck in the queue. And there's a bunch of those vulnerabilities and they're like coming out on a regular basis about like every two years. Pretty much like a rock bands albums release cycle. So this means that the router actually has a full queue at some point in time and doesn't actually accept any traffic anymore, so it gets stuck. And we want to detect those as well. And then we have binary exploitation. And in contrast to common belief, there has been Cisco hacking and binary exploitation before Mike Lin. However he actually did a really good job in like bringing in the interactive shell. So we do have binary exploits which roughly fall into two classes. One is you attack a service that runs on the router. Like the router runs services like every other computer on the internet does. And you can attack those services. So as you see with the protocols, it's like HTTP, FTP and stuff like that. However, people that are actually a little bit smart about their routers, they don't have an HTTP server running on it. So there are other attacks, stuff that routers actually have to do like OSPF or IPv6 or something, and there have been remote exploits for that. So in today's networks, how are people are actually monitoring and detection intrusion? If. Most don't. Like most just like not look at their routers. The ones that do use SNMP, as I said, for the most part, SNMP is a very protocol that is just like totally broken two slides ago, is the thing for managing routers. The problem here is from a forensics point of view, SNMP is built, it's called network management protocol. So it is built for managing the network aspect of it. So it tells you about the routing tables, op tables, blah, blah, blah, all that stuff. It doesn't actually tell you if you have an additional process running on your router. Then we actually have SysLog, which turns out to be a really useful tool for detection of intrusion into routers because it supports free form strings. So the coder of some piece of code in Cisco can actually go and like log a simple like text string. And if you configured SNMP, if you configured SysLog, it will actually take this text string and send it over to a sender server. So you actually have a record of what's going on. Then there's configuration polling. In most cases, people actually watch their conflicts if they ever change. So there's a cool tool called Renset that people actually use to monitor changes in the configuration because like, you're coming to work in the morning and this tool is telling you someone kind of like reconfigured your routers. That is a telltale that you actually should change from the meetings you had with the marketing guys to actually like fixing your routers today. For the protocol-based attacks, people run route monitoring and looking glasses. What that is is just like another machine, usually a router or some BSD box that participates in the routing protocol and just checks if the routes actually change in an unforeseen way. The idea is pretty much the same as with the conflict polling. And then we have a very surprising thing that we can use for forensics, which is traffic accounting. The thing is this, nobody actually watches their network closely enough to do any forensics or to actually see if the router gets owned or if someone does any mischief. However, they all do traffic accounting and they all are really, really keen about not losing information who sent what traffic. The reason being that's what they are paid for. Like this is what they use to charge you for the traffic. So there is actually an interest in not losing this data and there is actually an interest in making sure that nobody fucks with it. So it turns out to be a really valuable source for forensics because it's pretty much the only non-compromised central locked data that we have in networks. So take a table and see what of the attacks can we actually detect with the monitoring that we have in today's networks. And here's my virus scanner. Like hands for my not 32 virus scanner actually trying to update on the DEF CON network. Come on guys. That is so not smart. However, this is what kill switches are for. So if you look at this table, you actually see that in the bottom line if you do binary exploitation, we don't see shit. Like we have no idea if it actually happened unless the attacker was really, really stupid and like wrote the configuration because then we can get him with config polling. So we're actually concentrating on this. What do binary exploits do? What are we trying to detect? What happens if the binary exploit actually worked? Like we're not gonna detect the return address overwrite and then jump into some arbitrary code. We are gonna detect what's happening afterwards. So we should care about what is happening afterwards. We do have this one type of attack that people use. There was actually a blackhead talk on this which is the binary modification of the runtime image. So essentially you patch away user credential checking or essentially you backdoor the router. You also, and that was not covered, you patch away logging. What is the point of like patching away the user access credential checking when the log messages go to a central point and say here's user FX logging into your central Cisco machine. So you actually do patch logging as well. And when you think about what goals people would have when they own the router, they will actually patch firewall functionality. They will actually make sure that your ACLs look really, really good, but they actually don't work. What also is done is data structure patching. So you go ahead and you patch the access level of a VTY which is virtual terminals, Cisco speech, and we don't know how to implement ASAP spawning telnet. You actually check those access credentials and patch the check out or set the privilege level to a already high value. You can bind additional VTYs which is essentially like a port binding shell code. Or you just go ahead and terminate processes. Like there is a lot of annoying stuff running on a router that you don't want anymore once you own it. So you just terminate the processes. We need to detect that. You can change the configuration and runtime. You can change state machines. That is actually very, very powerful because it's really hard to detect. But actually so far nobody has done that. What has been done widely is TCL backdooring of routers. Mostly so far it has been done by people that worked for an ISP and then at some point didn't anymore but didn't wanna lose their exclusive access. The iOS in later versions has tickle script interpreters and don't actually ask me why they use tickle of all things. So they do actually have TCL scripts and they do actually have the ability to bind to a TCP port. So you can have a really, really short port binding shell code in TCL and just run it. And of course they implemented a new feature. They fucked it up badly. So there is a large range of iOS versions where you can actually have your TCL script running in your authenticated context and once you lock out the script keeps running with your former privileges. So what we need for the forensics, what we need for finding all this is, as I said in the beginning, evidence acquisition. We need to recover information and we need to now analyze this information. And by the way it will actually not hurt to know how iOS works internally. So let's do that. What types of memory do we actually have in such a Cisco device? Because that's kinda important for forensics because we wanna know how to get this memory. So in general, how does that work? Cisco device, 50,000 foot view, when it boots there is a BIOS type of thing that's called Rambon which is kicking off your iOS image. The image may or may not be self decompressing. So we have to take into the account that the image that's actually loaded is not the one that's running but it's actually the image that gets loaded is unpacking the image that will run eventually. The image may and will in most cases actually contain firmware for additional hardware. So they do piggy-pack like the byte code for like the ISDN controllers or what other line cards you have in. They are actually in the iOS image. They are piggy-packed in there. The configuration is loaded as an ASCII text from NVRAM or from the network which would be the most stupid thing to do. So we're not covering this. But it is actually parsed on load. So if the configuration is wrong, if it contains bullshit or if it contains like weird statements that this version of iOS doesn't understand, the way they solve this is they actually parse it as if you were like hacking it into the router every time you boot it. So you can actually have a pretty fucked up configuration and still working router. The statements in the configuration are gonna be mixed with defaults of the iOS image. So if you are not explicitly configuring a certain feature, it will default. The problem is it will actually default to whatever it feels like in this version of iOS. So this is not a consistent thing. The same configuration on two machines with slightly different iOS version will actually produce a different state. Everything is kept in RAM. So we don't have a hard drive in there. The configuration changes have immediate effects. So there is no incentive for an attacker or a network administrator to actually write them back to NVRAM. And this is the most common thing with like networks when you have a power outage because the guys just like do not save the configuration back to NVRAM and then when you have a power outage, they go like fuck, so what did we change last two years in this configuration? So I mentioned everything is kept in RAM. We need to actually get to this. On common operating systems and in forensic scenarios, the volunteer information is actually add-on. It's bonus. Like if you pull the power plug of your Unix Windows got-be-wear-mech-ass machine when the police is crashing in your door, that is not a problem. Like all the evidence is actually on the hard drive. The add-on, like bonus information of what is the runtime state of your machine would have been nice. And they could throw this whole machine into like super cooling and like pull the keys off and stuff. But in fact, that's actually not required. In fact, you're leaving so much evidence on the hard drive that it's actually not a big deal. With Cisco, that's a different story. Because everything is in RAM, we actually need to get to this RAM when stuff is happening, when we wanna know the state of the router or when the router actually crashes. We need this on demand or we need this before the router crashes. By the way, crashing and rebooting is the default behavior of those routers. Like if they detect anything wrong, there is no Dr. Watson, there is no police tell Cisco about this vulnerability. It will just reboot as quickly as it can, which means it is destroying all the evidence that we potentially would have to find out why it is actually crashing. We do have non-voluntary evidence on a Cisco. Of course, we have the flash fire system. On a flash fire system, there is the image. So if someone actually modified the image, like backdoor it, we can get it off the flash fire. So we don't actually need to do anything fancy. We can just take it off the flash and put it into IDA and then read. NVRAM, I mentioned, it contains the configuration, so if anyone changed the configuration and actually wrote it back, we get it off NVRAM. But in fact, nobody does that because that would be really stupid. From a attacker point of view, if you actually have a working zero day against Cisco, you are not writing the configuration back to NVRAM. You're so not. You're so trying to stay in the RAM image and hide it because this exploit that you have, there is way too valuable to give away just by writing the configuration changes. So the good thing is the Cisco engineers actually need pretty much the same thing because if people complain about the router's crashing and those people actually pay for service, the Cisco people need a way to tell why the router was crashing. So they have this not widely documented developer thing that's called core dump bits. Essentially, you can make an IRS machine dump core either on flash or onto a remote server in two cases, either when you issue a command, write core, or when a machine crashes. This is exactly what we want. We get a complete memory image. It contains main memory. It contains IO memory. It contains the PCI bus memory. And it's a raw dump, so it's perfect evidence. The router doesn't try to fuck with it. However, we should actually configure this feature before shit happens. Afterwards, it's too late. So we actually need to configure core dumps. And what's good about this is it actually has no performance impact. You configure it, it just sits there as information unless something happens. So you can configure that and then if you imagine you have a centrally located FTP server in your network, you can configure all the routers to dump core to the central FTP server. That saves you a lot of monitoring. And it also means that you don't get called in the middle of the night when one of your routers rebooted and one of your network management apes saw this red dot blinking in HP OpenView. But you can actually tell them, you're not calling me at night. I come in in the morning and look at the FTP server. If a core showed up in the incoming directory, I know something rebooted. So this is actually really cool. Why wasn't it used before? Reason being core dumps were only useful for Cisco engineers, kind of, and for exploit writers. Everyone else didn't have a use for it. So we actually need a piece of software that goes ahead and tells us the state of the router that recovers all this information on the actual abstract state, like what processes were running, what packets were handled right away, and all that from the core dump. We want this to be 100% independent. We want this to be a second opinion on what Cisco tells you. Because the command line on the router called lie. And it actually does quite often. And it, well, the thing that broke was Cisco code. So you're not gonna rely on Cisco code to tell you why it broke, right? On the other hand, we want this to be a forensics tool. So we don't want this to be like N-Case, so you get owned when you're actually looking at evidence, and then you tell people that this is actually not a vulnerability. So we actually want this code to be solid, so you're not getting owned by someone like crashing your router in a very funny way, and then you get cross-site scripted when you look at the output. As you probably figured out by now, we have implemented such a tool. The way we do this is we take the image that was supposed to run on this router, and use that together with the core. The reason is iOS images are actually a large ELF binary. It's like the biggest LS binary you've ever seen. It runs directly on the router. It doesn't have any concept of kernels or something, and the virtual memory mapping is just baseline, so they're like the TAB, are you fucking kidding me? Shit. The TAB actually only has only five or six entries that says here's code, here's data, go fire. Processes on iOS, if you lock into a Cisco machine, it shows you all the processes. They're not processes, they're threats, they're CPU contexts. That's it, there is no memory protection whatsoever. It has a really fucked up scheduling, and it has system-wide data structures, which is really useful for us in this case, because it has a common heap, like everything shares one heap, and it has very little abstraction over this stuff, so we can actually dig out the entire state really easily. So we take this image as a blueprint. We take this image, we take the section information, and we put it as a blueprint on top of the core. I wish it were as easy as it sounds. Cisco has probably found all 100% all possible ways to fuck up the L format, and then they have found some more. So it is actually really, really hard, and we wrote actually a lot of code, and we did a lot of testing to get this right. Once we got this, we can actually take this image and say, you know what, the code section, if that changed between the memory dump and the image, you got owned. It's like the most simple test in the world, but it actually works really, really well. So this is a fancy graphic of what we are doing. We take the elf header, we map out where stuff is in the core file, and then we compare everything that is supposed to be really static and really equal, which is code segment and read-only data. It's called read-only data. Nobody should write to it. And this is what we get. The core guys from core impact, not core dump, they actually wrote a backdoor for Cisco iOS. Topo did the original research, and he called it dick, that iOS root kit. So I can get to compare my tool to Topo's dick, which is kind of cool. And so he was nice enough to provide this backdoor to me before he actually showed it at pH Neutral. And so I put it into our tool, which is called SIR, and outcome the virtual addresses with the exact location where he actually patched the image in runtime. And we can actually tell that his dick is only three times four bytes. And I'm running out of time. I wanted to show you how his backdoor looks like. Because you get the virtual address, you just load it up as a core file into IDA and then press C at the right place. But I'm kind of running out of time, so maybe at the end. What we can do is also, we can reconstruct the entire heap. iOS has so much overhead on a single heap block allocation that we actually find a lot of valuable information in that. The heap blocks even have names, like literal ASCII strings telling you what they're supposed to be. This is really good for us because we can tell what the block was actually supposed to be used for, and then if it contains a bunch of capital A's, we know if it's not called the A-strip block, then we know something is going on here. We can reconstruct the entire heap. We find things that Cisco does to their own heap in regular runtime without being actually hacked that are really scary. Like, they free memory somewhere in the greed-only data section, and then go like, well, we don't need this memory anymore. Let's make it a heap block and just stick it into the linked list. Like, how can you do this? So we implement all the functionality that Cisco has that's called check heaps, like all the onboard tests. We implement that and a lot more. We find holds in the heap. We find heap overflow attacks pretty much, yeah, there's pretty much no hiding. We can even identify formally allocated heap blocks so we can actually tell what process was eating all your memory and then stop when you locked in so you couldn't find out who it is. We extract the process list, of course. Threat list, process list, whatever. It is called process list. We do extract that and this gives us the location of the stacks, which means now we do actually have process, memory, stack, and we can actually apply any known post-mortem analysis method to this and we can actually find out what went wrong. We also extract the TCL chunks and try to find the back doors. We're actually dumping the chunks right now. My biggest fear is that at some point in time, I will actually have to drink lots and lots of alcohol and then write a TCL decompiler to actually find the back doors by itself when they're compiled, but I'm so scared of this. So we have some random applications. You can imagine this tool is actually really cool for research because it actually gives you all the pointers and tells you what to do. You're not shutting me down, you're so not. I'm not shutting you down. Who thinks we should give FX five more minutes? That will be sufficient. Thank you very much for bearing with me. So we also have something. Because we get the IO memory as well, we actually see stuff that IO has dots to packets. It is when they process which packets, when they actually have to load them into main memory and think about them in the scenario of ACL matching, for example, or when they're running firewalls stuff, we actually get to see those packets. Now, IO memory is a part of the main memory in the lower end shared memory routers. It is usually a very large part. And it is ring buffers. So ring buffers have this wonderful property that they overwrite linearity, but they have different sizes of ring buffers. They actually have a ring buffer for small packets, medium packets, large packets, extra large packets. So if your network is usually transporting TCP packets that have the full size because everyone is streaming porn and someone sends an exploit in a small packet, this small packet is gonna stay in memory a long, long time. So what we do is we extract the traffic. We actually dump the traffic that the router was routing in his recent past, which is in so far cool as that we can say, you know what? This packet over there is the one that your router crashed on, which means we get instantaneous all day collection in the form it was actually sent. So we can actually like, this is how it looks like we actually produce a pcap file and you can see like all the passwords flying by and stuff, but you also like, if someone attacks the router you can just like take this one packet and say, save to disk and you got new Oday. And that was the entire point of the exercise. So quickly, what about crash info? So some iOS devices actually write a file called crash info, it's a text file and I'm just not going into the details, I'm just showing you something here. So on the top you see a very tell tale number that someone exploited this device. The problem with crash info is it's information that iOS writes into a text file of what iOS thinks the cause of the crash was. And in most cases, if you look at this, in most cases it actually takes a process called crash writer, which is the process that gets started to write the crash dump. So it wasn't actually existing at the point in time where something went wrong. iOS is just too fucking stupid to find out what crashed. So it's actually like blaming the process that writes the blame. So hackers like to get up on stage and say, I have this really cool tool and it's like 0.0.1 alpha and only compiles on MacOS X on a like Solaris platform. We actually put a lot of work in this. We actually have this in release state. We do actually work professionally on this. So since February, we do have an online service where you can submit core dumps and you get a full report and it's registration free and everything. There is, if there is interest and I don't know so far, so feedback please. There's gonna be a free root kit detection version that does like that finds Topos Dick in your routers. And we actually do have a professional version that actually costs money because all that research costs a lot of money. To find stuff and to use on your own FTP server and larger networks to automatically process core dumps that come in. The challenge here is this. iOS images have about like, there are about 100,000 different iOS images out there. 15,000 officially supported by Cisco at any given point in time. This is a great headache for us. It is also a great headache for exploitation because I want to make sure that you're not thinking like I'm saying everyone like all the Chinese heck your routers and own your routers. It's highly unlikely right now because remotely you actually have a chance, 1 to 100,000 to actually guess the right images. And the stacks are not stable. Like all the addresses are not stable. If you ever wrote a stable exploit, you know that hard-coded addresses really, really suck. But all the exploits, mine and everyone else's so far have been published with fixed addresses. So they work with one out of 100,000 images. So the diversity, the sheer diversity of code that Cisco puts out there is almost a better protection than the source pod randomization patch that you apply to your DNS due to Kaminsky's fucking around. So they actually like make it better for the worse. This is a slide on like what I think people with backdoors will do in the future. And as you see, there is no blanks on the detection side. Once we get all those iOS platforms like the hardware platforms covered and that's a lot of work. Once we do that, I think we should be pretty fine for the next couple of years if you guys start configuring your routers to actually dump core and not ignore reboots. And that is it. Thanks for the additional five minutes. If you're interested in this subject, I do recommend going to this website. There's the Vicky. We actually try to fill it with useful information and it actually contains exploits as well.