Re: POC Payloader dat

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

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

It would appear they class payloads - I am still working on
unravelling the groups but I did discover by tracing back through the
code that unicornscan does have multiple payloads for the same service
- it essentially cycles through each one until it gets a hit.

So - basically - I am still investigating but what I see so far is
that unicornscan:

- can share payloads/service but not ports (how ironic is that?); they
get around the ports problem in a similar way to nmap
- at some point iterates and loads up needed payloads - I think this
is at the beginning of every send packet; not sure yet
- has an option *not* to use default payloads
- has some builtin (as in the source code not a file) payloads (I am
assuming these are defaults) and some stored in a conf file
- uses a module framework for handling payloads
- uses a key do identify the payload (similar to what we want to do)

I think we can definitely do the following:
- use a keyword to share payloads
- have multiple ports per service (already planning on it)

I can start prototyping that now.

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?
- when should we load payloads? I am thinking as soon as we know what
ports we are scanning load em up into a table then (using a similar
method to how we get them now)  call them when needed... performance?
:)
- should we have an option not to use payloads and/or to have some
"safe defaults"? I think this is a good idea since later on we can
start adding more payloads; some of which I am sure  will be a little
*sketchy*.

*pant*pant*pant*

at least I'll be busy for the next few(weeks||months) :D

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