Re: POC Payloader dat

[David Fifield <david () bamsoftware com>]

On Sat, Dec 26, 2009 at 11:16:00AM -0500, Jay Fink wrote:
> On Tue, Dec 22, 2009 at 7:38 PM, Jay Fink <jay.fink () gmail com> wrote:
>
> > > I'm happy with this format if you want to get started.
> >
> > Excellent. I'll probably start fiddling with it this weekend.
>
> Ive been working on a prototype for this and so far so good, this
> morning however it occured to me that using this format we can have
> multiple ports per payload entry but we cannot have multple payloads
> per port entry. This will cause a parsing problem as I am matching on
> 'proto port'; then (for now) printing everything quoted except lines
> with \# and stopping when I hit the next 'proto' line. I noticed when
> I am looking for radius or citrix I print out 2 sets; I think we still
> need a keyword field to differentiate them. So for example:
>
>
> # Citrix Service Payload
> citrix 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"
>
> # Radius Service Payload
> radius udp 1645,1812 "\x01\x00\x00\x14"
>   "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
>
> I'm also thinking in the long run the ID field could be used for
> different versions of a service as well like bind8 vs. bind9 etc.

I can see your point about the value of having an identifer for payloads
that you otherwise have the same port/protocol combination. However, in
this case, it's not needed, because the citrix payload doesn't go with
ports 1645 or 1812. We may have used that as an example but that's not
the way it is in payload.cc now.

If we're having multiple payloads per port then there are other
questions that need to be answered. Like, how does a port scan work?
Does it send each payload with transmissions until it gets a response?
Does it send the first payload, then send the second if the first one
gets no response? In that case you have to weigh the likelihood that the
packet was dropped versus the likelihood that another payload would work
better; presumably we'd always send the best payloads first.

I'm a bit lost in thinking about how all this should work. How do
Unicornscan's payload groups work?

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