Re: Ncrack --resume option

[joewoe () fsmail de]

* ithilgore <ithilgore.ryu.l () gmail com> [090731 16:35]:
> Hello nmap-dev.
Hi!

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

Just an not so elegant idea:
Dump the whole process into an executable and start that on --resume:

% apt-cache show cryopid | grep -A 23 Descri
Description: Dumps a process into a self-executing file
  CryoPID allows you to capture the state of a running process in
  Linux and save it to a file. This file can then be used to resume the
  process later on, either after a reboot or even on another machine of the
  same architecture.
  .
  http://cryopid.berlios.de

%

Alas, this program tends to segfault on some (complicated?) processes,
but it might give some ideas.
And for now it is linux-only.

Greetings, J"o!

-- 
Whenever you find that you are on the side of the majority, it is time
to reform.
                -- Mark Twain

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