Avidity Software

21-80

21,23,80

or even...

21-80,5900,5800

I had been wondering if the TCP connection throttling that I mentioned here would have an effect on my current scanning code. Since any probe packets that I'm sending are sneaking by the kernel without it's knowledge, I had a hunch that it would no longer be a concern because without the kernel knowing about the packets, it can't throttle them.

I tested this the other day and it turns out that my hunch was correct! What does this mean for future Yavar users? It means that you won't have to install the "patch" to be able to scan more than 10 hosts. On the other hand, you will need to have WinPCap, (or LibPCap for Linux and other superior OSs), installed to use this functionality, but come on, what hardcore administrator doesn't already have this installed? ;) Seriously though, this is a much better trade off since you don't have to "patch" your TCPIP.sys file with a utility that you may not trust. At this point you may be wondering how you can trust WinPCap or LibPCap. Well, they're open source. Download them, audit them, and compile them yourself if you're concerned about what they may be doing on your system. :)

A while back I'd noticed that if I had VMWare installed on my PC, VNCAdmin scans would take forever. Shortly after that, I realized that if I disabled the two network interfaces that VMWare installs, the scan speed went back to normal. This bothered me, but I assumed that it was just an isolated issue on my machine. However, I asked around and tested on other machines and found that it wasn't just an isolated issue.

Well, after a year or two of wondering, I've finally figured out what the issue is. It has to do with using the gethostbyaddr() function for retrieving hostnames when all you have is an IP address. This function will use several different methods of finding the hostname if it needs to before giving up, (I forget in which order it does these, or even what all the methods are :) ). At some point, this function will try sending NetBIOS name requests to the remote PC. The issue here is that it sends NetBIOS requests on each network interface that is defined on your host. So we're doing a lot more work, for the same result, (If you wonder how I know this, it's because I've sniffed the network traffic that the function generates). However, these VMWare interfaces are configured with 192.168.0.0/24 addresses, so they may not even be communicating with your network. I would assume that this would cause gethostbyaddr() to wait for responses on those interfaces or timeout when it doesn't get one, thus slowing it down even more.

However, now the question is, "How do I get around this?". Do I look for a newer reverse lookup function? Do I just write my own name resolution code by crafting and injecting DNS/NetBIOS packets? Do I ignore this as it's probably a pretty rare occurrence? We'll see I guess...

I can't help but wonder if the NetBIOS name requests being sent to each interface is a protocol spec, or if it's just the way Microsoft decided to implement the function? Perhaps neither I suppose. Either way, it's great to finally know what on earth was causing the slowdown. :)

I've added a link under the downloads section for the Yavar source code. For now, the interesting networking code is in VA_Utils.cpp. Enjoy!

Disclaimer: This is all alpha testing code, use at your own risk! :) I've not included any makefiles or build instructions as of yet since the project is so young.

It's been a while since my last update, but there's been a LOT of progress in the last month. I've revamped my scanning code to be much easier to use and more moduler, (however it's still not in it's final form :) ). This has made adding features and probe types fairly trivial.

At the moment I'm able to scan both internal and external subnets. What's the difference you ask? Well, when building a packet you start from the Ethernet header, then onto the IP header, then the TCP header, (assuming we're creating a TCP/IP packet). In order to write an Ethernet header you need the MAC address of the remote host. For local subnets, this is the MAC address of the remote machine itself, and this information can be retrieved by sending broadcast ARP requests and then sniffing for the replies that contain the remote hosts MAC address. However, on external subnets, the MAC address to the remote host that gets entered into the Ethernet header if the MAC address of the sending hosts default gateway!

So I needed to find a way to get the sending hosts default gateway IP address. Once I have that, I can send an ARP request for that IP address in order to get it's MAC address. This was easier said than done, (well, it's only currently working on Windows, I'll be working on Linux soon). However, stepping through the Nmap source code was a big help. Thanks Fyodor!

I've also added the ability to send a ping request to external subnets in order to find all the live hosts before actually sending the probe packets that test port status. This makes it so I'm not sending SYN, (or other probe types), packets to every host in the scan range. Why this is a good idea, I'm not quite sure yet. :) I've only done this for external subnets for now at least, since ARPing for the hosts on the local subnet seems to fill this function already.

So at this moment, this VNC scanner is enormously faster than the old VNCAdmin. However when comparing scan results to the old scanner and Nmap scans, I noticed I wasn't finding the same number of results. So I thought I'd throttle the rate at which I sent probe packets a little bit since I had been sending them to the network card as fast I could generate them. Adding a few milliseconds of sleep time between each probe gave me perfect results that now matched my old scanner and Nmap. w00t!

However using this kind of timing mechanism makes me a little uneasy for some reason, so I'm wondering if there's a better way to throttle sends...