GATT/ATT Layer

1 Byte     2 Bytes           Variable Length
+--------+------------+------------------------------------+
|        |            |                                    |
| OPCODE |  HANDLE    |           ATTRIBUTE VALUE          |
|        |            |                                    |
+--------+------------+------------------------------------+
    ^          ^                       ^
    |          |                       |
 0x12 =    The ID of               The actual data
 Write     the data                (e.g., "0x01")
 Req       (0x002A)

Context: If PHY/Link/L2CAP are the networking stack (like TCP/IP), then ATT (Attribute Protocol) is the HTTP, and GATT (Generic Attribute Profile) is the REST API.

This is where the actual product logic lives. It is where the "Unlock Door" command is sent, where the "Battery Level" is read, and where "Firmware Updates" are triggered.

Why it matters: Most security researchers skip the lower layers (PHY/Link) because they are hard-coded in silicon. GATT is written by application developers. This means it is full of human errors: logic bugs, missing authentication checks, and input validation failures.

---

1. The Architecture: A Map for Attackers

To hack a device, you need to understand how it organizes data.

• ATT (The Transport): The protocol used to move data. It defines how to read, write, and notify.

• GATT (The Map): The hierarchy that defines what data exists.

The Hierarchy:

1. Profile: A collection of services (e.g., "Heart Rate Monitor").

2. Service: A specific feature. Identified by a UUID.

3. Characteristic: The actual variable (e.g., "Beats Per Minute"). This is where the data lives.

4. Descriptor: Metadata (e.g., "Enable Notifications").

🏴‍☠️ The Hacker's Insight: "Hidden Handles."

Developers often think, "If I don't list my custom Service UUID in the advertisement, hackers won't find it." Wrong. Every attribute has a Handle (a 16-bit ID, e.g., 0x002A). An attacker doesn't need to know the UUID. They can just iterate through every handle from 0x0001 to 0xFFFF and Read/Write to them. This is how you find "hidden" debug interfaces and factory modes.

---

2. The "Permissions" Lie (The #1 Vulnerability)

This is the most common vulnerability in BLE IoT.

• Properties: Metadata the device broadcasts (e.g., "I am Encrypted").

• Permissions: The actual code check in the firmware.

The Exploit: A Characteristic says PROPERTY_WRITE | PROPERTY_ENC. The mobile app sees this and bonds before writing. However, the firmware code might look like this:

C

// Vulnerable Code
void on_write_request(handle, data) {
    if (handle == UNLOCK_DOOR) {
        unlock_door(); // ERROR: Forgot to check if (connection.is_encrypted)
    }
}

Attack: Connect without pairing. Send the "Unlock" command. If the developer forgot the if statement, the door opens.

🛡️ Security Checks & Testing

• Access Control Bypass:

  • Tool: gatttool, bettercap, or nRF Connect (macros).

  • Test: Connect to the device but reject pairing. Attempt to read/write to every characteristic.

  • Goal: Find a characteristic that accepts data when it shouldn't.

---

3. Input Validation & Buffer Overflows

When you write data to a Characteristic, it goes into a memory buffer in the firmware. Embedded devices often have fixed-size buffers and poor bounds checking.

The Exploit:

• Buffer Overflow: The device expects a 10-byte User ID. You send 500 bytes. You might overwrite the stack return address or crash the device (DoS).

• Integer Overflow: The device expects a value 0-100. You send 0xFFFFFFFF.

🛡️ Security Checks & Testing

• GATT Fuzzing:

  • Tool: gattacker or Scapy scripts.

  • Test: Fuzz the Write request with varying lengths (0 bytes, 1 byte, 512 bytes) and random content.

  • Goal: Watch for device reboots (crashes).

• Logic Fuzzing:

  • Test: Send invalid values (e.g., if 0x01=Open, try 0xFF, 0x00, 0x02).

---

4. Replay Attacks: The Logic Failure

Even if the link is encrypted (SMP), the data might be static.

The Exploit:

1. Sniff: You capture the legitimate owner unlocking their smart lock.

2. Analyze: You see a Write command: 0xAA 0xBB 0xCC sent to Handle 0x0021.

3. Replay: You connect to the lock later and send 0xAA 0xBB 0xCC to Handle 0x0021.

4. Result: If the application doesn't implement a "nonce" or "rolling code" inside the data payload, the door opens.

Key Concept: SMP Encryption protects against sniffing, not replay. If you are an authenticated user (or if you hijacked a session), encryption doesn't stop you from sending old commands.

🛡️ Security Checks & Testing

• Replay Test:

  • Tool: Wireshark (with Sniffer) + gatttool.

  • Test: Capture a valid action. Disconnect the phone. Re-connect with your laptop and send the same hex bytes.

  • Goal: See if the action triggers again.

---

5. Race Conditions & Notification Abuse

The Exploit: Some devices have complex state machines (e.g., "Write Password" -> "Wait for OK Notification" -> "Write Unlock").

• Race Condition: What if you send "Unlock" immediately after "Password" without waiting? Or send "Unlock" 50 times in 1 second?

• Notification Leak: If you enable notifications (write 0x0100 to CCCD) Without authentication, the device might start streaming live sensitive data (heart rate, GPS) before you even log in.