I think Nmap is by far the best portscanner around if you want to do some serious port-scanning. Nmap performs a DNS resolution by default. This is good for obtaining the fully qualified domain names (FQDN), however, in some cases when you are scanning huge networks spanning several class Bs, it can have a significant effect on the duration of the scan.
Although using the -n parameter can completely stop nmap from performing any resolutions, but sometimes there’s that fine granularity that you need, i.e., you want to perform name resolutions but not if it exceeds a certain amount of time. I have to say that I wouldn’t have even craved for such an idiosyncratic feature, had it not been for nmap. Fyodor has been awesome enough to provide fine-grained control over port-scanning to your heart’s content.
So I opened up the nmap code, trying to figure out if I could fine tune that feature myself and I was not at all surprised that there were several comments in the code that would give you the impression that the authors of nmap have been considering this feature.
At this time it seems that the timeouts for the DNS servers are being read out of an arrayname:
static int read_timeouts[][] in nmap_dns.cc.
The way the code works is, this array has retransmission timeouts. Each row of this array represents what retransmission timeouts that nmap will follow depending on the number of DNS servers provided.

In nmap 4.76, therefore, if you specify one DNS server (or only one entry exists in /etc/resolv.conf) nmap will wait 4000ms, then another 4000ms followed by 5000ms before giving up. But if you do specify two DNS servers, then for the first DNS server the timeouts are 2500ms followed by 4000ms and then the same is tried for the 2nd entry in the DNS servers. Therefore, it seems that nmap will wait 13 seconds at max before giving up on the DNS resolution of a host. Imagine scanning a class B and having to wait 13 seconds for each of the hosts to resolve. It would be a significant overhead.

Of course, one can find other things to do if the IP address space is not DHCP, e.g., starting a separate list scan (-sL) and a portscan (with -n) simultaneously so that the DNS resolution timeouts do not result in a major impact as far as the portscanning itself is concerned.
There could be pros and cons to this as well which I may have failed to consider. But at this time it seems that it might be the most judicious approach.

I was just browsing away when I stumbled upon Johnny Long’s GooScan. He says that this is a Linux only tool but it seems to compile (not without problems though) on cygwin.
I kept getting the following errors:

L:\tools\gooscan-v1.0.9>gcc gooscan.c
gooscan.c: In function `inet_send':
gooscan.c:575: error: `MSG_WAITALL' undeclared (first 
                       use in this function)
gooscan.c:575: error: (Each undeclared identifier is 
                       reported only once
gooscan.c:575: error: for each function it appears in.)

Then I read somewhere that MSG_WAITALL is not defined for Cygwin and that instead of that zero would work. There are many neater solutions to this…but I’m a hacker and I’ll do the stuff that’s easiest and hassle-free.
Some people say that the following will work:
#ifdef __CYGWIN__
#define MSG_WAITALL 0

So in order to compile this bad boy, you need to goto line 574 in your favorite editor.
It looks like this:
recv(sock, recvbuf, sizeof(recvbuf), MSG_WAITALL);

You need to make it look like this:
recv(sock, recvbuf, sizeof(recvbuf), 0);//MSG_WAITALL);

You are all set:
gcc gooscan.c -o gooscan.exe

Compilation works! But then I observed that the results were not coming well. However, if you run it through a local proxy such as burp it still works…I bet it has something to do with socket establishment and receiving and being incompatible with the MSG_WAITALL flag.
But as long as you can get the results … who cares? If someone figures out exactly how to make this work, please post it as a comment.

It can get interesting to test the security of thick client applications. If you start debugging you could end up losing a lot of time with not too many results. Of course, time is always at a premium when you pen testing in a week long gig. There are a couple of tools that can really help you to gain insight into a thick client (i.e., an application written in a binary format such as an executable, ActiveX control, flash object, etc.) and communicating to a server using the client/server model.
The need for a proxy to hook into the communications is a prime need and EchoMirage can do a great job of hooking into function calls related to win32 sockets, openssl functions. You have to select an active process for Echomirage to inject into or you can even spawn a process from the menu options in EchoMirage itself. It’s a great tool with a built-in editor so you can edit the traffic. However, sometimes you have to be careful because it’s binary data that you are editing so while editing it is easy to mess up a few flags, etc.
Another great tool is actually a plugin for OllyDbg called UHooker that can let you specify which functions you want to place a hook into. You have to configure a binary editor of your choosing and the functions to be hooked into in a .cfg file. The documentation for Uhooker is located here.

Installing Firewalk turned out to be more complicated than I thought it would be. There were some compilation issues and some library errors.
The chief amongst them was:

checking for arp_get in -ldnet... no
configure: error: No libdnet?  http://libdnet.sourceforge.net.

I did install libdnet using aptitude but it did not do the trick. Thereafer, searching a few forums got me this information. The “Libdnet” that Firewalk looks for is libdumbnet1 in the ubuntu language.
So I got the Debian packages from the following links:
libdnet1
libdnet-dev
I continued to get that error and no wonder because there was nothing in /usr/lib.
So I executed the following commands :

$ cd /usr/lib
$ sudo ln -s libdumbnet.so libdnet.so
$ cd /usr/include
$ sudo ln -s dumbnet.h dnet.h

Then there was a compilation error:

firewalk.c: In function ‘firewalk’:
firewalk.c:193: error: label at end of compound statement
make[1]: *** [firewalk.o] Error 1
make[1]: Leaving directory `/home/trance/Desktop/Firewalk/src'
make: *** [all-recursive] Error 1

So then opening the firewalk.c file in vim (and following up on line 193) showed that the “break;” statement was missing after default: switch statement.
So then I added the the following characters (without quotes) “break;” at a line above the comment as shown below:

                    default:
                        break;
                        /* empty */

$ ./configure
$ make
$ sudo make install
$ sudo cp man/firewalk.8 /usr/local/man/man8

Now firewalk was installed and ready to use!

I decided to play around with Spike fuzzer and encountered some weird errors during installation. I was using gcc 4.1.2.

gcc -ggdb -o generic_listen_tcp generic_listen_tcp.o dlrpc.o 
dlargs.o spike.o listener.o hdebug.o tcpstuff.o 
spike_dcerpc.o base64.o udpstuff.o spike_oncrpc.o -ldl -L. -ldlrpc
/usr/bin/ld: generic_listen_tcp: hidden symbol `__stack_chk_fail_local' in
/usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: *** [generic_listen_tcp] Error 1

If you are also getting the same error, I would recommend that you do the following

SPIKE/SPIKE/src$ ./configure

Now open the Makefile in your favorite editor and edit the CFLAGS line to include the following option:

-fno-stack-protector

This is how my CFLAGS line looks like in the Makefile:

CFLAGS = -Wall -funsigned-char -c -fPIC -ggdb -fno-stack-protector

This should make it build fine (I do get a few warnings but that’s cool…it still does not result in a no-build.

I’ve been struggling to find the best working version of John so that it can crack MS Cache outputs from Cachedump (of course, this functionality is now included in fgdump). Running fgdump gives two files host.pwdump and hostname.cachedump. I’ve found 127.0.0.1.pwdump and 127.0.0.1.cachedump files upon using fgdump without any parameters.
So now you have the Cached credentials but then comes the big problem of cracking those. So there’s the jumbo patch for john-1.7.2.
Following commands need to be executed to get this patch going:

$ tar zxvf john-1.7.2.tar.gz
$ cd john-1.7.2/
$ wget http://www.openwall.com/john/contrib/john-1.7.2-all-9.diff.gz
$ gzip -d john-1.7.2-all-9.diff.gz
$ patch -p1 <john-1.7.2-all-9.diff
$ cd src/
$ make linux-x86-sse2

You get some warnings upon compilations but the executable works very well.

Go ahead and get cracking:
$ cd run/
$ ./john –format=mscash