as part of my project, I'm trying to send IP packets that contain HTTP requests to Google. I'm using Winpcap library and VC++. Currently, I have the TCP three-way handshaing packets done, but I'm stuck on sending the actual HTTP request packet after I send the TCP ACK packet. When I capture the packets using wireshark, this packet is marked "TCP segment of a Reassembled PDU". The protocol column is 'TCP' not 'HTTP' also. What's wrong? How would I send HTTP packets in this way?
You aren't necessarily doing anything wrong.
By default, Wireshark hands the TCP data to a higher level protocol handler - in this case, one that tries to reassemble entire HTTP requests and responses. It attaches the reassembled message to the final packet in the sequence, and labels the other packets with "TCP segment of a reassembled PDU":
You can disable this reassembly feature to examine the individual packets:
Edit -> Preferences -> Protocols -> TCP
Uncheck "Allow subdissector to reassemble TCP streams"
Why are you using WinPCap to send the packets? You should be using normal sockets instead. Better, use a socket library that implements the HTTP protocol for you, such as curl, or even Microsoft's own WinInet or WinHTTP APIs.
I would highly recommend that you learn the basis of the HTTP protocol before you try this if you're planning on extending this. Mess with doing raw sockets and throwing get requests; read some source code.
However, I wouldn't really see the point of pcap. You should be able to use the Wininet library if you don't want to have to code the actual socket:Wininet lib
However, if you're wanting to code raw sockets, I would go ahead and use winsocks. The difference between HTTP and TCP is hard for some to understand; HTTP is BASED on TCP, so they are technically all in the same, TCP is used for quite literally thousands of applications. Most of the connections on your computer are TCP.
If you're trying to intercept a connection as a MITM attack with a pcap program to send an HTTP request, I would probably learn some programming in Pcap. There are numerous tutorials for this, such as this one.
PS: Look up a winsocks tutorial as it's quite hard to understand for beginners. Also, winpcap isn't supported on all systems, and it can be (in some cases) a pain to install. It would honestly be better to use winsocks to do this. Wininet has much more support, and I (don't hold me on this) believe that all of the W2K+ builds all have wininet, so for compatability (which I don't really think is a problem for you) issues I would use wininet or winsocks.
Probably you are not finishing the request with \r\n twice.
If you send the GET / HTTP/1.0\r\n string, you will not receive any packets.
You must send this string: GET / HTTP/1.0\r\n\r\n.
Related
I need to write a proxy server in C language on Linux (Ubuntu 20.04). The purpose of this proxy server is as follows. There're illogical governmental barriers in accessing the free internet. Some are:
Name resolution: I ping telegram.org and many other sites which the government doesn't want me to access. I ask 8.8.8.8 to resolve the name, but they response of behalf of the server that the IP may be resolved to 10.10.34.35!
Let's concentrate on this one, because when this is solved many other problems will be solved too. For this, I need to setup such a configuration:
A server outside of my country is required. I prepared it. It's a VPS. Let's call it RS (Remote Server).
A local proxy server is required. Let's call it PS. PS runs on the local machine (client) and knows RS's IP. I need it to gather all requests going to be sent through the only NIC available on client, process them, scramble them, and send them to RS in a way to be hidden from the government.
The server-side program should be running on RS on a specific port to get the packet, unscramble it, and send it to the internet on behalf of the client. After receiving the response from the internet, it should send it back to the client via the PS.
PS will deliver the response to the client application which originates the request. Of course this happens after it will unscramble and will find the original response from the internet.
This is the design and some parts is remained gloomy for me. Since I'm not an expert in network programming context, I'm going to ask my questions in the parts I'm getting into trouble or are not clear for me.
Now, I'm in part 2. See whether I'm right. There're two types of sockets, a RAW socket and a stream socket. A RAW socket is opened this way:
socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
And a stream socket is opened this way:
socket(AF_INET, SOCK_STREAM, 0);
For RAW sockets, we use sockaddr_ll and for stream sockets we use sockaddr_in. May I use stream sockets between client applications and PS? I think not, because I need the whole RAW packet. I should know the protocol and maybe some other info of the packet, because the whole packet should be retrieved transparently in RS. For example, I should know whether it has been a ping packet (ICMP) or a web request (TCP). For this, I need to have packet header in PS. So I can't use a stream socket, because it doesn't contain the packet header. But until now, I've used RAW sockets for interfaces and have not written a proxy server to receive RAW packets. Is it possible? In another words, I've the following questions to go to next step:
Can a RAW socket be bound to localhost:port instead of an interface so that it may receive all low-level packets containing packet headers (RAW packets)?
I may define a proxy server for browser. But can I put the whole system behind the proxy server so that packets of other apps like PING may route automatically via it?
Do I really need RAW sockets in PS? Can't I change the design to suffice the data I got from the packets payload?
Maybe I'm wrong in some of the concepts and will appreciate your guidance.
Thank you
Can a RAW socket be bound to localhost:port instead of an interface so that it may receive all low-level packets containing packet headers (RAW packets)?
No, it doesn't make sense. Raw packets don't have port numbers so how would it know which socket to go to?
It looks like you are trying to write a VPN. You can do this on Linux by creating a fake network interface called a "tun interface". You create a tun interface, and whenever Linux tries to send a packet through the interface, instead of going to a network cable, it goes to your program! Then you can do whatever you like with the packet. Of course, it works both ways - you can send packets from your program back to Linux through the tun interface, and Linux will act like they just arrived on a network cable.
Then, you can set up your routing table so that all traffic goes to the tun interface, except for traffic to the VPN server ("RS"), which goes to your real ethernet/wifi interface. Otherwise you'd have an endless loop where your VPN program PS tried to send packets to RS but they just went back to PS.
There's something that bothers me: I'd like to distinguish between a packet coming from Youtube and a packet coming from Wikipedia: they both travel on HTTPS and they both come from the port 443.
Since they travel on HTTPS, their payload is not understandable and I can't do a full Deep Packet Inspection: I can only look at Ethernet, IP and TCP struct headers. I may look at the IP address source of both packets and see where they actually come from, but to know if they are from Youtube or Wikipedia I should already know the IP addresses of these two sites.
What I'm trying to figure out is a way to tell from a streaming over HTTP (like Youtube does) and a simple HTML transport (Wikipedia) without investigating the payload.
Edit 1: in a Wireshark session started during a reproducing video I got tons of packets. Maybe I should start looking at the timeout between packets coming from the same address.
If you are just interested in following the data stream in Wireshark you can use the TCP stream index, filter would be something like tcp.stream == 12
The stream index starts at zero with the first stream that wireshark encounters and increments for each new stream (persistent connection).
So two different streams between the same IPs would have two different numbers. For example a video stream might be 12 and an audio stream, between the same IP addresses, might be 13.
If you started the capture before the stream was initiated you'll be able to see the original traffic setting up the SSL connection (much of this is in clear text)
You may consider looking at the server certificate. It will tell you whether it's youtube (google) or facebook.
That would give you an idea whether SSL connection is to youtube, which one is to facebook.
You can try looking at the TCP header options, but generally the traffic is encrypted for a reason... so that it wouldn't be seen by man-in-the-middle. If it were possible, it would be, by definition, a poor encryption standard. Since you have the capture and all the information known to the user agent, you are not "in-the-middle". But you will need to use the user agent info to do the decryption before you can really see inside the stream.
this link: Reverse ip, find domain names on ip address
indicates several methods.
Suggest running nslookup on the IP from within a C program.
And remembering that address/ip values can be nested within the data of the packet, it may (probably will) take some investigation of the packet data to get to the originator of the packet
Well, you have encountered a dilema. How to get the info users are interchanging with their servers when they have explicitly encrypted the information to get anonymity. The quick response is you can't. But only if you can penetrate on the SSL connection you'll get more information.
Even the SSL certificate interchanged between server and client will be of not help, as it only identifies the server (and not the virtual host you'll try behind this connecton), and more than one SSL server (with the feature known as HTTP virtual host) several servers can be listening for connections on the same port of the same address.
SSL parameters are negotiated just after connection, and virtual server is normally selected with the Host http header field of the request (see RFC-2616) but these ocurr after the SSL negotiation has been finished, so you don't have access to them.
The only thing you can do for sure is to try to identify connections for youtube by the amounts and connection patterns this kind of traffic exhibit.
I want to modify packet header(IP header, TCP Header) before the host send them into the network.
For example, if I'm using firefox for browsing, then I want to intercept all the packets from firefox and modify the IP/TCP header and then send them into the network.
so basically, there are two requirements:
1 intercept all the packets from firefox(but not other programs). if this is not possible, is it possible to intercept the packets from a specific port or ip/port pair
2 modify the IP/TCP header and then inject them into the network
are there ways, APIs to achieve this?
how about libpcap?
are there similar source code snippets?
I'm working with linux c
thanks!
To modify the packets, it is better as simple as injecting the packet which is modified into your network.
C has a library libnet which does every thing related to packet injection.
Python has scapy to inject the packets .
Now you can do quite interesting things , with libent and scapy , instead of modifying your packet ip/tcp headers , perform arp spoofing and then inject falsify packets and redirect them to the victim.
Libpcap is used for capturing packets but not for modifying packets . So you can build your own sniffer using libpcap , but to inject/modify packets you need to use libnet .
To make life simpler , there are tools like burp suite etc..where you can modify the http headers only before forwarding it .
Razorback is an open source API for deep packet injection.
You can find the source at:
http://sourceforge.net/projects/razorbacktm/files/Razorback/
You can also request them for the source code for their proposed system.
http://www.icir.org/vern/papers/pktd-pam03.pdf
it should be for you Network packet capturing for Linux.
But it seems to intercept all process in the system.
maybe you can use
#include <sys/ptrace.h>
long ptrace (enum __ptrace_request request,
pid_t pid,
void *addr,
void *data);
and hook send(2) or recv(2) to modify the tcp header.
I want to build a simple DNS Proxy in C, which accepts DNS Queries from UDP Port 53, forwards the query to Google's DNS server TCP port 53 to do the lookup, and then returns the answer offered by Google.
Yes, this is a school project and I'm so confused that I don't know where to get started.
Thanks for helping!!
You've struck lucky with the requirements - because you're going from UDP -> TCP, it's actually a lot simpler than doing UDP -> UDP.
Specifically, what I mean is that because the outward facing side is using a connection orientated socket, you know straight away that the response you receive must pertain to the query you just sent, so long as you use a new TCP socket for each query.
If the outward facing side had been UDP it becomes a lot harder to figure out which query each response relates to - there's no guarantee in the protocol that responses arrive in the same order as the queries.
If multithreading isn't a requirement, then (in pseudo-code)
"open" a UDP socket
"bind" that socket to port 53
while (true) {
"recvfrom" a packet from the UDP socket
... and remember the address it was received from
"open" a TCP socket
"connect" it to Google's DNS
"write" the length of the original query (two bytes, network order - RFC 1035)
"write" the contents of the original query
"read" a two byte length header
"read" that many bytes from the TCP socket
"close" the TCP socket
"sendto" those bytes back over the UDP socket to the original client address
}
first of all you need to chose an API for writing messages on to a network.
For windows, you have Winsock API.
For unix-like systems you have the BSD Sockets API.
Although most of the courses use the BSD API.
Now your steps may be:
have a look at rfc for DNS implementation. You can only focus on format of request and response messages, as you may need to change some fields.
Now write a client server code which consists of two modules:
Server side code to receive a DNS query request, may need to change some fields.
Pass it on to the Module that interacts with Google's DNS server.
Capture the response and forward it back to requesting client. (again you may need to change some fields)
I have a Linux application that talks TCP, and to help with analysis and statistics, I'd like to modify the data in some of the TCP packets that it sends out. I'd prefer to do this without hacking the Linux TCP stack.
The idea I have so far is to make a bridge which acts as a "TCP packet modifier". My idea is to connect to the application via a tun/tap device on one side of the bridge, and to the network card via raw sockets on the other side of the bridge.
My concern is that when you open a raw socket it still sends packets up to Linux's TCP stack, and so I couldn't modify them and send them on even if I wanted to. Is this correct?
A pseudo-C-code sketch of the bridge looks like:
tap_fd = open_tap_device("/dev/net/tun");
raw_fd = open_raw_socket();
for (;;) {
select(fds = [tap_fd, raw_fd]);
if (FD_ISSET(tap_fd, &fds)) {
read_packet(tap_fd);
modify_packet_if_needed();
write_packet(raw_fd);
}
if (FD_ISSET(raw_fd, &fds)) {
read_packet(raw_fd);
modify_packet_if_needed();
write_packet(tap_fd);
}
}
Does this look possible, or are there other better ways of achieving the same thing? (TCP packet bridging and modification.)
There were some apps I used years ago to do some TCP/IP packet manipulation for testing a firewall: fragoute and fragtest. Looks like they haven't been touched in years, but they might give you some ideas of what to do in your code.
You might want to consider using a LD_PRELOAD library to hook the functions that it uses to send the data out (send(), write() etc).
That wouldn't involve any kernel messing-around at all.
Another option is to NAT the outbound connections to a local proxy which can read the data, make whatever modifications, and send it all out to the real destination (with some options to prevent it being NAT'd again and going round in circles)
You can use the click modular router. It is a software router implemented entirely in C++. Click allows you to capture packets as they pass through elements in the router where you can modify or collect statistics as needed. As a kernel module, you completely override the linux routing mechanism and as a userland binary you simply get a duplicate (as you mention in your post) of each packet from the interface. Packets can be directed through the Click graph by way of pcap filters and a variety of other mechanisms.
If you are headed down the bridge route, I think this provides the most direct support for what you are looking to do as you can use tun/tap, to/from host or to/from device capture methods as you require.