Re: POC Payloader dat

[David Fifield <david () bamsoftware com>]

On Wed, Dec 09, 2009 at 08:01:03AM -0500, Jay Fink wrote:
> So I don't like the label, I am going to push that back to the loader
> (somehow :) - so the new format would be more like unicornscan but
> less the payload group:
> /* PROTOCOL  USABLE_DESTINATION_PORTS_LIST  SOURCE_PORT PAYLOAD */
> /* radius */
> udp 1604,1645,1812  -1 {
> "\x1e\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";
> };

That looks pretty good, but if we're not going to be 100% compatible
with Unicornscan's file, then there's no need for ours to look like
theirs. The braces and semicolon can be removed. I'm thinking about a
format more like we have in nmap-service-probes, with named fields
instead of positional values.

/* comment */
payload udp 1604,1645,1812
"\x1e\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"
source 100

The "source 100" above is just an example of how a source port might be
specified, even though it's not used for this particular payload. I
would rather have payloads that use a source port say so explicitly than
have most of them with a dummy -1 value.

I don't think we need a label for each payload beyond the comments.

I want the interface for accessing a payload to stay pretty much the
same. This is what we have now:

const char *get_udp_payload(u16 dport, size_t *length);

I can imagine changing the return value to non-const for the case of
dynamic payloads, or perhaps requiring a caller-supplied buffer.

> What with holidays, new gig and all haven't had much time to look at
> this but unicornscan uses a mix of lex and c to parse these out - not
> very striaghtforward to me - so I might look at how nmap loads
> services etc. for guidance instead.

Parsing is certainly a non-trivial part of this problem. There are
custom parsers for all of Nmap's data files. The main thing is to watch
out for buffer overflows and such.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/