So I have intercepted a packet being sent from my android device to an apps server. I want to understand what my phone is sending to the server.
I have rooted the phone, and install tcpdump on it. I have used adb shell to run:
tcpdump -n -i wlan0 -w OUTPUT_FILE src host IP_ADDRESS and greater 200
I have gotten the packet on my pc and run it through wireshark.
I have been told that the long list of "........" prevalent in the ascii section is because there is no ascii representation of the specific HEX.
Is that true?
I have been able to determine the packet is not encrypted, because I can see clear text strings in the ascii that I type in the app.
I am guessing the data is either binary OR base64 encoded JSON, converted to hex and sent to the server. Is there any step I can take to further understand the structure of the data sent from my device to the remote server?
Any other tips, or random insights would be super helpful.
Is that true?
Yes.
Is there any step I can take to further understand the structure of the data sent from my device to the remote server?
The captured packet includes an Ethernet Ⅱ header and an IPv4 header and a UDP header as follows:
Ethernet Ⅱ: from 20:e5:2a:4f:b9:4f (NETGEAR) to 44:80:eb:ea:ef:9b (Motorola)
IPv4: from 169.55.244.58 to 192.168.1.12, not fragmented
UDP: from port 14242 to port 48818, payload length=1406 bytes
The right chunk of the 3rd line (i.e. bb 19 43 4f 02 c8 2b a3) is the start of the application data.
To analyze the application data, you need to know what protocol the application used to send the packet and to learn the protocol.
Related
I had written a code for micro-controller in which HTML text is sent on a LAN to browser via Ethernet,the code works fine until the Ethernet frame size exceed to 1500 bytes.
Is there any way of sending HTML text to browser successfully in a fragments via Ethernet?
CASE: If text is fragmented prior sending!
The Browser in this case only display's first part of text fragment. While the rest fragments aren't updated on the browser.
Any support in this regard would be appreciated!
I'm assuming you are using a TCP stack and have not attempted to write the TCP/IP headers directly with your own code on the device. Then your problem most likely has to do with the Ethernet MTU (maximum transmission unit).
MTU is the maximum payload that can be transmitted (and received) by all devices on the network. Typical MTU size is 1500 bytes, but unfortunately it is common to have networks that require a lower MTU (e.g. when PPPoE or VLAN headers get added at some point). Usually it is just a configuration problem. Most Ethernet hardware supports MTUs well over 1500 bytes.
What usually happens is that as soon as TCP attempts to send a packet that is too large, it gets dropped at some point (sender, receiver, switch or router). A packet sniffer like Wireshark will do TCP analysis and tell you about suspected packet loss and TCP retransmission attempts.
It's TCP that is is splitting a stream into packets, so the TCP stack needs to know what the MTU is. On Linux the TCP stack it will get this setting from the network interface. You can see the current value with ip link or ifconfig. It needs to be configured on both sides of TCP the connection, but your problem should go away by just setting a lower MTU in the TCP stack of the embedded device.
In addition to that, IP fragmentation can happen when a router wants to forward a frame from a network with high MTU to a network with lower MTU (or if it has added another Ethernet header, and the frame is now too large). Unless you are using a very poorly implemented IP stack that doesn't support fragmentation, this should not be a problem. (But it's wasting bandwidth.) Depending on the flags, the router may then send an ICMP message to notify the sender about the problem. But if there is a firewall in-between that drops ICMP packets this will not work, and result in retransmission attempts without lowering the MTU.
in order to code a program, i need to know how the ping command is working.
I need to know, if a command ping -c1 "something" is executed, how many ipv4 packets and ethernet frames will be created ? considering that every cache is empty
thanks..
The ping command uses ICMP packets. In order to code a ping command you need to be able to send and receive ICMP packets.
In windows, this is done using winsock raw socket support. Here is an example of a ping using raw sockets.
In Linux, you just need sockets support. Here is a stack overflow question about how to do ICMP packets in Linux.
Or you can find a library that implements this for you.
Reply from 192.168.2.10: bytes=32 time<1ms TTL=128 - **Computer is on OS kernel still in memory**
Request timed out. - **OS is shutdown/Firewall blocking ICMP**
Reply from 192.168.2.10: Destination host unreachable. - **Computer powered off. Physical network active**
Here is the ping command explained for troubleshooting
Can TCPDump and TCPReplay be used to record(tcpdump) network traffic coming in to a application server/webserver/queue application etc., and then replayed using the dump on TCPReplay?
Let's say I setup a apache server and use TCPDump to capture the entire network traffic and dump it to a file. Now I run apache in a different machine and want to replay the traffic to this new apache server using the file. How can I achieve this?
I especially want to understand how TCPReplay would work in such a scenario. i.e. how would syn/ack responses work for TCP. How would a new a connection etc. be initiated?
Fred is right. Also, this question is answered in the Tcpreplay FAQ: http://tcpreplay.synfin.net/wiki/FAQ#Doestcpreplaysupportsendingtraffictoaserver
No, you cannot use Tcpreplay to replay traffic to a server. TCP sessions have random sequence numbers, and are fully stateful. Replaying previously recorded TCP traffic will be ignored by a server.
I know the ICMP request contains the IP address. Is the client MAC address included in an ICMP request? What other info (if any) is included in a ping request?
An ICMP request is a layered packet which is sent over the internet. It contains the Ether layer, which has the target and source MAC address in it. It also contains the IP layer, which has the source and target IP and also a couple of flags included. And at last it contains the ICMP data. This contains a type, a subtype, then a checksum and the rest of the header, which can vary from type and subtype (E.g. The code for echo is 8 and reply is 0).
There is a lot of information in a network packet. Also note that ICMP is an part of the IPv4 protocol, so it cannot officially be carried by other protocols. Although the IP protocol can be carried on a different protocol than the ethernet protocol.
The MAC address will be changed after each passing of a router. So this is never the MAC address of the source IP address on the internet. But the IP address is definitely included and on a local network, the mac address of the client is still in the packet in the Ether layer.
Wikipedia has some readable article about ICMP packets: icmp message and different protocols with readable diagrams.
If you want to see some live requests, you can install wireshark, which will show and dissect all network traffic for you. It is a very convenient and cool tool.
The ICMP 'ping' packet, officially known as 'echo request', contains whatever the originating ping executable wants to have echoed back to it. In the Bad Old Days when the internet was first getting started up, the routers they had (and all computers, really) were subject to random memory failures. In order to detect that the path between two systems was clear, they would send echo request packets and compare the contents of the request with the reply. If the contents differed, they knew that there was a problem with either of the machines involved, or the routers in between.
It's impossible to state here categorically exactly what's in any given ping packet because it changes between implementations of ping.
It is usually not possible for a person to get the MAC address of a computer from its IP address alone. These two addresses originate from different sources. Simply stated, a computer's own hardware configuration determines its MAC address while the configuration of the network it is connected to determines its IP address.
However, computers connected to the same TCP/IP local network can determine each other's MAC addresses.
Look RFC 792 for full ICMP fields.
Is there any way to use adaptive ping option with Scapy? I need to send ICMP packets with flood interval for testing purposes.
Ping tool is not an option, because has adaptive ping yes, but cannot be send fragmented packets (except with -s option specifying bigger size than MTU for the interface) - however I am interested not in to send all the fragments, just some of them, it is why Scapy tool can do that but not ping.