Updates: 09/June/2021: The tools developed are still experimental. Expect several bugs/fixes over the next weeks.
The ble harverster connects to any device (be default) found in range and starts cloning and storing. Firstly, the tool initiates discovery and then retrieves all values for all characteristics found. The result for each target are saved on a json file.
Running the tool (all dependencies/libraries are included):
java -jar ble_harverster.jar
The tool can be configured by a configuration file named
When a configuration file exist, the following parameters can be configured:
- whitelist.names: Whitelisted targets (scan only the specified addresses - string array - delimiter: space)
- connection.attempts: Maximum failed trial attempts per target (int)
- connection.interval.min: Minimum connection interval configuration (int)
- connection.interval.max: Maximum connection interval configuration (int)
- connection.supervision: Connection supervision configuration (int)
BLE MiTM Server
The ble server allows for remote clients (only android client exists at the moment) to connect and control the BLE:Bit devices that are attached to the same machine. Once the client is connected, the target address can be configured. The ble server works as a man-in-the-middle between two ble devices. One pre-requisite is that the two devices must not be connected before starting the ble server.
How it works:
Once the target device is found, a connection is made between the BLE:Bit Central an the target peripheral. That is to make sure the target central won't be able to find the target peripheral device when in range. In BLE, the most devices (99%) aren't configured to connect to more than one device at a time. That way, when a device is connected with another device (ie our BLE:Bit central with target peripheral) other devices cannot initiate a connection with the particular one. This is because the device stops advertising while is connected, and its state is changed. Therefore, in most occasions the bluetooth stack and developer's logic disallows the device to advertise or to receive connections from other devices. Exploiting this behavior, our attack relies on the absence of advertisements by the target peripheral. While the target peripheral is connected wth us, we now wish the target central to be in range. This is where BLE:Bit Peripheral comes in place. The BLE:Bit peripheral starts advertising in order to convince the target central (ie an android device) to connect to our device. The BLE server makes sure that the BLE:Bit peripheral advertisement packets, mac address and offered services/characteristics will have the exact same data as the target peripheral. There is no other way for the target central, to make sure that the device is not which we claim we are. Then, the device will try to initiate a connection and all traffic is transferred from BLE:Bit Peripheral to BLE:Bit Central via the BLE server (as those are two different devices) and then, the BLE:Bit Central will forward that to target peripheral. That also works in vice versa. It must be said, that when the two devices are previously paired, and those devices ARE BOTH properly configured to disallow repairing, we cannot apply any man-in-the-middle as the connection will be "secure" (more attacks exist).
java -jar BLEBit_Server.jar
Connect with the android client:
Intercept and replay by swiping any packet to the right:
Scan for available devices.
java -jar scanner.jar
ttyS0 - Physical Port S0 ttyUSB1 - USB-to-Serial Port (cp210x) --------------- BLE:Bit found @ ttyUSB1 Devices Found: 1 Connection Parameters Set Successfully Set Address Successfully SDK Version: 17 CE FW Version: 17 --------------- Address Address Type RSSI Device name ff:ff:df:10:8d:f9 Public -89 M5 ff:ff:df:10:8d:f9 Public -88 M5 ff:ff:ff:30:22:1f Public -96 LT719 ff:ff:df:10:8d:f9 Public -87 M5 ff:ff:df:10:8d:f9 Public -87 M5
Enumerate the services and characteristics.
java -jar ble_enumerator.jar
ttyS0 - Physical Port S0 ttyUSB3 - USB-to-Serial Port (cp210x) --------------- BLE:Bit found @ ttyUSB3 Devices Found: 1 Connection Parameters Set Successfully Set Address Successfully SDK Version: 17 CE FW Version: 17 --------------- Listening for... c7:f6:85:7b:8b:24 Connecting to S20 Device Connected - Client Address: c7:f6:85:7b:8b:24 PRIVATE (4) 6e400001-b5a3-f393-e0a9-e50e24dcca9e (15) 6e400002-b5a3-f393-e0a9-e50e24dcca9e (WCMD,W,) Handle: 21 (16) 6e400003-b5a3-f393-e0a9-e50e24dcca9e (N,) CCCD:19 Handle: 18 (3) 00001812-0000-1000-8000-00805f9b34fb (11) 00002a4b-0000-1000-8000-00805f9b34fb (R,) Handle: 38 (12) 00002a33-0000-1000-8000-00805f9b34fb (R,W,N,) CCCD:41 Handle: 40 (13) 00002a4a-0000-1000-8000-00805f9b34fb (R,) Handle: 43 (14) 00002a4c-0000-1000-8000-00805f9b34fb (WCMD,) Handle: 45 (7) 00002a4e-0000-1000-8000-00805f9b34fb (R,WCMD,) Handle: 24 (8) 00002a4d-0000-1000-8000-00805f9b34fb (R,W,N,) CCCD:27 Handle: 26 (9) 00002a4d-0000-1000-8000-00805f9b34fb (R,W,N,) CCCD:31 Handle: 30 (10) 00002a4d-0000-1000-8000-00805f9b34fb (R,W,N,) CCCD:35 Handle: 34 (2) 00001800-0000-1000-8000-00805f9b34fb (2) 00002a00-0000-1000-8000-00805f9b34fb (R,) Handle: 7 (3) 00002a01-0000-1000-8000-00805f9b34fb (R,) Handle: 9 (4) 00002a02-0000-1000-8000-00805f9b34fb (R,) Handle: 11 (5) 00002a04-0000-1000-8000-00805f9b34fb (R,) Handle: 13 (6) 00002aa6-0000-1000-8000-00805f9b34fb (R,) Handle: 15 (1) 00001801-0000-1000-8000-00805f9b34fb (1) 00002a05-0000-1000-8000-00805f9b34fb (R,W,N,I) CCCD:4 Handle: 3