printkey issues-- keys not found

[GoogleCodeExporter]

What steps will reproduce the problem?
1. >python vol.py --profile=WinXPSP2x86 -f memory\silentbanker.vme
m printkey -K 'Microsoft\Windows\CurrentVersion\Explorer\Browser Helper 
Objects' 

What is the expected output? What do you see instead?
When I performed a hivedump it shows the following entry under BHO:

Microsoft\Windows\CurrentVersion\Explorer\Browser Helper 
Objects\{00009E9F-DDD7-AA59-AA7D-AA4B7D6BE000}

However when I try printkey I get:
The requested key could not be found in the hive(s) searched

What version of the product are you using? On what operating system?
Volatility 2.0, winXPSP3

Please provide any additional information below.

Original issue reported on code.google.com by missy.au...@gmail.com on 6 Nov 2011 at 6:58

[GoogleCodeExporter]

Thanks for reporting the issue. If there are spaces in the key name (like 
"Browser Helper Objects") then on Linux or OSX you can enclose the key in 
single quotes or double quotes. However, if there are spaces in the key name 
and you're using Windows, you must use double quotes and not single quotes. 

Using single quotes on Windows for keys with spaces in the name will show up 
"requested key could not be found..."

So just use double quotes like this, until we get a patch applied:

python vol.py --profile=WinXPSP2x86 -f memory\silentbanker.vme
m printkey -K "Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects"

Original comment by michael.hale@gmail.com on 7 Nov 2011 at 3:02

[GoogleCodeExporter]

Here's a bit more about this issue. It seems to be caused by an inconsistency 
in how Python's optparse module (http://docs.python.org/library/optparse.html) 
handles single vs double quoted strings on various operating systems. Also note 
that optparse is deprecated since Python 2.7 and that argparse is the new 
preferred module. 

A script to test what we're dealing with (a string option whose value is passed 
to split("\\") in the printkey.py plugin:

from optparse import OptionParser
parser = OptionParser()
parser.add_option("-s", "--string", action="store", dest="s", type="string", 
help="Desired Profile")
(opts, args) = parser.parse_args()
print opts.s.split("\\")

Here's the output of this script when run on an OSX machine:

$ python quote_test.py -s Microsoft
['Microsoft']
$ python quote_test.py -s "Microsoft"
['Microsoft']
$ python quote_test.py -s 'Microsoft'
['Microsoft']

Note the output is always enclosed in single quotes. Now do the same thing on 
Windows:

C:\Users\Jake\Desktop>python quote_test.py -s Microsoft
['Microsoft']
C:\Users\Jake\Desktop>python quote_test.py -s "Microsoft"
['Microsoft']
C:\Users\Jake\Desktop>python quote_test.py -s 'Microsoft'
["'Microsoft'"]

In this case, using single quotes on command line causes the output to be 
enclosed in both single quotes and double quotes: and "'Microsoft'" isn't a 
valid key name so the lookup fails. 

I haven't tested the argparse module to see if it handles this any different. 

Original comment by michael.hale@gmail.com on 13 Nov 2011 at 7:15

[GoogleCodeExporter]

Hey guys, thoughts on this? Is it something we even want to try and fix or just 
make sure our documentation states clearly that on Windows you must use no 
quotes or double quotes but *not* single quotes?  

Original comment by michael.hale@gmail.com on 17 Nov 2011 at 3:08

[GoogleCodeExporter]

This is not a bug. The convention on windows is that single quotes do not mean 
anything special - its only double quotes that do. This is why 'Microsoft' 
includes the single quotes in the name. Note that this is only really a problem 
on windows where command line parsing is left to the application (cmd.exe does 
not do any parsing). But this is actually handled deep within python itself and 
I doubt we can do anything about it.

On linux parsing is handled by the shell.

Original comment by scude...@gmail.com on 17 Nov 2011 at 5:17

[GoogleCodeExporter]

cool, then we can close this and update the documentation.  I'll update it 
later if no one else wants to...  Agreed?

Original comment by jamie.l...@gmail.com on 17 Nov 2011 at 5:23

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 17 Nov 2011 at 10:02

• Changed state: WontFix