Re: nmap-dev Digest, Vol 59, Issue 54

[kirubakaran S <kirubakaran1989 () gmail com>]

Hi,
   I am completely new to nmap. can any one guide me
where to start so that i can start contributing to nmap.
I have already sent mail but there were no replies yet !!

Thanks

On Fri, Feb 26, 2010 at 6:29 AM, <nmap-dev-request () insecure org> wrote:

> Send nmap-dev mailing list submissions to
>        nmap-dev () insecure org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://cgi.insecure.org/mailman/listinfo/nmap-dev
> or, via email, send a message with subject or body 'help' to
>        nmap-dev-request () insecure org
>
> You can reach the person managing the list at
>        nmap-dev-owner () insecure org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nmap-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: Raw IP NSE Functionality (David Fifield)
>   2. Re: Raw IP NSE Functionality (Kris Katterjohn)
>   3. pcap_register (David Fifield)
>   4. Re: [NSE] Minor feature enhancement for nbstat.nse (Ron)
>   5. Re: tracking the w32.download.X worm using zenmap (Ron)
>   6. Re: [NSE] Minor feature enhancement for nbstat.nse (David Fifield)
>   7. Re: Raw IP NSE Functionality (kx)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 25 Feb 2010 15:03:25 -0700
> From: David Fifield <david () bamsoftware com>
> Subject: Re: Raw IP NSE Functionality
> To: nmap-dev () insecure org
> Message-ID: <20100225220325.GF700@gusto>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Feb 23, 2010 at 03:00:17PM -0600, Kris Katterjohn wrote:
> > On 02/23/2010 01:39 PM, Patrick Donnelly wrote:
> > > Ok this patch wasn't quite right. I've attached a new one but I'm
> > > getting some strange C++ segfault I can't figure out. I'm not going to
> > > devote any more time to this since Kris has a viable patch already
> > > committed.
> >
> > Ah, yes, sorry about not mentioning this before you posted.  I wanted to
> put
> > it in there before I got busy today (i.e. right after I committed).  I
> didn't
> > mention it yet because I ended up finding a bug and wanted to investigate
> first.
> > I don't know if my script is somehow wrong, if it's a bug in the pcap
> reading,
> > or something entirely different. Using ipidseq on multiple hosts at the
> same
> > time (hostgroup) somehow gives my script a packet with the same ipid as
> (what
> > appears to be) the first packet read from the first host read from in the
> > group.  It's only the first one, the others are ipids from the real host.
> > This sounds horribly confusing after I read it, so here's something
> better
> > than my explanation (stripped Nmap output with some debugging in script):
> >
> > NSE: Starting ipidseq against 192.168.10.4.
> > NSE: Starting ipidseq against 192.168.10.3.
> > got ipid 49992 from 192.168.10.4:21
> > got ipid 49992 from 192.168.10.3:80
> > got ipid 49994 from 192.168.10.3:80
> > got ipid 38558 from 192.168.10.4:21
> > got ipid 49996 from 192.168.10.3:80
> > got ipid 38559 from 192.168.10.4:21
> > got ipid 49998 from 192.168.10.3:80
> > got ipid 38560 from 192.168.10.4:21
> > got ipid 50000 from 192.168.10.3:80
> > got ipid 38561 from 192.168.10.4:21
> > got ipid 50002 from 192.168.10.3:80
> > ipid #1 = 49992
> > ipid #2 = 49994
> > ipid #3 = 49996
> > ipid #4 = 49998
> > ipid #5 = 50000
> > ipid #6 = 50002
> > NSE: Finished ipidseq against 192.168.10.3.
> > got ipid 38562 from 192.168.10.4:21
> > ipid #1 = 49992
> > ipid #2 = 38558
> > ipid #3 = 38559
> > ipid #4 = 38560
> > ipid #5 = 38561
> > ipid #6 = 38562
> > NSE: Finished ipidseq against 192.168.10.4.
> >
> > Nmap scan report for 192.168.10.3
> > Host script results:
> > |_ipidseq: Incremental! [used port 80]
> >
> > Nmap scan report for 192.168.10.4
> > Host script results:
> > |_ipidseq: Randomized [used port 21]
> >
> >
> > Notice the same "ipid #1" lines for the hosts.
>
> I have this fixed in r16879. Man, you had me deep in the Nsock pcap code
> before I thought to look at this:
>
> --- scripts/ipidseq.nse (revision 16878)
> +++ scripts/ipidseq.nse (revision 16879)
> @@ -215,8 +215,6 @@
>
>        pcap:set_timeout(3000)
>
> -       math.randomseed(os.time())
> -
>        local tcp = genericpkt(host, port)
>
>        while i <= NUMPROBES do
>
> os.time has a resolution of one second, so most of the time both scripts
> had the same random seed. The first random number they generated was the
> source port for the first probe, which would be the same in both
> scripts. Therefore both scripts registered the same pcap key and both
> saw the same one out of the two reply packets. The fe times when there
> was no collision, the two calls to math.randomseed must have fallen on
> either side of a second boundary.
>
> The BPF filter alone won't prohibit one script from receiving another
> script's packets. As I understand it, that's the purpose of the extra
> pcap_register step. You could make the matching more robust by
> registering all the information that you currently have in the BPF,
> which is the source and destination hosts as well as the source port.
>
> This all looks good an ready to merge, once you add documentation for
> the nmap.get_ports function to nmap.luadoc and scripting.xml.
>
> David Fifield
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 25 Feb 2010 16:36:44 -0600
> From: Kris Katterjohn <katterjohn () gmail com>
> Subject: Re: Raw IP NSE Functionality
> To: nmap-dev () insecure org
> Message-ID: <4B86FB7C.9000906 () gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/25/2010 04:03 PM, David Fifield wrote:
> > I have this fixed in r16879. Man, you had me deep in the Nsock pcap code
> > before I thought to look at this:
> >
> > --- scripts/ipidseq.nse (revision 16878)
> > +++ scripts/ipidseq.nse (revision 16879)
> > @@ -215,8 +215,6 @@
> >
> >         pcap:set_timeout(3000)
> >
> > -       math.randomseed(os.time())
> > -
> >         local tcp = genericpkt(host, port)
> >
> >         while i <= NUMPROBES do
>
> Well damn, that wasn't very climactic.. or was it? ;)
>
> Yesterday and today I managed to get some afternoon spurts of debugging in,
> and while in the middle of it today, I smacked my forehead when I saw your
> commit mail.  I have piles of various debugging output statements, saved
> outputs and some packet captures which I should just save for a good laugh
> later :)
>
> Thanks, David!
>
> > os.time has a resolution of one second, so most of the time both scripts
> > had the same random seed. The first random number they generated was the
> > source port for the first probe, which would be the same in both
> > scripts. Therefore both scripts registered the same pcap key and both
> > saw the same one out of the two reply packets. The fe times when there
> > was no collision, the two calls to math.randomseed must have fallen on
> > either side of a second boundary.
>
> See, it always occurred for me.  I was wondering why (and now how) it
> happened
> without fail for me, but you saw otherwise.
>
> > The BPF filter alone won't prohibit one script from receiving another
> > script's packets. As I understand it, that's the purpose of the extra
> > pcap_register step. You could make the matching more robust by
> > registering all the information that you currently have in the BPF,
> > which is the source and destination hosts as well as the source port.
>
> I'm not understanding the purposefulness of this.  Why is one script with a
> filter for one host still getting packets from another host responding to a
> different script?  Matching source ports or not, I don't think it should
> happen because of the different address *in the filter*.  It's all raw
> packets
> here, so I don't grasp why this isn't done.
>
> I thought the pcap_register() bit was like additional filtering, after the
> processing pcap does with its BPF filter.  I thought it was very useful
> when
> things change, like the source port in the script, but only if (as I
> imagined)
> it happens after pcap's filtering.
>
> In this regard, I wanted to put as much in the BPF filter as I could to
> reduce
> the pcap_register() stuff, so if the filter doesn't really filter for the
> script, I must ask: what's the point of having both?  Or better yet: what
> advantages does the current way present?
>
> > This all looks good an ready to merge, once you add documentation for
> > the nmap.get_ports function to nmap.luadoc and scripting.xml.
>
> Great!  I'll try to write it up and commit it tonight.
>
> > David Fifield
>
> Thanks,
> Kris Katterjohn
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQIcBAEBAgAGBQJLhvt7AAoJEEQxgFs5kUfuouYP/iwrqlMaGe//ZeglmX7ct2Kn
> rrWV3CDCdyLLvkDsTtLIkvzgPkGVd4ok0MuFajGlkRntPMW5Oqy8UbRHcZ31PfRA
> nnxTnQOie+N/AOVn62diRwxb7WW+UOHoUZwt4Japwjz7nC2uCwAzAaaua2qdFOHm
> SuTJ60Kb0OLYkKHOuWEbQnElbm6Rn9MWUpGe7KBngPRAN32CA4lsbrEkVy4UWIvc
> 8Ni3l3q2bs1Jt08enGDbFnMqQdGeHQ6bsquU8CvLFcT96YpmTnl74c6Nr30YeefO
> 3sf43ucKglN7OLjK53WIyGRkM73V2n/jXz7QLSVfqPplpq98N33F0uhxXke0vaoh
> Fc3qzPJUstPvuMCGiYFf0obaEOOdSyeRjJD/fO1nGPGAZKb+ekO+hiQxvRUw7jAQ
> Cv0gtW/7gi2PBZrmPi/+cGgw5hCvjZ3dOcwImOJGEpFoBIlHewlOXZ7LlTbu2OrU
> WDViTsNczf1mx6SFCRuaxkUPBmkaCrejH2HjvvyrtvtTY7XB9bUgK2YM5wDVn2oR
> c172ho62JQxOn2t+hYqFQefmyCRxfVoV2hxnKW8G4Mn8f3VBFk24NMdffosNGdv8
> 5qkZNp91ZvY84DcfI7rQblKE8YQy8YGzn0ij1/8KVNNCO4VNIaAJNSjEjfmUOi0W
> MPeJwQfrXfbdb87UvWS2
> =1J8T
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 25 Feb 2010 15:48:12 -0700
> From: David Fifield <david () bamsoftware com>
> Subject: pcap_register
> To: nmap-dev () insecure org
> Cc: majek04 <majek04 () gmail com>
> Message-ID: <20100225224812.GG700@gusto>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 25, 2010 at 04:36:44PM -0600, Kris Katterjohn wrote:
> > > The BPF filter alone won't prohibit one script from receiving another
> > > script's packets. As I understand it, that's the purpose of the extra
> > > pcap_register step. You could make the matching more robust by
> > > registering all the information that you currently have in the BPF,
> > > which is the source and destination hosts as well as the source port.
> >
> > I'm not understanding the purposefulness of this.  Why is one script with
> a
> > filter for one host still getting packets from another host responding to
> a
> > different script?  Matching source ports or not, I don't think it should
> > happen because of the different address *in the filter*.  It's all raw
> packets
> > here, so I don't grasp why this isn't done.
> >
> > I thought the pcap_register() bit was like additional filtering, after
> the
> > processing pcap does with its BPF filter.  I thought it was very useful
> when
> > things change, like the source port in the script, but only if (as I
> imagined)
> > it happens after pcap's filtering.
> >
> > In this regard, I wanted to put as much in the BPF filter as I could to
> reduce
> > the pcap_register() stuff, so if the filter doesn't really filter for the
> > script, I must ask: what's the point of having both?  Or better yet: what
> > advantages does the current way present?
>
> It's more complicated than you would think at first. Marek Majkowski
> explained to me a little while ago, but I don't think I understand it
> well enough to speak authoritatively. I'll copy him on this and maybe he
> can tell you more about it.
>
> David Fifield
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 25 Feb 2010 17:49:17 -0600
> From: Ron <ron () skullsecurity net>
> Subject: Re: [NSE] Minor feature enhancement for nbstat.nse
> To: "Thomas Buchanan" <TBuchanan () thecompassgrp net>
> Cc: nmap-dev () insecure org
> Message-ID: <20100225174917.cccadcd9.ron () skullsecurity net>
> Content-Type: text/plain; charset=US-ASCII
>
> Hey,
>
> That's really cool!
>
> A thought on the similar vain -- is it possible to set the MAC address in
> Nmap from a script? And if not, can it be added? The same way we set the
> version and state for ports, it'd be useful to set the remote MAC address so
> Nmap (and other scripts) can use it.
>
> Ron
>
> On Thu, 25 Feb 2010 12:09:28 -0600 "Thomas Buchanan"
> <TBuchanan () thecompassgrp net> wrote:
> > Hello,
> >
> > Here's a patch for nbstat.nse (and datafiles.lua) that adds the
> > ability to look up MAC address manufacturer information and display
> > it alongside the MAC address, similar to the way nmap does when
> > scanning IP addresses on a local network.  The patch add a capture
> > pattern and associated parse function for nmap-mac-prefixes to
> > nselib/datafiles.lua, and then utilizes that function in nbstat.nse
> > to lookup MAC address manufacturers.
> >
> > Here's an example of how the output has been changed:
> >
> > Without patch:
> > Host script results:
> > | nbstat:
> > |   NetBIOS name: LATITUDE, NetBIOS user: <unknown>, NetBIOS MAC:
> > 00:1f:3c:6a:38:45
> > <snip>
> >
> > With patch:
> > Host script results:
> > | nbstat:
> > |   NetBIOS name: LATITUDE, NetBIOS user: <unknown>, NetBIOS MAC:
> > 00:1f:3c:6a:38:45 (Intel Corporate)
> > <snip>
> >
> > Hopefully somebody else will find this useful, it's been a help to me
> > doing network inventory management.
> >
> > Comments and questions regarding the patch are appreciated.
> >
> > Thanks,
> >
> > Thomas
>
>
> --
> Ron Bowes
> http://www.skullsecurity.org
> http://www.twitter.com/iagox86
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 25 Feb 2010 18:07:12 -0600
> From: Ron <ron () skullsecurity net>
> Subject: Re: tracking the w32.download.X worm using zenmap
> To: "David Carter" <dcarter () fusd1 org>
> Cc: nmap-dev () insecure org
> Message-ID: <20100225180712.60181a5b.ron () skullsecurity net>
> Content-Type: text/plain; charset=US-ASCII
>
> Hi David,
>
> I don't know the answer to your question, unfortunately, but somebody on
> the nmap-dev mailing list might, so I'm including it in my response.
>
> Good luck!
>
> Ron
>
> On Thu, 25 Feb 2010 15:01:04 -0700 "David Carter" <dcarter () fusd1 org>
> wrote:
> > Hi,
> >
> > I have been fighting a w32.download.X worm since November and finally
> > found some relief when a tech person from Symantec gave me a link for
> > zenmap.  I did some reading and tried to use the utility but I am not
> > really sure how to use this as a tracking tool to hunt down this worm.
> > I have a THREATTRACER entry in the regrestry on some machines that are
> > taking hits from the worm(Symantec utility) but this is really not
> > telling me where the source is.  Our Symantec software is mostly
> > deleting the worm but It is extremely hard finding the source.  I love
> > the zenmap interface but I don't know much about nmap other then it's
> > a fantastic tool for Security Administrators. Can you give me a nmap
> > scrip I can use to assist in finding this worm?   Please email me
> > with some good news PLEASE..
> >
> >
> >
> > Thank You Kindley!
> >
> >
> >
> > David Carter
> >
> > FUSD Tech Services
> >
> > 928-527-9440
>
>
> --
> Ron Bowes
> http://www.skullsecurity.org
> http://www.twitter.com/iagox86
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 25 Feb 2010 17:28:52 -0700
> From: David Fifield <david () bamsoftware com>
> Subject: Re: [NSE] Minor feature enhancement for nbstat.nse
> To: Thomas Buchanan <TBuchanan () thecompassgrp net>
> Cc: nmap-dev () insecure org
> Message-ID: <20100226002852.GH700@gusto>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 25, 2010 at 12:09:28PM -0600, Thomas Buchanan wrote:
> > Hello,
> >
> > Here's a patch for nbstat.nse (and datafiles.lua) that adds the ability
> > to look up MAC address manufacturer information and display it alongside
> > the MAC address, similar to the way nmap does when scanning IP addresses
> > on a local network.  The patch add a capture pattern and associated
> > parse function for nmap-mac-prefixes to nselib/datafiles.lua, and then
> > utilizes that function in nbstat.nse to lookup MAC address
> > manufacturers.
> >
> > Here's an example of how the output has been changed:
> >
> > Without patch:
> > Host script results:
> > | nbstat:
> > |   NetBIOS name: LATITUDE, NetBIOS user: <unknown>, NetBIOS MAC:
> > 00:1f:3c:6a:38:45
> > <snip>
> >
> > With patch:
> > Host script results:
> > | nbstat:
> > |   NetBIOS name: LATITUDE, NetBIOS user: <unknown>, NetBIOS MAC:
> > 00:1f:3c:6a:38:45 (Intel Corporate)
> > <snip>
> >
> > Hopefully somebody else will find this useful, it's been a help to me
> > doing network inventory management.
>
> Thanks, Thomas! It's a good idea and I've committed it.
>
> David Fifield
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 25 Feb 2010 19:59:50 -0500
> From: kx <kxmail () gmail com>
> Subject: Re: Raw IP NSE Functionality
> To: Kris Katterjohn <katterjohn () gmail com>,     David Fifield
>        <david () bamsoftware com>
> Cc: nmap-dev () insecure org
> Message-ID:
>        <a374c5951002251659t4afaa25wd4b35d7444f1aec6 () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Oh no! That is my fault.
>
> I recommended math.randomseed(os.time()) to Kris because when I ran
> the ip-id script it was generating the same 6 source port/tcp sequence
> numbers each time I ran Nmap and I wanted to see different values.
>
> What would be a better way to seed that? Something like os.time() plus
> the IP plus the port or something?
>
> Or could nse call math.randomseed(os.time()) once before any scripts run?
>
> Wow, I really suck at this.
>
> Thanks,
>  kx
>
> On Thu, Feb 25, 2010 at 5:36 PM, Kris Katterjohn <katterjohn () gmail com>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/25/2010 04:03 PM, David Fifield wrote:
> > > I have this fixed in r16879. Man, you had me deep in the Nsock pcap code
> > > before I thought to look at this:
> > >
> > > --- scripts/ipidseq.nse (revision 16878)
> > > +++ scripts/ipidseq.nse (revision 16879)
> > > @@ -215,8 +215,6 @@
> > >
> > > ? ? ? ? pcap:set_timeout(3000)
> > >
> > > - ? ? ? math.randomseed(os.time())
> > > -
> > > ? ? ? ? local tcp = genericpkt(host, port)
> > >
> > > ? ? ? ? while i <= NUMPROBES do
> >
> > Well damn, that wasn't very climactic.. or was it? ;)
> >
> > Yesterday and today I managed to get some afternoon spurts of debugging
> in,
> > and while in the middle of it today, I smacked my forehead when I saw
> your
> > commit mail. ?I have piles of various debugging output statements, saved
> > outputs and some packet captures which I should just save for a good
> laugh
> > later :)
> >
> > Thanks, David!
> >
> > > os.time has a resolution of one second, so most of the time both scripts
> > > had the same random seed. The first random number they generated was the
> > > source port for the first probe, which would be the same in both
> > > scripts. Therefore both scripts registered the same pcap key and both
> > > saw the same one out of the two reply packets. The fe times when there
> > > was no collision, the two calls to math.randomseed must have fallen on
> > > either side of a second boundary.
> >
> > See, it always occurred for me. ?I was wondering why (and now how) it
> happened
> > without fail for me, but you saw otherwise.
> >
> > > The BPF filter alone won't prohibit one script from receiving another
> > > script's packets. As I understand it, that's the purpose of the extra
> > > pcap_register step. You could make the matching more robust by
> > > registering all the information that you currently have in the BPF,
> > > which is the source and destination hosts as well as the source port.
> >
> > I'm not understanding the purposefulness of this. ?Why is one script with
> a
> > filter for one host still getting packets from another host responding to
> a
> > different script? ?Matching source ports or not, I don't think it should
> > happen because of the different address *in the filter*. ?It's all raw
> packets
> > here, so I don't grasp why this isn't done.
> >
> > I thought the pcap_register() bit was like additional filtering, after
> the
> > processing pcap does with its BPF filter. ?I thought it was very useful
> when
> > things change, like the source port in the script, but only if (as I
> imagined)
> > it happens after pcap's filtering.
> >
> > In this regard, I wanted to put as much in the BPF filter as I could to
> reduce
> > the pcap_register() stuff, so if the filter doesn't really filter for the
> > script, I must ask: what's the point of having both? ?Or better yet: what
> > advantages does the current way present?
> >
> > > This all looks good an ready to merge, once you add documentation for
> > > the nmap.get_ports function to nmap.luadoc and scripting.xml.
> >
> > Great! ?I'll try to write it up and commit it tonight.
> >
> > > David Fifield
> >
> > Thanks,
> > Kris Katterjohn
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iQIcBAEBAgAGBQJLhvt7AAoJEEQxgFs5kUfuouYP/iwrqlMaGe//ZeglmX7ct2Kn
> > rrWV3CDCdyLLvkDsTtLIkvzgPkGVd4ok0MuFajGlkRntPMW5Oqy8UbRHcZ31PfRA
> > nnxTnQOie+N/AOVn62diRwxb7WW+UOHoUZwt4Japwjz7nC2uCwAzAaaua2qdFOHm
> > SuTJ60Kb0OLYkKHOuWEbQnElbm6Rn9MWUpGe7KBngPRAN32CA4lsbrEkVy4UWIvc
> > 8Ni3l3q2bs1Jt08enGDbFnMqQdGeHQ6bsquU8CvLFcT96YpmTnl74c6Nr30YeefO
> > 3sf43ucKglN7OLjK53WIyGRkM73V2n/jXz7QLSVfqPplpq98N33F0uhxXke0vaoh
> > Fc3qzPJUstPvuMCGiYFf0obaEOOdSyeRjJD/fO1nGPGAZKb+ekO+hiQxvRUw7jAQ
> > Cv0gtW/7gi2PBZrmPi/+cGgw5hCvjZ3dOcwImOJGEpFoBIlHewlOXZ7LlTbu2OrU
> > WDViTsNczf1mx6SFCRuaxkUPBmkaCrejH2HjvvyrtvtTY7XB9bUgK2YM5wDVn2oR
> > c172ho62JQxOn2t+hYqFQefmyCRxfVoV2hxnKW8G4Mn8f3VBFk24NMdffosNGdv8
> > 5qkZNp91ZvY84DcfI7rQblKE8YQy8YGzn0ij1/8KVNNCO4VNIaAJNSjEjfmUOi0W
> > MPeJwQfrXfbdb87UvWS2
> > =1J8T
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
>
>
> ------------------------------
>
> _______________________________________________
> nmap-dev mailing list
> nmap-dev () insecure org
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
>
>
> End of nmap-dev Digest, Vol 59, Issue 54
> ****************************************



-- 
Kirubakaran.S
" GET RICH OR DIE TRYING"
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/