Introducing nOBEX – a tool for testing Bluetooth phone and messaging profiles

Introduction

The original Bluetooth standard (Bluetooth BR/EDR, commonly called Bluetooth Classic) provides a wide range of functions using standardized high level communication protocols known as profiles. Many of these profiles are built on a serial port like interface provided by the RFCOMM protocol. In automotive head units, Bluetooth is typically used to interface with cellular modems, make and receive phone calls, read phone books and read and write text messages. With the exception of the audio link used in phone calls, these functions are provided by the Hands Free Profile (HFP), Phone Book Access Profile (PBAP), and Message Access Profile (MAP). These profiles are all built on the RFCOMM protocol. HFP involves sending and receiving AT commands over the serial interface. PBAP and MAP are extensions of the Object Exchange (OBEX) standards which provide a mechanism to store and retrieve files on a remote (often virtual) file system. OBEX originated in infrared (IrDA) communication systems, but was later adopted by Bluetooth and other standards.

nOBEX is a tool which allows the PBAP, MAP, and HFP profiles to be emulated in order to test devices which use these profiles, such as vehicle infotainment systems. nOBEX provides its own PBAP and MAP clients and these can be used to clone the virtual file systems of real phones. This means that the entire phone book and all the text messages on a phone can be downloaded. Raw vCards, XML listings and MAP BMSG structures are stored and can be modified as desired for negative testing. nOBEX can then act as a PBAP and MAP server, allowing vehicles and other devices to connect to it and retrieve phone book and message information. BMSGs, vCards and XML listings are sent exactly as saved, allowing malformed user modified data to pass through as entered by the user. Since most vehicle head units require HFP support before they attempt to use PBAP and MAP, nOBEX also provides rudimentary support for HFP. It sends back user customizable preset responses to AT commands coming from the vehicle's head unit and this allows real cell phones to be mimicked.

nOBEX is built on top of the PyOBEX project by David Boddie [https://bitbucket.org/dboddie/pyobex]. This tool would not have been possible without David's great efforts in making OBEX clear, comprehensible and easy to work with. nOBEX extends PyOBEX by adding support for large multi-part OBEX messages, HFP emulation, PBAP and MAP servers, a MAP client, and an improved PBAP client.

Tool Details

nOBEX (and PyOBEX) use the BlueZ Bluetooth stack to advertise over the Service Discovery Protocol (SDP) and establish RFCOMM connections. nOBEX/PyOBEX contain standalone implementations of the OBEX specification for client and server roles. PyBluez [https://github.com/karulis/pybluez] is used to access the BlueZ API from Python.

Both Python 2 and 3 are supported by nOBEX. However, the SDP advertising functionality appears to be partly broken on the Python 2 version of PyBluez (as tested on Fedora 24, August 2016). SDP advertising does work correctly on the Python 3 version of PyBluez, so the recommended approach is to use Python 3.

Client Mode

In client mode, nOBEX uses BlueZ to query the services offered by the server. If it detects that the requested service is available, it connects to the server on the specified port using RFCOMM and SDP. OBEX requests are constructed and sent to the server in accordance with the profile in use. Any responses are interpreted and saved to disk. As noted above, the client modes for PBAP and MAP can be used to clone a real phone.

Server Mode

In server mode, nOBEX advertises the available services over SDP. When a client makes an RFCOMM connection on the advertised port, the server accepts and handles OBEX requests. OBEX responses to requests are sent using the data on disk. The PBAP and MAP servers serve file/folder structures matching those generated by the respective clients.

Installation Instructions

The following setup instructions were tested on Fedora 24. Other recent distributions should also work, but dependencies and incompatibilities other than those listed below may be encountered.

First install PyBluez:

sudo dnf install python3-bluez

Try probing advertised local services on SDP:

sudo sdptool browse local

If you are running a recent distribution (like Fedora 24), this will probably fail due to some incompatible API changes in new versions of BlueZ. You can fix this by running bluetoothd in compat mode. Do this by editing the systemd service for bluetoothd.

sudo vi /usr/lib/systemd/system/bluetooth.service

Add --compat to the ExecStart line:

ExecStart=/usr/libexec/bluetooth/bluetoothd --compat

Now restart bluetoothd:

sudo service bluetooth stop

sudo systemctl daemon-reload

sudo service bluetooth start

sudo hciconfig -a hci0 reset

Test browsing local SDP services again (it should now work):

sudo sdptool browse local

Get nOBEX and install it:

git clone https://github.com/nccgroup/nOBEX

cd nOBEX

git checkout python3

sudo python3 setup.py install

Usage Instructions

PBAP

Find the MAC address of a phone whose phone book you wish to clone:

hcitool scan

Clone the PBAP contents of an existing phone (replace the MAC below with the correct MAC and specify an empty destination directory; if you specify a non-existent directory, it will be created):

python3 examples/pbapclient-download.py 5C:51:88:8A:EC:5B ~/pbap_root/

Now that you have a copy of your phone’s data in the destination directory, modify the newly created vCards and listing XMLs as desired. You can then run a PBAP server using the cloned phone book:

sudo python3 examples/multiserver.py --pbap ~/pbap_root/

Note: you'll also need to pair your PBAP client with the computer (PBAP server).

MAP

Pull the message data off your phone to establish a test MAP tree:

python3 examples/mapclient-download.py 5C:51:88:8A:EC:5B ~/map_root/

Modify the sample data as desired. Then run the server, indicating where it should look for the root of the MAP tree.

sudo python3 examples/multiserver.py --map ~/map_root/

HFP

The HFP server (audio gateway) is fairly basic, sending back preconfigured replies to select commands. The server is set up to support common HFP commands out of the box, but every vehicle will likely require a few additional commands and/or changes to responses. Custom responses can be configured through an optional configuration file consisting of tab separated command and response pairs, one per line. Sample configuration files can be found in the examples/bbeast folder included with nOBEX.

To run a standalone HFP server:

sudo python3 examples/multiserver.py --hfp [config_file]

Combining Servers

The multiserver.py scripts allow any combination of HFP, MAP, and PBAP servers to be run simultaneously. Just combine the arguments from the examples shown above. To run HFP, MAP, and PBAP simultaneously:

sudo python3 examples/multiserver.py --map ~/map_root/ --pbap ~/pbap_root/ --hfp [config_file]

The combination of HFP and PBAP has been tested successfully on an unmodified 2012 Ford Focus.

Applications

The primary purpose of nOBEX is to perform negative testing and fuzzing of PBAP and MAP clients on automotive head units. The HFP support and PBAP/MAP client support are intended to facilitate this goal. Manual fuzzing can be performed by running a server with hand-modified XML listings, vCards, and BMSGs. OBEX is a rich fuzzing target with many nested TLV (type-length-value) structures that can span multi-part messages. PBAP and MAP greatly increase the attack surface with vCard, BMSG, and XML parsers.

nOBEX does not have integrated support for automated fuzzing, but since it is written in Python, it is easy to extend. More powerful fuzzing capabilities can be built by pairing it with a mutation engine and instrumenting the target device.

Beyond fuzzing MAP and PBAP on automotive head units, nOBEX can also be used for normal positive testing of PBAP, MAP, and other OBEX profiles (such as FTP) for both client and server roles. The PBAP and MAP servers were tested with the OBEX Commander [http://intradarma.com] app for Android, in which many crashes could be triggered by faulty OBEX communication and malformed profile specific data. Furthermore, the HFP support can be used to manually fuzz AT commands.

Future Enhancements

MAP Server

The MAP server only implements part of the specification, and lacks support for some features such as new message notifications. Implementing more of the specification would increase the area that can be fuzzed.

HFP AG

The HFP support is currently very rudimentary, providing hard coded responses for every command. A more intelligent and stateful HFP audio gateway (AG) would improve compatibility with more vehicles, and make more advanced fuzzing possible. The HFP specification also supports sending phone book contents through AT commands and so it may be useful to implement sending contacts over HFP.

Automated Mutation and Instrumentation

Both the low level OBEX protocol and the higher level PBAP/MAP protocols are rich fuzzing targets. Integrating a smart mutation engine for OBEX and PBAP/MAP would accelerate the process of generating test vectors. Full automated fuzzing would also require instrumentation of the target. Some basic instrumentation may be possible in a reusable manner remotely over Bluetooth. More comprehensive instrumentation would most likely be specific to the head unit being targeted.

Published date: 07 September 2016

Written by: Sultan Qasim Khan