BLE CTF Walkthrough

Oct 30, 2019

CTF stands for ‘Capture the Flag’, a means for hackers to test their chops in breaching simulated systems with specific securety flaws. As it happens, hackgnar set up a wonderful Bluetooth Low Energy CTF to teach folks about server client interactions over BLE. I highly recommend you approach this from scratch before looking for help, struggling a bit is often the best way to learn. Unfortunately, I’m shit at BASH programming, so I needed to dive a bit deeper to figure out what the hell I was doing, even with a cursory knowledge of BLE. Here is my walkthrough for those of you with a similar knowledge base.

It’s run off of an ESP32 with freely availble firmware from github, or you can buy pre-flashed versions for $20. I tried the latter, got sick of waiting, and went with the former.

I did the CTF in kali, it works nicely. I also used ‘bleah’, a handy BLE enumeration tool that makes everything much more human readable.

enter ‘bleah’ into your terminal to get a nice view of the bluetooth world around us


Look for a device labeled BLECTF, and find it’s MAC address. Mine was 3c:71:bf:84:b9:ca


Enter bleah -b 3c:71:bf:84:b9:ca -e

-b : connect to a specific mac address -e : ennumerate, make it human readable and pretty

You should get something like this:


You’ve made it to the starting line! Several scripts are reccomended to make things easier - a shell script that submits flags to the correct service in order to score points


gatttool -b $MAC –char-wrte-req -a 0x002c -n $(echo -n “$1”

xxd -ps)

gatttool |use gatttool| -b |feed it a mac address| $MAC |Actual mac address of your BLECTF device| –char-write-req|Make a request to write a character| -a |specify writing to a handle| 0x002c |the handle that stores the score| -n |going to be writing a value| echo |display a line of text| -n ?? NEW LINE? “$1” ?? FIRST CHARACTER INPUT | |pipe it!| xxd |hex dump of a text file -ps |Output in a postscript plain hexdump style

BLE Security for the tech illiterate

Sep 2, 2019

For the vast majority of cases, BLE security flaws come from poor implementation of BLE security practices, NOT from weaknesses in the BLE protocol itself. It’s not about making something that is flawlessly secure, that is a pipe dream. The goal is to make something too secure to be worth breaching, a level which LE Secure Connections Mode meets.

Bluetooth Low Energy Security can be a confusing, garbled mess even for the most astute of wireless developers. As the saying goes, the “S” in “IOT” is for Security. In addition, none of the BLE security features are mandatory, meaning you could encounter any combination of the following features in the wild.

In order to start a connection between two BLE devices, they must undergo a process called Pairing. This involves sharing things like keys in order to allow security capabilities such as encryption to be used. Paired devices can store this information for further use, making them bonded.

This process begins with a Pairing Feature Exchange:

     Initiator:  Sends SMP Pairing Request PDU to Responder


     Responder: Replies with SMP Pairing Response PDU


This Tells each device:


     -LE Legacy or LE Secure Connections?


     -Device Authentication during pairing? What kind?


     -Which key types should be distributed and generated?


     -What key length should the LTK be?


In Control












The request and response PDU: Name Size Function IO Capability What can the device do in terms of input/output. Keyboard only, display only, button only, some combination, none Bonding Flags Whether or not the device wants to store the keys for later use SC Flag 1 bit Supports Secure Connections Pairing MITM Flag 1 bit Requests Authentication as MITM protection OOB Data Flag Sends data over a mechanism other than BLE Maximum Encryption Key Size 7-16 octets (56 to 128 bits) Picks the smaller of the two devices capabilities (must have same size) Initiator Key Distribution LTK, CSRK, and/or IRK Responder Key Distribution LTK, CSRK, and/or IRK

If secure connections can be used, it must be

The Big List of BLE Acronyms:

ATT – Attribute Protocol

BLE – Bluetooth Low Energy

CRC – Cyclic Redundancy Check

CSRK – Connection Signature Resolving Key – used in signing data sent over unencrypted link

DHKey – Diffie Hellman Key

GAP – Generic Access Profile

GATT – Generic Attribute Profile

HMAC – MAC function based upon a hash function

IRK – Identity Resolving Key – used in Bluetooth Privacy feature

LTK – Long Term Key – Used in link encryption

MAC – Message Authentication Codes (Same as MIC)

MIC – Message Integrity Codes (Same as MAC)

MITM – Man in the Middle

NIST – National Institute of Standards and Technology

OOB – Out of Band – Used to exchange keys over non-BLE protocol

PDU – Protocol Data Unit – Single nit of information transmitted

SC – Secure Connections

SMP – Security Manager Protocol

TK – Temporary key – Used in Legacy LE Pairing

Bluetooth for People Not Paid to Care

Aug 16, 2019

Bluetooth Low Energy (BLE) is a low power wireless protocol designed as a cable alternative. It was designed for ease of use and implementation of developers, so as a result can be a bit of a mess.

Bare Minimum:

GAP: Generic Access Profile - How BLE devices discover each other, navigate a way to set up a secure communication channel. These set up the initial connection.

GAP Peripheral: Advertises, accepts connections. (i.e. a fitbit)

GAP Central: Scans for advertising packets, initiates connections (i.e. a smartphone)

There’s also GAP Broadcasters, which advertise but do not accept connections (i.e. a beacon), as well as GAP Observers, which scan for advertising packets, but do not initiate connections (i.e. app looking for beacons)

GATT: Generic Attribute Table - The framework for describing capabilities and descriptors of a BLE device. Made up of Services, Characteristics, and descriptors. This is how connected devices send data back and forth, and the secret sauce of how they work.

Services: Top level, describes what the BLE device does; their primary feature (i.e. heart rate monitor) Contain one or more characteristics. BLE SIG has a long list of predefined services to use in design.

Characteristics: Mid level, individual items of state data. Have a name, a value, and support one or more operations (read/write)

Descriptors: Low level, text description for characteristics regarding content and interaction

Security is covered on a later post