How to capture Bluetooth packets on Android 4.4

New mobile applications are constantly improving their use of advanced device features, like sensors and short range networks. In particular we have seen increased and wide-ranging use of Bluetooth. Bluetooth is a wireless technology used to exchange data at short ranges with high frequency radio waves (around 2.4 GHz) that has been around for about 20 years. Over time it has evolved with many versions and specifications. This technology is ubiquitous today. It is found it in smartphones and tablets (the main reason for this article), cars, accessories such as headphones and embedded devices, computers, speakers, and many other places. The number of applications leveraging Bluetooth will increase in the coming years. I anticipate Bluetooth Low Energy partnered with wearable devices such as Google Glass or the Samsung Gear smart watch will be a driving force behind this.

Developer option to enable Bluetooth HCI snoop

Auditing Bluetooth communications with Wireshark on Android

For a security analyst then it will become increasingly important to be able to audit the features of the software related to Bluetooth. In order to do a better analysis of Bluetooth communication, you would ideally use a dedicated device like the Ubertooth One. If you don’t own a sniffing device however, you aren’t necessarily out of luck. In many cases we can obtain positive results with a new feature introduced in Android 4.4: the ability to capture all Bluetooth HCI packets and save them to a file. When the Analyst has finished populating the capture file by running the application being tested, he can pull the file generated by Android into the external storage of the device and analyze it (with Wireshark, for example). Once this setting is activated, Android will save the packet capture to /sdcard/btsnoop_hci.log to be pulled by the analyst and inspected. We can then open a shell and pull the file: $adb pull /sdcard/btsnoop_hci.log andinspect it with Wireshark, such as a PCAP collected by sniffing WiFi traffic for example, so it is very simple and well supported:

Wireshark capture using Android HCI snoop

As we can see, the application made a GET web request over Bluetooth and we are able to see the traffic to spot vulnerabilities and gain information for the auditing process. By default, the information dumped by this new feature will be stored in the file ïbtsnoop_hci.log’ located under the ï/sdcard’ directory. This may be more than enough for those users who want to intercept the communication transmitted over the Bluetooth channel created between two or more devices, but for those advanced users who are looking for flexibility or a way to configure the bluedroid module, they will likely be missing an interface to play with different possible configurations. During the research process, we found that under the folder ï/etc/bluetooth’ there were different files used to configure multiple options related to the interception process and its verbosity, among other options to create a blacklist to block the access from a range of specific devices and to configure the device internals to define its behavior.

shell@hammerhead:/etc/bluetooth $ ls -l
        -rw-r--r-- root root 1541 2013-09-30 00:52 auto_pair_devlist.conf
        -rw-r--r-- root root 2821 2013-09-30 00:52 bt_did.conf
        -rw-r--r-- root root 947 2013-09-30 00:52 bt_stack.conf        

The content for the ‘auto_pair_devlist.con’ file looks as follows:

# Do NOT change this file format without updating the parsing logic in
                # BT IF module implementation (btif_storage.c)

                # This file contains information to prevent auto pairing with Bluetooth devices.
                # Blacklisting by vendor prefix address:
                # The following companies are included in the list below:
                # ALPS (lexus), Murata (Prius 2007, Nokia 616), TEMIC SDS (Porsche, Audi),
                # Parrot, Zhongshan General K-mate Electronics, Great Well
                # Electronics, Flaircomm Electronics, Jatty Electronics, Delphi,
                # Clarion, Novero, Denso (Lexus, Toyota), Johnson Controls (Acura),
                # Continental Automotive, Harman/Becker, Panasonic/Kyushu Ten,
                # BMW (Motorola PCS), Visteon, Peugeot, BMW (MINI10013)
AddressBlacklist=00:02:C7,00:16:FE,00:19:C1,00:1B:FB,00:1E:3D,00:21:4F,00:23:06,00:24:33,00:A0:79,00:0E:6D,00:13:E0,00:21:E8,00:60:57,00:0E:9F,00:12:1C,00:18:91,00:18:96,00:13:04,00:16:FD,00:22:A0,00:0B:4C,00:60:6F,00:23:3D,00:C0:59,00:0A:30,00:1E:AE,00:1C:D7,00:80:F0,00:12:8A,00:09:93,00:80:37,00:26:7E

                # Blacklisting by Exact Name:
                ExactNameBlacklist=Motorola IHF1000,i.TechBlueBAND,X5 Stereo v1.3,KML_CAN

                # Blacklisting by Partial Name (if name starts with)
                PartialNameBlacklist=BMW,Audi,Parrot,Car

                # Fixed PIN keyboard blacklist. Keyboards should have variable PIN
                # The keyboards below have a fixed PIN of 0000, so we will auto pair.
                # Note the reverse logic in this case compared to other's in this file
                # where its a blacklist for not auto pairing.
                FixedPinZerosKeyboardBlacklist=00:0F:F6

                # Blacklisting by addition of the address during usage

As we were mentioning before, basically we can blacklist different devices by their address, exact name, partial name, or even block by those ones who have a fixed PIN. In second place, the file ïbt_did.conf’, contains the device ID (DID) configuration

# Device ID (DID) configuration
        [DID]

        # Record Number: 1, 2 or 3 - maximum of 3 records
        recordNumber = 1

        # Primary Record - true or false (default)
        # There can be only one primary record
        primaryRecord = true

        # Vendor ID '0xFFFF' indicates no Device ID Service Record is present in the device
        # 0x000F = Broadcom Corporation (default)
        #vendorId = 0x000F

        # Vendor ID Source
        # 0x0001 = Bluetooth SIG assigned Device ID Vendor ID value (default)
        # 0x0002 = USB Implementer?s Forum assigned Device ID Vendor ID value
        #vendorIdSource = 0x0001

        # Product ID & Product Version
        # Per spec DID v1.3 0xJJMN for version is interpreted as JJ.M.N
        # JJ: major version number, M: minor version number, N: sub-minor version number
        # For example: 1200, v14.3.6
        productId = 0x1200
        version = 0x1436

        # Optional attributes
        #clientExecutableURL =
        #serviceDescription =
        #documentationURL =
        …

And last but not least, the file ïbt_stack.conf’ which includes the output path where we will redirect the dumped information and the level verbosity used by the different components, which has been set to ï2′ by default, in case you were using the option available under the developers menu.

# Enable BtSnoop logging function
        # valid value : true, false
        BtSnoopLogOutput=false

        # BtSnoop log output file
        BtSnoopFileName=/sdcard/btsnoop_hci.log

        # Enable trace level reconfiguration function
        # Must be present before any TRC_ trace level settings
        TraceConf=true

        # Trace level configuration
        # BT_TRACE_LEVEL_NONE 0 ( No trace messages to be generated )
        # BT_TRACE_LEVEL_ERROR 1 ( Error condition trace messages )
        # BT_TRACE_LEVEL_WARNING 2 ( Warning condition trace messages )
        # BT_TRACE_LEVEL_API 3 ( API traces )
        # BT_TRACE_LEVEL_EVENT 4 ( Debug messages for events )
        # BT_TRACE_LEVEL_DEBUG 5 ( Full debug messages )
        # BT_TRACE_LEVEL_VERBOSE 6 ( Verbose messages ) - Currently supported for TRC_BTAPP only.
        TRC_BTM=2
        TRC_HCI=2
        TRC_L2CAP=2
        TRC_RFCOMM=2
        TRC_OBEX=2
        TRC_AVCT=2
        TRC_AVDT=2
        TRC_AVRC=2
        TRC_AVDT_SCB=2
        TRC_AVDT_CCB=2
        TRC_A2D=2
        TRC_SDP=2
        TRC_GATT=2
        TRC_SMP=2
        TRC_BTAPP=2
        TRC_BTIF=2        

Big thanks and credits to Sebastiàn Guerrero (@0xroot) about how to customize the settings and the output logs.

Pros and Cons of this technique:

Pros:

1. Very easy to perform
2. Supported by open source tools
3. Even if we don’t know exactly what kind of Bluetooth connection the app uses, we can get the traffic anyway

Cons:

1. It simulates an attack by a privileged adversary that has access to the device, not a more general attack where the attacker can only sniff radio traffic, so we have only a part of the picture of the security of the application or device.
2. It works only on Android >= 4.4
3. Once the application is audited in this way, you still have work to do to understand if the information passed in the Bluetooth communication is properly protected by, for example, Bluetooth encryption.