search

Leor3961 / volatility

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

updating volatlity from SVN broke caching due to code change #21

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Not really sure how to file this or if its a bug that can really be fixed, but 
I thought I should post it anyway.

So the problem is that I was on a previous version of volatility from yesterday 
and had generated caches. Today I updated to the latest in svn and sometime 
later ran pslist to get the PID of a process and this happened:

root@newubuntu:~/vol# python volatility.py pslist -f winXP-32-SP3.vmem 
--profile=WinXPSP3
Volatile Systems Volatility Framework 1.4_rc1
Name                 Pid    PPid   Thds   Hnds   Time
System                    4      0     54    249 1970-01-01 00:00:00
smss.exe                552      4      3     19 2010-08-26 01:00:40
csrss.exe               600    552     11    361 2010-08-26 01:00:41
winlogon.exe            624    552     24    550 2010-08-26 01:00:42
services.exe            668    624     16    250 2010-08-26 01:00:42
lsass.exe               680    624     26    379 2010-08-26 01:00:42
vmacthlp.exe            840    668      1     25 2010-08-26 01:00:42
svchost.exe             852    668     19    198 2010-08-26 01:00:42
svchost.exe             920    668      9    239 2010-08-26 01:00:43
svchost.exe            1016    668     71   1188 2010-08-26 01:00:43
svchost.exe            1060    668      5     73 2010-08-26 01:00:43
svchost.exe            1156    668     13    192 2010-08-26 01:00:43
spoolsv.exe            1312    668      6     51 2010-08-26 01:00:44
VMwareService.e        1608    668      3    144 2010-08-26 01:01:01
alg.exe                2004    668      8    106 2010-08-26 01:01:10
explorer.exe            528    500     17    290 2010-08-26 01:01:31
wscntfy.exe             292   1016      1     28 2010-08-26 01:01:32
VMwareTray.exe          908    528      1     29 2010-08-26 01:01:34
VMwareUser.exe         1004    528      4     76 2010-08-26 01:01:34
msmsgs.exe             1220    528      4    153 2010-08-26 01:01:35
4±OPO     2172747816 2174491220 2174491300 538517528 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 "/home/x/vol/volatility/commands.py", line 96, in execute
    func(outfd, data)
  File "/home/x/vol/plugins/internal/taskmods.py", line 153, in render_text
    task.CreateTime))
  File "/home/x/vol/plugins/overlays/Windows/xp_sp2.py", line 167, in __format__
    dt = self.as_datetime()
  File "/home/x/vol/plugins/overlays/Windows/xp_sp2.py", line 159, in as_datetime
    dt = datetime.datetime.utcfromtimestamp(self.v())
ValueError: timestamp out of range for platform time_t

-----------------

now I think the datetime stuff was updated in the revisions that got pulled so 
I am sure that is why its broke, but obviously the cache doesn't know about 
this....

Again, I am not really sure if this is a bug or not, and if I were doing a real 
investigation I wouldn't be updating software in the middle unless something 
was really broken....

either way, removing the cache directory under /tmp for the image fixed it and 
now everything works as expected

Original issue reported on code.google.com by atc...@gmail.com on 26 Aug 2010 at 2:02

GoogleCodeExporter commented 8 years ago 
Ok.  The datetime code shouldn't have been changed, and particularly not in 
relation to the cached data.  Also, it looks like all the values being read are 
wrong (but the exception was raised on the date because there's a bit more 
validation over dates).  My guess is more than the pslist or some value in the 
vtypes changed, leading to a bad pointer.

Unfortunately the caching framework doesn't have proper invalidation yet (which 
hopefully would solve this kind of issue), so I'm going to roll this into issue 
13.

In the interim, please make a note of invalid cache problems like this (and 
possibly save the tmp directories) so that we can check if they still occur 
once invalidation's been added.

Original comment by mike.auty@gmail.com on 27 Aug 2010 at 9:13