Nmap Development mailing list archives
Re: POC Payloader dat
From: Jay Fink <jay.fink () gmail com>
Date: Wed, 30 Dec 2009 09:48:52 -0500
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/
Current thread:
- Re: POC Payloader dat, (continued)
- Re: POC Payloader dat Jay Fink (Dec 04)
- Re: POC Payloader dat Jay Fink (Dec 09)
- Re: POC Payloader dat David Fifield (Dec 13)
- Re: POC Payloader dat Jay Fink (Dec 14)
- Re: POC Payloader dat Jay Fink (Dec 19)
- Re: POC Payloader dat David Fifield (Dec 21)
- Re: POC Payloader dat Jay Fink (Dec 22)
- Re: POC Payloader dat Jay Fink (Dec 26)
- Re: POC Payloader dat David Fifield (Dec 27)
- Re: POC Payloader dat Jay Fink (Dec 28)
- Re: POC Payloader dat Jay Fink (Dec 30)
- Re: POC Payloader dat David Fifield (Dec 30)
- Re: POC Payloader dat Jay Fink (Dec 30)
- Re: POC Payloader dat Jay Fink (Dec 04)