I have a device (made in china) that works great but with a very annoying flaw. It's a massage device that will only work if it is connected to the internet at startup. Once it starts, it would work without the internet until it is turned off. So in short, if the internet is down, it will never work or it is impossible to bring this device on an area with no connection.
What I'm planning to do is emulate its server/client communication at start-up by using an old-PC that would run the server emulator software and some DNS re-routing and a WiFi router (using the PC as WAN).
I'll connect the device on the router, and its communication with the Chinese Server is emulated by the PC.
Can anyone give me an idea where to start, tools needed etc? I'm a programmer but new to packet emulation/replay. I've sniffed packets that the device does and its always consistent on every start/restart of the device. Here's the wireshark capture (IMG):
WireShark Packet Capture
You have two tasks, IMHO neither of them requires special tools:
Redirect requests to local address
You need to setup local DNS server and configure it to provide local IP address on hengdetech lookup. I didn't dive into this part, but google has plenty of forums discussing necessary config for different DNS servers.
Device most likely gets DNS server address from DHCP server. So you need to point device to local DNS instead of default one by configure DHCP server (which is run on your router, I suppose).
Once your DHCP configures local DNS and local DNS redirects hedgdete to local IP address, you are free to go to the second part which is
Emulate server behavior
Server must wait for some initial data from client before sending some data back. Such logic doesn't fit well into common "replay packets" tool capabilities, but it's quite easy to implement dumb TCP server with desired functionality on whatever language you like. Open socket, wait for data, send data, not a big deal, isn't it? So I wouldn't bother searching for the right tool, but would creat new instead.
If you need quick proof of concept, that you understand data flow right, before start coding, you may try netcat utility on Unix system for quick server emulation. I did the following once: extracted exchanged payload data from traces and saved as binaries (e.g. file1.bin is sent by server after the first request, file2.bin is sent after the second etc), then used something like this: cat - file1.bin - file2.bin | nc -l -p <local_port> -n. Using cat without dashes results into nc sending all files content to client, once it connects. Dash means "use data from console input rather than file" and they are used only as flow control. cat hangs on the first dash waiting for user input, so pressing ctrl+d proceeds to next file content and sends file1.bin, then hangs on the second dash. So you wait for the first request, press ctrl+d to send file1.bin content, then wait for the second request, press ctrl+d to send file2.bin content and so on.
EDIT
You generally got the idea of extracting data from wireshark traces right, but I want to clarify some subtlenesses.
When you said "saved binaries", did you mean to save individually captured packets as binaries so that netcat could send them to clients as a reply one by one (with the help of dash) ? If so, how do I save captured packets as binaries? Can I just extract them from the wireshark capture files, paste it on a new file and save as binary?
Only payload part of the packet needs to be saved, not the whole packet. TCP header, IP header and so on shouldn't be extracted, only tcp data section should be saved. Check second part of this answer for howto. I suppose, TCP data in your case consists of binary data rather than plain text, so you need to copy it as "raw binary" and use some binary editor allowing to paste "raw binary" into file such as frhed. So yes, you create new file and paste data copied from wireshark into it, so file consists of exactly the same bytes as packet payload.
Another thing to mention, TCP is a stream protocol, one packet doesn't always mean one response message. If you see several TCP packets of maximum size (aka MTU, which is usually 1.5 Kbytes) without PSH flag followed by packet of lesser size with PSH flag, they all contain parts of the single response message, so their payloads should be combined into one "fileX.bin".
Related
Whenever I open a website in my browser, I want to see the packet that is going out of my computer. I want to do this to check how the proxy extension on my browser is encrypting the information.
Is there a way to check the packet that is going out of my NIC?
Some sniffer tool like tcpdump or wireshark may help you.
Wireshark is easier, with a good GUI and easy to learn and advanced filtering rules, analyse each packet on all levels of the packet, save packets into external files, load from external files, filter prototyped protocols and more advanced usage.
tcpdump is fast and useful but it will require a little bit more learning than wireshark GUI. But, is a really good solution for command line, ready to use.
A simple step-by-step for wirshark:
Install wireshark
Open it with root/admin permissions
Choose the target NIC
Click on 'Start' for start packet sniffer
On this new window, you will see a list of continous packets passing--through chosen NIC
On the top of this window, you have a filtering field. By example, you can write down on it:
tcp.port == 443 and ip.addr = 10.0.0.106
Then, only packets matching this rule will be shown
On this example, we are filtering all traffic passing by TCP port 443 (SSL) and have even target (request) and source (response) host under address 10.0.0.106.
It is possible filter by mac-addresses, and a lot of parameters under each packet, protocol specific parameters, and a lot of things.
Im a student and as a hobby I am writing a program that is supposed to perform a man in the middle attack with ARP spoofing, and then manipulate the traffic before sending it on to the victim. For this I need to examine the packets, manipulate them and forward them to my victim.
Note: This is strictly a hobby project and the network is my own local network at home. Its just some generic AT&T homeportal and a bunch of machines connected via wireless.
I know that when I enable IP forwarding on my machine, it does the following to packets that are to be forwarded:
Put my MAC as SRC in the ethernet header
Put forwarding target's MAC as DST in ethernet header
Decrement TTL
Recalculate IP Header checksum
Send the packet
Since I want to manipulate the traffic before sending it on, I am trying to write a program that does the manipulation and then the forwarding manually so to speak. What I tried to do:
See if packet is for my victim
If so, manipulate it how I want
Put my homeportals MAC address as SRC in the eth header
Put my victims MAC as DST in eth header
Send the packet
My train of thought was that when looking at the packets it would be indistinguishable from "normal" traffic. If I decrement the TTL and recalc. the checksum and put in my machines MAC as SRC, its kinda easy to notice whats going on if you look at the packets.
However, my method does not work. As in, if I put the homeportals MAC as SRC on the ethernet header, for some reason none of the webpages load on machine A.
If I put in my machines mac address, the webpages load although slowly and wireshark shows me a lot of TCP retransmissions coming from the webpages server, I am guessing this is because my program is forwarding the packet too slowly to machine A and so A can't respond in time?
So anyway, thats pretty much my question: Why can't I pretend to be the homeportal? As in put its MAC address in the ethernet header of the packets I forward to A. Also, what else could cause all the retranmissions from the webpage servers when I use my machines MAC address? English isn't my first language so I hope this is not too vague.
Is it possible to dump contents of tcp recv/send to a pcap file and then have wireshark analyse this. I want to do this because I want to log an applications conversations in order to debug issues but I don't want to have to write my own parsers (wireshark already supports it) and don't necessarily trust the application to parse frames correctly.
What follows is based on work that I've done exclusively on Windows.
I can't speak to how well any of this might apply to other systems.
FWIW, I would suggest editing your question (or at least tagging it)
to be more clear about what OS you're targeting.
If you are talking about writing what's received directly from a TCP client to a pcap file, the answer is no. The pcap file format requires at least some networking headers, e.g., the IP and TCP headers, in order for the file to be valid.
There are four approaches I see.
You could fake these headers for each read from the socket. This wouldn't necessarily require a lot of work, but it would require some knowledge of the relationships between the network header, the transport header, and the payload (i.e., your data) in order for everything to work right. If you're only interested in analysis of the payload in Wireshark, this might be a valid approach. However, if the analysis you're wanting to do in Wireshark is network analysis (i.e., analysis that includes the network headers), then you'll want to avoid this option and figure out how to capture the network headers directly.
You could use a raw socket to capture network traffic at the network layer. This will give you the IP packet - IP header, TCP header, and payload. You could dump this to a pcap file using LINKTYPE_RAW as the link-layer header type, and Wireshark will read the file fine. I've used this approach before.
The third approach would be to use WinPcap to collect your data. This is the same software that Wireshark uses behind the scenes to collect the data, and it's the approach I'm using now. If you have Wireshark installed, the WinPcap is already installed, too. WinPcap has a simple API with numerous examples for opening an interface, collecting the data, and dumping it to a pcap or pcap-ng file.
The fourth option is the simplest...just use Wireshark to collect the data simultaneously with your application.
HTH.
I want to capture and save the data that's being sent to a certain process through internet .
Are there any tools for the job?
If not, does listening to the same port as the process that I'm trying to get data from, will get me the data?
Any help appreciated !
You can try Wireshark: http://www.wireshark.org/
Or RawCap: http://www.netresec.com/?page=RawCap
I don't know what is the data format you are trying to capture. I used these two tools to capture xml data from web service.
On Windows, use Winsock Packet Editor (WPE). You will be able to hook a process' all Winsock-related functions and capture (and even modify/block) any TCP/IP, UDP packets that the application receives or sends. For all other operating systems, you will have to either:
write your own tool that hooks various socket functions (e.g. send, recv, etc.)
or just use Wireshark which will capture all Layer-3 packets that goes through your network card. You will have to use your own knowledge of the application that you're trying to monitor in order to filter the packets that are specific to the application.
Are there any tools for the job?
Wireshark. But what have you tried?
If not, does listening to the same port as the process that i'm trying to get data from, will get me the data?
Not if you don't forward the traffic to the real destination, otherwise the other party will be waiting forever on a response, or simply timeout and close the connection. You should create something like a proxy.
Wireshark is easier.
I need to write a ftp program linking two, only two, computers, but this must be done using raw sockets on promiscuous mode. Since the socket will receive any data that come across the network device, my problem is how to address the correct program. For example: Imagine I have a server on a machine and two clients on the other. The server sends a message, how can the two clients know which of them will receive the message? Another problematic situation would be if I open a client and a server in the same machine, both may start to commune with each other.