BLE on less on sec

Reversing the FT100 BLE Fitness Bracelet

Thu, 12 Mar 2026 09:00:00 +0200

The device

The device is called FT100 Fitness Bracelet by TWENTYFIVESEVEN and it offers some basic features such as heart rate and blood pressure monitoring, step count, music control, notifications handling, a find device functionality, and OTA firmware update.

It features a display and a soft touch button, and it is possible to use the manufacturer’s app to configure the device via BLE connection.


FT100 Fitness Bracelet

The watch features a PHY6202 MCU, 512Kb of ROM, 16Kb of RAM and a whopping 50mAh battery (that I promptly swapped with an external power supply as it was giving me troubles).

The companion app Lefun Health allows interaction with device’s functionalities. It offers “data aggregation” features such as recording sport activity or sleep quality. The app itself works ok-ish but it has frequent ads, it often asks for additional permissions and it tries to push to users some unrelated AI services made by Lefun. It’s not my favorite app, but it is good enough to work with.


Lefun App

What I’ll do in this article is try to instrument the android companion app to access BLE traffic between smartphone and our smartwatch to attempt reverse engineering the communication.

Sniffing the BLE traffic with frida

In order to target the functionalities on the FT100 it is necessary to gain visibility of the BLE traffic exchanged between the phone and the bracelet. So we need to work toward that.

To be completely fair, there are multiple ways that could be used to dump the BLE traffic in this exact situation, with android HCI Snoop log being my usual choice. However I’ve been working on mobile applications a lot more recently, I’ve recently checked out this article which uses a similar technique and I figured this project would be a nice way to get practice working with frida, so I decided to go for this way. This method could also come in handy when working on a non-rooted android device as usually there is no access to HCI logs, and a frida gadget could be patched into the apk, bypassing the need for root access.

The first step here would be to perform a static analysis of the apk. Using jadx I decompiled the apk and started digging for clues on the right point to hook into.

During static analysis, the obvious first attempt was to look for and attempt hooking android default functions to handle BLE GATT events in BluetoothGattCallback class. Ideally we would need at least access to onCharacteristicChanged() and onCharacteristicWrite() to intercept characteristic writes and GATT notifications traffic. But simply hooking these functions I was only able to intercept traffic for writes. After further analysis I realized the app was not using the base Android BluetoothGattCallback, but instead some of these functions would be overridden by anonymous classes. So I needed to reliably hook the override implementations used at runtime in order to access incoming data.

The turning point was identifying BluetoothDevice.connectGatt() as the universal entry point for every BLE connection. This method always receives the actual callback instance as an argument. By hooking all overloads of connectGatt() and dynamically extracting the runtime callback class (callback.$className), it became possible to hook the correct implementation of the target functions regardless of anonymous inner classes as observed in jadx.

var BluetoothDevice = Java.use("android.bluetooth.BluetoothDevice");

    var hookedCallbacks = {};

    BluetoothDevice.connectGatt.overloads.forEach(function (overload) {

        overload.implementation = function () {

            logSection("connectGatt intercepted");

            for (var i = 0; i < arguments.length; i++) {
                console.log("arg[" + i + "] = " + arguments[i]);
            }

            // Callback is always argument index 2 in all overloads
            var callback = arguments[2];

            if (callback) {

                var className = callback.$className;
                console.log("[+] Real callback class: " + className);

                hookGattCallback(className);
            }

            return overload.apply(this, arguments);
        };
    });

Then inside the hookGattCallback function each interesting function can be hooked explicitly like this:

if (Callback.onCharacteristicChanged) {
                Callback.onCharacteristicChanged
                    .overload(
                        "android.bluetooth.BluetoothGatt",
                        "android.bluetooth.BluetoothGattCharacteristic"
                    )
                    .implementation = function (gatt, characteristic) {

                        var value = characteristic.getValue();

                        logSection("BLE RX (Notification)");
                        console.log("Device : " + gatt.getDevice().getAddress());
                        console.log("Service: " + characteristic.getService().getUuid());
                        console.log("Char   : " + characteristic.getUuid());
                        console.log("Data   : " + bytesToHex(value));
                        console.log("ASCII  : " + bytesToAscii(value));

                        return this.onCharacteristicChanged(gatt, characteristic);
                    };
            }

With this method it was possible to achieve full visibility over the BLE events including characteristic read and writes, as well as notifications. Now it’s time to analyze the protocol.

GATT traffic overview

We can now check out the extracted data from the frida hooks and having access to GATT level operations, we can start digging into the protocol. Now, if you’ve worked with BLE before you will surely know GATT in more or less details, but if you don’t, feel free to check out this post on solving BLE CTF on esp32 I go through basics there.

For the sake of clarity, let’s explicit that the stack we are working with looks something like this:

App protocol
     ↓
GATT characteristic
     ↓
ATT packets
     ↓
BLE link

For the scope of the article, we may as well just consider App protocol and GATT characteristics.

Picking out a few messages we can start figuring out what’s going on under the hood:

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 05 31 01 bf
ASCII  : ..1..

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 05 06 00 a2
ASCII  : .....

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE RX (Notification)
======================================
Device : C0:00:A1:A2:1F:04
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d00-0000-1000-8000-00805f9b34fb
Data   : 5a 09 06 00 00 a0 32 14 79 00 00 00 00 00 00 00 00 00 00 00
ASCII  : Z.....2.y...........

From these few exchanges we can already tell a few things about the protocol: first off the protocol lives on top of service 000018d0-0000-1000-8000-00805f9b34fb which doesn’t appear to be a standard GATT service.

The app writes on char 00002d01-0000-1000-8000-00805f9b34fb (handle 0x002b) and the BLE notifications from the smart band are received on char 00002d00-0000-1000-8000-00805f9b34fb (handle 0x002e).

We can also see that some commands from the app trigger a response from the device through a BLE notification, and some other don’t.

In order to understand the semantics of the protocol, we need to observe some more traffic. For brevity, char writes by the app will be marked as TX, while BLE notifications from the smartband will be marked with RX.

[TX] AB 05 56 01 8B
[TX] AB 05 E0 01 23
[TX] AB 0A 39 00 01 02 D0 06 40 23
[TX] AB 05 51 00 BB
[TX] AB 05 31 01 BF
[TX] AB 05 06 00 A2
[RX] 5A 09 06 00 00 A0 32 14 79 00 00 00 00 00 00 00 00 00 00 00
[TX] AB 04 00 0C
[RX] 5A 14 00 FF 27 14 F1 50 31 39 02 01 02 32 19 54 4A 44 50 16
[TX] AB 04 03 EE
[RX] 5A 05 03 23 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[TX] AB 04 70 F4
[TX] AB 05 22 00 58
[RX] 5A 07 22 00 1F FF 06 00 00 00 00 00 00 00 00 00 00 00 00 00

Messages are tagged with an header depending on the direction of the communications, char writes from phone to device always have 0xAB header, while notifications have a 0x5A header. Additionally notifications always seem to be padded to 20 bytes (padding with zeros).

The other bytes seem to have a straightforward meaning as well, the second byte is in fact the length of the message, while the third and fourth bytes seem to be command bytes (CMD, SUB-CMD).

Reversing the protocol

Now, we could start black box reversing from these messages, but it would be pretty hard to make progress, both because some messages don’t produce an observable result and because payloads and message sending is out of our control. It would be wise to start somewhere simpler and more controlled.

Find my device

From the app, it is possible to use the find my device functionality to have the smarband buzz three times to help the owner find it. This functionality seems straightforward, so for the time being, we can ignore other messages and we can try to intercept the find my device messages only:

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 04 09 90
ASCII  : ....

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE RX (Notification)
======================================
Device : C0:00:A1:A2:1F:04
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d00-0000-1000-8000-00805f9b34fb
Data   : 5a 05 09 01 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ASCII  : Z...................

We see that the smartphone app writes payload ab 04 09 90 on the target service characteristic, it triggers the find my device behavior on the smartband.

Surely enough, if we try on our own, connect to the smartwatch and write on characteristic 00002d01-0000-1000-8000-00805f9b34fb the value ab 04 09 90 we can trigger device vibration.

This can be done quite simply with gatttool -b [MAC] --char-write-req -a 0x002c -n ab040990. (gatttool is technically deprecated, but I was having issues with pairing using bluetoothctl, so I figured it would be alright for quick testing).

NOTE: I wish I had a GIF of the device reacting to the command, but as I’m writing this article I just broke the device screen. My bad.

This was fun, but let’s dig deeper.

Notification handling

We can move on and reverse engineer how smartphone notifications are forwarded to the device. We can trigger android notifications on the smartphone and have the Lefun app relay the notification to the smartband to observe the payloads.

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 12 17 14 01 01 01 74 65 73 74 3a 20 74 65 73 74 67
ASCII  : .......test: testg

For this test, the notification is a whatsapp notification and the text shown on the screen is: test: test. We can see from the logs of our instrumented app that we see ab121714010101746573743a207465737467 payload written to the characteristic with handle 0x2c. By converting it in ASCII we can see that the text payload is shared in cleartext as 746573743a2074657374 is the hex for ASCII test: test. Last byte looks suspicious and I’m sure it’s some kind of CRC, but we will figure this out later.

Based on what we know, we can make an educated guess and suppose that the base message frame looks something like this:

Offset	Field	Note
0	Header	`0xAB` (phone to device)
1	Length	Length of the message
2	Command ID	In case it is a `0x5A` message, it mirrors the command byte
n..m	Payload	Command payload (optional)
last	CRC	?

This fits both the notification message format and the find device message format.

Now, we can replay our notification countless time, but can we modify it? If we change the ASCII payload, we see that the smart band doesn’t react to the message anymore even adjusting the length byte. And just like that, now it’s the perfect time to figure out the CRC.

So we attempt using reveng to understand which CRC we are working with and surely enough it gives us a result:

./reveng -w 8 -s ab121714010101746573743a207465737467

width=8 poly=0x31 init=0x00 refin=true refout=true xorout=0x00 check=0xa1 residue=0x00 name="CRC-8/MAXIM-DOW"

Now, it is possible to implement the function to calculate the CRC and we can start creating valid messages.

Minding the CRC and the length byte, we can generate our own notifications commands to send to the device.


Custom notification

Only one last step is missing for full notification handling as we know the longest payload we can send on the exchanged MTU is 20 bytes. Now, if we remove, header, length, command ID and CRC bytes we are left with 16 bytes for the notification text, which is not much… Also we kind of figured out the packet format, but it doesn’t account for every byte in notification messages. It would make sense for there to be one or more bytes to handle some type of data fragmentation, to handle payloads longer than 16 bytes.

So I’ve sent a dozen of notifications to the smartwatch using the phone and I was able to figure the notification message format out almost entirely: As anticipated we confirm we have a fragmentation mechanism, in particular 2 extra bytes that specify the total fragment number and the current fragment. Then by experimenting I figured out two more bytes that are part of the notification message format which I called sub-command and extra bytes.


Fragmented custom notification

The sub-command byte specifies the notification icon that will be shown on the smart band screen. By creating and sending notification messages to the device, it was possible to compile a list of sub-commands and their respective notification type.

Code	Icon
1	Call
2/3	SMS
4	Snapchat
5/6/7	SMS
8	SMS (style 2)
16/17	Facebook
18	Twitter
19	LinkedIn
20	WhatsApp
21	Line
22	Talk
23	Facebook messenger
24	Instagram
25	WhatsApp Business

Some icons appear on the FT100 for multiple sub-command values. This might be due to the fact that not all the supported notification types have a dedicated icon, but I’m just guessing.

To this day I’m not sure what the extra byte is there for. Sometimes it gets printed as a normal character, sometimes it doesn’t.

The notification message format is completely reconstructed as follow:

Offset	Field	Note
0	Header	`0xAB` (phone to device)
1	Length	Length of the message
2	Command ID	`0x17`
3	Sub-command
4	Total Fragments	Total number of fragment for messages longer than 20 bytes
5	Fragment Index
6	Extra
n..m	Payload	ASCII data
last	CRC8	CRC-8/MAXIM-DOW

Finally, whenever I see fragmentation I have to try and mess with it a little bit and I noticed a weird behavior. Fragment indexes are 1 based, and the device starts buffering fragments at index 1 as expected, however, if a second message sets fragment index = 1, the first chunk of buffered message gets overwritten. The funny part is that fragment 1 is the only one that shows this behavior. Fragments with indexes greater than 1 will be buffered in order of arrival (and not depending on the frame number) until one message with fragment index = total fragments is written on the target characteristic, again not dependent on the actual number of frames received.

Weather data push

Just because there’s way too much stuff to ignore it all, I wanted to reverse engineer another message type: weather data push. I’m not sure if this happens periodically while using the app, but it is possible to trigger a manual weather data push in the app, so it was kind of easy to experiment with this feature as well.

For the first time, the menu item for this functionality appears on the device only if a weather push has been performed before.

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 08 2a 00 08 0f 05 28
ASCII  : . . . . . . . . (

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE RX (Notification)
======================================
Device : C0:00:A1:A2:1F:04
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d00-0000-1000-8000-00805f9b34fb
Data   : 5a 05 2a 01 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ASCII  : Z...................

Again, I’ve sent a few of these messages and figured out the packet format:

Offset	Field	Note
0	Header	`0xAB` (phone to device)
1	Length	Length of the message
2	Command ID	`0x2A`
3	Sub-command
4	Extra
5	Max Temp	Maximum temperature value
6	Min Temp	Minimum temperature value
last	CRC8	CRC-8/MAXIM-DOW

Sub-command values in this case change the weather icon shown in the weather menu. Values in this case are:

Code	Icon
0	Sun
1	Cloud + Sun
2	Rain
3	Snow
4	Cloud

Any other value will default to cloud icon.

Here too, no image of the smartwatch because I broke the screen, it sucks I know.

Watchface data push

I meant to keep the analysis of this feature for a part 2 of the article, but as the screen is now broken I figured it was worth wrapping up what I have done to this point.

After identifying several control commands, I wanted to understand how the companion app uploads custom watchfaces to the device. Capturing a full update revealed that the process consists of two distinct phases: a short control exchange that prepares the watch for the transfer, followed by a large stream of fragmented image data.

The actual watchface image is transmitted as a sequence of packets written on the same BLE characteristic used for other commands. Unlike the notification and weather packets analyzed earlier, these frames do not include a length byte. Instead, they are simple fragments of raw pixel data indexed with a 16-bit counter. The start of image stream is probably set up by previous communications.

Typical fragments look like this:

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 2c 00 00 79 ce 00 00 08 42 c7 39 e7 39 c7 39 08 42 c7 39
ASCII  : .,..y....B.9.9.9.B.9

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 2c 00 01 c7 39 e7 39 e7 39 a6 31 e8 41 a6 31 c7 39 e7 39
ASCII  : .,...9.9.9.1.A.1.9.9

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 2c 00 02 c7 39 e7 39 c7 39 08 42 21 08 e3 18 86 31 04 21
ASCII  : .,...9.9.9.B!....1.!

======================================
BLE WRITE ACK
======================================
Status : 0

======================================

By analyzing multiple captures it becomes clear that these packets implement a simple fragmentation scheme.

Offset	Field	Note
0	Header	`0xAB` (phone to device)
1	Command ID	`0x2C`
2	Index (MSB)	Fragment index high byte
3	Index (LSB)	Fragment index low byte
4..n	Payload	Raw image data
last	CRC8	CRC-8/MAXIM-DOW

The index field increments sequentially for each fragment, allowing the watch to reconstruct the full image stream.

Once all fragments are concatenated in order, the resulting byte stream contains nothing but pixel data. Now, it was easy to determine how images were sent, but it took a lot of fiddling to make sense of the data.

There are still two unknowns:

Data format
Image size

What I did was use an “easy to debug with” image, I decided to go for a numbered chess board.

I then captured the traffic when performing the upload operation, wrote a small parser that extracts 0xAB 0x2C packets from the BLE dump, sorts them by fragment index, and rebuilds the binary stream. I then tried using different image encoding formats to interpret the payload. I was eventually able to determine that the correct one was RGB565. I focused on common color encodings used in embedded displays, and the payload started to make sense when decoded this way.

Finding out the image size took longer to figure out as at first it wasn’t clear if or how metadata was included in the extracted binary blob. After a few attempts and a couple of hours spent staring at badly distorted images, it was possible to understand that the size is 80 x 160 pixel.


Badly reconstructed image

The correctly extracted watchface image looks like this:


Reconstructed image

This fragmentation approach is fairly typical for BLE devices: instead of relying on large MTU sizes, the application simply slices the image into fixed-size chunks and transmits them sequentially. The watch then reassembles the data internally before updating the displayed watchface.

Now that the format of the watchface stream is understood, the next logical step would be to reproduce the process in reverse, however, I didn’t get to achieve this as I broke the watch.

Response message format

While we are at it we might as well formalize the response format, which looks something like this:

Offset	Field	Note
0	Header	`0x5A` (device to phone)
1	Length	Length of the message
2	Command ID	Reflected from the message the device is responding to
n..m	Payload
last	CRC8	CRC-8/MAXIM-DOW

With the payload being either a status code (0x01 positive outcome, 0x00 negative outcome) or a returned value.

Conclusions

As I’m finishing this article, I’ve found a bunch of interesting classes that could help for future reversing efforts, namely com.tjd.lefun.sdk.ble.BleWatchServiceImpl and com.tjd.lefun.sdk.ble.WristbandCommandByte these classes explain quite well message formats and what operations the SDK supports, however many commands are not implemented in the app or in the smartband as I’ve forging messages for a few of those and got no response from the smartband.


App code handling notifications

This would have saved me some frustration reversing the protocol, but it is what it is. It might be useful for future work.

All relevant scripts and resources are available here: https://github.com/0xless/FT100_fitness_bracelet_reversing

Walkthrough: BLE CTF

Sun, 17 Apr 2022 14:08:32 +0200

This CTF has been in my todo list for a good while, finally I had the time to solve it and to publish a walkthrough article on it! The challenge is available at: https://github.com/hackgnar/ble_ctf and is an awesome tool to learn about BLE and get your feet wet.

To be fair I expected the CTF to be a bit more security oriented, but I learned way more than I expected, both on BLE technologies and on the tools used to interact with those.

Disclaimer
I’m not a fan of walkthrough articles that ignore the request of the creators not to post those. The reasons I’m publishing this article are that:

No request by the creator has been made not to post the solutions

There are plenty of walkthrough articles on this CTF that don’t really teach anything and barely explain the solutions

The CTF is self-hosted and is more of a teaching tool than a proper challenge

Of course I strongly recommend trying to solve the challenges on your own before checking the solutions here! Anyway I suggest reading the first part of the articles to gather some useful information about the technologies involved in the challenge.

Without further ado, let’s get started!

How does this CTF works?

The CTF is composed of a series of challenges hosted on an ESP32 board. The software required to setup the challenge is in fact a firmware to be installed on the board. I won’t enter in details about the installation in this article, but you can find detailed instructions here: https://github.com/hackgnar/ble_ctf/blob/master/docs/setup.md

When the firmware is installed, the ESP32 will host a GATT server with which we can interact to solve the challenges and gather the flags.

What’s a GATT server

GATT is the name of a protocol that is used to exchange data between two Bluetooth Low Energy devices. This is developed on top of the Attribute Protocol (ATT) and manages device interactions following the advertising and pairing processes. A GATT Server is a device that stores attribute data locally and provides data access methods to a remote GATT Client paired via BLE. A client, on the other hand, is a device that access data on a remote GATT Server. When two devices are paired, each can function as both a GATT Server and a GATT Client.

GATT lists a device’s characteristics, descriptors, and services in a table as either 16 or 32-bits values. A characteristic is a data value sent between the server and the client.

These characteristics can have descriptors that provide additional information about them. Characteristics are often grouped in services if they have purposes related to each other. Services can have several characteristics.


GATT Server content layout Credits - Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things

ATT/GATT basics

It is possible to interact with a GATT server, by interacting with each of the characteristics available. It is possible to do that using handles, or UUID: handles define the address of a characteristic, while the UUID works as an identifier, but also gives the user some indication about the content of a characteristic. In general, handles are to be preferred to reference to a particular characteristic, this is because UUID can vary depending on the GATT implementation, while handles are expected to remain immutable for each device.

As anticipated, UUID contain info about the service or characteristic. These are useful because they are defined by profiles: standards that use known UUID to serve specific information, profiles can be found here: https://www.bluetooth.com/specifications/specs/ While UUID vary depending on the device functionality some UUID remains the same, for example: 0x2800, around which service discovery is built. This UUID allows GATT servers to understand service boundaries without having to know the exact standard the device is following.

Finally, there are characteristic properties. Properties indicate how to interact with a characteristic and what to expect from it.


GATT chatateristic proprieties Credits - devzone.nordicsemi.com

Properties are defined as an hex value and work as bitmasks, so using bitwise operations it is possible reveal the properties of a characteristic starting from its properties value.

Properties need to be interpreted knowing Attribute Protocol Packets, these are:

Commands (Client -> Server, no response required)
Requests (Client -> Server, response required)
Responses (Server -> Client, it’s the response to a request)
Notifications (Server -> Client, no response required - Signal the fact that a

characteristic’s value has changed)
Indications (Server -> Client, ACK response required by the client - Similar to

notifications)
Confirmations (Client -> Server, it’s the response to an indication)

As indicated in the image, the Read and Write properties are like permissions, and allow the reading and writing of the characteristic if set. The other properties are an indication of the behavior of a characteristic in response of an action by the client.

Actions performed by the client are limited to read and write operations. While read operations are requests by nature, write operations can either be commands or requests.

CTF

The tools that will be employed for this challenge are: gatttool and hcitool. There are other tools that can be used, in particular bettercap, which is a bit more user friendly but lacks some functionalities, or libraries that implement GATT operations, that were avoided to allow familiarizing with the tools available on a standard linux system. I think this “Living off the Land” approach helps better understanding GATT operations and also leads to a more generally employable approach to solve BLE related tasks. Of course you’re free to use the tools you prefer for this challenge.

Before starting, I suggest familiarizing with the challenge page and to understand how to operate actions relative to the challenge, like reading the score and submitting a flag. The list of the flags at the bottom of the page is really useful, as understanding exactly what to do can be tricky. There are also hints there, don’t be afraid to check those out. None of the hints gives away too much and in certain cases those are needed to understand the challenge and to get the flag.

NOTE: the score is reset each time the ESP32 is powered off! Keep that in mind.

Let’s begin! First thing first, we need to retrieve the device BT MAC address and we can do that using hcitool:

less@machine:~$ sudo hcitool lescan
LE Scan ...
78:21:84:80:A2:22 BLECTF
[...]

Now we know the address for my board is: 78:21:84:80:A2:22, it will vary on yours.

Once we have the address we can start enumerating services on the GATT server. The first thing to do is to connect to the board, we will do that using gatttool and its interactive mode:

less@machine:~$ gatttool -I
[                 ][LE]> connect 78:21:84:80:A2:22
Attempting to connect to 78:21:84:80:A2:22
Connection successful

Now we need to enumerate the services, we can do that using the primary command or by reading the UUID 0x2800.

[78:21:84:80:A2:22][LE]> primary
attr handle: 0x0001, end grp handle: 0x0005 uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x0014, end grp handle: 0x001c uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0028, end grp handle: 0xffff uuid: 000000ff-0000-1000-8000-00805f9b34fb
[78:21:84:80:A2:22][LE]> char-read-uuid 0x2800
handle: 0x0001 	 value: 01 18 
handle: 0x0014 	 value: 00 18 
handle: 0x0028 	 value: ff 00

And in both cases we retrieve services boundaries. The first two services are standard, and contain info about the server itself, while the third is the one we want to work with.

Now we can enumerate the characteristic of each service. This can be done using the command characteristics and using the boundaries found as upper and lower limits:

[78:21:84:80:A2:22][LE]> characteristics 0x0001 0x0014
handle: 0x0002, char properties: 0x20, char value handle: 0x0003, uuid: 00002a05-0000-1000-8000-00805f9b34fb
[78:21:84:80:A2:22][LE]> characteristics 0x0014 0x0028
handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a01-0000-1000-8000-00805f9b34fb
handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002aa6-0000-1000-8000-00805f9b34fb
[78:21:84:80:A2:22][LE]> characteristics 0x0028 0x00ff
handle: 0x0029, char properties: 0x02, char value handle: 0x002a, uuid: 0000ff01-0000-1000-8000-00805f9b34fb
handle: 0x002b, char properties: 0x0a, char value handle: 0x002c, uuid: 0000ff02-0000-1000-8000-00805f9b34fb
handle: 0x002d, char properties: 0x02, char value handle: 0x002e, uuid: 0000ff03-0000-1000-8000-00805f9b34fb
handle: 0x002f, char properties: 0x02, char value handle: 0x0030, uuid: 0000ff04-0000-1000-8000-00805f9b34fb
handle: 0x0031, char properties: 0x0a, char value handle: 0x0032, uuid: 0000ff05-0000-1000-8000-00805f9b34fb
handle: 0x0033, char properties: 0x0a, char value handle: 0x0034, uuid: 0000ff06-0000-1000-8000-00805f9b34fb
handle: 0x0035, char properties: 0x0a, char value handle: 0x0036, uuid: 0000ff07-0000-1000-8000-00805f9b34fb
handle: 0x0037, char properties: 0x02, char value handle: 0x0038, uuid: 0000ff08-0000-1000-8000-00805f9b34fb
handle: 0x0039, char properties: 0x08, char value handle: 0x003a, uuid: 0000ff09-0000-1000-8000-00805f9b34fb
handle: 0x003b, char properties: 0x0a, char value handle: 0x003c, uuid: 0000ff0a-0000-1000-8000-00805f9b34fb
handle: 0x003d, char properties: 0x02, char value handle: 0x003e, uuid: 0000ff0b-0000-1000-8000-00805f9b34fb
handle: 0x003f, char properties: 0x1a, char value handle: 0x0040, uuid: 0000ff0c-0000-1000-8000-00805f9b34fb
handle: 0x0041, char properties: 0x02, char value handle: 0x0042, uuid: 0000ff0d-0000-1000-8000-00805f9b34fb
handle: 0x0043, char properties: 0x2a, char value handle: 0x0044, uuid: 0000ff0e-0000-1000-8000-00805f9b34fb
handle: 0x0045, char properties: 0x1a, char value handle: 0x0046, uuid: 0000ff0f-0000-1000-8000-00805f9b34fb
handle: 0x0047, char properties: 0x02, char value handle: 0x0048, uuid: 0000ff10-0000-1000-8000-00805f9b34fb
handle: 0x0049, char properties: 0x2a, char value handle: 0x004a, uuid: 0000ff11-0000-1000-8000-00805f9b34fb
handle: 0x004b, char properties: 0x02, char value handle: 0x004c, uuid: 0000ff12-0000-1000-8000-00805f9b34fb
handle: 0x004d, char properties: 0x02, char value handle: 0x004e, uuid: 0000ff13-0000-1000-8000-00805f9b34fb
handle: 0x004f, char properties: 0x0a, char value handle: 0x0050, uuid: 0000ff14-0000-1000-8000-00805f9b34fb
handle: 0x0051, char properties: 0x0a, char value handle: 0x0052, uuid: 0000ff15-0000-1000-8000-00805f9b34fb
handle: 0x0053, char properties: 0x9b, char value handle: 0x0054, uuid: 0000ff16-0000-1000-8000-00805f9b34fb
handle: 0x0055, char properties: 0x02, char value handle: 0x0056, uuid: 0000ff17-0000-1000-8000-00805f9b34fb

And just like that we retrieved every characteristic available, their value and their properties.

At this point it is useful to define utility functions to work with the handles:

mac="78:21:84:80:A2:22" #change the value to match your board's MAC

# HEX encode
encode() {
        echo -n $1 | xxd -ps;
}

# HEX decode
decode() {
        echo $1 | tr -d "" | xxd -r -p; echo
}

# Write flag to handle 0x002c
submit_flag() {
        gatttool -b $mac --char-write-req -a 0x002c -n `encode "$1"`
}

# Read handle 0x002a to get the score
get_score() {
        read_hnd 0x002a
}

# Read values from handle and decode it
read_hnd() {
        decode "`gatttool -b $mac --char-read -a $1 | awk -F':' '{print $2}'`"
}

# List properties from hex property value
get_properties() {
		if (( ($1 & 0x1) == 0x1 )); then echo "Broadcast"; fi
        if (( ($1 & 0x2) == 0x2 )); then echo "Read"; fi
        if (( ($1 & 0x4) == 0x4 )); then echo "Write without response"; fi
        if (( ($1 & 0x8) == 0x8 )); then echo "Write"; fi
        if (( ($1 & 0x10) == 0x10 )); then echo "Notify"; fi
        if (( ($1 & 0x20) == 0x20 )); then echo "Indicate"; fi
        if (( ($1 & 0x40) == 0x40 )); then echo "Authenticated Signed Writes"; fi
        if (( ($1 & 0x80) == 0x80 )); then echo "Extended Properties"; fi
}

NOTE: properties for each characteristic of interest are listed in the challenge description, so the get_properties function won’t be used explicitly.

Flag #1 To get this flag we need to use the hint!

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x002c -n $(echo -n "12345678901234567890"|xxd -ps)
Characteristic value was written successfully

Now, reading the handle 0x002a confirms we got the first flag.

less@machine:~$ get_score
Score:1 /20

Flag 0x002e

Properties: Read

To get this flag we simply need to read the handle 0x002e.

less@machine:~$ read_hnd 0x002e
d205303e099ceff44835
less@machine:~$ submit_flag d205303e099ceff44835
less@machine:~$ get_score
Score:2 /20

Flag 0x0030

“MD5 of Device Name”

Properties: Read

So for this flag we need to submit the MD5 of the Device Name. Note: the MD5 hash needs to be truncated to 20 characters as suggested in the README of the CTF project.

We already know the device name as we encountered it connecting to the device:
```
less@machine:~$ sudo hcitool lescan
LE Scan ...
78:21:84:80:A2:22 BLECTF
[...]
```
Now we only need to get the MD5 digest of the name, cut and submit it:
```
less@machine:~$ echo -n "BLECTF" | md5sum | cut -c 1-20
5cd56d74049ae40f442e
less@machine:~$ submit_flag 5cd56d74049ae40f442e
Characteristic value was written successfully
less@machine:~$ get_score 
Score:3 /20
```
Flag 0x0016

This is a particular challenge, the hint says:

“Bluetooth GATT services provide some extra device attributes. Try finding the value of the Generic Access -> Device Name.”

But the name of the challenge is “Flag 0x0016”, so it gives it away!

Reading the handle we get the flag:
```
less@machine:~$ read_hnd 0x0016
2b00042f7481c7b056c4b410d28f33cf
```
Of course we need to cut it before submitting it (as it is a name and the README clearly states that names and digests need to be cut to the 20th character):
```
less@machine:~$ echo 2b00042f7481c7b056c4b410d28f33cf | cut -c 1-20
2b00042f7481c7b056c4
less@machine:~$  submit_flag 2b00042f7481c7b056c4
Characteristic value was written successfully
less@machine:~$  get_score 
Score:4 /20
```
But it is important to understand the reason why this flag is there. We already talked about profiles and standard UUID, these include an UUID that corresponds to the Device Name, this UUID is: 0x2A00.

Using gatttool, we can read the UUID and note that the handle is indeed 0x0016:
```
less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-read -u 0x2A00
handle: 0x0016 	 value: 32 62 30 30 30 34 32 66 37 34 38 31 63 37 62 30 35 36 63 
```

Flag 0x0032

The content of the handle is: “Write anything here”

Properties: Read, Write

To get the flag we need to write “anything” to the 0x0032 handle.

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x0032 -n `encode "anything"`
Characteristic value was written successfully

Now, we can read the handle a second time and it will reveal the flag

less@machine:~$ read_hnd 0x0032
3873c0270763568cf7aa
less@machine:~$ submit_flag 3873c0270763568cf7aa
Characteristic value was written successfully
less@machine:~$ get_score 
Score:5 /20

Flag 0x0034

The content of the handle is: “Write the ascii value “yo” here”

Properties: Read, Write

The task is similar to the last one, but this time we don’t have to hex encode the string

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x0034 -n `encode "yo"`
Characteristic value was written successfully

Now, we can get the flag reading the handle again

less@machine:~$ read_hnd 0x0034
c55c6314b3db0a6128af
less@machine:~$ submit_flag c55c6314b3db0a6128af
Characteristic value was written successfully
less@machine:~$ get_score 
Score:6 /20

Flag 0x0036

The content of the handle is: “Write the hex value 0x07 here”

Properties: Read, Write

This task is not different from the previous ones, but since the default encoding used in BLE communications is hex, and the value is to be sent in hex, no encoding needs to be used
```
less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x0036 -n 07
Characteristic value was written successfully
```
Now the flag should be available at the same handle
```
less@machine:~$ read_hnd 0x0036
1179080b29f8da16ad66
less@machine:~$ submit_flag 1179080b29f8da16ad66
Characteristic value was written successfully
less@machine:~$ get_score 
Score:7 /20
```
Flag 0x0038

The content of the handle is: “Write 0xC9 to handle 58”

Properties: Read Handle 58 properties: Write

First off we need to convert 58 in hex to get the hex value for the handle, hex(58) is 0x3A. Now we need to write the hex value 0xC9 to the handle, this can be done exactly like we did for the last challenge:
```
less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x003A -n C9
Characteristic value was written successfully
```
Now reading the handle 0x0038 again reveals the flag
```
less@machine:~$ read_hnd 0x0038
f8b136d937fad6a2be9f
less@machine:~$ submit_flag f8b136d937fad6a2be9f
Characteristic value was written successfully
less@machine:~$ get_score 
Score:8 /20
```
Flag 0x003C

The content of the handle is: “Brute force my value 00 to ff”

Properties: Read, Write

This can be achieved in multiple ways, but for consistency gatttool and a bit of bash scripting will be used.
```
less@machine:~$ for i in {0..255};
> do gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x003c -n $(printf '%02x\n' $i) > /dev/null;
> done;
```
This script iterates through every value from 0 to 255 (which is FF in hex) and writes such value in the handle 0x003C. The $(printf '%02x\n' $i); command converts the value to write from decimal to hex.

Once the script has finished, it’s possible to read the handle 0x003C again to get the flag
```
less@machine:~$ read_hnd 0x003c
933c1fcfa8ed52d2ec05
less@machine:~$ submit_flag 933c1fcfa8ed52d2ec05
Characteristic value was written successfully
less@machine:~$ get_score 
Score:9 /20
```

Flag 0x003E

The content of the handle is: “Read me 1000 times”

Properties: Read

This can be done simply modifying the script used in the previous challenge

less@machine:~$ for i in {0..1000}; 
> do gatttool -b 78:21:84:80:A2:22 --char-read -a 0x003e;
> done;

This command will print out the content of the reads, and after a while you’ll notice that the output changes like in the example here:

[...]
Characteristic value/descriptor: 52 65 61 64 20 6d 65 20 31 30 30 30 20 74 69 6d 65 73 
Characteristic value/descriptor: 52 65 61 64 20 6d 65 20 31 30 30 30 20 74 69 6d 65 73 
Characteristic value/descriptor: 52 65 61 64 20 6d 65 20 31 30 30 30 20 74 69 6d 65 73 
Characteristic value/descriptor: 36 66 66 63 64 32 31 34 66 66 65 62 64 63 30 64 30 36 39 65 
Characteristic value/descriptor: 36 66 66 63 64 32 31 34 66 66 65 62 64 63 30 64 30 36 39 65 
Characteristic value/descriptor: 36 66 66 63 64 32 31 34 66 66 65 62 64 63 30 64 30 36 39 65

The values printed after the variation represent the flag!

So we just need to submit it to complete this challenge

less@machine:~$ decode "36 66 66 63 64 32 31 34 66 66 65 62 64 63 30 64 30 36 39 65"
6ffcd214ffebdc0d069e
less@machine:~$ submit_flag 6ffcd214ffebdc0d069e
Characteristic value was written successfully
less@machine:~$ get_score 
Score:10/20

Flag 0x0040

The content of the handle is: “Listen to me for a single notification”

Properties: Read, Write, Notify

To listen for a notification, we first need to send a write request, but we will have to listen to the notification, this can be achieved with the following command:

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0040 --value=dummy --listen
Characteristic value was written successfully
Notification handle = 0x0040 value: 35 65 63 33 37 37 32 62 63 64 30 30 63 66 30 36 64 38 65 62

The notification value is the flag!

less@machine:~$ decode "35 65 63 33 37 37 32 62 63 64 30 30 63 66 30 36 64 38 65 62"
5ec3772bcd00cf06d8eb
less@machine:~$ submit_flag 5ec3772bcd00cf06d8eb
Characteristic value was written successfully
less@machine:~$ get_score 
Score:11/20

Flag 0x0042

The content of the handle is: “Listen to handle 0x0044 for a single indication”

Properties: Read

Handle 0x0044 Properties: Read, Write, Indicate

This flag can be obtained just like the last one:

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0044 --value=ffff --listen
Characteristic value was written successfully
Indication   handle = 0x0044 value: 63 37 62 38 36 64 64 31 32 31 38 34 38 63 37 37 63 31 31 33

Once the notification value is retrieved we can decode and submit it:

less@machine:~$ decode "63 37 62 38 36 64 64 31 32 31 38 34 38 63 37 37 63 31 31 33"
c7b86dd121848c77c113
less@machine:~$ submit_flag c7b86dd121848c77c113
Characteristic value was written successfully
less@machine:~$ get_score 
Score:12/20

Flag 0x0046

The content of the handle is: “Listen to me for multi notifications”

Properties: Read, Write, Notify

And with the same command we can get this flag too!

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0046 --value=ffff --listen
Characteristic value was written successfully
Notification handle = 0x0046 value: 55 20 6e 6f 20 77 61 6e 74 20 74 68 69 73 20 6d 73 67 00 00 
Notification handle = 0x0046 value: 63 39 34 35 37 64 65 35 66 64 38 63 61 66 65 33 34 39 66 64 
Notification handle = 0x0046 value: 63 39 34 35 37 64 65 35 66 64 38 63 61 66 65 33 34 39 66 64 
Notification handle = 0x0046 value: 63 39 34 35 37 64 65 35 66 64 38 63 61 66 65 33 34 39 66 64

After the first notification, we get the content of the flag! (The decoded content of the first notification is “U no want this msg”).

less@machine:~$ decode "63 39 34 35 37 64 65 35 66 64 38 63 61 66 65 33 34 39 66 64"
c9457de5fd8cafe349fd
less@machine:~$ submit_flag c9457de5fd8cafe349fd
Characteristic value was written successfully
less@machine:~$ get_score 
Score:13/20

Flag 0x0048

The content of the handle is: “Listen to handle 0x004a for multi indications”

Properties: Read

Handle 0x004a Properties: Read, Write, Indicate

Once again the same command is the key to the flag!

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x004a --value=ffff --listen
Characteristic value was written successfully
Indication   handle = 0x004a value: 55 20 6e 6f 20 77 61 6e 74 20 74 68 69 73 20 6d 73 67 00 00 
Indication   handle = 0x004a value: 62 36 66 33 61 34 37 66 32 30 37 64 33 38 65 31 36 66 66 61 
Indication   handle = 0x004a value: 62 36 66 33 61 34 37 66 32 30 37 64 33 38 65 31 36 66 66 61 
Indication   handle = 0x004a value: 62 36 66 33 61 34 37 66 32 30 37 64 33 38 65 31 36 66 66 61

Now we can decode and submit the flag like always.

less@machine:~$ decode "62 36 66 33 61 34 37 66 32 30 37 64 33 38 65 31 36 66 66 61"
b6f3a47f207d38e16ffa
less@machine:~$ submit_flag b6f3a47f207d38e16ffa
Characteristic value was written successfully
less@machine:~$ get_score 
Score:14/20

Flag 0x004c

The content of the handle is: “Connect with BT MAC address 11:22:33:44:55:66”

Properties: Read

Now, this challenge depends on the BT card you’re using. I’m using a raspberry pi 3b+ and I could solve the challenge in the following way:

less@machine:~$ sudo hcitool cmd 0x3f 0x001 0x66 0x55 0x44 0x33 0x22 0x11
< HCI Command: ogf 0x3f, ocf 0x0001, plen 6
  66 55 44 33 22 11 
> HCI Event: 0x0e plen 4
  01 01 FC 00 
less@machine:~$ sudo hciconfig hci0 reset
less@machine:~$ systemctl restart bluetooth.service
Authentication is required to restart 'bluetooth.service'.
Authenticating as: ,,, (less)
Password: 
==== AUTHENTICATION COMPLETE ===

At this point we can confirm our BT MAC address executing hciconfig:

less@machine:~$ hciconfig
hci0:	Type: Primary  Bus: UART
	BD Address: 11:22:33:44:55:66  ACL MTU: 1021:8  SCO MTU: 64:1
	UP RUNNING 
	RX bytes:13820 acl:117 sco:0 events:824 errors:0
	TX bytes:16604 acl:108 sco:0 commands:606 errors:0

And of course now, reading the handle gives us the flag:

less@machine:~$ read_hnd 0x004c
aca16920583e42bdcf5f
less@machine:~$ submit_flag aca16920583e42bdcf5f
Characteristic value was written successfully
less@machine:~$ get_score 
Score:15/20

Check out these resources for more info on this solution: https://www.lisha.ufsc.br/teaching/shi/ine5346-2003-1/work/bluetooth/hci_commands.html and https://raspberrypi.stackexchange.com/a/124117

Flag 0x004e

The content of the handle is: “Set your connection MTU to 444”

Properties: Read

Even if there is the option to do that (-m), I can’t seem to get the flag without using the interactive mode of gatttools, so my solution to this flag is:

less@machine:~$ gatttool -I
[                 ][LE]> connect 78:21:84:80:A2:22
Attempting to connect to 78:21:84:80:A2:22
Connection successful
[78:21:84:80:A2:22][LE]> mtu 444
MTU was exchanged successfully: 444
[78:21:84:80:A2:22][LE]> char-read-hnd 0x004e
Characteristic value/descriptor: 62 31 65 34 30 39 65 35 61 34 65 61 66 39 66 65 35 31 35 38 
[78:21:84:80:A2:22][LE]> exit

And just like that we got the flag

less@machine:~$ decode "62 31 65 34 30 39 65 35 61 34 65 61 66 39 66 65 35 31 35 38 "
b1e409e5a4eaf9fe5158
less@machine:~$ submit_flag b1e409e5a4eaf9fe5158
Characteristic value was written successfully
less@machine:~$ get_score 
Score:16/20

Flag 0x0050

The content of the handle is: “Write+resp ‘hello’ "

Properties: Read, Write

I suggest checking the hint for this challenge! The key is in correctly handling the ACK response from the write instruction, this is the reason

--char-write-req needs to be used.

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0050 --value=`encode hello`
Characteristic value was written successfully
less@machine:~$ read_hnd 0x0050
d41d8cd98f00b204e980

Now we only need to submit the flag.

less@machine:~$ submit_flag d41d8cd98f00b204e980
Characteristic value was written successfully
less@machine:~$ get_score 
Score:17/20

Flag 0x0052

The content of the handle is: “No notifications here! really?”

Properties: Read, Write

In fact even if there is no notification property set…

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0052 --value=`encode hello` --listen
Characteristic value was written successfully
Notification handle = 0x0052 value: 66 63 39 32 30 63 36 38 62 36 30 30 36 31 36 39 34 37 37 62

The flag is revealed through a notification! Now we can decode and submit it.

less@machine:~$ decode "66 63 39 32 30 63 36 38 62 36 30 30 36 31 36 39 34 37 37 62"
fc920c68b6006169477b
less@machine:~$ submit_flag fc920c68b6006169477b
Characteristic value was written successfully
less@machine:~$ get_score 
Score:18/20

Flag 0x0054

The content of the handle is: “So many properties!”

Properties: Broadcast, Read, Write, Notify, Extended properties

…and to be fair this handle has “Broadcast, Read, Write, Notify, Extended properties” properties. It’s a bit of a mess!

But getting the flag is fairly simple. The first half can be retrieved simply listening for a notification:
```
less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0054 --value=ffff --listen
Characteristic value was written successfully
Notification handle = 0x0054 value: 30 37 65 34 61 30 63 63 34 38 
```
For the second half we need to read the handle once more:
```
less@machine:~$ read_hnd 0x0054
fbb966958f
```
Now we just need to put the two halves together and submit the flag (the second half of the flag goes first!):
```
less@machine:~$ submit_flag fbb966958f07e4a0cc48
Characteristic value was written successfully
less@machine:~$ get_score 
Score:19/20
```
Flag 0x0056

The content of the handle is: “md5 of author’s twitter handle”.

Properties: Read

So we need to do a bit of OSINT to solve this challenge!

The starting point is the github page of the challenge: https://github.com/hackgnar/ble_ctf Luckily in the README.md file we can find a twitter follow button, this leads us to: https://twitter.com/hackgnar And now we know the handle is: @hackgnar

Now we can get the MD5 digest of the handle and cut it to 20 chars:
```
less@machine:~$ echo -n "@hackgnar" | md5sum | cut -c 1-20
d953bfb9846acc2e15ee
```
We can now submit it as a flag
```
less@machine:~$ submit_flag d953bfb9846acc2e15ee
Characteristic value was written successfully
less@machine:~$ get_score 
Score:20/20
```

Conclusions

Hope this article is useful to anyone who’s stuck on one of these challenges or to anyone who’s trying to learn about BLE technologies. Writing this article has helped me formalizing most of the things I learned solving these challenges and my main takeaways are an improved understanding of BLE, GATT and ATT, but also the ability to use the tools needed to work with these technologies.

In future I’ll try working with GATT libraries to programmatically interact with GATT servers!

Resources:

https://epxx.co/artigos/bluetooth_gatt.html (ATT/GATT basics)
Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things (General BLE introduction)
https://axodyne.com/2020/08/ble-uuids/ (Explanation on standard UUIDS)
https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt (Profiles and services)
https://devzone.nordicsemi.com/guides/short-range-guides/b/bluetooth-low-energy/posts/ble-characteristics-a-beginners-tutorial (Properties)