Closed GoogleCodeExporter closed 8 years ago
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
Issue 7 has been merged into this issue.
Original comment by mike.auty@gmail.com
on 18 Aug 2010 at 10:35
Original comment by mike.auty@gmail.com
on 18 Aug 2010 at 10:46
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
Issue 16 has been merged into this issue.
Original comment by mike.auty@gmail.com
on 26 Aug 2010 at 11:18
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
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
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
Original comment by mike.auty@gmail.com
on 21 Jan 2011 at 9:04
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
This issue was closed by revision r647.
Original comment by mike.auty@gmail.com
on 31 Jan 2011 at 11:16
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
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
Original issue reported on code.google.com by
atc...@gmail.com
on 18 Aug 2010 at 1:34