If you want to find out the components of a site’s certificate the following commands will help you.
If you want to find if the certificate is signed with the weak MD5 signature algorithm:
$ echo | openssl s_client -connect webserver.example.com:443 2>/dev/null | sed -ne ‘/—–BEGIN CERTIFICATE—–/,/—–END CERTIFICATE—–/p’ | openssl x509 -text | grep “Signature Algorithm”| gawk ‘{print $3}’

$ echo | openssl s_client -connect 167.155.38.24:443 2>/dev/null | sed -ne ‘/—–BEGIN CERTIFICATE—–/,/—–END CERTIFICATE—–/p’ | openssl x509 -text | grep “Exponent”

In metasploit there’s a plugin admin/backupexec/dump. This plugin uses the default credentials to login to Veritas backupexec agent and download an arbitrary file. The catch is it downloads it in the MTF (Microsoft Tape Format) file. You need a utility called NTBackup to restore this file. Metasploit authors have conveniently made this available for us at http://metasploit.com/tools/msbksrc.tar.gz.
However, if you compile this file you get an error:
msqic.c:814: error: conflicting types for ‘bques’
This happens because the function prototype is missing.
Goto line 169 of msqic.c file in the source code and add the following line:
int bques(char);
Once you add this, you should be able to make the client and should be able to extract the file from the .mtf file.

I like using dcfldd for creating the raw images, because it shows a nice status…it’s interesting to see progress.

dcfldd if=/dev/sda of=/mnt/sdb1/filename.dd hash=md5 md5log=hashfile.md5 conv=noerror,sync bs=4096

It’s the ‘bs’ (stands for bytesize) that makes the difference (…always does doesn’t it .

Autopsy – The forensics browser always uses the ~/.autopsy as the base directory for storing the files from the cases. The following command is helpful in changing the directory in which the cases should be stored:

./autopsy -d /mountpoint/dirname

The exiftool is a cool application that can read meta-information to determine the different types of files.

Web services security has been very much talked about in the recent times. Especially, with the Service Oriented Architecture (SOA) gaining increasing importance. One of the interesting ways to protect these web services encapsulated in SOAP (Simple Object Access Protocol) is using digital client-side authentication certificates. Programmers typically use Java Key Store (.JKS) files to establish connectivity to these applications. However, if we want to create a custom client using some scripting it creates an issue as we tend to use languages such as perl, bash, etc. to create connectivity. So I ran into this excellent tool called KeyTool IUI. This tool helps you import the Java Key Store (Tools -> Keystore Manager -> JKS Keystore) and export it in the PKCS#12, X.509 PEM, and DER formats. You can further use OpenSSL to change the formats as you please or separate out the components of the certificates.
You could even take these certificates in X.509 or PFX formats and convert into JCEKS, JKS formats! Pretty cool huh? Nice software!

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.cgooscan.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 oncegooscan.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.