Nmap Development mailing list archives
Re: POC Payloader dat
From: Jay Fink <jay.fink () gmail com>
Date: Mon, 30 Nov 2009 12:05:07 -0500
Just for a chance to glance over how unicorn scan does it - I definitely like the conf file format and I like the payload module structure - it is pretty slick. I think I will use unicorn's method as a jump off point. On Wed, Nov 25, 2009 at 5:55 PM, David Fifield <david () bamsoftware com> wrote:
On Mon, Nov 23, 2009 at 12:04:57PM -0500, Jay Fink wrote:Attached is a very minimalist parser to change keeping payload data in the payload.cc file. In this example (which is not in the nmap tree) I am using a very simple parameter retrieve ; in the example were just getting and printing the DNS Request payload - but I think I can implement this in nmap - just wanted to get some thoughts on it. Eventually the way it would work is the case in payload.cc now would simply read in the value from payload.dat (or db et cetera). It needs work like better dynamic allocation etc. but this is a POC idea right now.Thank you for starting work on this. Having the payloads in a separate data file is indeed a goal. Not only would it make it possible to add payloads without recompiling, but it would allow people to easily disable payloads they don't like. There are some things to be considered for the data file format. The contents of the data file you sent are DNS_STATUS_REQUEST "\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00" There is more information that should be stored in the data file. In this case, Nmap still has to know that DNS_STATUS_REQUEST corresponds to port 53/udp, and to change it would require recompiling. We can learn from Unicornscan's payloads.conf. I think they have a good format. An example entry looks like this: /* citrix */ udp 1604 -1 1 { "\x20\x00\x01\x30\x02\xfd\xa8\xe3\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" }; The five fields are protocol (udp or tcp), destination port, source port, payload group, and { payload }. -1 for the source port means any port can be used. I don't know what the payload group means. This is a good format. Its biggest deficiency is that you have to copy and paste if you want the same payload on different ports. We already have one case of that in payload.cc. It is expressed very nicely in C++: /* RFC 2865: "The early deployment of RADIUS was done using UDP port number 1645, which conflicts with the "datametrics" service. The officially assigned port number for RADIUS is 1812. */ case 1645: case 1812: SET_PAYLOAD(payload_radius); break; The symbolic names (payload_DNSStatusRequest, payload_radius) are an implementation detail and there's no reason to keep them in an external data file. Here is a list of desiderata for the ideal payload definition file format. * Uses the C string syntax like payloads.cc or nmap-service-probes. * Allows comments at least as expressive as what are in payload.cc. (This includes comments between the bytes of a payload.) * Lets several ports share the same payload without redundancy. * Allows indicating if a payload should come from a specific source port. For example, our payload_ike works better coming from 500. And here are some bonus items that would make it even better. * Allows variable payloads through simple substitutions (for example an IP address or 8 bytes of random data). Our payload_ike uses a constant initiator cookie, but in my testing this causes targets not to respond to any probes after the first. It would be great if we could fill the first 8 bytes with random data instead. I wouldn't be totally happy with a format that made this impossible. * Allows indicating if the response will come from a port other than the one the probe was sent to. A TFTP server sends its responses from a random ephemeral port, not the tftp port. If you use Unicornscan's TFTP payload and do a -p1-65535 scan of a TFTP server, you get the tftp port open|filtered but a random high port open, which is not what you want. This is a tricky problem and hasn't been fully specified. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- POC Payloader dat Jay Fink (Nov 23)
- Re: POC Payloader dat Jay Fink (Nov 24)
- Re: POC Payloader dat David Fifield (Nov 25)
- Re: POC Payloader dat Jay Fink (Nov 25)
- Re: POC Payloader dat Jay Fink (Nov 30)
- Re: POC Payloader dat Jay Fink (Dec 04)
- 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)