vijaykumarmit55 / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

Output file configuration automatically creates a file and overwites pre-existing ones. #409

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Define the --output-file parameter to vol.py and point to a pre existing 
file.
2. Run the tool.
3. Look at the output and witness the destruction of the previous file.

What is the expected output? What do you see instead?

It would be expected to either append to the file, not open a filehandle or at 
least warn before overwriting the file.

What version of the product are you using? On what operating system?
In this particular case it does not matter, but the latest trunk on Ubuntu 
Precise.

URL: http://volatility.googlecode.com/svn/trunk
Repository Root: http://volatility.googlecode.com/svn
Repository UUID: 8d5d6628-2090-11de-9909-f37ff7dbbc12
Revision: 3386

Please provide any additional information below.

See the code here:
https://code.google.com/p/volatility/source/browse/trunk/volatility/commands.py#
93

Copied for your convenience: 
        if self._config.OUTPUT_FILE:
            outfd = open(self._config.OUTPUT_FILE, 'w')
            # TODO: We should probably check that this won't blat over an existing file 
        else:
            outfd = sys.stdout

For now I'm just creating the issue, will submit a patch.

The question really is, what should the expected behavior be? Depending on the 
render_XXX functions they are either simple text based functions that can use 
the outfd object straight up and it would not cause any issue to change the 
open operation to an append mode.

In other render_ functions they may be doing something completely different, 
for instance if I would like to write a SQLite output renderer or the XLSX 
rendered which is an already existing example. These rendered cannot work 
directly on the filehandle outfd, and need to either close it before doing 
anything or in the case of XLSX just ignore it. This may or may not be an 
issue, but I'm trying to modify the timeliner plugin to use plaso output, and 
in that case I'm trying to append to a ZIP container, which the plaso libraries 
do pretty well, however volatility overwrites the storage file before I can 
pass it on.

Another option would be to check the render_XXX function to see if it likes a 
copy of the outfd? Or have some sort of option to define whether or not you 
want a copy to be opened? Or just blindly open the file with append flag?

Original issue reported on code.google.com by ki...@kiddaland.net on 17 Apr 2013 at 8:56

GoogleCodeExporter commented 9 years ago
Hi Kristinn,

I know there are a few other plugins that haven't yet been released that rely 
on this behavior.  What they do to get around clobbering a file is to add an 
option for a separate log file or sqlite db that is handled differently.  There 
is also some troubleshooting text that comes out using outfd so you can log it 
separately.  

I can see how it can be confusing and there are probably arguments for or 
against this method.  I also know it has been discussed sometime in the past 
that the whole rendering mechanism will probably be modified sometime in the 
future.  

Perhaps in the meantime you should add an option for a sqlite file and handle 
it as you see fit, while ignoring outfd or using that to display a status of 
what is being written to the sqlite file or whatever.

I'll leave this open so others can comment as they see fit.  I just didn't want 
you to think we didn't notice your bug report :-)

Original comment by jamie.l...@gmail.com on 19 Apr 2013 at 11:15

GoogleCodeExporter commented 9 years ago
Hi, so your preferred method of solving this is to register a new parameter for 
the plugin that is then only used by this specific render_ function? And not 
rely on the --output-file?

I'm fine with that, if you prefer that over patching the current behavior.

Original comment by ki...@kiddaland.net on 20 Apr 2013 at 3:47

GoogleCodeExporter commented 9 years ago
closing this issue for now, but it can be reopened if someone has a difference 
of opinion. 

Original comment by jamie.l...@gmail.com on 7 Mar 2014 at 4:50