Jump to content
  • Advertisement
Sign in to follow this  
Bow_vernon

Anyway to list all open sockets in the computer?

This topic is 2642 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm back to learning network programming again, and have reread the winsock manual. But still, I got some questions in mind:
- is there anyway to list all open sockets in the computer? (I know there is a program that lists all open port, and netstat also does that. But what I want is to list open sockets)
- is there anyway to get access to that open sockets? to peek what message is in the buffer of that socket? or do anything else?
- what is exactly a raw socket? I often hear tutorials about packet sniffing use raw sockets. Is there a good book about raw socket? all I got is about winsock and winsock. And only list the stream socket and datagram socket :(

I will really really appreciate your help. I've been banging my heads to the keyboard cause I've been heavily confused and can't find a way to solve the fore mentioned problems.

Thank you :D

Share this post


Link to post
Share on other sites
Advertisement

I'm back to learning network programming again, and have reread the winsock manual. But still, I got some questions in mind:
- is there anyway to list all open sockets in the computer? (I know there is a program that lists all open port, and netstat also does that. But what I want is to list open sockets)
- is there anyway to get access to that open sockets? to peek what message is in the buffer of that socket? or do anything else?
- what is exactly a raw socket? I often hear tutorials about packet sniffing use raw sockets. Is there a good book about raw socket? all I got is about winsock and winsock. And only list the stream socket and datagram socket :(

I will really really appreciate your help. I've been banging my heads to the keyboard cause I've been heavily confused and can't find a way to solve the fore mentioned problems.

Thank you :D


1) Under UNIX, I know you can look at all open file descriptors for each process, either inside /proc, or using "lsof." I don't know what the similar tool/API for Windows is to list all open handles, but I believe such a tool/API exists. You may need to look at the NT kernel interface (rather than Win32) to get to it, though.

2) The only way to get access to an open handle is to either be in a process that has the handle open (so, using DLL injection or similar), or being in the kernel (such as being a device driver) and walk the undocumented data structures that keep track of handles.

3) A raw socket is like a datagram socket, but it will give you the packet as seen on the link layer. Thus, it's a socket that reads from (and potentially writes to) your network card directly, rather than any higher-level abstraction like an IP network stack. Open it with SOCK_RAW. You may want to Google for that constant to find more tutorials.

Share this post


Link to post
Share on other sites
Wow hplus, thanks for the answer :D

BTW I got some follow up questions :

1. how can two programs not crash/getting mixed up when they are connect()-ed to the same address (same address same destination port)? I open two browser, all going to the same address. no error/crash. is it because each socket has different "source port"?

2. it's from your answer #2. assume I successfully dll-inject the target program. How can I get the socket handle? by "hooking" the send()/recv() call and get the socket handle from there? or...what?

3. I wrote a packet sniffer using winsock raw socket. I created RAW socket, bind it to port 0, call setsockopt with IP_HDRINCL flag. then call recvfrom() indefinitely. and it catches ALL incoming packet. I was surprised. now what will happen if I call sendto() instead? can I "forge" a packet (build a packet by filling the IP header, TCP header, data) and call sendto() to make it looks as if another program (IRC app) was sending it (instead of my program)?

4. I know when I call send()/sendto() the data isn't sent directly. Instead, they are going to the network buffer first. But is it one network buffer "shared" by all socket or is it one buffer per socket? and is it only one buffer for incoming and outgoing packets or is it one buffer for incoming and one for outgoing?

Duh, sorry if I ask too many questions. I really don't know where else to look. And google seems to hate me x( so I came here. I thank you for any attempt to enlight my n00bness. I really like to learn but being in a third world country could make you stupid enough :P

Thanks

Bow Vernon

Share this post


Link to post
Share on other sites

1. how can two programs not crash/getting mixed up when they are connect()-ed to the same address (same address same destination port)? I open two browser, all going to the same address. no error/crash. is it because each socket has different "source port"?


When TCP accept()s a socket on port 80 (for example), it creates a new socket that does the communication. So server will be talking to a different socket, not the one doing that accept()s connections. These sockets are unique on server and are not seen by client who only sees port 80.

UDP doesn't use connections so all traffic is done over exactly the same socket and applications need to fill in or flip the sender/destination fields.

2. it's from your answer #2. assume I successfully dll-inject the target program. How can I get the socket handle? by "hooking" the send()/recv() call and get the socket handle from there? or...what?[/quote]Native applications are just blobs, so it's an exercise in searching the memory image. With languages that support reflection things are simpler, just walk to application to find socket proxy.

can I "forge" a packet (build a packet by filling the IP header, TCP header, data) and call sendto() to make it looks as if another program (IRC app) was sending it (instead of my program)?[/quote]
Yes, in theory. Though I seem to recall Windows disabled ability to send raw sockets. Network packets however have no context or other information - if you somehow put bytes onto network card's output buffer, they will get sent and internet won't be any wiser. After all, networking stack isn't magical, at some point it needs to fill in this data itself, it's just a question of whether it exposes such functionality to userland.

Raw sockets were used for DDOS attacks, where attacker forges sender IP (which isn't used until it arrives on server) requesting TCP connection (by sending SYN packet). Since return address was faked it will never reply with SYNACK, resulting in timeout. But while waiting for timeout, server needs to keep track of the request, so by sending enough such requests, it would run out of resources. Since TCP SYN packets are small, such attack didn't require much bandwidth and could be performed by single machine. It's no longer viable for OS network stacks, but would likely still work against many UDP servers which establish connections.

4. I know when I call send()/sendto() the data isn't sent directly. Instead, they are going to the network buffer first. But is it one network buffer "shared" by all socket or is it one buffer per socket? and is it only one buffer for incoming and outgoing packets or is it one buffer for incoming and one for outgoing?[/quote]
Each socket has two buffers, incoming and outgoing. Network cards typically have their own buffers as well to avoid interrupt storms, obviously one or two buffers in the range of kilobytes (per card). Higher end cards might have more complicated buffering since they can often perform various checksum calculations or additional services.

Share this post


Link to post
Share on other sites

1. how can two programs not crash/getting mixed up when they are connect()-ed to the same address (same address same destination port)? I open two browser, all going to the same address. no error/crash. is it because each socket has different "source port"?


A TCP connection is uniquely identified by a quad-tuple: Source IP, Source Port, Destination IP, Destination Port.


2. it's from your answer #2. assume I successfully dll-inject the target program. How can I get the socket handle? by "hooking" the send()/recv() call and get the socket handle from there? or...what?
[/quote]

I imagine you'd hook the "socket()" and "closesocket()" calls so you can keep track of all open sockets for that process, but there really is a variety of ways this could be done.


3. I wrote a packet sniffer using winsock raw socket. I created RAW socket, bind it to port 0, call setsockopt with IP_HDRINCL flag. then call recvfrom() indefinitely. and it catches ALL incoming packet. I was surprised. now what will happen if I call sendto() instead? can I "forge" a packet (build a packet by filling the IP header, TCP header, data) and call sendto() to make it looks as if another program (IRC app) was sending it (instead of my program)?
[/quote]

On the wire, nobody knows who actually sent the data. The packet is the packet, and will be treated according to the protocol. That being said, the TCP protocol uses a sequence number scheme that makes undetected long-term hi-jacking or injecting harder than what you suggest -- you'd need to keep capturing each packet going both ways and re-writing them if you want to "hide" yourself. Which would be a terrible thing to do -- the user should always know what you're doing.


4. I know when I call send()/sendto() the data isn't sent directly. Instead, they are going to the network buffer first. But is it one network buffer "shared" by all socket or is it one buffer per socket? and is it only one buffer for incoming and outgoing packets or is it one buffer for incoming and one for outgoing?
[/quote]

Typically, there are two buffers. One buffer for the network card (which generally is just a big ring buffer), and one buffer per socket in the network stack. Packets get removed from the incoming card buffer, decoded, and put into the socket receive buffer, and vice versa. Some hardware can do smart DMA things and avoid at least one of these buffers, though.


Share this post


Link to post
Share on other sites

while waiting for timeout, server needs to keep track of the request, so by sending enough such requests, it would run out of resources


Google "syn cookies" sometime for a solution to this attack (implemented in the Linux kernel).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!