Re: POC Payloader dat

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

On Wed, Dec 30, 2009 at 6:20 PM, David Fifield <david () bamsoftware com> wrote:
> 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.

multiple destination ports for the same payload.
>

> 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

yes - I was just reiterating tha :).

> 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.

That works!
> I think it's reasonable to load them into memory in advance. I mean,
> they're in memory now, being part of the executable.

Excellent - well looks like were good to go ... again :)

thanks David,

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