mutantscan plugin breaks on XP SP3 32 bit

[GoogleCodeExporter]

root@newubuntu:~/vol# python volatility.py mutantscan -f winXP-32-SP3.vmem 
--profile=WinXPSP3
Volatile Systems Volatility Framework 1.4_rc1
Phys.Addr. Obj Type   #Ptr #Hnd Signal Thread     CID        Name
Traceback (most recent call last):
  File "volatility.py", line 138, in <module>
    main()
  File "volatility.py", line 129, in main
    command.execute()
  File "/home/x/vol/volatility/commands.py", line 96, in execute
    func(outfd, data)
  File "/home/x/vol/plugins/internal/filescan.py", line 276, in render_text
    self.parse_string(object_name_info_obj.Name)
AttributeError: 'NoneType' object has no attribute 'Name'
root@newubuntu:~/vol#

run from a linux 32 bit machine

Original issue reported on code.google.com by atc...@gmail.com on 26 Aug 2010 at 1:18

[GoogleCodeExporter]

this blows up due to this code path:

in render_text this is called:

self.parse_string(object_name_info_obj.Name)

which is the line shown in the backtrace. The object_name_info_obj comes from 
line 246 in the calculate function in class MutantScan(FileScan):

## Now we need to work out the _OBJECT_NAME_INFO object
object_name_info_obj = obj.Object("_OBJECT_NAME_INFO", vm = address_space,
                                  offset = object_obj.offset - \
                                  object_obj.NameInfoOffset )

so I grepped for _OBJECT_NAME_INFO and the only reference is in 
plugins/overlays/Windows/vtypes.py and its hardcoded to have a directory and 
name member, but when I look the vtypes file for XP SP3. I see a structure 
OBJECT_NAME_INFORMATION that has the definition:

 '_OBJECT_NAME_INFORMATION' : [ 0x8, {
    'Name' : [ 0x0, ['_UNICODE_STRING']],
} ],

which only has the name member. I assuming that the differences in the 
_OBJECT_NAME_INFO structure between vtypes.py and the xp sp3 vtypes is the 
problem. the code should properly be changed to use a _OBJECT_NAME_INFORMATION 
structure instead of the "INFO" version unless I am missing something.

Original comment by atc...@gmail.com on 26 Aug 2010 at 1:52

[GoogleCodeExporter]

I edited the code to use OBJECT_NAME_INFORMATION and it seems to work now as 
lines like this are coming back in the results:

0x018df700 0x00000005 -506228896    1      1 0x00000000            
WindowsUpdateTracingMutex

there are a bunch of jibberish lines though like this one:

0x018bf3f0 0x00000003 -510376504    1      1 0x00000000            
㼿㼿㼿㼿㼿㼿㼿㼿㼿㼿㼿

which may be normal since its hitting unallocated memory. either way it works a 
lot better and doesn't break

Original comment by atc...@gmail.com on 26 Aug 2010 at 2:18

[GoogleCodeExporter]

Excellent, thanks.  This is the kind of bug I was expecting to hit because the 
names in vtypes were entered manually and people might have used their own 
versions (like using INFO rather than INFORMATION).  I've made the change 
(r400), and it still seems to work with XPSP2 (even though 
OBJECT_NAME_INFORMATION seems to have a directory pointer in SP2).  Thanks for 
spotting it, and tracking down the fix!  5:)

Original comment by mike.auty@gmail.com on 26 Aug 2010 at 11:16

• Changed state: Fixed