Re: Ncrack --resume option

[Michael Pattrick <mpattrick () rhinovirus org>]

Hey ithilgore,

Sorry for not reading the source code prior to sending this message,
but why can’t you just store your current position in the
username/password list? Do you try them out randomly?

-M

On 7/31/09, ithilgore <ithilgore.ryu.l () gmail com> wrote:
> Hello nmap-dev.
>
> One of the options that Ncrack will eventually support is --resume, which
> will
> enable the user to temporarily stop a cracking session (usually by Ctrl+C)
> and
> later continue from where it left by calling Ncrack with --resume. However
> there
> are some points to consider here:
>
> Nmap supports the same option by saving some state information in the output
> files just before closing after catching the terminating signal (whatever
> that
> may be). The state information used is:
> a) Nmap's invocation arguments
> b) How many hosts have been *completed* up until that time
>
> What this essentially means, is that if a host was partially scanned at the
> time
> Nmap was closed, then that host will have to be rescanned from the
> beginning.
>
> Now, supporting the same thing in Ncrack is fairly easy, since parsing that
> information from the log files isn't much work. However, Ncrack is of
> different
> nature and a better approach would be to able to continue from almost the
> exact
> moment that Ncrack was stopped. This means that if a host had half the
> username/password list completed at the time Ncrack is closed, then Ncrack
> will
> continue from cracking the rest of the half username/password list when
> restarted with the --resume option.
> This provides maximum flexibility in our scans, however the implementation
> now
> gets a lot more complex. To be able to attain that level of state retrieval,
> Ncrack will have to dump nearly all current information into a separate
> special
> file (which can be binary or text) and then reparse it when it is resumed.
> Since, most of that information is inside Ncrack's different Classes and
> that
> involves a lot of dynamic memory (in addition to STL lists and vectors) it
> would
> require an Object Serialization scheme.
> There are a couple of resources on the net about how this is implemented,
> and it
> is usually done by writing the memory length inside a fixed-size value that
> is
> parsed before a dynamic object is retrieved. By that way, the parser knows
> how
> many bytes to allocate to the next variable-length object.
>
> Anyway, I would like your opinions on this matter. I think the 2nd more
> flexible
> approach is worth the trouble, yet it is fairly challenging. What do you
> think?
>
> Cheers,
> ithilgore

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