networking plugins need some work on x64

[GoogleCodeExporter]

I'm just creating an issue so we don't forgot to fix these plugins for XP/2k3 
x64.  We need to find the symbol offsets and create new structs most likely.

Original issue reported on code.google.com by jamie.l...@gmail.com on 24 Jan 2012 at 7:28

[GoogleCodeExporter]

Issue 209 has been merged into this issue.

Original comment by mike.auty@gmail.com on 12 Feb 2012 at 9:01

[GoogleCodeExporter]

We also need to include windows 7 in there, and we've got people starting to 
try out trunk running into this...

Original comment by mike.auty@gmail.com on 12 Feb 2012 at 9:02

• Added labels: Milestone-2.1.x, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Actually for systems Vista+ they should be using netscan, not any of these 
plugins ;-)

Original comment by jamie.l...@gmail.com on 14 Feb 2012 at 12:31

[GoogleCodeExporter]

Few things regarding this:

* Gleeda's right technically for Win 7 the one network-related plugin is 
netscan. Although netscan has been ported to x64 there may be some issues on 
Vista x64 so we might as well include netscan for x64 in this issue (AW and I 
are aware of this and will be spending some time on it shortly)

* If we don't get to the whitelist/blacklist plugins before 2.1 we should 
remember to at least add statements to connections/connscan/sockets/sockscan to 
back off >= vista systems and to netscan to back off < vista systems (but there 
is already an issue for this so its just duplication here...but a good 
reminder).

Original comment by michael.hale@gmail.com on 14 Feb 2012 at 2:57

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 26 Mar 2012 at 1:04

• Changed title: networking plugins need some work on x64

[GoogleCodeExporter]

Ok, so I recently added some plugin whitelisting/blacklisting code.  At the 
moment it just hides the plugins from --help (or shows them with -v), but 
doesn't actually prohibit the plugin from running.  I can add in stronger 
blocks, but it's the kind of thing I can see irritating people if they really 
know what they're doing and have a situation where it would all work if only we 
weren't stopping them.  How do people want to handle this?

Original comment by mike.auty@gmail.com on 6 May 2012 at 11:37

[GoogleCodeExporter]

Hey Mike, 

I think hiding them from --help is a good start. I think whether we add 
stronger blocks depends on the plugin. For example using netscan on xp/2003 
will never work, even if you know what you're doing. Likewise, 
connscan/connections/sockscan/sockets will never work on 2008/vista/7. So those 
are perfectly fine to block strongly. We might want to make a list somewhere of 
any plugins that don't work on various profiles (something like the OS Support 
column of http://code.google.com/p/volatility/wiki/FeaturesByPlugin but that 
probably needs updating itself) which could make it easier to decide per plugin 
what is the best choice. 

Also here's a patch that fixes connections, connscan, sockets, and sockscan on 
windows 2003 sp1 and sp2 x64. I'll talk with Gleeda tomorrow about testing it 
on some of her images, but it works on mine so its a step in the right 
direction for closing this issue. 

Support for xp x64 (same as 2003 sp0 x64) will come in a separate patch, as 
will any updates needed for vista, 2008, and 7 to the netscan plugin. 

Original comment by michael.hale@gmail.com on 9 May 2012 at 3:00

Attachments:

• volatility_2003_sp1_sp2_x64.patch

[GoogleCodeExporter]

Oh I forgot to mention, if Gleeda or anyone else gets to try this patch and it 
doesn't work, please moddump your tcpip.sys and send it to me (or if you have 
access to the disk of the system, send the real tcpip.sys from 
c:\windows\system32\drivers). -Thanks

Original comment by michael.hale@gmail.com on 9 May 2012 at 3:11

[GoogleCodeExporter]

After some more testing by Gleeda, which resulted in us adding support for one 
more tcpip.sys module from win2003 x64 (thanks Gleeda!), this patch has been 
committed. 

Note: one particular win2003sp2x64 we've seen has a 32-bit tcpip.sys module 
loaded. thus the _AddrObjTable and _TCBTable symbols are 32-bit pointers, but 
our code in network.py uses the 'address' type which for the 64-bit profile 
will be a 64-bit
value. until we have a way of saying "use a 64-bit profile, but for this 
particular plugin, an address should be 32-bits" then the list walking network 
plugins (sockets and connections) will fail. also since the 32-bit tcpip.sys 
structures are going to differ in size, the connscan and sockscan will find the 
right pools but print bad data for several members. 

Original comment by michael.hale@gmail.com on 9 May 2012 at 6:12

[GoogleCodeExporter]

The netscan command should work on vista/2008/7 all service packs, x86 and x64. 
I've built an alternate method of finding connections based on tcpip.sys 
partition tables and hash buckets (the way the OS enumerates connections when 
you use netstat), but the netscan fixes should suffice for closing this issue. 

Let me know if you have questions or issues using the plugins ;-)

Original comment by michael.hale@gmail.com on 18 May 2012 at 10:49

• Changed state: Fixed