How likely are low-cost BLE trackers to fall to passive eavesdropping or MITM?
Capturing pairing + sync traffic with an nRF sniffer under realistic conditions.
Security & privacy analysis of low-cost fitness trackers over Bluetooth Low Energy.
A final-year research project by Wiktor Knapik — intercepting BLE traffic, simulating MITM attacks, and reverse-engineering companion Android apps for four budget wearables bought on Temu, AliExpress and Shein.
┌──(kali㉿kali)-[~] └─$ lsusb | grep -i bluetooth Bus 001 Device 002: ID 1915:552a Nordic Semiconductor ASA nRF Sniffer for Bluetooth LE Bus 001 Device 004: ID 13d3:3617 IMC Networks Bluetooth Radio Bus 001 Device 022: ID 2357:0604 TP-Link TP-Link Bluetooth USB Adapter Bus 001 Device 023: ID 2357:0604 TP-Link TP-Link Bluetooth USB Adapter ┌──(kali㉿kali)-[~] └─$ sudo systemctl start bluetooth $ sudo hciconfig hci1 up $ sudo hciconfig hci2 up $ sudo python3 ~/evil_twin_tracker.py ================================= EVIL TWIN - Fake Device ================================= [ATTACK] EVIL TWIN TRACKER IS ADVERTISING! [ATTACK] Waiting for victim …▍
Abstract
What the project investigates and why it matters.
Four very cheap fitness trackers — the kind you can add to your basket on Temu, AliExpress or Shein for a handful of euros — are put through a full BLE security pipeline. Everything runs from a persistent Kali Linux USB using Wireshark, an nRF52840 sniffer, nRF Connect, mitmproxy, Burp Suite and MobSF to capture BLE traffic, test MITM capabilities, and dissect each companion Android app.
These aren’t meant to be lab-perfect attacks. The goal is to show what a curious, motivated individual with a laptop, basic tooling and a handful of YouTube tutorials could realistically pull off — and whether paying a few euros for a tracker silently exposes your health data. Findings are mapped to the OWASP IoT and Mobile Top Ten, and the project closes with practical recommendations for both consumers and manufacturers.
BLE 4.2 / 5.x
Passive eavesdropping
Active MITM
APK static analysis
OWASP IoT Top 10
OWASP Mobile Top 10
Research questions
Four questions driving the methodology.
Can a realistic attacker impersonate a tracker to the companion app?
Building an Evil Twin using a laptop + TP-Link adapters and feeding the app fabricated health data.
What private data could someone extract with basic tooling?
Heart rate, steps, routines, notifications, identifiers — what leaks, and how loudly.
Do companion apps help or hurt the overall security posture?
Static analysis of each APK — permissions, hardcoded keys, endpoints, BLE code paths.
Threat model
An attacker within BLE range, low skill, off-the-shelf gear.
Attacker profile
- Physically close to the target — a gym, office, café, shared flat.
- Laptop running Kali Linux from a persistent bootable USB.
- A BLE sniffer dongle (nRF52840) + TP-Link Bluetooth Nano adapter.
- No privileged access — only tools anyone can buy or download.
Two attack paths
- Passive eavesdropping. Listen to pairing + GATT traffic between the tracker and the phone, decode in Wireshark.
- Active MITM / GATT access. Relay between tracker and phone with btlejack, or fall back to pairing the tracker directly to Kali via the TP-Link adapter to poke at GATT characteristics.
Toolkit
Everything the attacker carries in their bag.
Kali Linux
Persistent bootable USB — keeps host OS untouched and preserves configs across sessions.
Wireshark + nRF Sniffer
Capture and decode BLE frames via an nRF52840 USB dongle. Logs pairing and sync sessions; flags plaintext vs. encrypted payloads.
nRF Connect (Desktop & Mobile)
Scan BLE advertisements, enumerate GATT services & characteristics, monitor advertising packets.
mitmproxy
Transparent HTTP/S interception for the companion app ↔ backend traffic.
Burp Suite
Find insecure API calls and TLS misconfigurations on the companion app’s backend.
btlejack
CLI for BLE relay, connection hijacking, and adapter management.
MobSF
Static analysis of each companion APK — permissions, hardcoded values, risky manifest entries.
nRF52840 Dongle + TP-Link Nano
Primary sniffer + secondary BLE interface for when phone-based MITM doesn’t pan out.
Attack workflow
The same eight steps, applied to every device.
-
01
Scan advertisements
Use nRF Connect + Wireshark to collect BLE advertisement packets from the tracker.
-
02
Fingerprint GATT
Record MAC address behaviour (static vs. rotating) and enumerate GATT services exposed by the device.
-
03
Passive sniff
Capture pairing + sync traffic passively to observe the pairing method actually in use.
-
04
Plan B — direct pair
If the phone relay fails, pair the tracker directly to Kali via the TP-Link adapter and interact with GATT characteristics.
-
05
Evil Twin attack
Using the Kali laptop and two TP-Link Nano adapters, advertise a clone of the real tracker — same name, same service UUIDs — from evil_twin_tracker.py. One adapter impersonates the watch to the phone, the other holds the link so the companion app believes it’s talking to the genuine device. Once the app latches onto the fake, the script pushes forged GATT notifications (heart rate, step count, battery) to see what the app trusts, stores and forwards to its backend.
-
06
Log & timestamp
Every capture is saved, tagged by device name, date/time and connection method for later comparison.
-
07
APK reverse engineering
Run each companion APK through MobSF; inspect permissions, hardcoded endpoints and BLE-handling code paths.
-
08
Intercept backend
Proxy the companion app’s HTTPS traffic with mitmproxy and Burp Suite to spot insecure API calls.
Devices under test
Four unbranded budget trackers bought from Temu, AliExpress and Shein.
01
R50
Companion app · Da Fit
- Companion app
- Da Fit
- MAC address
- 2A:E3:B0:5F:28:31
- Status
- Primary target — Evil Twin attack reproduced end-to-end.
02
H13
Companion app · FitPro
- Companion app
- FitPro
- MAC address
- 41:42:07:37:64:85
03
V15Z
Companion app · H Band
- Companion app
- H Band
- MAC address
- 00:EF:CF:2F:16:FE
04
HT37
Companion app · FitCloud Pro
- Companion app
- FitCloud Pro
- MAC address
- 41:42:70:F1:59:FF
Evaluation metrics
Every device is scored against the same criteria.
Pairing methodJust Works · Passkey · LE Secure
GATT encryptionPresent · Partial · Absent
Passive eavesdropSuccess rate per device
Active MITMEvil Twin attack outcome
MAC behaviourStatic vs. rotating
App permissionsRequested vs. needed
Hardcoded valuesKeys, endpoints, secrets
OWASP mappingIoT & Mobile Top 10
Hypothesis
Lower price ⇒ fewer engineering hours spent on BLE security. The cheaper trackers are expected to lean on Just Works pairing, skip encryption on non-standard GATT characteristics, and ship companion apps with over-broad permissions and hardcoded endpoints.
Project files
Downloadable deliverables — research, report and proposal.
Files will be attached here as each deliverable is finalised.