Closed GoogleCodeExporter closed 9 years ago
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...
Original comment by mike.auty@gmail.com
on 9 Sep 2010 at 10:51
I couldn't reproduce it with my xp sp3 memory image..
ran both of the plugins with and without --profile
Original comment by atc...@gmail.com
on 9 Sep 2010 at 11:09
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
Original comment by michael.hale@gmail.com
on 9 Sep 2010 at 11:19
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 ?
Original comment by atc...@gmail.com
on 9 Sep 2010 at 11:33
tested it on windows 7 x64 host with python 2.7 and it still works fine...
Original comment by atc...@gmail.com
on 9 Sep 2010 at 11:52
Ah, it works with --no-cache. Sorry, I could have sworn I tried that before.
Original comment by michael.hale@gmail.com
on 9 Sep 2010 at 11:55
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)
Original comment by atc...@gmail.com
on 10 Sep 2010 at 12:15
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.
Original comment by michael.hale@gmail.com
on 10 Sep 2010 at 12:21
No problem, this is exactly why we need precise cache invalidation. Marking as
duplicate of issue 13. 5:)
Original comment by mike.auty@gmail.com
on 10 Sep 2010 at 12:24
Original issue reported on code.google.com by
michael.hale@gmail.com
on 9 Sep 2010 at 12:42