hackgnar / ble_ctf Goto Github PK

The hint for flag 3 was:

root@kali-vm:~# gatttool -b b4:E6:2d:96:14:7F --char-read -a 0x0030
Characteristic value/descriptor: 4d 44 35 20 6f 66 20 44 65 76 69 63 65 20 4e 61 6d 6
root@kali-vm:~# echo -n "4d 44 35 20 6f 66 20 44 65 76 69 63 65 20 4e 61 6d 65" | tr -d ' ' | xxd -r -p
MD5 of Device Name

So retrieving the device name and md5sum'ing it, and submitting the first 20 characters doesn't get the flag:

root@kali-vm:~# gatttool -b b4:E6:2d:96:14:7F --char-read --handle=0x0016
Characteristic value/descriptor: 32 62 30 30 30 34 32 66 37 34 38 31 63 37 62 30 35 36 63 34 62 34 31 30 64 32 38 66 33 33 63 66
root@kali-vm:~# echo -n "32 62 30 30 30 34 32 66 37 34 38 31 63 37 62 30 35 36 63 34 62 34 31 30 64 32 38 66 33 33 63 66" | tr -d " " | xxd -r -p
2b00042f7481c7b056c4b410d28f33cf
root@kali-vm:~# echo -n 2b00042f7481c7b056c4b410d28f33cf | md5sum
8489c638085eb7b7416e682af1dd5474  -
root@kali-vm:~# gatttool -b b4:E6:2d:96:14:7F --char-write-req -a 0x002c -n $(echo -n "8489c638085eb7b7416e"|xxd -ps)
Characteristic value was written successfully
root@tuv-kali-vm:~# gatttool -b b4:E6:2d:96:14:7F --char-read -a 0x002a|awk -F':' '{print $2}'|tr -d ' '|xxd -r -p;printf '\n'
Score:2 /20

However, ignoring the clue "MD5 of Device Name", and just returning exactly the hex version of the device name, not md5sum'ing anything, we get the flag:

root@kali-vm:~# gatttool -b b4:E6:2d:96:14:7F --char-write-req -a 0x002c -n $(echo -n "2b00042f7481c7b056c4"|xxd -ps)
Characteristic value was written successfully
root@kali-vm:~# gatttool -b b4:E6:2d:96:14:7F --char-read -a 0x002a|awk -F':' '{print $2}'|tr -d ' '|xxd -r -p;printf '\n'
Score:3 /20

I think this is a bug? Or at the very least a misleading clue?

I was wondering if you might know if there is anything special you have to do in order to get gatttool to play nice with Kali Linux?

I'm able to use hcitool to lescan, find my device. When I try to use gatttool I get a connection refused error:

root@kali-vm:~# gatttool -b b4:e6:2d:96:14:7F --char-read -a 0x002a
connect: Connection refused (111)
root@kali-vm:~# gatttool --adapter=hci1 -I
[                 ][LE]> connect b4:e6:2d:96:14:7F
Attempting to connect to b4:e6:2d:96:14:7F
Error: connect: Connection refused (111)

I am able to connect to the device and read GATT data using nRF Connect from an Android device, so the device itself seems to be working fine. I also made sure my Android device was disconnected and bluetooth was disabled before trying to connect from Kali.

Any pointers on getting this set up right?

In the Flags section, the initial command for obtaining the target MAC address is incorrect, not sure if its changed between hcitool versions. Instead of sudo hcitool blescan it should read sudo hcitool lescan

The instructions about hcitools don't work with Bluetooth versions 5.0 and greater, which is what's included in newer hardware. The bluetoothctl tool can do most of it, and supports Bluetooth 4.0 (the minimum hardware version for the lab).

I had to look at writeups... the handle to read for instructions is 0x004e

z@ubuntu:~/esp/ble_ctf$ make 
Toolchain path: /home/z/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: esp32-2019r1
Compiler version: 8.2.0
Python requirements from /home/z/esp/esp-idf/requirements.txt are satisfied.

App "gatt_server_service_table_demo" version: 1.0-3-g1e85408
CC build/main/gatts_table_creat_demo.o
/home/z/esp/ble_ctf/main/gatts_table_creat_demo.c:193:22: error: 'char_value' defined but not used [-Werror=unused-const-variable=]
 static const uint8_t char_value[4]                 = {0x11, 0x22, 0x33, 0x44};
                      ^~~~~~~~~~
/home/z/esp/ble_ctf/main/gatts_table_creat_demo.c:192:22: error: 'heart_measurement_ccc' defined but not used [-Werror=unused-const-variable=]
 static const uint8_t heart_measurement_ccc[2]      = {0x00, 0x00};
                      ^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
/home/z/esp/esp-idf/make/component_wrapper.mk:289: recipe for target 'gatts_table_creat_demo.o' failed
make[1]: *** [gatts_table_creat_demo.o] Error 1
/home/z/esp/esp-idf/make/project.mk:582: recipe for target 'component-main-build' failed
make: *** [component-main-build] Error 2
z@ubuntu:~/esp/ble_ctf$ grep -nr char_value
main/gatts_table_creat_demo.c:193:static const uint8_t char_value[4]                 = {0x11, 0x22, 0x33, 0x44};
z@ubuntu:~/esp/ble_ctf$ grep -nr heart_measurement_ccc
main/gatts_table_creat_demo.c:192:static const uint8_t heart_measurement_ccc[2]      = {0x00, 0x00};
z@ubuntu:~/esp/ble_ctf$ xtensa-esp32-elf-gcc --version
xtensa-esp32-elf-gcc (crosstool-NG esp32-2019r1) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

we may nop this two unused-const-variable.

• Development Kit: [ESP32-DevKitC]
• Kit version unknown
• Module or chip used: [ESP32-WROOM-32]
• IDF version v3.1.2
• Build System: [Make]
• Compiler version // 1.22.0-80-g6c4433a
• Operating System: [Linux]
• Power Supply: [USB]

printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/esp/xtensa-esp32-elf/bin

Problem Description

When I make flash I get
CC build/bootloader/bootloader_support/src/bootloader_flash.o
/root/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/as: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
make[2]: *** [/root/esp/esp-idf/make/component_wrapper.mk:286: src/bootloader_flash.o] Error 1
make[1]: *** [/root/esp/esp-idf/make/project.mk:468: component-bootloader_support-build] Error 2
make: *** [/root/esp/esp-idf/components/bootloader/Makefile.projbuild:41: /root/esp/ble_ctf/build/bootloader/bootloader.bin] Error 2

YOUR README SAYS:

The purpose of BLE CTF is to teach the core concepts of Bluetooth Low Energy client and server interactions.

Do you think this is true? I think it might be different.

should refer to 0x0048

Encountered during make step of flashing process.

/ble_ctf# make
Toolchain path: /root/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a
Compiler version: 5.2.0
Python requirements from /root/esp/esp-idf/requirements.txt are satisfied.

App "gatt_server_service_table_demo" version: 1.0-5-g366122b
CC build/main/gatts_table_creat_demo.o
/root/Addons/ble_ctf/main/gatts_table_creat_demo.c:25:29: fatal error: esp_gap_ble_api.h: No such file or directory
compilation terminated.
make[1]: *** [/root/esp/esp-idf/make/component_wrapper.mk:290: gatts_table_creat_demo.o] Error 1
make: *** [/root/esp/esp-idf/make/project.mk:552: component-main-build] Error 2

esp/ble_ctf/main/gatts_table_creat_demo.c:25:10: fatal error: esp_gap_ble_api.h: No such file or directory
#include "esp_gap_ble_api.h"

1. My bluetooth device is enable
2. and all compiled properly

When i got up to Flag 10, the flag is already there without me solving anything. Is that an intended event or a side effect of completing flags 1-9?

As of Fedora 34, the gatttool, hciconfig, and related have been moved to the bluez-deprecated package, which is not installed by default anymore.

I did most of the challenges on a mobile phone using Nordic's nRF Connect. Reading the first hint, it said to send a payload to a specific handle? Which was confusing until I realsied it was specific to Linux and how gatttool works.

Instead, may I suggest you introduce the concept of UUIDs and how each characteristic on a service has incrementing numbers based on the Services' UUID?

A new flag idea wcould be to challenge the player to identify a 16bit UUID and send a payload that conforms to that standard, Like setting the time with a UUID of 0x1805 (Current Time Service)

You could use that as an opportunity to perform OSINT on GATT UUIDs.

Another idea is to set up a BLE beacon and using a tool like RamBLE to locate the beacon and read the flag from the advertised data.

Hi,
Was just thinking about another level to add to the CTF: Add Pairing Feature. [e.g (1)]
Maybe with two different types: All Zeroes and Random PIN.

Thus players can also try to crack the TK with crackle ;]

(1) https://github.com/espressif/esp-idf/blob/master/examples/bluetooth/gatt_security_server/tutorial/Gatt_Security_Server_Example_Walkthrough.md

I know it says that flags are truncated to 20 characters and I see that in the source code, but I don't think it's clear that you must truncate flags to 20 characters (at least on some devices).
If I transmit the full md5 to flag 3 and view the console I see this:
I (458161) ESP_GATTS_DEMO: ESP_GATTS_WRITE_EVT
I (458161) ESP_GATTS_DEMO: PREPARE WRITE TRIGGERED
I (458161) ESP_GATTS_DEMO: prepare write, handle = 44, value len = 18
I (458241) ESP_GATTS_DEMO: ESP_GATTS_WRITE_EVT
I (458241) ESP_GATTS_DEMO: PREPARE WRITE TRIGGERED
I (458241) ESP_GATTS_DEMO: prepare write, handle = 44, value len = 14

In fact anything over 20 characters is transmitted as two writes, so 18 and 4 for 22 characters for example, meaning nothing over 20 characters gets recognised as a correct flag.
If I write exactly 20 characters then it works fine.

$ hciconfig hci0
hci0: Type: Primary Bus: USB
BD Address: xx:xx... ACL MTU: 1021:4 SCO MTU: 96:6