search

yojota / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

[profile offsets per build/revision number] was: Process Owner Info not found for TCP_ENDPOINT scan output on Vista (netscan) #174

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Running netscan plugin on Vista SP2 dump
2.
3.

What is the expected output? What do you see instead?
PID, Process name is not found TCPEndPoint scan output. However that 
information is present in Listener, UDP scan output.

0xcf7c0de8 TCPv4    0.0.0.0:61618                  0.0.0.0:0            
LISTENING        2016     spoolsv.exe    
0x1cedd88  TCPv4    0.0.0.0:57883                  0.0.0.0:443          CLOSED  
         -------- -------------- 
0x14e85e08 TCPv4    10.130.179.251:64286           10.177.226.18:1533   
ESTABLISHED      -------- -------------- 

What version of the product are you using? On what operating system?
using volatility 2 standalone python precompiled version on vista sp2.

Please provide any additional information below.

Original issue reported on code.google.com by welcome....@gmail.com on 3 Jan 2012 at 5:59

GoogleCodeExporter commented 8 years ago 
Hi,
I see that netscan plugin prints using p.UniqueProcessId. However it was casted 
as Pointer. I suspect it could be the problem (i may be wrong thought it would 
be helpful).

'_EPROCESS' : [ 0x270, {
   <snip>
    'RundownProtect' : [ 0x98, ['_EX_RUNDOWN_REF']],
    'UniqueProcessId' : [ 0x9c, ['pointer', ['void']]],
    'ActiveProcessLinks' : [ 0xa0, ['_LIST_ENTRY']],

Original comment by welcome....@gmail.com on 3 Jan 2012 at 6:27

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Hi there,

The problem may simply be that it isn't output, but it's also possible that 
that information isn't easily available given the type of scan that TCPEndPoint 
does versus what UDP scan does.

MHL, any idea about this one?

Original comment by mike.auty@gmail.com on 3 Jan 2012 at 9:33

GoogleCodeExporter commented 8 years ago 
Sure, as you guessed, the netscan plugin scans for several different structures:

1) _TCP_LISTENER for listening TCP sockets
2) _TCP_ENDPOINT for TCP endpoints 
3) _UDP_ENDPOINT for listening UDP sockets

Each of these structures has an Owner member which points to an _EPROCESS. See 
the file:

http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/overl
ays/windows/tcpip_vtypes.py

So the fact that you see process names and pids for _TCP_LISTENER and 
_UDP_LISTENER doesn't necessarily mean you'll always see process names and pids 
for _TCP_ENDPOINT since they're totally different structures. 

That being said, there are 2 likely reasons the _TCP_ENDPOINT process info is 
missing: 

1) We've got the offset incorrect. It should be at offset 0x160 as shown below. 

tcpip_vtypes_vista = {
    '_TCP_ENDPOINT': [ None, { # TcpE
        'Owner' : [ 0x160, ['pointer', ['_EPROCESS']]],

I doubt this is the reason, since I see process info on some of my test Vista 
SP2 dumps. However, I can verify if you extract the tcpip.sys module from your 
memory dump and attach it here. Use the following command:

$ vol.py -f mem.img moddump --dump-dir outdir --regex tcpip --ignore-case 
--profile=VistaSP2x86

2) The Owner _EPROCESS field is invalidated (zero-ed out or otherwise 
overwritten) in the _TCP_ENDPOINT structures. This can happen since netscan is 
basically scanning for any used *or* unused structures. 

Most likely its #2. Especially since once the the lines you pasted is in a 
CLOSED state and reports the remote endpoint is 0.0.0.0:443. In that case the 
Owner _EPROCESS is not the only field that's been cleared/overwritten - also 
the remote IP field (0.0.0.0). But the port is still visible (443).

Original comment by michael.hale@gmail.com on 3 Jan 2012 at 11:17

GoogleCodeExporter commented 8 years ago 
The process info is not shown for all entries listed by _TCP_ENDPOINT scan that 
includes ESTABLISHED, CLOSED_WAIT.Attaching the tcpip.sys, tcpipreg.sys drivers 
pulled from memory.

Original comment by welcome....@gmail.com on 4 Jan 2012 at 12:24

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks. 

On Win7SP0x86 tcpip.sys you see:

push    dword ptr [edi+174h]
call      ds:__imp__PsGetProcessId@4

The argument to PsGetProcessId is PEPROCESS, thus we know the Owner field is at 
offset 174h of the _TCP_ENDPOINT on this OS. 

On my VistaSP2x86 tcpip.sys (file version 6.0.6002.18005) you see this:

push    dword ptr [edi+160h]
call      ds:__imp__PsGetProcessId@4 

Since the offset is 160h, that's why you see the following in our code:

tcpip_vtypes_vista = {
    '_TCP_ENDPOINT': [ None, { # TcpE
        'Owner' : [ 0x160, ['pointer', ['_EPROCESS']]],

However, on your tcpip.sys which is, as you say, also from a VistaSP2x86 
machine, it shows:

push    dword ptr [edi+164h]
call      ds:__imp__PsGetProcessId@4 

So the Owner is at offset 164h on your system. AFAIK this is the only instance 
I've ever seen where the structure offsets differ on the same OS version and 
service pack. 

If you have access to the tcpip.sys from disk, can you right click Properties 
and show the Build number? Or even better if you have access to the command 
shell, can you type 'systeminfo' and then paste the following fields (for 
example):

C:\> systeminfo 
OS Version:                6.1.7600 N/A Build 7600
OS Build Type:             Multiprocessor Free
System Model:              VMware Virtual Platform
System Type:               X86-based PC

Original comment by michael.hale@gmail.com on 4 Jan 2012 at 3:21

GoogleCodeExporter commented 8 years ago 
OS Name:                   Microsoftr Windows VistaT Enterprise
OS Version:                6.0.6002 Service Pack 2 Build 6002
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Member Workstation
OS Build Type:             Multiprocessor Free

tcpip.sys version is 6.0.6002.18519

Original comment by welcome....@gmail.com on 4 Jan 2012 at 5:53

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Hi, I use volatility.exe which is precompiled version, can you help me how can 
i patch tcpip_vtypes.py

Original comment by welcome....@gmail.com on 4 Jan 2012 at 6:01

GoogleCodeExporter commented 8 years ago 
I don't think modifying the source files is possible with the precompiled 
version. You'd have to catch tcpip_vtypes.py after its extracted by the exe and 
before its used. Some type of hook? If anyone knows its mike.auty, but I'd 
recommend using the "Volatility 2.0 Windows Module Installer" or "Volatility 
2.0 Source Code" if you need to patch files. 

Hopefully this will be fixed in time for the release of 2.1 and there will be a 
precompiled version with the patch already integrated. 

To devs: what we have here is a case where the structures are different on two 
builds of tcpip.sys (6.0.6002.18005 and 6.0.6002.18519), but both are from the 
same OS architecture and service pack.

Original comment by michael.hale@gmail.com on 6 Jan 2012 at 1:37

GoogleCodeExporter commented 8 years ago 
hrmmm this might be possible.  I think you could write another plugin that 
inherits netscan and updates the tcpip types.  However, it seems like a lot 
more work than just installing the source...

Original comment by jamie.l...@gmail.com on 6 Jan 2012 at 1:40

GoogleCodeExporter commented 8 years ago 
So Jamie's got it spot on, that's probably the easiest way to make the change.  
Since we've opted for using pyinstaller it's possible to modify the running 
code for the duration of a single run, but it's a big pain and probably not 
worthwhile...

Either install the source, or if you don't want a full copy of python then 
you'll have to write a plugin that inherits and overrides appropriately...

Original comment by mike.auty@gmail.com on 6 Jan 2012 at 9:43

GoogleCodeExporter commented 8 years ago 
Is it possible to provide the doc for compiling the patched code with python to 
executable volatility.exe . I am looking at this compiled one as i wanted it to 
be part of Incident Response kit, easy and portable.
Thanks in advance.

Original comment by welcome....@gmail.com on 9 Jan 2012 at 8:04

GoogleCodeExporter commented 8 years ago 
You should use the pyinstaller manual and the provided pyinstaller.spec file in 
the source of the volatility directory, after making the necessary changes.  
I'd strongly recommend using volatility-2.0 as your base, since it's much 
better tested than the current trunk.

You'll also need to make sure you've installed pycrypto, distorm3 and a few 
other external dependencies...

Original comment by mike.auty@gmail.com on 21 Feb 2012 at 9:35

GoogleCodeExporter commented 8 years ago 
Is there any further progress to be made on this issue, or can we close it off 
please?

Original comment by mike.auty@gmail.com on 15 May 2012 at 10:59

GoogleCodeExporter commented 8 years ago 
I'll take ownership of this one, since I'm already working on Issue #194 
(netscan for vista/2008/7 on x64). If I can fix it in any way, I will, but if 
not, we might want to keep it open as low priority (since its not frequent and 
shouldn't block the 2.1 release). Right now each profile can have a major, 
minor, build, and memory model, but this is an example of a problem where we 
might need to associate vtypes with a particular driver (because the vtypes 
differ between 6.0.6002.18005 and 6.0.6002.18519 although they're both vista 
sp2 x86).

Original comment by michael.hale@gmail.com on 16 May 2012 at 4:30

GoogleCodeExporter commented 8 years ago 
Here's a little more info. 

6.0.6002.18272
Microsoft Windows Server 2008 Standard
6.0.6002 Service Pack 2 Build 6002
push    dword ptr [edi+164h]
call      ds:__imp__PsGetProcessId@4 

6.0.6002.18519
Microsoft Windows VistaT Enterprise
6.0.6002 Service Pack 2 Build 6002
push    dword ptr [edi+164h]
call      ds:__imp__PsGetProcessId@4 

6.0.6002.18005
Microsoft Windows Server 2008 Standard (also seen Microsoft Windows VistaT 
Ultimate)
6.0.6002 Service Pack 2 Build 6002
push    dword ptr [edi+160h]
call      ds:__imp__PsGetProcessId@4 

As you can see, regardless of whether the OS identifies itself as "Server 2008" 
or "Vista" if the revision number > 18005 then the offset is 0x164. If the 
revision number <= 18005 then the offset is 0x160. I don't have tcpip.sys 
binaries for every revision, so I'm not sure if 18005 is exactly where the line 
is drawn. 

Unfortunately until we can choose vtype offsets based on revision number (in 
addition to the major, minor, build, and memory model which is already 
possible), then there's not a good way to handle this. I'm not sure we should 
close this issue since currently we won't print process information for 
VistaSP2x86/Win2008SP2x86 whose revision numbers are > 18005. However, we might 
have to defer to fixing it later. In the meantime, manish, you'll have to use a 
version of volatility where you can change the vtype offset (and if needed 
build your own exe from it).

Original comment by michael.hale@gmail.com on 18 May 2012 at 9:08

GoogleCodeExporter commented 8 years ago

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 6:21

GoogleCodeExporter commented 8 years ago 
Issue 428 has been merged into this issue.

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 6:22

GoogleCodeExporter commented 8 years ago 
Issue 484 has been merged into this issue.

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 6:25

GoogleCodeExporter commented 8 years ago

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 9:19

GoogleCodeExporter commented 8 years ago

Original comment by mike.auty@gmail.com on 18 Feb 2015 at 6:53