[Victor43]

I'm not sure but would the source code for TCPView the data itself (process name, port number, IP address and so on) that is shown within the TCPView GUI be located in NetstatpSource.zip file ? I have downloaded the file sysinternals_site_rip.7z so this .7z file should contain the source code zipped in the NetstatpSource.zip file yes ? I want to take a look at how the actual process names are retrieved (which API functions are used) along with some of the other data shown in the TCPView window.

This is what TcpView.html (taken from sysinternals_site_rip.7z) says about Netstatp

"Wonder how TCPView works? Netstatp is a program with source that demonstrates how to program some of TCPView's functionality. It shows how to use IP Helper interfaces, documented in MSDN, to obtain a list of TCP/IP endpoints. Note, however, that netstatp doesn't show process names on NT 4 and Win2K like TCPView and TCPVCon."

Thanks

[Brock]

Yes, that is the code used in TCPView, but not all of it as it's missing some modules and from what I see supported < XP but doesn't show the code to handle process names in Windows 2000 and NT. Anyhow, on XP+ it uses the IP Helper APIs GetExtendedTcpTable and GetExtendedUDPTable to list connections for both transport layer protocols (TCP and UDP). Each table row it returns will contain the local and remote port, local and remote IP address, connection state and process id of the process which initiated the connection.

The process id field is not available for the non-extended GetTcp/UdpTable APIs that pre-date XP SP2. In order to determine the process id in earlier OSs (NT/2K) it likely used a driver for this or fetched the system handle table, queried the handle names and checks for \Device\Tcp and \Device\UDP then requested the TDI connection information, the process id is already in the handle table. After you have the process id you simply map this to the process name using the ToolHelp API. That's it

[Victor43]

Yes, that is the code used in TCPView, but not all of it as it's missing some modules and from what I see supported < XP but doesn't show the code to handle process names in Windows 2000 and NT. Anyhow, on XP+ it uses the IP Helper APIs GetExtendedTcpTable and GetExtendedUDPTable to list connections for both transport layer protocols (TCP and UDP). Each table row it returns will contain the local and remote port, local and remote IP address, connection state and process id of the process which initiated the connection.

The process id field is not available for the non-extended GetTcp/UdpTable APIs that pre-date XP SP2. In order to determine the process id in earlier OSs (NT/2K) it likely used a driver for this or fetched the system handle table, queried the handle names and checks for \Device\Tcp and \Device\UDP then requested the TDI connection information, the process id is already in the handle table. After you have the process id you simply map this to the process name using the ToolHelp API. That's it

Thanks for the update. I'm interested in a similar process but one makes use network stack (a kernel mode driver) to record what TCP data each application process is sending or receiving. These API's I imagine are only available from a user mode application yes or is there an equivalent set of API's that are available to kernel mode drivers ?

https://msdn.microsoft.com/en-us/librar ... s.85).aspx

[Brock]

GetExtendedTcp/UdpTable() is usermode API only. There is a subset of IP helper APIs for kernel mode drivers though, see here https://msdn.microsoft.com/en-us/window ... /ip-helper - you might also look into NDIS, TDI (supposedly phased out since Vista and no longer supported by MS as they push for Windows Filtering Platform), WFP and WSK (Winsock Kernel). Depending on what you're trying to accomplish these interfaces and platforms can be useful to socket programmers and for network data analysis.

[Victor43]

GetExtendedTcp/UdpTable() is usermode API only. There is a subset of IP helper APIs for kernel mode drivers though, see here https://msdn.microsoft.com/en-us/window ... /ip-helper - you might also look into NDIS, TDI (supposedly phased out since Vista and no longer supported by MS as they push for Windows Filtering Platform), WFP and WSK (Winsock Kernel). Depending on what you're trying to accomplish these interfaces and platforms can be useful to socket programmers and for network data analysis.

Brock thanks. Two things first TDI is no longer a development option under WDK 8.1/10 yes so no is developing TDI drivers ? Secondly and more importantly this is I want to do:

I want to be be able to record/log which process (whether it is a user mode application such as Outlook.exe or Firefox.exe or its a kernel mode driver or a user mode driver) that are making use of the network TCP stack that is sending out TCP data and or vice versa. I need to isolate a single data packet that would be even better to the exact process that sent it or received it locally. I believe I can do this all from a kernel mode driver possibly as you have suggested from a NDIS layer yes ? Just to summarize I want to be able to record and log any process (user mode or kernel mode driver and this includes windows services as well) which makes use of any sort of TCP (DNS, DCHP, ICMP) )communications either receiving a single TCP data packet or sending it out. I might be rambling on but I want to be able to record or log that a process A.exe located in the memory space FFBFCDFFxxx - FFFFFFFFxxxx. has sent out a TCP data packet or has received a TCP data packet recording as much detail of the data packet. As long as data packets are being received and or sent out locally I want to keep track which process is doing this and where in memory is this process located.

Can this be done ?

[Brock]

Windows Filtering Platform (WFP) is what you want to be using. WFP is supported on Vista SP2+ and supports callout drivers as well as usermode API to filter and inspect network data. Microsoft designed WFP to replace NDIS, TDI, LSP etc. It's why I mentioned in my previous post that Microsoft is "pushing" WFP on developers in order to phase out legacy network interfaces. It's a robust and flexible framework for developers and much easier to work with imho

[Victor43]

Brock thanks again. I understand that Windows Filtering Platform (WFP) is what I should be using which I will be looking into. But the question I need answered is whether can I can map a TCP data to a process that is receiving or sending the data via a WFP driver ?

[Vrtule]

Yes, you can. You get notified when an application calls routines like bind, connect, listen or accept. At these cases, you also get information about the calling application (process ID and name). When servicing these notifications (you can actually block the operations if you wish) you may obtain the famous tuple (source address, source port, destination address, destination port, protocol) and associate the application information with it.

When you later receive notifications about transmitted or received packets, you can use the tuple to find corresponding process information. WFP does not provide these information in such cases.

You should be especially interested in so-called ALE layers because on these layres, the process information is available. Look at this page to see when exactly your driver would be triggered.
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

If your task is just monitoring, WFP is fine and quite straightforward thing. If you wish to do more, things get quite complicated and I personally prefer using WFP sample drivers as reference since WFP documentations seems to be misleading or quite vague in some cases.

[Victor43]

Yes, you can. You get notified when an application calls routines like bind, connect, listen or accept. At these cases, you also get information about the calling application (process ID and name). When servicing these notifications (you can actually block the operations if you wish) you may obtain the famous tuple (source address, source port, destination address, destination port, protocol) and associate the application information with it.

When you later receive notifications about transmitted or received packets, you can use the tuple to find corresponding process information. WFP does not provide these information in such cases.

You should be especially interested in so-called ALE layers because on these layers, the process information is available. Look at this page to see when exactly your driver would be triggered.
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

If your task is just monitoring, WFP is fine and quite straightforward thing. If you wish to do more, things get quite complicated and I personally prefer using WFP sample drivers as reference since WFP documentations seems to be misleading or quite vague in some cases.

Thank you Vrtule for the response. So just to understand correctly when an user mode application calls the connect function a WFP (filter) driver gets notified (sort of like a callback perhaps) and information such as you mentioned "information about the calling application (process ID and name)" becomes available in via the ALE layer yes ? What about the recv function call the actual data can I receive details of the data itself along with the process ID and name of the process that the data is associated to whether the data is being sent or received, the protocol being used, size of the data packet and anything else about "who" "what" and "where" all from the ALE layer ? You said it gets more complicated but is it doable without resorting to hacking, patching or special hooking (like hooking the SSDT) the Windows kernel or walking the TCP stack ? Is this what you're getting at being more complicated ?

Thank you

[Brock]

As Vrtule mentioned in his post, you can use ALE with WFP and identify things such as the process information you seek. It's a layer that makes it possible to identify the application associated with the network operation(s). Refer to WDK's WFP layered samples under \src\network\trans. "inspect" sample may be helpful for instance