Exploring Bluetooth & iBeacons – from software to radio signals and back.

This is the story of my Bluetooth hacking adventures. If you want to start with BTLE hacking right away, feel free to jump over to the 2nd (technical) part, otherwise read on as I share my BT exploration findings and thoughts.

NOTE: When I refer to BT I also mean BTLE, which as everyone already concluded, aside from the name and the frequency range, it got nothing todo with good-old-BT, but it’s there, so we’re including BTLE as part of our BT attack vector.

As I usually do with a new target, I go for the sources – I started with looking at the BT stack itself – both on Linux and on Android, since apparently they are not the same. Google switched the Android BT stack from BlueZ – the default Linux BT stack – to their own BT stack named BlueDroid, which obviously made all my Linux BT tools & sources obsolete. It seems when Google set to replace BlueZ with their own home-grown BlueDroid, the reason speculated was licensing issues – BlueZ is GPL and Android and its eco system are Apache (yea, well, aside for the closed-source parts held by Google whilst ignoring the elephant in the room – the GPL Linux kernel). However, if you compare the sources of the two projects from a commercial point of view, you notice two big names who contributed most of the code to each project – Intel @ BlueZ and Broadcom @ BlueDroid, which makes me think something else was involved.

On with my target, I then looked at some of the existing BT attacking tools and hacked their sources to get a better understanding of what was going on. Some of the interesting tools are:

• atshell – opens a connection to a BT target on curtain channel
• attest – save as above, will also blindly try to retrieve contacts, calls, etc
• bluesnarfer – same as above, but with more options
• bt_dos – denial of service attack on a BT target

(more info here: http://tools.kali.org/tag/bluetooth)

I continued with looking at the BT documentation (over 2700 of pages long, 8 volumes, hundreds of revisions, and thats apart for BTLE) and was pretty confident I will find some problematic implementation of such an horrifying design. Returning to the BT stack source code confirmed my feeling and I found some promising leads which I wanted to follow. I first mapped my target frequencies:

BT has 79 Channels:

channel 00 : 2.402000000 Ghz
channel 01 : 2.403000000 Ghz
channel 02 : 2.404000000 Ghz
…
channel 78 : 2.480000000 Ghz

BTLE has 40 Channels:

channel 37 : 2.402000000 Ghz
channel 00 : 2.404000000 Ghz
channel 01 : 2.406000000 Ghz
channel 02 : 2.408000000 Ghz
channel 03 : 2.410000000 Ghz
channel 04 : 2.412000000 Ghz
channel 05 : 2.414000000 Ghz
channel 06 : 2.416000000 Ghz
channel 07 : 2.418000000 Ghz
channel 08 : 2.420000000 Ghz
channel 09 : 2.422000000 Ghz
channel 10 : 2.424000000 Ghz
channel 38 : 2.426000000 Ghz
channel 11 : 2.428000000 Ghz
channel 12 : 2.430000000 Ghz
channel 13 : 2.432000000 Ghz
channel 14 : 2.434000000 Ghz
channel 15 : 2.436000000 Ghz
channel 16 : 2.438000000 Ghz
channel 17 : 2.440000000 Ghz
channel 18 : 2.442000000 Ghz
channel 19 : 2.444000000 Ghz
channel 20 : 2.446000000 Ghz
channel 21 : 2.448000000 Ghz
channel 22 : 2.450000000 Ghz
channel 23 : 2.452000000 Ghz
channel 24 : 2.454000000 Ghz
channel 25 : 2.456000000 Ghz
channel 26 : 2.458000000 Ghz
channel 27 : 2.460000000 Ghz
channel 28 : 2.462000000 Ghz
channel 29 : 2.464000000 Ghz
channel 30 : 2.466000000 Ghz
channel 31 : 2.468000000 Ghz
channel 32 : 2.470000000 Ghz
channel 33 : 2.472000000 Ghz
channel 34 : 2.474000000 Ghz
channel 35 : 2.476000000 Ghz
channel 36 : 2.478000000 Ghz
channel 39 : 2.480000000 Ghz

I then put together a simple wrapper around hcitools to perform periodic inquiry and sniff the results, and automatically execute the various BT attack tools upon a newly detected target. This resulted in lots of information retrieved (many phones still provide their contacts list, many BT audio-devices allows connecting using ‘1234’ as pin, etc) but no active attack. It then dawned on me I can no longer avoid using my HackRF if I want to achieve active attacks – the BT tools nor the firmware on my Laptop (nor on my Android) allows much to be played with and I didn’t feel like reversing the firmware is a good idea… so HackRF it is.

I found that Jiao Xianjun was working on a BTLE decoder/encoder and was able to successfully replay iBeacons using his hackrf, so I fired up hackrf_transfer and started playing with recording BTLE channel 37 (one of 3 BTLE advertising channels) on 2.402ghz frequency while sending iBeacons from my laptop, and then replaying the sniffed data – but nothing worked – nothing seemed to be appearing on Gqrx nor in SDRSharp. Was I doing something wrong? I double checked everything, and even made a GNURadio flow for debugging – but same results – nothing was appearing on my 2.402 spectrum. I concluded my antenna which is designed for 75mhz-1ghz range was to blame, and I decided to wait until I get a decent 2.4ghz antenna. The day after I got such antenna (actually I cheated – I took a female SMA 2.4ghz antenna and inserted a pin turning it into a male), plugged it to my hackrf – same results. Now I knew I was doing something wrong, but what was it?

Gain.

The hackrf is very picky about its gain values, and it seems each SDR GUI program behaves differently with different gain values. Once I found the correct values (the values used for each program including hackrf_transfer were different for each) I finally was able to watch my iBeacons and replay them to my enjoyment. I also tried to watch for some interesting data in real time, first using gr-bluetooth but that failed miserably with ‘general protection fault’ errors and I’m guessing thats due to lack of project updates, and so I proceeded to NRF24-BTLE-Decoder which worked nicely with hackrf_transfer as follows:

# hackrf_transfer -r /dev/stdout -f 2402000000 -a 1 -g 16 -l 32 -s 8000000 | nrf24-btle-decoder -d 2

Although decoding was wrong, it was still nice to get some results from the decoder (I’m suspecting the sample rate is wrong here, but too lazy to investigate this further).

HTH.

Recording & replaying an iBeacon:

1. Start sending iBeacons from your computer:

# hciconfig hci0 leadv
# hciconfig hci0 noscan
# hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 00 00 00 C8 00

2. Start recording channel 37 using hackrf_transfer:

# hackrf_transfer -r ibeacon.raw -f 2402000000 -g 16 -l 32 -a 1 -s 8000000 -b 4000000

3. Watch for iBeacons on your iPhone or Android (I used this but you can use any other iBeacon detector) and press CTRL-C on hackrf_transfer once you see an iBeacon on your scanner and stop sending iBeacons:

# hciconfig hci0 noleadv
# hciconfig hci0 piscan

4. Replay your iBeacon from HackRF:

# hackrf_transfer -t ibeacon.raw -f 2402000000 -x 47 -a 1 -s 8000000 -b 4000000

You might need to replay it quickly simultaneously a few times to make the iBeacon get detected. Try something like this (loops 50 times):

# for i in {1..50}; do hackrf_transfer -t ibeacon.raw -f 2402000000 -x 47 -a 1 -s 8000000 -b 4000000; done

5. To further optimize the file to filter out the noise and manually select the BTLE signal we are interested at, we need to open Audacity and import the ibeacons.raw file using the following options:

File > Import > Raw Data

Now search in the file for something which looks like this nice bluetooth wave (depends on your zoom level):

Select this signal on Audacity, and multiply it at least 10 times in a new file. Result should look something like this:

Export the new file using the following options:

File > Export Audio > Other uncompressed files > Options

And enjoy your replayed file:

# hackrf_transfer -t ibeacon_new.raw -f 2402000000 -x 47 -a 1 -s 8000000 -b 4000000

Advertisement