Nmap Development mailing list archives
Re: POC Payloader dat
From: David Fifield <david () bamsoftware com>
Date: Wed, 30 Dec 2009 16:20:15 -0700
On Wed, Dec 30, 2009 at 09:48:52AM -0500, Jay Fink wrote:
I'm a bit lost in thinking about how all this should work. How do Unicornscan's payload groups work?It would appear they class payloads - I am still working on unravelling the groups but I did discover by tracing back through the code that unicornscan does have multiple payloads for the same service - it essentially cycles through each one until it gets a hit. So - basically - I am still investigating but what I see so far is that unicornscan: - can share payloads/service but not ports (how ironic is that?); they get around the ports problem in a similar way to nmap
I don't know what you mean. What is the ports problem? I also don't understand the distinction between "service" and "port" here. We're not concerned at all with "service" in terms of -sV at this point in the scan.
- at some point iterates and loads up needed payloads - I think this is at the beginning of every send packet; not sure yet - has an option *not* to use default payloads - has some builtin (as in the source code not a file) payloads (I am assuming these are defaults) and some stored in a conf file
I didn't know there were builtin ones. We already went through payloads.conf and used or modified the ones that 1) we could show to be safe, and 2) were for common ports (top 1,000 I believe). There might be some worth investigating among the builtin ones.
- uses a module framework for handling payloads - uses a key do identify the payload (similar to what we want to do)
Having a name for each payload is fine, as it's a reasonable way to distinguish multiple payloads for the same port. But don't stress out about that too much. The internal API doesn't even have to be aware of it as we would have no way to use it yet.
I think we can definitely do the following: - use a keyword to share payloads - have multiple ports per service (already planning on it)
I don't understand what you mean by "share payloads." Isn't that what we're already doing with the "1645,1812" in radius udp 1645,1812 "\x01\x00\x00\x14" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
The questions I have now are: - is there a chicken and egg problem? We know for instance if a host does not reply to the pre-ping we just move on but what if the scan is a full tcp-connect/port? Do we still iterate through every payload or shut it off in that case or shut it off by default but allow user override?
If I undertand you correctly, you want to know, if there are mutiple payloads for a port, whether all of them should be tried or just the first one. Let's forget that complexity for now. I'm fine with the data format being extensible to allow multiple payloads per port but at the moment we don't need it and don't even know how it should work. At this stage I don't want any changes to the scanning engine. Let's keep it simple--all we need is a new implementation of get_udp_payload that reads from an external data file.
- when should we load payloads? I am thinking as soon as we know what ports we are scanning load em up into a table then (using a similar method to how we get them now) call them when needed... performance? :)
I think it's reasonable to load them into memory in advance. I mean, they're in memory now, being part of the executable.
- should we have an option not to use payloads and/or to have some "safe defaults"? I think this is a good idea since later on we can start adding more payloads; some of which I am sure will be a little *sketchy*.
You can already turn off payloads with --data-length 0. (Or any --data-length.) I don't want any sketchy payloads being sent during a ping or port scan; that's for version detection and NSE. There's a comment at the top of payload.cc with the safety criteria for UDP payloads. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: POC Payloader dat, (continued)
- Re: POC Payloader dat Jay Fink (Dec 09)
- Re: POC Payloader dat David Fifield (Dec 13)
- Re: POC Payloader dat Jay Fink (Dec 14)
- Re: POC Payloader dat Jay Fink (Dec 19)
- Re: POC Payloader dat David Fifield (Dec 21)
- Re: POC Payloader dat Jay Fink (Dec 22)
- Re: POC Payloader dat Jay Fink (Dec 26)
- Re: POC Payloader dat David Fifield (Dec 27)
- Re: POC Payloader dat Jay Fink (Dec 28)
- Re: POC Payloader dat Jay Fink (Dec 30)
- Re: POC Payloader dat David Fifield (Dec 30)
- Re: POC Payloader dat Jay Fink (Dec 30)