How to get an application listening ports with windows c++ api - winapi

As show in Windows Resource Monitor:
I want to analyse network traffic of an application, but I dont know the Windows API. I used scapy or wireshark, but I don't know what data packages are this application.
So, I want to get the listening port first. But I don't know the API.

You can use GetTcpTable2() or GetExtendedTcpTable() to enumerate open TCP ports, determining which ports are listeners, and get each one's owning process.
You can use GetExtendedUdpTable() to enumerate open UDP ports and get each one's owning process.

Related

Developing a Mac OSX Network Driver for a Serial Port AT Command Based Modem

First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)

Is there a way to monitor what process sends UDP packets (source/dest IP and port) in Windows?

I discovered almost accidentally that my machine was sending and receiving UDP packets to a machine in Poland. Not that I have any problem with Poland, I just don't know why my laptop has the need to communicate with a server there. Reverse DNS shows just the ISP providing the address to some end user. Using Wireshark, I can monitor the messages, which were indecipherable as they were probably encrypted. All packets sent from my machine had the same source port, so clearly the application that sent them opened this UDP socket to use it. I am searching for ways to:
1) enumerate all current sockets open in the system, including the process that created it and, for both TCP and UDP, what ports and addresses they are current bound to.
2) because applications can open these sockets, use them, and close them right away, I would love to find (or perhaps even write) a program that once started would somehow get notification each time a socket gets created, or really more importantly when bound to a source and/or destination address and port. For UDP, I would love to also be able to monitor/keep track of the destination IP addresses and ports that socket has sent messages to.
I don't want to monitor the traffic itself, I have Wireshark if I want to view the traffic. I want to be able to then cross reference to discover what application is generating the packets. I want to know if it is from a process I trust, or if it is something I need to investigate further.
Does anybody know of any applications (for the Windows platform) that can do this? If not, any ideas about a .NET or Windows API that provides this capability, should I want to write it myself?
Edit:
After further research - looks like the APIs to use are GetExtendedUdpTable and GetExtendedTcpTable, CodeProject.com has some samples wrapping these in .NET (see http://www.codeproject.com/Articles/14423/Getting-the-active-TCP-UDP-connections-using-the-G). So a combination of this API and some sniffer code would be needed to monitor and keep track of what hosts at what ports using what protocol any particular application on your machine is talking to. If I ever get some free time, I'll consider creating this, if you know of an app that does all this, please let me know.
Try SysInternals TCPView. Despite its name, it handles UDP as well.
netstat -b to enumerate all ports along with the process names.
You can try using SysInternals' Process MOnitor (ProcMon.exe or ProcMon64.exe).
It allows for filtering of Processes by "UDP Send" Operation - and provides detailed UDP Connection data, including source and destination addresses(IP) and ports etc.

Mapping Port to PID for Transient Windows TCP Connections

I am trying to reverse engineer a third-party TCP client / server Windows XP, SP 3 app for which I have no source available. My main line of attack is to use WireShark to capture TCP traffic.
When I issue a certain GUI command on the client side, the client creates a TCP connection to the server, sends some data, and tears down the connection. The server port is 1234, and the client port is assigned by the OS and therefore varies.
WireShark is showing that the message corresponding to the GUI command I issued gets sent twice. The two messages bear a different source port, but they have the same destination port (1234, as mentioned previosuly).
The client side actually consists of several processes, and I would like to determine which processes are sending these messages. These processes are long-lived, so their PIDs are stable and known. However, the TCP connections involved are transient, lasting only a few milliseconds or so. Though I've captured the client-side port numbers in WireShark and though I know all of the PIDs involved, the fact the connections are transient makes it difficult to determine which PID opened the port. (If the connections were long-lived, I could use netstat to map port numbers to PIDs.) Does anybody have any suggestions on how I can determine which processes are creating these transient connections?
I can think of two things:
Try sysinternals' tcpview program. It gives a detailed listing of all tcp connections opened by all the processes in the system. If a process creates connections, you will be able to see them flash (both connect and disconnect are flashed) in tcpview and you will know which processes to start looking into.
Try running the binary under a debugger. Windbg supports multi-process debugging (so does visual studio I think). You may have only export symbols to work with but that should still work for calls made to system dlls. Try breaking on any suspected windows APIs you know will be called by the process to create the connections. MSDN should have the relevant dlls for most system APIs documented.
Start here... post a follow-up if you get stuck again.
I ended up creating a batch file that runs netstat in a tight loop and appends its output to a text file. I ran this batch file while running the system, and by combing through all of the netstat dumps, I was able to find a dump that contained the PIDs associated with the ports.

How to capture network traffic application wise using winpcap?

I have to make a windows based application for which captures network traffic per application where some of running application uses same port number for sending and receiving the packets.
I have used winpcap and successfully captured and filtered them port wise and destination wise but I dont know how to capture them application wise that means how to know application information from ip packets.
Is only winpcap can solve the problem or some other api's or library shoud be used.
Can we get the application information from which packet is generated from packet header?
**
Can anyone give me example that uses iphlpapi and winpcap in vc++ for capturing network traffic per application.
**
I don't think this is possible with winpcap.
Take a look at Windows Filtering Platform. It's not advanced at all.If you look in the samples you can find one which does exactly what you want.
winpcap doesn't have a good way to tell what process is sending what data.
But windows does.
try using
netstat -a -o
netstat is a program that tells you what ports are being used on your terminal.
-a switch says, "show me all the ports"
-o switch says, "show me the pid of the processes using this port"
you can't see what port your processes are sending on, but you can see what ports are receving on for udp packets.
for tcp packets you'll see all the info you could want, includeing the remote connections ip address.

How to forward the TCP/IP traffic of a process in Windows XP?

alt text http://img440.imageshack.us/img440/6950/problemyd1.png
(The curly lines with dots represent a network route.)
Having a process called "foo.exe", is there a way to forward everything it communicates over TCP/IP to a forwarding proxy located elsewhere? This forwarding should not reflect to other processes.
Another question: if there are multiple network adapters, is it possible to force a process to use one specific adapter.
Since in this example the targethost.com is known, I could just edit "system32\drivers\etc\hosts" to map targethost.com's IP to localhost, where on port 8765 would be the first forwarder waiting for an incoming connection and pass everything forward to proxy.foo.com. I was wondering if there's a more elegant way of doing this.
This is not for malware, I'm doing some network testing with my complex home network. Thank you for warning us.
Some free software for this would be perfect, alternatively a code idea (native or .net). Thank you very much.
It's not too hard if you make your own computer a firewall, then your app connects to a port on your own computer, and that port is forwarded to both the original destination and logged or forwarded on to your spying computer.
Alternatively you can make your other computer the firwall and have it log/forward the info.
Finally you could use a sniffer.
SocksCap will probably do the job (if you're OK with establishing a SOCKS proxy at proxy.foo.com).
You could hook into the TCP stack, for example, by using the Windows Filtering Platform or its predecessors, or you could substitute the network libraries/calls of that particular process.

Resources