files plugin breaks on windows 7 x86

[GoogleCodeExporter]

generates another issue....

C:\Users\admin\Desktop\vol>C:\Python27\python.exe volatility.py files 
--profile=Win7SP0x86  --no-cache -f win7vss.vmem
Volatile Systems Volatility Framework 1.4_rc1
Pid:      4
Traceback (most recent call last):
  File "volatility.py", line 138, in <module>
    main()
  File "volatility.py", line 129, in main
    command.execute()
  File "C:\Users\admin\Desktop\vol\volatility\commands.py", line 96, in execute
    func(outfd, data)
  File "C:\Users\admin\Desktop\vol\plugins\internal\taskmods.py", line 123, in render_text
    for h in handles:
  File "C:\Users\admin\Desktop\vol\plugins\internal\taskmods.py", line 136, in handle_list
    for h in task.handles():
  File "C:\Users\admin\Desktop\vol\plugins\overlays\Windows\xp_sp2.py", line 260, in handles
    for h in self._make_handle_array(offset, table_levels):
  File "C:\Users\admin\Desktop\vol\plugins\overlays\Windows\xp_sp2.py", line 227, in _make_handle_array
    for h in self._make_handle_array(offset, level - 1):
  File "C:\Users\admin\Desktop\vol\plugins\overlays\Windows\xp_sp2.py", line 219, in _make_handle_array
    count = 0x200, parent = self)
  File "C:\Users\admin\Desktop\vol\volatility\obj.py", line 631, in __init__
    parent = parent, name = name)
  File "C:\Users\admin\Desktop\vol\volatility\obj.py", line 301, in __init__
    raise InvalidOffsetError("Invalid Address 0x{0:08X}, instantiating {1}".format(offset, name))
volatility.obj.InvalidOffsetError: Invalid Address 0x00000000, instantiating 
None

Original issue reported on code.google.com by atc...@gmail.com on 17 Aug 2010 at 11:33

[GoogleCodeExporter]

Hmmm, ok.  This is because we recently changed the invalid_offset checking from 
being in the Object factory function, to being in the BaseObject.  Array runs 
the BaseObject.__init__ on it's subtype, and then _make_handle_array does the 
checking manually for each subobject.

Could you please try that attached patch, which dumps out early if the array 
isn't at a valid offset?  There should be no change in functionality.

Original comment by mike.auty@gmail.com on 17 Aug 2010 at 11:34

Attachments:

• issue-3-fix.patch

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 17 Aug 2010 at 11:38

• Changed state: Started

[GoogleCodeExporter]

Ok, applied the patch to the tree (r385), so this should now be fixed.

Original comment by mike.auty@gmail.com on 18 Aug 2010 at 1:32

• Changed state: Fixed