I'm doing a security analysis project on an IoT device that uses an unencrypted BLE connection (with ATT protocol) and I want to spoof an individual BLE packet with the source address of an already connected device. Is there some tool or API that would allow me to do this easily? I've already tried gatttool and spooftooph but they seem to be connection based and don't allow you to send out single packets with modified fields (as far as I could tell).
You will need some hardware where you can access the radio peripheral directly. What you basically need to do is to find or write a ble sniffer firmware, with the modification that it at a given moment sends a packet on the connection it is currently listening to. But note that the signal strength must be stronger than the original device's signal so it doesn't interfere.
The only open source project I'm aware of is Ubertooth. You will also be able to do this with an nRF52 but then you need to write your own sniffer firmware since Nordic Semiconductor's is closed source.
I can't comment on Emils reply yet, < 50 rep:
Nordic Semis nRF Sniffer v2 needs only the nRF52DK and wireshark to work as a general BLE sniffer. At 40$ it's not that expensive. I know for a fact they will release a new dongle soon that will sell for ~10-15 bucks if you can wait a a month or two.
Related
My question is regarding an ESP8266 board and the ESP-touch technology.
ESP-touch uses the length field of a UDP package to broadcast wifi ID and PW through a device (like a smartphone) to the chip (like in my case ESP 8266).
I want to turn this around, more specifically:
I want the ESP8266 chip to broadcast UDP packets with some sort of identifier-number in the length field of the UDP packet, without beeing connected to any wifi connection. Then these UDP packets are recieved by an app on a smartphone so the identifier-number can be extracted and used on the smartphone.
I am relatively new to this topic and do not know if this can work.
When I try to find any information online they all say that the first step is to connect the chip to a wifi. But I don't want that. The smartphone and the chip don't know each other and are not connected in any way. So I want this type of "broadcasting" so that the smartphone can recieve the package without really beeing connected to the chip.
I guess there must be some way to make it function like I explained above, but I can't find a way how this can work.
I don't need the chip to send UDP packets explicitely, it can be any type of package. I took UDP packet as an example because there is already the ESP-touch technology which is more or less similar.
The important thing is that the package that I send has a field where I can put some identifier-number in (not encrypted), which can then be recieved by another device like a smartphone where this identifier-number is extracted.
For clarification: I don't need to use ESP touch or anything related to that. I only stated this technology as an example. I just want to achieve the behavior stated above and in the picture! :)
This is an example picture how I want it to work:
No, it's not possible to send any packages without being connected to the network. ESP-touch or TI Smart Config or similar technologies utilize Monitor mode. As the name suggests, in this mode one can listen for packages, but can't send them.
ESPNOW provides data flow between ESP devices without connections via router. It is another feature of the Espressive API. There are tutorials for ESP8266 and ESP32...
https://randomnerdtutorials.com/esp-now-esp8266-nodemcu-arduino-ide/ .. https://www.instructables.com/ESP32-With-ESP-Now-Protocol/
I have a remote sensor that talks to the world via a low bandwidth TCP connection over GSM. It can often be in a location with extremely patchy GSM connectivity though. At the moment, the remote sensor waits for a GPRS network and then initiates a TCP connection with the server and then listens for commands (which are only a dozen or so bytes every hour or so)
Is an SMS more or less likely to get through to the remote sensor than being able complete a TCP connection? I guess I'm wondering how likely it is that a network signal strength is sufficient for SMS but not for TCP.
Using standard text messaging services for M2M is good idea if you can fit your data in 140 bytes. For short transmissions, opening an GPRS/1xRTT (2G) IP session, transmitting the data to a server and closing the session is less efficient and more likely to go wrong than sending an SMS.
As a side note, you can also use SMS (MT-SMS) to bring IoT device online (mechanism called "Shoulder-Taps" ).
Compared to data (or voice), SMS use only the signaling part of the mobile network. It's a quite cheap operation in terms of network resources reservation so you'll more likely get through with an SMS than with a data connection in a weak signal environment. One additional advantage is much lower power consumption of your terminal which might be important for M2M context.
As stated by #Jarek previously, you need to be able to pack your data into 140 bytes or to forge "long" SMSes which are kind of concatenation of "simple" 140-bytes SMSes
I am developing a logic core to perform data transfer between a FPGA and a PC over ethernet, using a LAN8710 PHY on my FPGA board.
I've achieved to transfer some UDP data packets from the FPGA to the PC. It's a simple core that complies with the PHY transfer requirements. It builds the UDP package and transfer it to the PC.
To check the reception on the PC, I am using Wireshark and as said above, I receive the packets correctly. I've checked the reception with a simple UDP receiver written by myself.
But, I've noticed that I only receive these packets when Wireshark is running on the PC. I mean, if Wireshark is ON, my application receives the packets too, and the counter of received packets of the following picture increases. (This picture is not mine, just one from the internet)
http://i.stack.imgur.com/wsChT.gif
If I close Wireshark, the PC stops receiving packets and the counter of received packets stops. My application stops receiving too.
Although novice on networking topics, I suspect that this issue is related to PC-side. Seems like Wireshark is "opening/closing" the ethernet communication channel, or something like that. Does anyone knows about this issue?
To build a functional core to transfer data between a PC and the FPGA, I've developed a core to transfer and receive UDP packets. Next step will be ARP implementation (to let the PC identify my FPGA board, as I understand). What protocols are necessary to perform full-duplex data transfer between this 2 devices?
Thank you very much in advance,
migue.
Check whether you are able to get appropriate receive interrupt at ethernet driver level on PC-side for a single transmitted packet by FPGA. If you do not get the receive interrupt, check on the transmit side(FPGA) for appropriate transmit interrupts for packet that is being transmitted. This should mostly help you in cornering the issue.
As far as i know, wireshark is just a packet analyzer/sniffer. However, if wireshark is suspected, one option could be to try with alternate packet sniffer to rule out if any such scenario is happening.
A handy tool for determining problems in network and also for determining the network statistics shall be netstat. netstat -sp udp shall list down the statistics only for UDP. There are many other parameters that can be used with netstat for diagnosis.
After many months I solved it, I post to help someone stucked in the same point.
Finally I figured out that Wireshark uses a tool to access the network link layer of the computer. This tool allows Wireshark to sniff all incoming and outgoing packets at a specified network device. To do this, the first step is to OPEN the network device, and that's why my program only worked if Wireshark was open.
Regards.
I read a lot about WiFi sensors being used to track smart phones in Retail environment. The location triangulation is done on basis that a smart phone has its WiFi turned ON, be it in connected or unconnected state.
Case 1 : WiFi turned ON but unconnected
Why should a smart phone which has its WiFi turned ON need to transmit the packets, unless the user 'scans' for nearby WiFi networks?
Case 2 : WiFi turned ON and connected
Why should a smart phone transmit any packets, unless the user is browsing the net?
In both the above cases, there is a high chance that most of the time the WiFi device does not send any packet, which means none of the WiFi sensors detect it. If that is true, then the whole idea behind WiFi sensor based triangulation in Retail goes for toss, clearly with so many companies working on this, I must be wrong. Please answer with more than a yes or no, as to which packets are generally sent in both the above scenarios.
If wifi is turned on it will periodically search for new networks. This happens even if you are already connected to one, as it allows the device to connect to a 'better' network, if available.
Scanning/network discovery can be done in two ways. First is passive when a device listens to surrounding access point's (AP) beacon frames. These are basically advertisements for their network. The second method is called active. This is the most likely explanation of how the technology you mentioned works. Active scanning is when the device sends out a probe frame asking for available APs. These are generally ones that you have associated with previously, e.g. Your home network. These probes can be listened to from nearby 802.11 (wifi) devices, therefore tracking you.
Active and passive scanning
801.11 frames
As mentioned in #AndrewLeeming answer, one of the causes for data transmission data is scanning.
It's not necessary but normally it will be performed to find a network to connect to (or a better network in case of already connected). Active scanning can be turned off for power saving reasons. Passive scanning doesn't involve transmissions, so it's irrelevant to this question.
However, the most important reason for WiFi devices to transmit packets while connected is to let the AP know that the client is still available. Otherwise the AP will drop the link after a certain period of time without activity. Additionally, the clients might be in power save mode and instruct the AP not to transmit data to them. From time to time the client will inquire the AP to see if there are any pending packets for it.
I have a GSM ModeM connected to a serial port, and I use it so send SMS upon certain events.
Since it is not Plug-and-Play, I am confused as to how I'll detect its connection status. Win APIs like GetCommState will obviously not work.
I could periodically send packets of data and check whether the data is being consumed or not, but I'm wary about the risks of polling over performance and clogging up the buffers which might be in use.
So, is there any other method, or some interrupt based thing, which I could use to check whether is still connected, via a serial port, to my system?
I'd be grateful for any help on this.
Thanks.
From Windows 7 onwards, use Windows Mobile Broadband API to get information about a GSM modem.
Serial ports are very primitive communication devices, they date from the very early days of computing. It is what you plugged your ASR-33 teletype into to start banging in your Fortran program. The only reason they are still around is because they are simple, hardware vendors like them because they don't have to spend money developing and supporting a custom api to use their device.
Still, even back in the sixties did a computer have a need to find out if a teletype was attached. Which is done through the hardware handshake signals. The DSR signal, Data Set Ready, is turned on by the device when it is powered up. If you use the .NET SerialPort class then you can check that signal with the SerialPort.DsrHolding property. If you use the winapi then use GetCommModemStatus(), MS_DSR_ON flag.
That still only tells you that some device is attached. If you want to find out that it is the modem that you wrote your program for then you can interrogate it with AT commands, a protocol that's specific to modems. No vendor implements this exactly the same way but you can usually count on an identification from the modem with the ATI command. Check the programming manual for the modem for details.