 My name is Fyodor from Insecure.org. Can you guys all hear me? No. No? That wasn't up! All right, well thank you all for coming. DEF CON is always a blast and it's an honor to be here giving the opening talk to start out the conference. This year I'm going to talk about end map hacking. Basically there are a lot of security people who use end map, but many of them don't understand its full power. And end map deserves a lot of the blame for this because it kind of is too helpful sometimes. If you do a scan such as endmap scan me dot end map dot org, you're leaving end map to worry about deciding on the scan type, the timing options, the output format, the target ports, the source ports and addresses, and more. Well that's helpful reducing that complexity in terms of making end map easy to use. It's also troublesome in terms of a lot of people never explore the literally hundreds of advanced options that end map has for making your scan more effective. So in this presentation I'm basically going to go over three real world common examples and scenarios. And then I'm going to demonstrate how you can use end map effectively to solve them with an emphasis on options that are a little bit off the beaten path. I'm also happy to be releasing a new version of end map, a special for DEF CON. End map version 3.83 DC 13 is available at this URL here. You definitely want to get the one on the web rather than the CD as it's a lot newer. It is a lot of cool features which I'll talk about in this presentation shortly. Also I'm going to give early warning now that this presentation does use real uncensored IP addresses and host names. That's because I trust you guys not to abuse the information. Also, okay, okay, but if there are any black hats in the room who would use this information maliciously, then I'm sorry, but I'm going to have to ask you to either leave or when the IP addresses come on the screen just cover your eyes. I'd appreciate that. Before I begin, it would help me to get an idea of how much introductory end map material I need to cover. So if I could get a show of hands for anyone here who has ever used end map. All right, everyone. So we'll skip end map for dummies and move directly to host discovery. Host discovery covers the real common case where you just want to look at a network and find all the hosts on that network that are online. Maybe you're a pen tester who just busted into a new subnet and wanted to see what machines are on. Or maybe you're a network administrator doing IT inventory. Or maybe you're going to do a more intensive scan, but you want to figure out what hosts are up first so you can focus your efforts on those. End map used to only be able to send an ICMP echo request message and later a TCP act to a port. And at the time, you know, that was useful. And that's still the default because there was a time when end map could send a ping request and expect that the vast majority of hosts would respond. Unfortunately, that time is well past. Many hosts, you know, don't respond to a ping, you know, even though the RFCs say that they should. The internet is a much more guarded and filtered place nowadays. Fortunately, end map has also evolved with the times and offers a wide variety of options to make your host discovery more powerful. For example, you can send SIN probes. If you want to get through a stateful firewall that only allows SINs, you can send ACP probes for those stateless firewalls that watch for SIN packets but can't tell, you know, that the ACP's not part of an established connection. UDP probes you can send, and all three of these types you can send to a big list of ports in the hopes that you'll find just one of them that's responsive. Also, ICMP echo requests and pings, time stamp requests, net mask requests. So you have a whole lot of options there. You can combine those options almost arbitrarily. But with so much many options, that leaves you to the question of, well, you know, what's going to be most effective? And sure, you know, I can speculate on what might be most useful or what networks I've seen, you know, have available. But the best way to answer these questions is empirical results. So let's start with what are the most valuable TCP ping ports to use? I did a scan of more than 10,000 IPs on the internet using NMAP's random target selection option. And I took that and looked at just those hosts that are heavily filtered because the unfiltered ones we're going to be able to find anyway. And of those, I said, hey, which ports are most responsive to a SIN packet? And this is the list starting with the most common. SMTP is also popular, SSH, HTTPS, FTP, OFF, telnet's down there, but it's nice to see it below SSH. And these are the sort of things that you would expect to see. You know, if you have your firewalled host, you still have to have port 25 open if you want to receive mail. You know, a lot of times they make 22 widely open, so if they're off it, well, DEF CON is a bad example. But if something bad happens while you're away, you want to be able to connect in and remotely administer. So your best bet is to pick a variety of these. The next question then is what sort of TCP probes do I want to send? You know, there's the SIN probes and the ACP probes. You know, the answer is just send both. That way, if it's the stateful firewall, like Microsoft.com, your SIN will get through, but your ACP won't. Whereas a stateless firewall, your ACP's more likely. So send them back. All you need is one response to tell you that the host is open. So send them both. What about UDP ports? Here you have a little different idea than with TCP. With TCP, an open port is still responsive, so it tells you that the host is up. With UDP, NMAP's blank UDP messages are unlikely to elicit a response from an open port, and so you don't want to hit an open one. So your best bet is probably just to pick a high port, like 22,131 or whatever, that's less likely to be filtered. And a little exception to the rule is you might want to try 53 as well, just because DNS is so common. Yes, if it's open, you probably won't get a response, but sometimes administrators open it for a whole section of network, and so from those machines that aren't running DNS servers, you can still get through. For PING types, I would recommend an echo request, and then either a timestamp request or a netmask request. The idea is that some hosts, for example, Google or insecure.org will let you PING them, whereas there are other hosts that have said, hey, I'm going to block PINGs, but they do it poorly and they forget about the sister options like timestamp request and netmask request. But the ones who block the latter are likely to block them both. So your best shot is generally to do both, or to do a PING request and then one of these others. So let's put that all together. Take all of these ideas and put it into one intense discovery combination. And here's one that I would recommend. Here we're doing an echo request, timestamp, a variety of SIN probes, ACP probes, and also setting the source port 53. You never know when that little trick will work to get through port configurations. One thing to note when doing this is that this is 13 probes rather than two. And host enumeration time is going to be roughly proportional to the number of probes that you send, and so you want to consider whether it's worth it. But in many cases, you really do want a comprehensive list so it's worth taking a little longer. And like I said, speculation is all well and good, but when you're deciding whether you do want to spend the extra time or what's going to be most effective, empirical data is the best to have. So I did a test. I used the random target option again to generate a list of 50,000 random IPs. And then I ran it and mapped with the default scan types. And it chugged away and chugged away, and eventually it said, okay, out of those 50,000 IP addresses, 1,770 are up. All right, so now let's try it with the more intense discovery. We use all these probes, and suddenly instead of 1,700, it gets 2,698 hosts up. So we see a 50% improvement just by adding these extra options. And yes, it did take four times as long, but in many cases, if not most, you know it's worth it for you because you really want to find all of the hosts. And there are a couple of notes that I want to make regarding this sort of scan and these results that we've found. One is that it's not quite as exciting as it seems because some of these 2,698 hosts are going to be network artifacts. For example, in my last DEF CON talk, I showed an example where a host that was a firewall was spoofing reset packets to any probe sent to port 113 on any of the hosts behind it. And so some of these are network artifacts and you'll have to use the sort of techniques I talked about last time to discern which are the artifacts and which are the actual hosts. The other thing worth noting is that these techniques will give the most improvement in a case like this where we're doing a worldwide scan over the internet against tons of firewalls and filters and such. If you're scanning a local LAN, the defaults may work fine. But while we're speaking about scanning a local Ethernet LAN, that crops up with its own big bunch of issues. Here I do an Nmap command for a ping scan of a host on the Ethernet LAN that's not really up. SendIP is a new option that I'll talk about later. But for now, you just need to know that that does the same default behavior as all of the pre-DEF CON releases. So I run Nmap and I've pasted in some ethereal output to kind of show what's going on under the covers. I give the OS an IP packet. It sends an ARP request looking for the machine immediately. Then after one second, it sends yet another ARP request. And after two seconds, it sends a third ARP request. And finally, it gives up and Nmap ends after just over two seconds. And there are a couple of problems that... Can you guys hear me better? All right. There are a couple of problems with this two seconds. You know, it may sound, oh, two seconds big deal, but if you're scanning 10.0.0.0.8, that's 16 million hosts and two seconds is going to add up. Even 192.168 is still 65,000 hosts. And Nmap scans these in parallel, but still it's not as fast as you would like it to be. And it's wasting time waiting for these ARP requests. Another problem is that most operating systems, you know, they have an ARP table and that ARP table is finite. So when they have an incomplete entry such as this, they'll add that ARP table will fill up and sometimes Nmap has to wait, you know, as much as four minutes for those ARP entries to expire. You may have seen that if you scan a big network, Nmap is like, hey, I can't send right now waiting 60 seconds, then waiting 120 seconds. It's very frustrating. And since scanning your own local LAN is extremely common, that's something that's worth optimizing. And so one of the features in the new Nmap is ARP scanning. The idea is give Nmap full control to send those ARP packets. That way Nmap can worry about the timing and the retransmissions. It can skip over the ARP table for the OS entirely and do the scan a lot faster. Another advantage not only is that it's much faster, but it's more accurate. As we've already seen, many hosts have all sorts of filters that can block your host discovery packets. But if they want to communicate on the network, they generally have to reply to ARP. So if Nmap gets an ARP reply, it knows that it's online. So here's a quick example I have here where I scan the same machine as before with the new Nmap and instead it sends one ARP at the beginning and then one ARP after a tenth of a second. And then it gives up in two tenths of a second. So it takes less than an eighth of the time that it took before. I can try and do a live demonstration here, which is always risky at a conference, but we'll give it a try. So here I'm doing Nmap, a ping scan. I probably have to make this bigger, don't I? Or can you guys read it? All right, huge we are. So I'm going to do a...what a mess this is. So I'm going to do a ping scan. PR is the new ARP feature, and I'm going to scan the wireless network that I'm on now with aggressive timing. And so it goes, it starts showing you the machines that are up and it shows you their MAC addresses. Right now we're only seeing one because I'm just scanning the short subnet, but we see that it finished and showed that Dell guy. Another tool that you can use to do this sort of scanning is THC Root. How many people have used that? It's a nice little tool by the hacker's choice. So here I'm going to do the same scan, and I'll make it huge again, with THC Root. And again it goes through, it finds the gateway machine, and it thinks and it thinks, but you can see that it's taking a bit longer. Nmap took five seconds and it took ten, which is no big deal, but on a large scan, having it go faster is a lot helpful. But it's worth noting that while Nmap may be faster, THC Root still has a lot of great things going for it. For example, I compiled it just recently, and you can see all the configure screens, and at the end it gives you this beautiful ASCII art of a giant monster holding a white hat severed head who's screaming, help, help, I'm just stupid white hat, please don't hurt me. So Nmap can't quite compete with their ASCII art. Or can it? Yes, I'm pleased to announce that the new DEF CON version, yes, we've got the ASCII art for you, it's just not quite as violent. So that's ARP scanning, and another feature I added just for you guys is ARP spoofing. When you've been kicked off as many networks as I have, you start to appreciate the values of stealth and misdirection. So say you're sitting in a conference room, and you've got the only think pad, unlikely, I know, and all of a sudden a big scan starts, and everyone sees the MAC address is registered to IBM, you know, heads will turn in your direction. So with the new spoofing option, I did this at the hotel last night, I specify spoof MAC Apple, and Nmap looks through the OUI table, finds the MAC prefix registered to the company you specify, fills out the last three bytes randomly, and then you can point at the Apple guy and say it must be him. Thanks. You can also specify it, you know, in other formats, if you want to specify a specific MAC address, or just give another prefix, it'll fill in the rest, or just give it zero, and it'll give you a fully random MAC. And it shows you down here what MAC that it selected. So that's basically host discovery. As you can see, there are a lot of different options that you can do there, a lot of different things to play with, and by manipulating these different options, you can get much faster and more accurate results. Now let's look at another common scan, and that's single host discovery. Say a new vulnerability comes out in some product. You want to scan your network before the bad guys can and identify all instances of the vulnerable product. Or maybe there's a new worm going around, and you want to scan to find infected hosts before they can do much damage so you can quarantine them. Or maybe you're doing forensics on a compromised host, and you find that they've left a back door open on some unusual port. Well, scan your network real quick, and maybe you'll find other compromised machines that have the same back door. So here we're going to do an example of this, which is a little bit unusual, but basically covers the idea. Our mission statement is to locate web servers on the Playboy.com network offering free images. The idea here is that I was thinking, hey, you know, they charge $10 a month for their content or whatever, and I'm a cheapskate. Maybe they have a development server or a staging server somewhere where you can download all the images for free. You know, it's worth a try. So how are we going to do this? Well, first we need the address to scan, and that's pretty obvious. Just do a look up on Aaron for Netblocks owned by Playboy. The first one we get is this slash 20, 4,096 hosts. There are a lot more Netblocks they have, but for this example, that's enough for us. And so let's give it an initial try. We're going to do end map. We'll say don't ping because we're only scanning one port. The ping would take longer than the scan. The port is 80. Save the results in greppable format so we can easily grep out the open servers, and then we give it the network. And it chugs along and it completes, but it takes 20 minutes. You know, even for 4,096 hosts, that's longer than I want to wait. So how can we speed that up? One thing you can do is help by giving end map timing information that it is trouble getting itself. On a responsive network, on your local LAN or whatever, you can usually, end map is able to calculate its own response times based on the responses it's getting and usually optimize those pretty effectively. But when you're scanning over the internet on a highly filtered network, end map's not actually getting much responses. And so it doesn't really have a good idea of how long it has to wait before it can time out and retransmit. So the idea here is we'll try and figure out some of that ourselves, and then we'll pass that information along to end map. So I look for hosts on the network. First I try their web server, and I see that that's on a different IP, so that's no good. There are two different servers, and we lucked out there are two of them that are both on the networks we're trying to scan. Normally I might just take one host on the network, but here, you know, we don't know a lot about the network configuration, and also given the names, we can tell that this one's probably in Los Angeles and this one's in Chicago, so the latencies are likely to differ dramatically. So how do we figure out the latencies? Well, let's ping the hosts. But they both say 100% packet loss. They're blocking our pings. Well, that's a bummer. But, you know, they're mail servers, and so they've got to have port 25 open. So let's use HPING2 to do a TCP ping of those ports and see how long that takes. So we say HPING2, send a SIN to port 25, like we're opening a connection, send five of them, and we do it to both the Chicago and the LA networks. And here, the information you really want is not the fastest time, it's not the average time, it's the longest time that any of those pings take, because you want to be a little bit conservative here. If you try and get too aggressive, you'll actually make the scan take longer because NMAP will be retransmitting when the response is in transit. So even though the longest we saw out of these two was 61 milliseconds, you know, LA is a lot faster than I was scanning from California, we're going to pick a bit higher numbers to be on the safe side. So we're going to say the max RTT timeout is 200, so we'll wait up to a fifth of a second, and we tell NMAP to start out with 150 milliseconds so that NMAP will only go up to 200 if it needs to, and NMAP can still go faster if it determines that it can. Another optimization is to say scan in bigger groups. We're going to specify a minimum host group size of 512 that breaks up the 4,096 machines into eight groups of 512 and allows NMAP to go much faster by more efficiently handling them in larger groups, and the rest of the options are pretty much the same. So how long does that take? NMAP chugs away, and it still takes almost 15 minutes. That's better than 20 by a long shot, but let's be honest. When I'm looking for these free images, I'm not a patient guy. This is an urgent matter, and so I say, how can we make it a bit faster here? Well, think about what NMAP is doing under the covers in this case. NMAP, you may know, does reverse DNS resolution by default, and when I'm doing P0 scans, no ping, that means that NMAP is considering all of the hosts up, and so it's doing a reverse DNS resolution on every host. And reverse DNS, I'm afraid, is one of the few NMAP functions that's not yet parallelized, so that may be taking quite a lot of time. So I do the same scan, but this time I add hyphen N to get rid of reverse DNS resolution, and here we see that it only takes about three minutes, which is perfect, because that's about as long as I last. And so, by just manipulating these different values, we've been able to reduce the scan time from 20 minutes to only three. But enough about timing, let's look at the results. We did that big scan of 4,000 IPs, but we only found two that are open. Well, that was sort of a little bit worrisome, but you never know, maybe they're good ones. Let's take a look in Firefox. So we'll go to the first one, which is 216.163.140.20, and we see Microsoft Outlook Web Access. Now, that would be really exciting if we were trying to break into their network, but it's not very gratifying for our particular goal here. What this does tell us is that, hey, maybe the network we scanned was the corporate network when we really should have been scanning the production network. It is nice to note their cute little Playboy Mail logo up in the URL bar. But all is not lost because we still have one more site. And I'm very pleased to report that that one has gigabytes of free images that I downloaded immediately upon download. In fact, I think I'll even show you. So this one is 142.135. And so here it chugs away, and we see free BSD ISO images right over here. We see Fedora images, lots of them. And if you're on the kinky side of things, they've got the whole Perl network right around here. So whatever your tastes, this is a great site to download images. And I would also like to mention this is also named mirrors.playboy.com, and it actually is a real valuable site that I use when I need to download. So we can say mission accomplished on that goal. But let's look at another quick single service discovery option. And that's NMAP's version detection. In many cases, you want to not just know what ports open, but you want to find out the exact service that's listening. And so with version detection, instead of browsing the well-known ports table, NMAP actually interrogates the ports and tries to figure out what's running there. And so that way you can maybe distinguish the vulnerable services from the invulnerable ones or find the services, even if they're listening on a non-default port. And NMAP now has more than well over a thousand different version detection signatures to identify all sorts of crazy things. In this example, this is just one that someone sent last year when my DOOM was basically causing havoc. Right when it was released, he posted this to the NMAP dev. Here's a probe you can add so that you can identify compromised machines or infected machines. So I'm just showing this as an example to show that it's actually pretty easy to add your own custom identification if you want to add services that aren't in the official file. So you just say, do a TCP probe. We'll call it my DOOM. These two bytes are the data that you need to send. These are the ports that it normally listens on. And you'll match for service my DOOM if you get this back in the response. The program is my DOOM. The number he just put, you know, the data was found in the wild. So that's a real useful thing to add. And to add it, all you do is add this little s capital V and NMAP does the rest of the work for you. So that's enough for single service scanning. Let's try something a little different that's also common. What if you want to defeat a firewall? Sometimes you really want to look at what ports are open on a machine, but those pesky firewalls can get in the way and NMAP has some techniques that can help you resolve that problem. So we've got another mission. This time we want to discern the open TCP ports on docserve.caldera.com. Now I was a little reticent about using SCO as an example because at one time they were kind of considered a threat to free software. But lately, you know, their litigation is in shambles and they're pretty much a laughing stock. And so it feels kind of like beating a dead horse. The problem is it's so useful because every time I want to find like really pathetic network configuration, you know, I can find an example right there. Also, they are a fun horse to beat, so let's do it. If we want to find the open ports, the first thing we're going to want to do is a SIN scan. You know, that makes sense. It's the default. It's often the most useful. So we do a SIN scan against the machine. We find port 80 open, port 5,507 open, and 113 is closed. So did we do it? Well, not really. Because while we figured out the state of three ports, the 1,660 remaining ones are in the state filtered. So we don't know if they're open or closed. It's worth noting that in a real scenario you would probably want to add hyphen p hyphen so that it'll scan all 65,000 ports. But just like with the Playboy example, I'm limiting it just to be a useful example. So we've got three, but there's still a huge number that we've not really determined. Those ports could be open and exploitable, those 1,660, or they could be closed. We just don't know. So what do we want to try next? Let's try a different type of scan. Let's try the fin scan. That basically sends a fin packet, and if it receives a reset back, the port is probably closed, whereas if we get nothing back, the port is either filtered or open. And this isn't true of all machines, since some of them aren't susceptible to this issue, but it's true of a lot of them, so it's worth trying. So we try it against Docksurf, and as you can see, we get a whole big long list of ports that are either open or filtered, and then the rest of them are in the state closed. So that's very interesting. It's limited the number of ports quite a bit here to just a few dozen that are either open or filtered, and one would hope that most of those are actually in the filtered state because it would be pretty pathetic to have that many open, but this is SCO, so you never really know. So how are we going to figure out, differentiate, because it's very important distinction whether the port is open or filtered? Well, let's try yet another type of scan against them. This time, we're going to try an act scan against Docksurf, and that sends an act packet, and if it receives a reset back, it knows that the port is unfiltered because it got a response, whereas if it receives nothing back or an ICMP port filtered message, it knows that it's filtered. And so this gives us a lot more information. Here, the vast, vast majority are unfiltered, but it tells us that just two of them are filtered. So what's an interesting thing you can do is combine those by looking at the last results and comparing them with these. For example, look at port 135. Here it says filtered, whereas before 135 was open or filtered. Well, if you kind of take the logical end of those, you see that it's got to be filtered. Similarly, 1434 looks like it's really filtered. Let's take another example. Say you want to know about the SSH port, 22. In this case, it says that 22 is unfiltered because it's one of all these other ports, and in this case, we see 22 is open or filtered. So if we have open or filtered on one scan and unfiltered on the other, that just leaves open. And so if you combine all of these different results from the two scans, what the hypothesis is is that 135 and 1434 are filtered, but all of these other ones on this huge list are open. And so that tells you a lot. And you can see a little bit of confirmation in terms of the two that we know are open to the SIN scan 80 and 507. You see here as well 80 and 507 in the open or filtered. So we have a pretty good idea about what we're seeing, but networks can be tricky. It's always good to check your results, try different things, see what's matching up. So let's try yet another type of scan. And that's the Windows scan, which is a little-known scan technique, but it's very similar to the ACC scan, except that it noticed a property that certain hosts have where when they send a reset back from a probe to one of their open ports, they set the window as they would if it was a SIN act for a real connection. Whereas when they're sending a reset back from a closed port, they set the window to zero. So by looking at that window, TCP receive window value carefully, we can determine which of the ports are open and which are closed. So we do an ACC scan against this machine, and sure enough, like we thought, all the ports are open except 135 is filtered, and I think 443 is the other one, or no, it was my MS SQL was the other one, 1434 was filtered. So that sort of confirms our results now. We've tried a lot of different things, and now we have a good idea where they're open. And it kind of shows the value of taking the SIN scan and seeing it doesn't get you all the results that you want, so you just keep trying different things until you meet your goals. So that was basically our three missions. And so now I'm going to just give a quick overview, since I've got, oh, about five minutes, of some of the new features that I have in the DEF CON version. There's the ARP scanning that we've already talked about, the MAC spoofing. One nice new feature is raw Ethernet packet sending, because raw IP packets can be a huge mess. You know, a lot of systems screw them up, and Microsoft, even worse, they recently banned them with their Windows XP SP2. So now we're saying, well, screw you, Microsoft. We're just going to send at a lower level and send the Ethernet packets directly, and that should be a lot faster. It also has 350 new OS fingerprints for a total of 1,690, from this ACC Amazon WAM concentrator to the Xyxcel Xywall. 250 new version detection signatures. So there are now 1,312 of those, covering 212 protocols, such as SMTP, SNMP, KAZA, all sorts of bizarre things. It integrates Doug Stong's excellent libdnet, which helps with the raw Ethernet packet sending. Version detection now helps you find OS information. So the version detection now can find three extra things in many cases. If it sees a service that only works on Windows, or if the service responds with a certain platform name, it can now report, and MAP now reports that next to the OS detection results. The OS detection results are this, and version detection says it looks like this OS. And some people would say, hey, combine those to get just one result. But in reality, what you really want is to have both, because they may be distinct. If you're scanning a firewall that proxies to an IIS server, you should get checkpoint firewall one or whatever for the OS detection results via TCP-IP fingerprinting, whereas it should say Windows for the application version detection results. And that's pretty common. You'll get the same thing if you're scanning, you know, someone's Linksys network, for example, where they've NAT forwarded different ports to different machines. Version detection also now gives a device information and host name information, which can be valuable. I broke the Windows support, I'm afraid, for the moment, but that may be fixed eventually. And when it is fixed, though, we'll have the advantages of the raw packet sending. But for the DEF CON release, I figured the priority was to get the UNIX versions out, and I've tested this one on Linux, OS X, Solaris, FreeBSD. And then there's also quite a few more features, which you can find in the changelog. What's coming next? Well, I'm happy to report that Google has sponsored 10 students to work on NMAP for the summer. And, yeah, they're student programmers, but some of them are serious students, like PhD students, in doing very relevant research. And so that's pretty exciting, and they're working on a whole lot of projects. There were 233 applications, and I picked the top 10, and we worked out some pretty cool projects. One of them is NCAT, which is sort of a re-implementation of Netcat that adds a bunch of new features that I've wanted. You know, things like SSL, IPv6, password protection. There's a connection brokering feature so that two nut hosts behind a nut can connect into the Netcat listener, and then it brokers the communications between them. You know, all sorts of cool features, and you'll find a man page that he's posted so far on the NMAP dev list, and he's working on the implementation. New GUIs. And GUIs sort of sometimes have a reputation as, oh, this is just for newbies who can't remember those hundreds of NMAP options. But these are more advanced user GUIs. Things for, they're mostly results viewers. So you've scanned, you know, tens of thousands of machines. These make it easier to identify which machines have this port open or compare the difference between two scans and show me what's changed. You know, features like that. There's probably two user, two of these SOC students writing independent GUIs. Potential scripting language. I'm not sure if that's going to work out yet or not, but this guy is working on that. And when that is added, we'll probably use that for host discovery stuff. Information gathering, as opposed to, you know, trying to add a thousand different vulnerability detection modules will focus on, hey, have a script that does trace route. Have a script that checks whether a proxy is open. Have, you know, scripts for all these different things that it can look up once NMAP has determined the OS and port service version and such. Windows performance is a big priority. Also, I've been chugging away at my NMAP book, which has taken a long time, but I'm pleased to report progress. I've got more than 200 pages of it here now, and I think it's looking out to be pretty good. Given how slow publishing is, you know, it'll probably be six months, but I've added a bunch of cool network scanning goodies and corny jokes, so it'll be great. There's a hyphen hyphen reason option I would like to add so that NMAP can say, hey, we think this port is closed because we received a reset back. We think it's filtered because we received nothing back or because we received an ICMP port unreachable or destination unreachable message back. So that'll be useful for more understanding what's going on under the covers. And then I might add proxy and sock scanning. So that's basically my presentation, which is good because I'm about out of time. I'll just take two questions here if anyone has them. Yes, I'll put the slides. Yeah. Yes, docserve.keldera.com. No, right now I have the new version of NMAP up here at presentation slash defcon.13 and I'll put the slides up there shortly as well. Thank you very much.