verinfo module missing and moddump outputs 0KB files

[GoogleCodeExporter]

This is using Volatility framework 2.0.

What steps will reproduce the problem?
For verinfo: Try running verinfo on a module, will say nothing to do. Use the 
"-h" flag and see that this module is not in the list of usable modules. Yet 
despite this the module is listed as usable on the wiki at 
<http://code.google.com/p/volatility/wiki/CommandReference#verinfo>.

For moddump: Ran on a XP SP2 image "python vol.py --profile WinXPSP2x86 -f 
image.img moddump -D <destination_directory> -o <memory_offset> -u" and just 
receive 0KB files output.

What is the expected output? What do you see instead?
verinfo: instead of getting nothing to do error expect output as shown in wiki 
at <http://code.google.com/p/volatility/wiki/CommandReference#verinfo>.

moddump: instead of getting 0KB files expect modules dumped with actual content.

What version of the product are you using? On what operating system?

Volatility Framework 2.0 on Windows 7 SP1 with Python 2.7.3

Please provide any additional information below.

Original issue reported on code.google.com by johnmusb...@gmail.com on 13 May 2012 at 7:41

[GoogleCodeExporter]

The verinfo plugin is available in the contrib directory as it is not an 
officially maintained plugin.  If you want to make use of it, please add 
"--plugins=/path/to/contrib/directory".

As to the moddump issue, I've CCed in some of our other developers that may be 
able to help...

Original comment by mike.auty@gmail.com on 13 May 2012 at 8:00

[GoogleCodeExporter]

Thanks, got the verinfo plugin working now. Perhaps it should be noted in the 
wiki that it's in the contrib directory.

Original comment by johnmusb...@gmail.com on 13 May 2012 at 8:16

[GoogleCodeExporter]

Glad you got it working, the wiki was updated to reflect that 10 minutes ago.

Original comment by mike.auty@gmail.com on 13 May 2012 at 8:17

[GoogleCodeExporter]

Regarding moddump, if you specify -o <memory_offset> its only going to try and 
dump 1 module whose base address is memory_offset. If you leave off -o and just 
do: 

python vol.py --profile WinXPSP2x86 -f image.img moddump -D 
<destination_directory> 

Then it should try and dump all modules that are listed in the output of the 
'modules' command. So could you please: 

1) Test without -o and see if you get files 
2) If you're trying to dump a specific module according to its offset, make 
sure the 'modules' command reports that there is in fact a module at 
module_offset. 

Perhaps we're confusing offset with base address here. For example in the 
modules output:

Offset(V)  File                                               Base         Size 
    Name
0x84131c98 \SystemRoot\system32\ntkrnlpa.exe                  0x008280b000 
0x410000 ntoskrnl.exe

In that case, 0x84131c98 is the offset of the _LDR_DATA_TABLE_ENTRY for the 
module, but the module's base address is 0x008280b000 (where you find the PE 
header). So the value you pass to -o is the base address where you can find the 
PE header. 

Original comment by michael.hale@gmail.com on 13 May 2012 at 8:30

[GoogleCodeExporter]

Ohhh, thanks that was it! I was reading the details at 
http://moyix.blogspot.com/2008/10/plugin-post-moddump.html and the blog post 
says "-b" is base which I thought came from the modules command base column and 
"-o" offset which I figured came from the modules command offset column. Once I 
passed the value from the base column to "-o" it worked.

Original comment by johnmusb...@gmail.com on 13 May 2012 at 8:38

[GoogleCodeExporter]

Thanks for the quick help guys. :)

Original comment by johnmusb...@gmail.com on 13 May 2012 at 8:47

[GoogleCodeExporter]

@MHL, before marking this as fixed, do you think it would be worth changing the 
offset flag to a base flag to make this clearer, or are we happy that the help 
for -o says the base address?  It may confuse people for a little bit who are 
used to --offset, but as long as they get an error trying it in future, they 
should be ok, so I'm happy with either solution...

Original comment by mike.auty@gmail.com on 13 May 2012 at 9:20

[GoogleCodeExporter]

Yeah I just think the parameters are a little counter-intuitive as is.

Original comment by johnmusb...@gmail.com on 13 May 2012 at 9:29

[GoogleCodeExporter]

Hmm, yeah, I think it would be fine to change the parameter to --base instead 
of --offset. I know the dlldump command takes --base, but it also takes 
--offset (so you can specify the physical offset of the process in which the 
base address applies). 

Original comment by michael.hale@gmail.com on 13 May 2012 at 11:28

[GoogleCodeExporter]

I haven't looked at the code yet, should we go with both, or just with base?  
Also do you want to make the changes or should I?

Original comment by mike.auty@gmail.com on 14 May 2012 at 12:35

[GoogleCodeExporter]

I think we should just go with --base. Unlike dlldump, moddump doesn't need 
--offset.  If you don't mind making the change, go ahead, otherwise I can do it 
shortly. 

Original comment by michael.hale@gmail.com on 14 May 2012 at 8:33

[GoogleCodeExporter]

This issue was closed by revision r1698.

Original comment by mike.auty@gmail.com on 14 May 2012 at 8:43

• Changed state: Fixed