pslist/psscan on 1.4 and xpsp3 memory about volatility HOT 9 CLOSED

Hmmm, it appears to be finding bogus entries (with rubbish in the datetime 
stamps).  There was an exception around this in the experimental branch, but 
that always returned 0, which seemed like a poor way of indicating an error had 
occurred trying to interpret the time.

I've tried most of the other images I have and can't seem to hit the problem 
(although I don't have any XPSP3 images, so perhaps it's specific to that)?  
Can I ask whether using the XPSP3 profile works any better (shouldn't do if 
vol-1.3 could pick it up, but worth a check).  Failing that you'll have to step 
into them both and compare the offsets they're producing.  My guess is one of 
them's off, but figuring out why will require a bit of debugging...

I couldn't reproduce it with my xp sp3 memory image..

ran both of the plugins with and without --profile

Here's a link to an image you can use to reproduce. psscan does OK with this 
image but pslist still seems to have a problem. 

http://www.mnin.org/XPSP3.vmem.zip

I ran it against the file you provided and it still seems to work:

python volatility.py pslist -f XPSP3.vmem
Volatile Systems Volatility Framework 1.4_rc1
Name                 Pid    PPid   Thds   Hnds   Time
System                    4      0     56    382 1970-01-01 00:00:00
smss.exe                552      4      3     19 2010-09-08 14:57:09
csrss.exe               600    552     11    394 2010-09-08 14:57:11
winlogon.exe            628    552     23    521 2010-09-08 14:57:11
services.exe            676    628     16    270 2010-09-08 14:57:12
lsass.exe               688    628     21    332 2010-09-08 14:57:12
vmacthlp.exe            848    676      1     25 2010-09-08 14:57:12
svchost.exe             872    676     19    197 2010-09-08 14:57:12
svchost.exe             940    676     14    276 2010-09-08 14:57:12
svchost.exe            1032    676     66   1158 2010-09-08 14:57:12
svchost.exe            1092    676      5     59 2010-09-08 14:57:12
svchost.exe            1184    676     15    196 2010-09-08 14:57:13
spoolsv.exe            1412    676     15    128 2010-09-08 14:57:14
jqs.exe                1576    676      5    148 2010-09-08 14:57:22
vmtoolsd.exe           1684    676      7    266 2010-09-08 14:57:22
VMUpgradeHelper        1812    676      5     98 2010-09-08 14:57:25
alg.exe                 120    676      6    107 2010-09-08 14:57:26
explorer.exe            588    500     14    303 2010-09-08 14:57:30
VMwareTray.exe         1112    588      1     50 2010-09-08 14:57:30
VMwareUser.exe         1144    588      8    176 2010-09-08 14:57:30
jusched.exe            1156    588      1     24 2010-09-08 14:57:30
wscntfy.exe            1220   1032      1     28 2010-09-08 14:57:32
imapi.exe              1324    676      7    118 2010-09-08 14:57:35
wuauclt.exe            1536   1032      7    177 2010-09-08 14:58:10
wuauclt.exe            1916   1032      5    136 2010-09-08 14:58:25
cmd.exe                1848    588      1     30 2010-09-08 14:58:48
ipconfig.exe           1068   1020      0 ------ 2010-09-08 15:00:08

same results with and without --profile

whats the host machine you are running it on? is it 64bit? also can you try it 
with --no-cache ?

tested it on windows 7 x64 host with python 2.7 and it still works fine...

Ah, it works with --no-cache. Sorry, I could have sworn I tried that before.

hmmm so I have tried this on:

win 7 x64
ubuntu 32 bit
ubuntu 64 bit

all with all combinations of cache/--no-cache and --profile and leaving out 
--profile and I can't get it to crash

michael could you please list:

- what version of python you are using
- what your host machine is (architecture & OS)

Hey guys, 

My Python version is 2.6.1 on Mac OSX. However, it works now with --no-cache. I 
actually deleted the /tmp/*.cache files to clear it out and now it all works 
with or without --no-cache. Sorry for raising a false alarm. I guess at some 
point, the cache files got filled with some bogus data. 

No problem, this is exactly why we need precise cache invalidation.  Marking as 
duplicate of issue 13.  5:)