Re: POC Payloader dat

[Jay Fink <jay.fink () gmail com>]

On Sun, Dec 13, 2009 at 5:32 PM, David Fifield <david () bamsoftware com> wrote:
> 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.

That certainly looks a great deal easier and is more consistent with
what other nmap code does.

> 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);

*ditto* - less system shock too :-)

> I can imagine changing the return value to non-const for the case of
> dynamic payloads, or perhaps requiring a caller-supplied buffer.
>
> 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.

The services probe has some good bits in it I think.

Thanks for the pointers!
  j
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/