OptionConflictError and AttributeError in verinfo

[GoogleCodeExporter]

Hey guys, 

In contrib/plugins/verinfo.py there is a small bug:

config.remove_option("PIDS") <== should be PID

Otherwise, you get the error:

$ python volatility.py verinfo -f rustock.vmem -h
Volatile Systems Volatility Framework 1.4_rc1
Traceback (most recent call last):
  File "volatility.py", line 126, in <module>
    main()
  File "volatility.py", line 111, in main
    command = MemoryRegistry.PLUGIN_COMMANDS[module](config)
  File "/Users/Mike/Desktop/Volatility-1.4_rc1/volatility/plugins/verinfo.py", line 309, in __init__
    help = 'dump modules matching REGEX')
  File "/Users/Mike/Desktop/Volatility-1.4_rc1/volatility/conf.py", line 364, in add_option
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1006, in add_option
    self._check_conflict(option)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 981, in _check_conflict
    option)
optparse.OptionConflictError: option -p/--pattern: conflicting option 
string(s): -p

With regards to the paths in the error message, I copied verinfo.py to 
volatility/plugins just FYI. 

Original issue reported on code.google.com by michael.hale@gmail.com on 14 Dec 2010 at 4:05

[GoogleCodeExporter]

There is also an instance of ModuleName in verinfo.py which should be 
BaseDllName or it causes an AttributeError.

Original comment by michael.hale@gmail.com on 14 Dec 2010 at 4:15

• Changed title: OptionConflictError and AttributeError in verinfo

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hmm this one, I am unfortunately not sure how to fix...

$ python volatility.py verinfo -f rustock.vmem -p kernel32
Volatile Systems Volatility Framework 1.4_rc1
C:\WINDOWS\system32\kernel32.dll

Traceback (most recent call last):
  File "volatility.py", line 126, in <module>
    main()
  File "volatility.py", line 117, in main
    command.execute()
  File "/Users/mike/Desktop/Volatility-1.4_rc1/volatility/commands.py", line 101, in execute

  File "/Users/mike/Desktop/Volatility-1.4_rc1/volatility/plugins/verinfo.py", line 387, in render_text
    vinfo = self.get_version_info(s, m.DllBase)
  File "/Users/mike/Desktop/Volatility-1.4_rc1/volatility/plugins/verinfo.py", line 371, in get_version_info
    for rname, rentry, rdata in root.get_entries():
  File "/Users/mike/Desktop/Volatility-1.4_rc1/volatility/obj.py", line 301, in __getattr__
    raise AttributeError("Unable to resolve attribute {0} on {1}".format(attr, self.obj_name))
AttributeError: Unable to resolve attribute get_entries on 
_IMAGE_RESOURCE_DIRECTORY

Original comment by michael.hale@gmail.com on 14 Dec 2010 at 4:19

[GoogleCodeExporter]

This issue was closed by revision r564.

Original comment by mike.auty@gmail.com on 14 Dec 2010 at 6:48

• Changed state: Fixed

[GoogleCodeExporter]

Hiya Michael!

Thanks very much for the fixes.  I haven't really paid verinfo too much 
attention, but your fixes do the bulk of making it work again, so thanks!  5:)

The last error that you weren't sure about was caused because in the past, 
simply defining a class with the same name as vtype would mean that the class 
would get instantiated.  Several months back, we changed it so that only 
classes had to register with their profile (allowing different classes to 
override structs for different profiles, which is good).  Adding the classes 
into the profile's object_classes before calling add_types, ensures that the 
new type definitions pick up the objects rather than standard CTypes when 
they're created.  Note: if they're added afterwards, then the structs'll 
already have been added to profile.types as normal CTypes, so it won't work.

The only other caviat was that for some reason an object was trying to build a 
BufferAddressSpace using self._config as the config, rather than 
self.obj_vm._config (or, in fact, self.obj_vm.get_config(), since _config is 
private to the obj_vm).

Thanks again for reporting those!  5:)

Original comment by mike.auty@gmail.com on 14 Dec 2010 at 6:55

[GoogleCodeExporter]

Awesome, I'll get a look at the changes you make for the CTypes and see exactly 
how its done. I was using your verinfo as a template for parsing PE 
headers...so I can enumerate imports and exports without the use of pefile 
(thus removing a dependency library for my malware plugins). 

Thanks!

Original comment by michael.hale@gmail.com on 14 Dec 2010 at 7:20