No CreateTime for sockets on Win2k3 SP0

[GoogleCodeExporter]

Hey guys, I encountered an issue regarding sockets and sockscan on win2k3 sp0 
machines. The problem is that win2k3 sp0 is the only profile whose 
_ADDRESS_OBJECT does not contain a CreateTime member. The pool size of TCPA 
object is less on sp0 as a direct result of this. I have no idea why MSFT 
doesn't track CreateTime for win2k3 sp0 only...but that's besides the point. 

So assuming we point the win2k3 sp0 profile to tcpip.tcpip_vtypes, the date is 
incorrectly printed (since in fact there is no date):

$ python vol.py --profile=Win2K3SP0x86 -f ../win2k3sp0.vmem sockscan
Volatile Systems Volatility Framework 1.4_rc1
 Offset     PID    Port   Proto  Create Time               
---------- ------ ------ ------ -------------------------- 
0x02092778    844   1039     17 -
0x020d9240   2672   1036      6 9008-03-23 17:07:43       
0x020e69e8    844   1028     17 9008-03-23 17:08:10       
0x02150ce0   2020   1031      6 -
0x021efea8    948   1027     17 -
0x022f32d0    516    500     17 9008-03-23 17:07:26       
0x02319540    516   1026      6 9008-03-23 17:07:26       
0x02321200      4    137     17 8997-06-17 18:28:24       
0x023214d8      4    138     17 8997-06-17 18:28:24       
0x023217b0      4    139      6 8997-06-17 18:28:24       
0x0232c390    928   1025      6 -
0x026654e0   2672   1033      6 9008-03-23 17:08:10

I thought about creating tcpip.tcpip_vtypes_w2k3sp0 and deleting the CreateTime 
member, then putting something like this in the render_text:

if hasattr(sock_obj, 'CreateTime'):
    ctime = sock_obj.CreateTime
else:
    ctime = '' # Or perhaps we have some other message like N/A

However with this change, we then run into:

$ python vol.py --profile=Win2K3SP0x86 -f ../win2k3sp0.vmem sockscan
Volatile Systems Volatility Framework 1.4_rc1
 Offset     PID    Port   Proto  Create Time               
---------- ------ ------ ------ -------------------------- 
WARNING : volatility.obj      : CreateTime has no offset in object 
_ADDRESS_OBJECT. Check that vtypes has a concrete definition for it.

This is probably because of the CheckSocketCreateTime check in 
PoolScanSockFast. 

So a possible solution would be to also add a hasattr() check in 
CheckSocketCreateTime but you can already see its getting kind of messy. 

What other possibilities, if any can you think of? 

Original issue reported on code.google.com by michael.hale@gmail.com on 8 Apr 2011 at 2:44

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 8 Apr 2011 at 2:44

[GoogleCodeExporter]

Hello,

So I believe what can be done is what ikelos & I came up with for the Linux 
branch. Since linux has a huge number of structure members that change between 
versions, we already had to solve this. 

Look at the code here first (at the end with changing object_classes):

http://code.google.com/p/volatility/source/browse/branches/linux-support/volatil
ity/plugins/overlays/linux/linux.py

and if it doesn't make sense continue reading...

We do this by using an abstract class (AbstractLinuxProfile) that all profiles 
inherit from and then we update the object_classes for the abstract profile 
with classes that implement a member like get_files, get_pid etc

then all plugins have to do is instead of doing obj.file then do obj.get_file() 
which abstracts away all the nastiness of having plugins or scanners call 
hasattr()

if you choose to do it this way you would just need to update the places that 
deference CreateTime and change it to something like .getCreateTime()

Original comment by atc...@gmail.com on 8 Apr 2011 at 4:54

[GoogleCodeExporter]

attc please do not do this. It defeats the whole point of object oriented 
vtypes. It  replaces the natural readability of x.y.z with x.get_y().get_z() 
etc.

The correct way to solve this is to create aliases for those profiles which are 
missing certain fields (for example if fields are renamed). In the case of 
win2k3sp0 you can simply have a constant 0 for the create time by adding the 
field to the overlay. For example:

overlays = { ...
  '_ADDRESS_OBJECT': [None, 
     'CreateTime' : [ 0, ['VolatilityMagic', dict(value = 0)]]
   ]}

This will ensure this field always exists but is always 0 (but only for 
win2k3sp0).

Similarly for the linux solution this problem should simply be solved by having 
different overlays for different versions, and aliasing one member to another. 
If there is a fair bit of logic (not just simple aliasing) you can use classes 
to add the missing members (or even additional ones). For example:

http://code.google.com/p/volatility/source/browse/branches/win64-support/volatil
ity/plugins/overlays/windows/windows.py#301

Adds additional optional header structs in the constructor because they require 
some complex os dependent parsing. The clients of this dont really care though 
because it appears like the extra fields are just part of this struct.

Original comment by scude...@gmail.com on 30 Sep 2011 at 8:03

[GoogleCodeExporter]

Scudette, 

Thanks for the suggestion, sorry its taken so long to reply. 

So if this is a win2k3sp0-specific overlay, I figured it should go in 
win2k3_sp0_x86.py. I placed the following line in that file:

win2k3sp0x86overlays['_ADDRESS_OBJECT'][1]['CreateTime'][1] = 
['VolatilityMagic', dict(value = 0)]

However, when using the sockets command, it still prints garbage times like 
"9008-03-23 17:07:43 " which it shouldn't be doing if the CreateTime is 0. 

Am I adding the overlay incorrectly? 

Also, this may have a negative effect on sockscan, since one of the scanner 
checks is based on the CreateTime being > 0. If we "hard-code" CreateTime to 0 
in the overlay, is that going to make sockscan come up empty? See: 

http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/socks
can.py#57

Thanks!

Original comment by michael.hale@gmail.com on 27 Oct 2011 at 2:50

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 9 Apr 2013 at 7:22

• Changed state: WontFix