Re: wdbrpc_memory_dump.rb bug and question

[Robin Wood <robin () digininja org>]

On 25 January 2012 20:53, Joshua J. Drake <jdrake () metasploit com> wrote:
> Robin,
>
> Setting the "OFFSET" variable indictates that you wish to resume a
> partial dump. This feature is intended to be used along with an
> existing dump that did not complete.
>
> The initial portion of the dump should remain undisturbed while the
> new parts will be written starting at the supplied offset. Currently,
> starting at a specific offset and writing to a new file is not
> supported. This is due to some strangeness with ruby's handling of
> various file options...
>
> For now, if you absolutely must preserve the old partial dump, copy
> vxworks_memory2.dump to vxworks_memory3.dump and then retry.
>
> If you haven't created a ticket yet, it may not be necessary. I
> modified the module to fall-back to writing a new file in case it
> fails to open..


The only reason I moved the original file away was in case it
overwrote the existing file when I restarted the download, I didn't
want to lose the 30% already downloaded. Now I know the intended
functionality it makes perfect sense and the fix you've put in should
be fine. I've finished the job I was on where I could test this so
I'll trust you that it works find and hopefully have chance to test it
some time in the future.

Robin


> You can see the pull request / commit here:
> https://github.com/rapid7/metasploit-framework/pull/130
>
> PS. Please Include the datastore (via info or set commands) in your bug
> reports to help streamline the troubleshooting process in the future.
>
>
> On Wed, Jan 25, 2012 at 03:54:59PM +0000, Robin Wood wrote:
> > I've just reproduced this showing the directory exists but the file
> > doesn't, this is only when the offset is set to non-zero, if I set it
> > to 0 then it runs fine. I'll put a ticket in for it.
>
> --
> Joshua J. Drake
_______________________________________________
https://mail.metasploit.com/mailman/listinfo/framework