Leor3961 / volatility

Automatically exported from code.google.com/p/volatility
0 stars 0 forks source link

rawreg.py error: unpack requires a string argument of length 4 #55

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
When running the printkey plugin on Moyix' ds_fuzz image I get the following 
error:

$ ./volatility.py -f ds_fuzz_hidden_proc.img --no-cache --profile=WinXPSP3x86 
printkey -o 0xE1482008 -K 'SAM\Domains\Account\Users'

Volatile Systems Volatility Framework 1.4_rc1
Key name: Users
(Stable)
Last updated: 2008-09-19 20:29:49 

Subkeys:
  000001F4(Stable)
  000001F5(Stable)
  000003E8(Stable)
  000003EA(Stable)
  000003EB(Stable)
  Names(Stable)

Values:
Traceback (most recent call last):
  File "./volatility.py", line 126, in <module>
    main()
  File "./volatility.py", line 117, in main
    command.execute()
  File "/TESTING/vol_1.4/volatility/commands.py", line 101, in execute
    func(outfd, data)
  File "/TESTING/vol_1.4/volatility/plugins/registry/printkey.py", line 105, in render_text
    tp, dat = rawreg.value_data(v)
  File "/TESTING/vol_1.4/volatility/win32/rawreg.py", line 156, in value_data
    valdata = struct.unpack(">L", valdata)[0]
struct.error: unpack requires a string argument of length 4

For Volatility 1.3 I get:

$ ./volatility printkey -f ds_fuzz_hidden_proc.img  -o 0xE1482008   
'SAM\Domains\Account\Users'

Key name: Users (Stable)
Last updated: Fri Sep 19 16:29:49 2008

Subkeys:
   000001F4 (Stable)
   000001F5 (Stable)
   000003E8 (Stable)
   000003EA (Stable)
   000003EB (Stable)
   Names (Stable)

Values:
REG_DWORD_BIG_ENDIAN            : 0 (Stable)

The difference is there are default values that are used in 1.3 that are not 
used in 1.4:

_DEFAULTS = { 
    "REG_NONE": "", 
    "REG_SZ": "", 
    "REG_EXPAND_SZ": "", 
    "REG_BINARY": "", 
    "REG_DWORD": 0,
    "REG_DWORD_BIG_ENDIAN": 0,
    "REG_LINK": "", 
    "REG_MULTI_SZ": [], 
    "REG_RESOURCE_LIST": "", 
    "REG_FULL_RESOURCE_DESCRIPTOR": "", 
    "REG_RESOURCE_REQUIREMENTS_LIST": "", 
    "REG_QWORD": 0,
}

And they are handled like so (example for REG_DWORD_BIG_ENDIAN):

     elif valtype == "REG_DWORD_BIG_ENDIAN":
        if len(valdata) != 4:
            default = _DEFAULTS.get(valtype, "")
            return (valtype,default)

If I patch rawreg.py to work like 1.3 it seems ok:

$ ./volatility.py -f ds_fuzz_hidden_proc.img --no-cache --profile=WinXPSP3x86 
printkey -o 0xE1482008 -K 'SAM\Domains\Account\Users'

Volatile Systems Volatility Framework 1.4_rc1
Key name: Users
(Stable)
Last updated: 2008-09-19 20:29:49 

Subkeys:
  000001F4(Stable)
  000001F5(Stable)
  000003E8(Stable)
  000003EA(Stable)
  000003EB(Stable)
  Names(Stable)

Values:
REG_DWORD_BIG_ENDIAN            : 0 (Stable)

Original issue reported on code.google.com by jamie.l...@gmail.com on 4 Jan 2011 at 6:29

GoogleCodeExporter commented 8 years ago
Ok, I can patch that up before the end of the week.  I'm a little concerned 
that it's just masking a misread of the data, but a graceful failure's better 
than a catastrophic one...  5:)

Original comment by mike.auty@gmail.com on 4 Jan 2011 at 11:55

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r574.

Original comment by mike.auty@gmail.com on 6 Jan 2011 at 1:03

GoogleCodeExporter commented 8 years ago
Ok, so this now returns NoneObjects which will show up in the debugging logs if 
enabled and return "-" when displayed as text (which is a little safer than 
returning 0 for a field that could legitimately be a number).

Interesting, I also found this broken key on an XPSP3 image under the SAM hive 
in exactly the same place, and it makes me wonder if there was a change in the 
registry, or whether those fields are supposed to be broken?

I've CCed in moyix in case he has any views on this, but the reported issue has 
been fixed.  If there's a further issue that the registry code won't work 
properly on other profiles, it should be opened separately.

Original comment by mike.auty@gmail.com on 6 Jan 2011 at 1:06