Re: POC Payloader dat

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

Just a quick update, the way I am working on this is to write the
function(s) separately and just call them - once I *think* it is in a
decent state I'll plug it in (probably inside the payload.cc file
itself).
That said I have managed to get as far as getting on complete string
back from the file parser so far although admittedly I've only worked
on it about 2 or 3 solid hours or so over the last 2 weeks, the
prototype accepts the payload key word and returns the payload:

$ ./payload dns
\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00
Note this is one contiguous string, webmail chops it:
$ ./payload nbstat
\x80\xF0\x00\x10\x00\x01\x00\x00\x00\x00\x00\x00\x20CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x00\x00\x21\x00\x01
$ ./payload amanda
Amanda 2.6 REQ HANDLE 000-00000000 SEQ 0\nSERVICE noop\n

It also handles inline comments gracefully.

What I have left is:
- the key matching uses strstr, it shouldn't do that for obvious
reasons :) needs changed
- assigning dports
- assigning sports
- making sure memory is dealt with gracefully/correctly

Once those 4 nits are taken care of I will start (trying to) plugging
it into nmap.

thx,
 j

On Wed, Dec 30, 2009 at 8:50 PM, Jay Fink <jay.fink () gmail com> wrote:
> 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/