GATT Profiles Explained: How BLE Devices Actually Communicate
Two BLE devices can find each other through advertising. But actually exchanging useful data - reading a sensor value, sending a command, subscribing to notifications - requires a higher-level protocol. That's GATT: the Generic Attribute Profile.
GATT defines how BLE devices structure their data and capabilities into a hierarchy of services, characteristics, and descriptors. It's the reason your BLE heart rate monitor can be read by your phone without any custom software, and why a BLE lock can receive commands from an app. It's also the protocol that security researchers probe when assessing BLE devices - and where many BLE security vulnerabilities live.
The GATT Client/Server Model
GATT uses a client/server model. One device acts as the GATT server (it holds the data and exposes functionality). The other acts as the GATT client (it queries and interacts with the server).
graph TD
subgraph "BLE GATT Hierarchy"
PROFILE["GATT Profile
(e.g., Heart Rate Profile)"]
PROFILE --> SVC1["Primary Service
Heart Rate Service
UUID: 0x180D"]
PROFILE --> SVC2["Primary Service
Device Information
UUID: 0x180A"]
SVC1 --> CHAR1["Characteristic
Heart Rate Measurement
UUID: 0x2A37
Properties: Notify"]
SVC1 --> CHAR2["Characteristic
Body Sensor Location
UUID: 0x2A38
Properties: Read"]
SVC1 --> CHAR3["Characteristic
Heart Rate Control Point
UUID: 0x2A39
Properties: Write"]
CHAR1 --> DESC1["Descriptor
CCCD (0x2902)
Enable/disable notifications"]
CHAR1 --> DESC2["Descriptor
Char User Description
(0x2901)"]
SVC2 --> CHAR4["Characteristic
Manufacturer Name
UUID: 0x2A29"]
SVC2 --> CHAR5["Characteristic
Firmware Revision
UUID: 0x2A26"]
SVC2 --> CHAR6["Characteristic
Model Number
UUID: 0x2A24"]
end
GATT hierarchy - a Profile contains Services, each Service has Characteristics with specific properties, and Characteristics may have Descriptors
The role assignment is independent of the BLE advertising/connection role. The peripheral device (the one that advertises, like a sensor or a lock) is typically the GATT server. The central device (the one that scans and connects, like a phone) is typically the GATT client. But this isn't a requirement - a single device can be both server and client simultaneously.
Once a BLE connection is established, the client can discover the server's GATT hierarchy and start reading, writing, and subscribing to characteristics.
The GATT Hierarchy
The GATT data model is hierarchical:
Profile - the top-level concept. A profile defines a collection of services designed to accomplish a particular use case. The Heart Rate Profile defines services and characteristics for monitoring heart rate. The Device Information Profile defines services for exposing manufacturer and model information. Profiles are defined by the Bluetooth SIG and published in the Bluetooth specification.
Service - a collection of related characteristics. Services are identified by UUIDs (Universally Unique Identifiers). Bluetooth SIG-assigned services have 16-bit UUIDs (e.g., 0x180D = Heart Rate Service, 0x180A = Device Information Service). Custom/vendor services use full 128-bit UUIDs.
Characteristic - the fundamental data unit. A characteristic holds a value (the actual data) and defines how it can be accessed (read, write, notify, indicate). Characteristics are also identified by UUIDs. The Heart Rate Measurement characteristic (UUID 0x2A37) contains the heart rate value. Characteristics also have properties that define allowed operations.
Descriptor - optional metadata attached to a characteristic. The most common descriptor is the Client Characteristic Configuration Descriptor (CCCD, UUID 0x2902), which a client writes to in order to subscribe to notifications or indications from a characteristic.
UUIDs in GATT
The Bluetooth SIG maintains a registry of standardized UUIDs for common services and characteristics. These are assigned as 16-bit values and are implicitly expanded to 128-bit by inserting them into a base UUID template: 0000XXXX-0000-1000-8000-00805F9B34FB.
Common standardized service UUIDs you'll encounter:
-
0x1800- Generic Access (device name, appearance) -
0x1801- Generic Attribute (GATT service itself) -
0x180A- Device Information (manufacturer, model, firmware version) -
0x180D- Heart Rate -
0x180F- Battery Service -
0x1812- Human Interface Device (HID - keyboards, mice)
When you see a 128-bit UUID that doesn't match the base UUID pattern, it's a vendor-defined custom service. Most IoT devices have custom GATT services for their primary functionality. A smart lock might expose a custom service with characteristics for lock/unlock commands, status, and audit logs.
Characteristic Properties
Each characteristic advertises its allowed operations through a Properties byte. The possible properties:
- READ: Client can read the current value
- WRITE: Client can write a value (with acknowledgment from server)
- WRITE WITHOUT RESPONSE: Client can write a value without waiting for acknowledgment (faster, no retransmission)
- NOTIFY: Server can push value updates to the client without the client polling. Client must enable notifications by writing to the CCCD.
- INDICATE: Same as NOTIFY but with acknowledgment - server waits for the client to confirm receipt
- BROADCAST: Characteristic value can be included in the advertising packet
Understanding properties is critical for security assessment. A characteristic with WRITE without authentication is a potential attack surface - you can send arbitrary data to it without proving who you are.
sequenceDiagram
participant C as BLE Client (Central)
participant S as BLE Server (Peripheral)
Note over C,S: Service Discovery
C->>S: Discover All Primary Services
S->>C: Service list (UUIDs, handle ranges)
C->>S: Discover Characteristics (for service)
S->>C: Characteristic list (UUID, properties, handles)
C->>S: Discover Descriptors (for characteristic)
S->>C: Descriptor list (CCCD, etc.)
Note over C,S: Read Operation
C->>S: Read Request (handle 0x000E)
S->>C: Read Response (value: "BLEShark")
Note over C,S: Write Operation
C->>S: Write Request (handle 0x0010, value: 0x01)
S->>C: Write Response (success)
Note over C,S: Notifications (Subscribe)
C->>S: Write CCCD (0x2902) = 0x0001
S->>C: Write Response (notifications enabled)
loop Periodic updates
S->>C: Handle Value Notification (new data)
end
Note over C,S: Indications (Confirmed)
C->>S: Write CCCD = 0x0002
S->>C: Handle Value Indication (data)
C->>S: Handle Value Confirmation
GATT client-server interaction - service discovery, read/write operations, and notification/indication subscriptions
GATT Security: Where It Often Falls Short
GATT security is supposed to come from the BLE security layer: pairing, bonding, and link-level encryption. The idea is that before a client can read sensitive characteristics or write commands, the devices should have paired (establishing shared keys) and encrypted the connection.
In practice, many BLE devices implement security poorly:
No pairing required: Some devices expose WRITE characteristics on their custom services without requiring pairing. Any BLE device within range can connect and write to these characteristics. A BLE bulb that accepts color/brightness commands without pairing is a trivial target - anyone nearby can control it.
Unauthenticated pairing (Just Works): Even devices that require pairing sometimes use "Just Works" pairing mode, which provides no man-in-the-middle protection. The devices establish encryption, but an active attacker can intercept the pairing and establish separate sessions with each side.
Sensitive data in standard services: The Device Information Service (0x180A) exposes manufacturer name, model number, firmware version, and serial number - all readable without pairing on most devices. This is often intentional (for device discovery purposes), but it can reveal information useful for targeted attacks.
No authorization on critical characteristics: Some devices pair correctly but then don't check whether the bonded device has authorization to perform specific actions. A device might encrypt the connection but still accept commands from any device that completes pairing, including new, unknown devices.
GATT Service Enumeration
The first step in BLE security assessment is enumerating the target device's GATT services and characteristics. This is analogous to port scanning in network security - you're discovering what the device exposes before probing specific areas.
Tools for GATT enumeration:
nRF Connect (iOS/Android): The most accessible tool. Connect to any BLE device and it displays the full GATT hierarchy - services, characteristics, properties, and current values. You can read characteristics and write values directly from the UI. Essential for quick assessment.
gatttool (Linux): Command-line GATT client. Connect to a device and interactively read/write characteristics by handle or UUID. Part of the BlueZ stack.
Gattacker: A more aggressive assessment tool that proxies BLE connections, allowing a man-in-the-middle position to observe and modify GATT traffic.
BtleJuice: Similar to Gattacker, a framework for BLE MITM attacks.
The HID Profile: Why BLEShark's Bad-BT Works
The HID (Human Interface Device) profile (Service UUID 0x1812) deserves special attention because it's the foundation of BLE keyboard/mouse functionality - and therefore the mechanism behind HID injection attacks.
A device presenting the HID profile with keyboard report support is treated by the connecting OS as a keyboard. No driver required. No verification that the device is actually a legitimate keyboard. The OS sees "HID keyboard" and trusts it immediately, accepting keystrokes as if they came from a physical keyboard.
The BLEShark Nano's Bad-BT feature works by presenting a GATT HID profile. When paired with a computer, the computer's OS recognizes it as a Bluetooth keyboard and accepts input from it. The DuckyScript payloads translate to HID key reports that the OS executes as if typed by a human.
The HID profile's key characteristic is the HID Report characteristic (UUID 0x2A4D). The HID Report Map characteristic (UUID 0x2A4B) describes the structure of the reports - what each byte means. For a standard keyboard, the report is 8 bytes: 1 modifier byte (Ctrl, Shift, Alt, etc.), 1 reserved byte, and 6 key code bytes.
This structure is completely standardized. Any device that correctly implements the HID profile will be recognized as a keyboard on Windows, macOS, Linux, iOS, and Android. The universality is by design for accessibility and hardware compatibility. The security implication is that this trust is unconditional - the OS has no mechanism to verify that the HID device is legitimate.
BLE Scanning and GATT Discovery With BLEShark
The BLEShark Nano's BLE scanning feature captures advertising packets and performs OUI lookups on device MAC addresses. This gives you the first layer of information about nearby BLE devices - device names (from the advertising data), manufacturer data, advertised service UUIDs, and rough signal strength.
Devices that advertise standard service UUIDs (like 0x1812 for HID, or 0x180D for heart rate) give away their primary function immediately in the advertisement. Devices that advertise only custom 128-bit UUIDs require GATT enumeration after connection to understand their function.
For a complete BLE security assessment, the BLEShark scan gives you the initial reconnaissance layer - what's in range, what it's advertising, who made it. The deeper GATT enumeration happens with nRF Connect or a similar tool after you've identified a target of interest.
Understanding GATT is fundamental to understanding BLE security. Most BLE vulnerabilities aren't in the radio protocol or the crypto - they're in the GATT implementation decisions made by device firmware developers. Exposed WRITE characteristics without authentication, predictable custom UUIDs, sensitive data in readable characteristics - these are engineering decisions that can be found and assessed by anyone with a BLE connection and a GATT enumeration tool.
BLE security assessment should only be performed on devices you own or have explicit authorization to test. Connecting to and writing commands to BLE devices without authorization may constitute unauthorized computer access under applicable laws.