This is not a post about BLE, but rather on how to hack it … well, to be honest, BLE devices are usually very easy to hack, so it’s just a quick intro to it, I’ll also take the chance to open source one of the last tools I’ve made and that I kept private so far. I moved the features I thought to be dangerous ( aka: auto fuzzing all the BLE things and bring chaos ) in a private fork which will stay private, however it’s not that complicated to chain
bleah with other tools ( cough … radamsa … cough ) and have lots of fun.
Oh and this is also because someone asked me some intro on BLE, so yeah, his fault.
For some more detailed (and serious) information, there’s a lot of stuff online already, you know how to Google.
BLE is a cheap and very insecure version of Bluetooth, in which you have no channel hopping (all hail easy sniffing and MITM!) and no builtin protocol security (fuzzing like there’s no tomorrow dudez!), it is mostly used for two reasons:
- Decent batteries are expensive.
- Decent batteries are big.
If you wanna build and sell some IoT-smart-whatever crap, and you wanna do it quickly because your competitor is about to go on the market with the same shit, you take Bluetooth, you strip it from the very few close-to-decent things it has and voilà, you have its retarded little brother which won’t bother the battery too much but will be functional enough to burp random data at you from time to time … easy win, litte R&D efforts, very small production costs.
Being the retarded little brother of BT, it doesn’t really take too long to explain how to hack it.
Imagine you have a BT device, which 99% of the times it’s discoverable, on the same frequency and channel, always, that literally burps at you its information ( what it’s called advertisement data, sometimes they also broadcast security tokens, etc … to anyone … ), you connect to it (because 99.999999% of the times it allows anyone to connect) and the device tells you everything you need to know in order to control it, read data from it and write data to it … how kind, isn’t it? :D
You are provided with read and write primitives / channels ( called
characteristics ), each one with a specific identifier, some of them are standard and some of them are usually vendor specific, therefore you won’t be able to easily map something like
d0611e78-bbb4-4591-a5f8-487910ae4366 to something like
Apple Continuity Service (more on how to solve this problem later).
Rather than this, all the implementation details ( aka: the communication protocol ) are up to the vendor … you see now?
As I was saying yesterday night to Viss, you can approach BLE hacking in two ways.
You can go passive, therefore you’ll need a Ubertooth One to sniff raw BLE packets out of the air and Wireshark to visualize them. In this case you’ll end up performing signal analysis / RE on the raw bitstream you’ve managed to capture, simply try some replay attack or blackbox fuzzing ( aka: throw mutated stuff back at the mother fucker ). As for this first methodology, there’re already plenty of good examples online, it’s just like sniffing TCP, but with BLE.
Or you can go active (the way I like it :D), and that doesn’t require any specific hardware other than a bluetooth dongle which supports BLE, most likely your Linux laptop already does, and exploit those little bastards for what they are, just retarded bluetooth devices. Find the mobile app (they always have one, they’re smart toys after all), reverse it to find the right characteristics to use for your goal and then just blow the thing up. My point is that you’ll end up reversing “something” anyway, so let it be cheap and effective, right?
Let’s start by verifying if your hardware supports BLE by performing a scan ( I’m assuming you are using GNU/Linux, bluez and all the default BT stack utilities are installed, etc ):
sudo hcitool lescan
If it worked, you’ll see an output like:
LE Scan ... AA:BB:CC:DD:EE:FF (unknown) AA:BB:CC:DD:EE:FF STORZ&BICKEL AA:BB:CC:DD:EE:FF (unknown) AA:BB:CC:DD:EE:FF (unknown) AA:BB:CC:DD:EE:FF (unknown) AA:BB:CC:DD:EE:FF (unknown) AA:BB:CC:DD:EE:FF (unknown) AA:BB:CC:DD:EE:FF (unknown) AA:BB:CC:DD:EE:FF (unknown) AA:BB:CC:DD:EE:FF [LG] webOS TV OLED55E6V
I could now explain you how to read advertisement data using
hcitool, how to connect to it using
gatttool and how to enumerate services, characteristics and handles, how to mask flags and translate their bits to permissions, etc … but I made it a little bit easier for you (and for me), so let’s skip this boring stuff ok? :P
But let me give you some examples and swag.
Scanning for BTLE devices continuously:
sudo bleah -t0
Connect to a specific device and enumerate all the things:
sudo bleah -b "aa:bb:cc:dd:ee:ff" -e
Write the bytes
hello world to a specific characteristic of the device:
sudo bleah -b "aa:bb:cc:dd:ee:ff" -u "c7d25540-31dd-11e2-81c1-0800200c9a66" -d "hello world"
Hint: there’s a
--data-file argument which is perfect in combination with things like
radamsa … just saying.
As usual the public fork of this tool is on github, now you know and have everything you need to bring chaos in the BLE world, enjoy :D