I have some clients connected to my server. I want to know how much they use telegram (from it's desktop and mobile application).
can anyone explain me how can I detect this protocol from header of the packets?
I read this from Telegram official site:
There is an abridged version of the same protocol: if the client sends 0xef as the first byte (important: only prior to the very first data packet), then packet length is encoded by a single byte (0x01..0x7e = data length divided by 4; or 0x7f followed by 3 length bytes (little endian) divided by 4) followed by the data themselves (sequence number and CRC32 not added).
but I didn't understand when abridged version is used?
Telegram uses MTProto to communicate. Check this page for more details of the packets. Every packet is encrypted so you can't see inside.
By the way, if I was in your shoes, I would filter packets by their source and destination IP address. Telegram has dedicated servers with fixed IPs. All you have to do is to find all Telegram IP addresses. If any packet is coming from or going to these IPs, it's someone using Telegram.
Related
I have a BLE device that doesn't respond to SCAN_REQ and am working it out with the vendor independently per https://github.com/espressif/esp-idf/issues/10660.
When I use Nordic nRD Connect iphone app as a client I can see that device in the scan list and can connect to it. However, when I use a different client, a python Windows one, that client doesn't show the device in its scan list and doesn't connect to it if I specify the exact address.
My question is, are BLE 4 devices required to respond to SCAN_REQ requests to be discoverable and connectable or is it just optional response to provide additional advertisement data?
EDIT, I believe that Emil's answer below (thanks) refers to this quote
Yes, it's required to reply with a scan response. That is defined in Bluetooth Core v5.3, Vol 6 Part B (Link Layer), section 4.4.2.3, using the word "shall".
There is one exception though. There is a Filter Accept List in the controller which can contain addresses of centrals allowed to scan and/or connect. There are four combinations the host can set (advertising filter policy) that control if this list shall be used for filtering incoming SCAN_REQ and CONNECT_IND packets, respectively. If you don't use this filtering mechanism, then the device must send a scan response to every scan request.
There are two possible approaches to scanning—Passive Scanning or Active Scanning.
Passive Scanning is when Scanners receive advertising packets and process the contents.
In the case of Active Scanning, however, a device may decide it wants to know more about an advertising device and respond to the initial advertising packet by sending a Scan Request GAP protocol data unit (PDU). This basically means ‘Tell me more.’ The device receiving the Scan Request can send back a Scan Response PDU with more information, once again in the form of a collection of AD types.
The above has been extracted from: https://www.bluetooth.com/blog/advertising-works-part-1/ [the emphasis mine].
What exactly is a BLE scan response packet?
Since there is almost nothing to be found online, we would like to now this.
Does a scan response packet, respond on a device scan or is it like the advertisement packet sent every x seconds?
A BLE scan response is the packet that is sent by the advertising device (peripheral) upon the reception of scanning requests (i.e. yes, it is a response to a device scan). The scan response usually has more data than the advertising packets. In other words, central devices send scan requests to the advertising device in order to get additional user data through the scan response. Please also note that scan responses are considered to have fixed 'static' data relative to the more dynamic advertising data.
Advertising packets and scan response share the same format, and are transmitted over the same three physical channels (they are both sent as advertising events), but are otherwise two different things.
For more information, I recommend reading about scan response packets in the SIG's core specification found here.
I hope this helps
An important addition to yousif saeed's answer:
According to the Bluetooth 4.x specification, Peripheral devices accepting Scan Requests,
Must advertise this by using a specific Advertising Type value in the protocol header.
Must use advertising intervals of equal or bigger than, at least, 100 ms, so that the Central/Peripheral devices can exchange the Scan Request/Response packets in the time between two consecutive advertising packets (advertising interval).
Keep in mind, also, that depending on your particular hardware platform and Bluetooth Low Energy software stack,
You may find that a peripheral device accepting Scan Requests is non connectable, that is, may be limited to behave as a pure beacon (connection-less).
I was just looking for this information and it is difficult to find good technical resources beyond the basic description.
There is a great few pages on one of the manufacturer's sites that goes into the details of how their hardware interacts with these communications.
The scan response packet consists of:
Device name,
Transmission power,
Beacon ID,
Firmware version,
Battery level
https://support.kontakt.io/hc/en-gb/articles/201492492-iBeacon-advertising-packet-structure
https://support.kontakt.io/hc/en-gb/articles/201493072-Beacon-services
https://support.kontakt.io/hc/en-gb/articles/201492492-iBeacon-advertising-packet-structure
I am not promoting Kontakt.io, but they did a pretty good job of providing this answer in good detail.
Yes it does depend on device scan.
I recently had this experience.
I was working with Nordic device and started sending advertising packets which included scan rsp data. But either I was getting no scan rsp packet or hardly any packet. The issue was I was not scanning from my other nordic device. Once I started scanning from another device, scan rsp packets started coming quickly.
How is a packet received by a wireless devices with thousands of users/devices connected to the same network?
If we are using UDP, will it send the packets to all the devices such that only the authenticated devices will accept the packets and others would reject?
How does the situation change if we use TCP instead of UDP?
UDP and TCP are the same as they are higher layer protocols.
Majorly simplified, but the device opens a tunnel to a GSN (Gateway Serving Node) which is a server installed at the carrier. Which GSN to use is based on the APN (Access Point Name) supplied when the tunnel (PDP context) is requested. The tunnel is assigned an IP address at the GSN and that is the address used for IP communication. Packets will be filtered at the GSN and routed to the specific device. Traffic is tunneled between the GSN and the device using telecom specific protocols. Packets are not broadcast out to all devices and then filtered there.
Ps. I phrased the answer using GPRS terms. Other 2.5/3/4G protocols use the same structure but sometimes have different names.
what you mean by authenticated user?
are you concentrating in application level ? or at lower layers of the n/w?
even it is UDP , it should be thought of sending it to specific IP.even in complex n/w each s/m is an unique entity
Rohith Gowda , actually if you are concentrating on udp packets at Application level (either java, c# ...) u creates the packets for specific ip and sends to an IP,( which is the recivers ip) and the reciver have to grab it , i think you actually want this right? and no need to fear about others with different ip than what you are sending to, because you are in abstracted APP Layer, your doubt will be look after by lower layers.if you want an additional snooping proof just encode the data that you want to send
one Example is (in java)
DatagramPacket (UDP) can be created by invoking a new instance of
DatagramPacket(packet data [],offset ,length ,address* ,port* )
look at the last 2 params they specify the SeverAddress and the Port of transmit to the server
i think you are now clear that the destination server with the ip (Sever-address) listening at the particular port can grab it.
I am doing some experiment for which I need to collect Data from wlan driver.
I am interested in transmitting IEEE 802.11b Packets with more flexibility in terms of Data Rate, Packet Size etc.
Basically, I will have the laptop as the transmitter and I have built a custom receiver for IEEE 802.11b which would read the packets ( IEEE 802.11b 1/2/5.5 or 11Mbps) .
So, I am looking at some Linux tool which gives the option of setting these parameters while transmitting data.
I am thinking at commands like iwpriv to set the parameters for the wireless driver, and iperf commands to generate Traffic.
I am not sure, how to use them to achieve a Data traffic, say 1Mbps / and 1024 Bytes PSDU (Packet Size).
The receiver is a dedicated hardware ( not a Computer). Any suggestion or idea in this direction would be helpful.
Thanks
Use wireshark or pcap (via perl,python etc) to capture what you want.
You may be better off asking this on Server Fault. I found a couple of packet generators that look like they could do what you need but I'm by no means an expert.
packETH:
you can create and send any ethernet packet [...]
sending sequence of packets
delay between packets, number of packets to send
sending with max speed, approaching the teoretical boundary
change parameters while sending (change IP & mac address, UDP payload, 2 user defined bytes, etc.)
Ostantino:
Modify any field of any protocol (some protocols allow changing packet fields with every packet at run time e.g. changing IP/MAC addresses)
[...]
Configure stream rates, bursts, no. of packets
I found these in the Wireshare Wiki where there are a number of other tools that may help.
im now developing a project using winpcap..as i have known packets being sniffed are usually fragmented packets.
how to reassemble this TCP segements?..any ideas, suggestion or tutorials available?..
this i assume to be the only way i can view the HTTP header...
thanks!..
tcp is a byte stream protocol.
the sequence of bytes sent by your http application is encapsulated in tcp data segments and the byte stream is recreated before the data is delivered to the application on the other side.
since you are accessing the tcp datasegments using winpcap, you need to go to the data portion of the segment. the header of tcp has a fixed length of 20 bytes + an optional part which you need to determine using the winpcap api.
the length of data part in the tcp segment is determined by subtracting the tcp header length (obtained from a field in the tcp segment) and the ip header length (from a field in the ip datagram that encapsulates the tcp segment) from the total length (obtained from another field in the ip datagram).
so now you have the total segment length and the length of the data part within the segment. so you know offset where the http request data starts.
the offset is
total length-length of data part
or
length of ip-header + length of tcp header
i have not used winpcap. so you will have to find out how to get these fields using the api.
also ip datagrams may be further fragmented but i am expecting that you are provided only reassembled datagrams using this api. you are good to go!
There is no such thing as a TCP fragment. The IP protocol has fragments. TCP is a stream protocol. You can assemble the stream to its intended order by following the sequence numbers of both sides. Every TCP Packet goes to the IP level and can be fragmented there. You can assemble each packet by collecting all of the fragments and following the fragment offset from the header.
All of the information you need is in the headers. The wikipedia articles are quite useful in explaining what each field is
http://en.wikipedia.org/wiki/TCP_header#Packet_structure
http://en.wikipedia.org/wiki/IPv4#Header
PcapPlusPlus offers this capability out-of-the-box for all major OS's (including Windows). Please check out the TcpReassembly example to see a working code and the API documentation to understand how to use the TCP reassembly feature
Depending on the whose traffic you're attempting to passively reassemble, you may run into some TCP obfuscation techniques designed to confuse people trying to do exactly what you're trying to do. Check out this paper on different operating system reassembly behaviors.
libtins provides classes to perform TCP stream reassembly in a very high level way, so you don't have to worry about TCP internals to do so.