psscan relies on WorkingSetLock which isn't in vtypes for windows 7 x86 images

[GoogleCodeExporter]

the psscan module drops into the debugger when attempting to scan a windows 7 
image. see the following:

C:\Users\admin\Desktop\vol>C:\Python27\python.exe volatility.py  psscan 
--profile=Win7SP0x86  -f win7vss.vmem
Volatile Systems Volatility Framework 1.4_rc1
PID    PPID   Time created             Time exited              Offset     PDB  
      Remarks
------ ------ ------------------------ ------------------------ ---------- 
---------- ----------------
--Return--
> c:\users\admin\desktop\vol\volatility\debug.py(38)b()->None
-> pdb.set_trace()
(Pdb) bt
  c:\users\admin\desktop\vol\volatility.py(138)<module>()
-> main()
  c:\users\admin\desktop\vol\volatility.py(129)main()
-> command.execute()
  c:\users\admin\desktop\vol\volatility\commands.py(96)execute()
-> func(outfd, data)
  c:\users\admin\desktop\vol\plugins\internal\psscan.py(273)render_text()
-> for eprocess in data:
  c:\users\admin\desktop\vol\volatility\cache.py(400)generate()
-> for x in g:
  c:\users\admin\desktop\vol\plugins\internal\psscan.py(237)calculate()
-> for offset in PSScanner().scan(address_space):
  c:\users\admin\desktop\vol\volatility\scan.py(143)scan()
-> for match in BaseScanner.scan(self, address_space, o, l):
  c:\users\admin\desktop\vol\volatility\scan.py(112)scan()
-> if self.check_addr(i + self.base_offset):
  c:\users\admin\desktop\vol\volatility\scan.py(76)check_addr()
-> debug.b()
> c:\users\admin\desktop\vol\volatility\debug.py(38)b()->None
-> pdb.set_trace()
(Pdb)

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

• Blocking: #9

[GoogleCodeExporter]

Forgot to add... The host machine is 64 bit windows 7 running python 2.7

Original comment by atc...@gmail.com on 17 Aug 2010 at 11:14

[GoogleCodeExporter]

Yep, this can be recreated with any Windows 7 image and psscan plugin.  It 
appears this plugin looks for the WorkingSetLock attribute of an _EPROCESS, 
which isn't defined for Vista/7.

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

[GoogleCodeExporter]

Ok, so Vista and 7 don't have a WorkingSetLock, and there's something else at 
the same offset, so we're going to have to change how psscan finds/validates 
potential _EPROCESS objects.  That's probably something for mooyix or 
labarumXP, so I'm assigning it to them.

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

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 18 Aug 2010 at 10:36

• Changed title: psscan relies on WorkingSetLock which isn't in vtypes for windows 7 x86 images

[GoogleCodeExporter]

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

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 21 Jan 2011 at 9:03

• Added labels: Milestone-Release1.4

[GoogleCodeExporter]

Sorry for the bugspam, but better to get this right now than later once it's 
more in use.

Original comment by mike.auty@gmail.com on 4 Feb 2011 at 9:34

• Added labels: Milestone-1.4.x
• Removed labels: Milestone-Release1.4

[GoogleCodeExporter]

It looks as though the DispatchHeader scanner (psscan) is slower than the Pool 
scanner (psscan2) and only turns up results that psscan2 doesn't in very 
specific situations (such as the Idle "process" and malware that's capable of 
messing with anything it pleases, in which case it could avoid psscan as well).

We're therefore going to move psscan into the contrib directory, and rename all 
the remaining "scan2" plugins into "scan" plugins.  The descriptions may need 
updating to make them more accurate.  I'll make sure psscan details that it 
scans for pool headers, but more than that I'll need other people to 
comment/patch/shout at me on IRC...  5:)

Original comment by mike.auty@gmail.com on 21 Jun 2011 at 7:12

[GoogleCodeExporter]

This issue was closed by revision r1003.

Original comment by mike.auty@gmail.com on 21 Jun 2011 at 7:43

• Changed state: Fixed