win32/network functions rely on hardcoded offsets into tcpip.sys - need updating and moving to profiles

[GoogleCodeExporter]

host changed to a 32 bit windows 7 running python 2.7. the image is still the 
same x86 windows 7 image.

C:\Users\admin\Desktop\vol>C:\Python27\python.exe volatility.py sockets 
--profile=Win7SP0x86  -f win7vss.vmem
Volatile Systems Volatility Framework 1.4_rc1
Traceback (most recent call last):
  File "volatility.py", line 138, in <module>
    main()
  File "volatility.py", line 129, in main
    command.execute()
  File "C:\Users\admin\Desktop\vol\volatility\commands.py", line 72, in execute
    data = self.calculate()
  File "C:\Users\admin\Desktop\vol\plugins\internal\sockets.py", line 40, in calculate
    result = win32.network.determine_sockets(addr_space)
  File "C:\Users\admin\Desktop\vol\volatility\win32\network.py", line 139, in determine_sockets
    target = obj.Curry(obj.Pointer, "_ADDRESS_OBJECT"))
  File "C:\Users\admin\Desktop\vol\volatility\obj.py", line 631, in __init__
    parent = parent, name = name)
  File "C:\Users\admin\Desktop\vol\volatility\obj.py", line 301, in __init__
    raise InvalidOffsetError("Invalid Address 0x{0:08X}, instantiating {1}".format(offset, name))
volatility.obj.InvalidOffsetError: Invalid Address 0x7CCC153B, instantiating 
None

Original issue reported on code.google.com by atc...@gmail.com on 18 Aug 2010 at 1:34

• Blocking: [Tracker] Plugins that fail on profiles other than XPSP2 #9

[GoogleCodeExporter]

Ok, this was another instance of an array being instantiated directly rather 
than through the Object factory function.  This should be fixed in r386, 
however, it will still not produce any output for windows 7, because these 
plugins rely on fixed offsets within the tcpip.sys modules which need updating 
to windows 7 (and moving into the profile).

Original comment by mike.auty@gmail.com on 18 Aug 2010 at 10:34

• Changed title: win32/network functions rely on hardcoded offsets into tcpip.sys - need updating and moving to profiles
• Changed state: Accepted

[GoogleCodeExporter]

Issue 7 has been merged into this issue.

Original comment by mike.auty@gmail.com on 18 Aug 2010 at 10:35

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 18 Aug 2010 at 10:46

[GoogleCodeExporter]

Ok, the fix I checked in didn't help.  It looks like arrays really shouldn't 
instaniate their first object in case it's invalid, but the array itself isn't. 
 I've asked for scudette's advice on how best to handle this...

Original comment by mike.auty@gmail.com on 18 Aug 2010 at 11:34

[GoogleCodeExporter]

Issue 16 has been merged into this issue.

Original comment by mike.auty@gmail.com on 26 Aug 2010 at 11:18

[GoogleCodeExporter]

Right, not sure what comment 4 was about, but just to make it clear, this need 
someone to track down the offsets in all the different versions of tcpip.sys.  
Once that's done, I can help turn it into a VolatilityMagic object that'll be 
called for the specific profiles...

Original comment by mike.auty@gmail.com on 26 Aug 2010 at 11:19

[GoogleCodeExporter]

I think Michael said he had some plugins as a work in progress for these, so 
I'm assigning it to him.  Feel free to unassign if you think someone else 
should be handling it...  5:)

Original comment by mike.auty@gmail.com on 24 Nov 2010 at 10:53

[GoogleCodeExporter]

Yep, I'm working on this, and it will take a little while longer. Just 
something to think about in the meantime though, the networking architecture 
has changed significantly starting with Vista, so its not just a matter of 
adding new offsets in tcpip.sys to the connections/sockets commands. We'll need 
to perform an entirely new sequence of actions on Vista and Windows 7, because 
they use hash tables and bitmaps. Here is a preview though (sockets only...I am 
yet to have a preview for connections):

$ python volatility.py netstat -f Windows7.vmem --profile=Win7SP0x86 
Volatile Systems Volatility Framework 1.4_rc1
Proto    Local Address        Foreign Address      State            Pid      
Owner
TCP      0.0.0.0:135          0.0.0.0:0            LISTENING        712      
svchost.exe
TCP      169.254.53.234:139   0.0.0.0:0            LISTENING        4        
System
TCP      0.0.0.0:445          0.0.0.0:0            LISTENING        4        
System
TCP      0.0.0.0:5357         0.0.0.0:0            LISTENING        4        
System
TCP      0.0.0.0:49152        0.0.0.0:0            LISTENING        408      
wininit.exe
TCP      0.0.0.0:49153        0.0.0.0:0            LISTENING        764      
svchost.exe
TCP      0.0.0.0:49154        0.0.0.0:0            LISTENING        948      
svchost.exe
TCP      0.0.0.0:49155        0.0.0.0:0            LISTENING        524      
services.exe
TCP      0.0.0.0:49156        0.0.0.0:0            LISTENING        532      
lsass.exe
TCP      0.0.0.0:49160        0.0.0.0:0            LISTENING        0         
w+? w+? w+?(w+?
TCP      0.0.0.0:49184        0.0.0.0:0            LISTENING        0        
??脸?脸?????
UDP      172.16.237.155:68    *:*                                   764      
svchost.exe
UDP      0.0.0.0:123          *:*                                   1088     
svchost.exe
UDP      169.254.53.234:137   *:*                                   4        
System
UDP      169.254.53.234:138   *:*                                   4        
System
UDP      254.128.0.0:1900     *:*                                   2192     
svchost.exe
UDP      0.0.0.0:3702         *:*                                   1088     
svchost.exe
UDP      254.128.0.0:50046    *:*                                   2192     
svchost.exe
UDP      0.0.0.0:50047        *:*                                   2192     
svchost.exe
UDP      169.254.53.234:50048 *:*                                   2192     
svchost.exe
UDP      127.0.0.1:50049      *:*                                   2192     
svchost.exe
UDP      0.0.0.0:51971        *:*                                   1088     
svchost.exe
UDP      0.0.0.0:51972        *:*                                   1088     
svchost.exe
UDP      0.0.0.0:54170        *:*                                   2192     
svchost.exe
UDP      0.0.0.0:54171        *:*                                   2192     
svchost.exe
UDP      0.0.0.0:59787        *:*                                   1088     
svchost.exe
UDP      0.0.0.0:59788        *:*                                   1088     
svchost.exe

Original comment by michael.hale@gmail.com on 29 Nov 2010 at 6:24

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 21 Jan 2011 at 9:04

• Added labels: Milestone-Release1.4

[GoogleCodeExporter]

Made some good breakthroughs today, should be done by week's end.

Original comment by michael.hale@gmail.com on 25 Jan 2011 at 4:39

[GoogleCodeExporter]

This issue was closed by revision r647.

Original comment by mike.auty@gmail.com on 31 Jan 2011 at 11:16

• Changed state: Fixed

[GoogleCodeExporter]

Ok, I just checked these in.  Netscan seems to work fine, although netstat 
didn't return me any results for a win7 dump on the Win7SP0x86 profile, so it 
might be worth people checking what I added in case there's an issue?

Also, we should try to either produce similar output for older profiles, or 
clearly indicate which plugins work with which profiles.  This will become even 
more important when linux profiles hit, so I'm going to create a new bug (and 
critically *not* blocking on 1.4, although this particular instance should 
probably be solved before we release).

Original comment by mike.auty@gmail.com on 31 Jan 2011 at 11:20

[GoogleCodeExporter]

Sorry for the bugspam, but better to get this right now than later once it's 
more in use.

Original comment by mike.auty@gmail.com on 4 Feb 2011 at 9:34

• Added labels: Milestone-1.4.x
• Removed labels: Milestone-Release1.4