search

Leor3961 / volatility

Automatically exported from code.google.com/p/volatility
0 stars 0 forks source link

pslist/psscan on 1.4 and xpsp3 memory #29

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Hey guys, 

I encountered this issue this week. I've been updating the code from CVS about 
once a week and the problem just starting happening so it may be due to a 
recent change.

$ python volatility.py pslist -f XPSP3.vmem
Volatile Systems Volatility Framework 1.4_rc1
Name                 Pid    PPid   Thds   Hnds   Time 
System                    4      0     56    196 1970-01-01 00:00:00      
                          0      0      0 ------ 1970-01-01 00:00:00      
                          0      0      0 ------ 1970-01-01 00:00:00      
Traceback (most recent call last):
  File "volatility.py", line 138, in <module>
    main()
  File "volatility.py", line 129, in main
    command.execute()
  File "/Users/user/Desktop/Volatility-1.4_rc1/volatility/commands.py", line 98, in execute
    func(outfd, data)
  File "/Users/user/Desktop/Volatility-1.4_rc1/plugins/internal/taskmods.py", line 153, in render_text
    task.CreateTime))
  File "/Users/user/Desktop/Volatility-1.4_rc1/plugins/overlays/Windows/xp_sp2.py", line 165, in __format__
    dt = self.as_datetime()
  File "/Users/user/Desktop/Volatility-1.4_rc1/plugins/overlays/Windows/xp_sp2.py", line 157, in as_datetime
    dt = datetime.datetime.utcfromtimestamp(self.v())
ValueError: year is out of range

Same with psscan:

$ python volatility.py psscan -f XPSP3.vmem
Volatile Systems Volatility Framework 1.4_rc1
PID    PPID   Time created             Time exited              Offset     PDB  
      Remarks
------ ------ ------------------------ ------------------------ ---------- 
---------- ----------------
     0      0                                                   0x005529a0 0x00319000 Idle           
     0      0                                                   0x01f6a978 0x00000000                
     0      0                                                   0x01f8e7e0 0x00000000                
     0      0                                                   0x01fa63c0 0x00000000                
Traceback (most recent call last):
  File "volatility.py", line 138, in <module>
    main()
  File "volatility.py", line 129, in main
    command.execute()
  File "/Users/user/Desktop/Volatility-1.4_rc1/volatility/commands.py", line 98, in execute
    func(outfd, data)
  File "/Users/user/Desktop/Volatility-1.4_rc1/plugins/internal/psscan.py", line 280, in render_text
    eprocess.ImageFileName))
  File "/Users/user/Desktop/Volatility-1.4_rc1/plugins/overlays/Windows/xp_sp2.py", line 165, in __format__
    dt = self.as_datetime()
  File "/Users/user/Desktop/Volatility-1.4_rc1/plugins/overlays/Windows/xp_sp2.py", line 157, in as_datetime
    dt = datetime.datetime.utcfromtimestamp(self.v())
ValueError: year is out of range

I can analyze the memory in Volatility 1.3 just fine though:

$ python volatility pslist -f XPSP3.vmem
Name                 Pid    PPid   Thds   Hnds   Time 
System               4      0      56     196    Thu Jan 01 00:00:00 1970   
823c8830
smss.exe             532    4      3      19     Sun Aug 22 17:39:08 2010   
81df0388
csrss.exe            596    532    12     388    Sun Aug 22 17:39:10 2010   
81e45978
winlogon.exe         620    532    19     520    Sun Aug 22 17:39:10 2010   
822dfda0
services.exe         664    620    17     340    Sun Aug 22 17:39:10 2010   
81e41610
lsass.exe            676    620    21     351    Sun Aug 22 17:39:10 2010   
82175b90

Original issue reported on code.google.com by michael.hale@gmail.com on 9 Sep 2010 at 12:42

GoogleCodeExporter commented 8 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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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