Sockets plugin: XP using 2K3 offsets or vice versa

[GoogleCodeExporter]

Hey guys,

We recently came across a bug and were able to confirm that at times the 
incorrect offsets are being used for the sockets plugin.  For example, I have 
an XP SP 3 image which incorrectly uses the offsets for 2K3.  This results in 
garbage output in an infinite loop.  I have also had the reverse happen with 
2K3 images using XP offsets.  Example:

$ ./vol.py -f XPSP3.dmp sockets --profile=WinXPSP3x86
Volatile Systems Volatility Framework 2.1_alpha
 Offset(V)  PID    Port   Proto               Address        Create Time               
---------- ------ ------ ------------------- -------------- 
-------------------------- 
0x886ad1a8      0   1792   2567 -              1.0.0.0            1970-01-01 
00:00:00       
0x886ad1a8 2326665472  14590  34921 -              0.0.188.0          
1970-01-01 00:00:00       
0x8869fe38 1532872800  36920  35269 -              0.0.0.0            
1970-01-01 00:00:00       
0xe686e910 2326665472  14590  34921 -              0.0.188.0          
1970-01-01 00:00:00       
0x8869fe38 1532872800  36920  35269 -              0.0.0.0            
1970-01-01 00:00:00       
0xe686e910 2326665472  14590  34921 -              0.0.188.0          
1970-01-01 00:00:00       
0x8869fe38 1532872800  36920  35269 -              0.0.0.0            
1970-01-01 00:00:00       
0xe686e910 2326665472  14590  34921 -              0.0.188.0          
1970-01-01 00:00:00       
0x8869fe38 1532872800  36920  35269 -              0.0.0.0            
1970-01-01 00:00:00       
0xe686e910 2326665472  14590  34921 -              0.0.188.0          
1970-01-01 00:00:00       
0x8869fe38 1532872800  36920  35269 -              0.0.0.0            
1970-01-01 00:00:00       
0xe686e910 2326665472  14590  34921 -              0.0.188.0          
1970-01-01 00:00:00       

[snip - this goes on and on]

Now after commenting out the 2k3 offsets in network.py, success:

$ ./vol.py -f XPSP3.dmp sockets --profile=WinXPSP3x86
Volatile Systems Volatility Framework 2.1_alpha
 Offset(V)  PID    Port   Proto               Address        Create Time               
---------- ------ ------ ------------------- -------------- 
-------------------------- 
0x88af6a08    360  38009      6 TCP            127.0.0.1          2011-03-07 
21:10:10       
0x88af6a08    708   1089     17 UDP            0.0.0.0            2011-03-07 
21:07:57       
0x896b1bf0      4   1150      6 TCP            0.0.0.0            2011-03-07 
21:10:11       
0x896b1bf0      4      0     47 GRE            0.0.0.0            2011-03-07 
21:10:11       
0x89973e98   3208   6950      6 TCP            0.0.0.0            2011-03-07 
21:08:51            
0x8873d3f8      4    138     17 UDP            192.168.2.100      2011-03-07 
21:07:33       
0x8864aa48   1608  52311     17 UDP            0.0.0.0            2011-03-07 
21:14:32       
0x8864aa48   4044   1210      6 TCP            127.0.0.1          2011-03-07 
21:11:11       
0x888d6008      4    139      6 TCP            192.168.2.100      2011-03-07 
21:07:44       
0x8856e628    708   3151      6 TCP            0.0.0.0            2011-03-07 
21:55:38       
0x8856e628   1928   1157     17 UDP            127.0.0.1          2011-03-07 
21:10:25       
0x89b64c70      4    445      6 TCP            0.0.0.0            2011-03-07 
21:06:43       
0x89b64c70    388   4242      6 TCP            127.0.0.1          2011-03-07 
21:07:59       
0x887b7bf0   4876   1554      6 TCP            0.0.0.0            2011-03-07 
21:15:34   

[snip]

Therefore we will have to make this plugin OS aware.

Original issue reported on code.google.com by jamie.l...@gmail.com on 19 Oct 2011 at 1:43

[GoogleCodeExporter]

Here is a patch that fixes this for now.  Look it over and see if it looks ok.

Original comment by jamie.l...@gmail.com on 19 Oct 2011 at 2:05

Attachments:

• network.diff

[GoogleCodeExporter]

It looks good to me. In the future we may need to:

1) get even more specific (i.e. include service pack), in which case we can 
leverage ImageInfo's function here 
(http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/imag
einfo.py#139)...since there's a chance the 5.1 SP2 offsets could cause infinite 
loops for 5.2 SP3 machines 

2) develop an entirely new method that doesn't depend on hard-coded offsets 
(for example, integrate PDB symbols)

3) use a hybrid approach, with combined pool scanning and list traversal. 
sockscan and connscan find individual structures, but the symbols we're looking 
for like TCBTableOff and AddrObjTableOffset (not the real symbol names) are in 
pools with pool tags as well. so we could use pool scanning to find the list 
head, then use traversal to enumerate individual structures. there is one 
complication with this method that i can describe further if we decide its 
necessary to pursue.  

Original comment by michael.hale@gmail.com on 19 Oct 2011 at 2:48

[GoogleCodeExporter]

Let's commit this? I think my options 1, 2, and 3 above are long-term solutions 
(if anything). 

Original comment by michael.hale@gmail.com on 27 Oct 2011 at 12:41

[GoogleCodeExporter]

Sorry, I realize this has been open a long time, but I only just got around to 
looking at it.  Just in case we decide to end up supporting 2000, or something 
like that, could be make the check be xp if <= 5.1 else 2k3?  That way we're 
not being specific to just single out XP?  Otherwise looks absolutely fine (and 
if it's too difficult/much effort then do just commit as is, I'd sooner have 
the fix than be too picky).  5;)

Original comment by mike.auty@gmail.com on 27 Oct 2011 at 6:51

[GoogleCodeExporter]

Ok, I'll make the change and commit it then :-)

Original comment by jamie.l...@gmail.com on 27 Oct 2011 at 1:23

[GoogleCodeExporter]

This issue was closed by revision r1138.

Original comment by jamie.l...@gmail.com on 27 Oct 2011 at 1:56

• Changed state: Fixed