nOBEX allows emulating the PBAP, MAP, and HFP profiles to test vehicle infotainment systems and similar devices using these profiles. nOBEX provides PBAP and MAP clients to clone the genuine virtual filesystems for these profiles from a real phones. This means downloading the entire phone book and all text messages. 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. Vcards, BMSGs, and XML listings are sent exactly as saved, allowing malformed user modified data to go through. Since most vehicle head units require HFP support before they attempt using PBAP and MAP, nOBEX also provides rudimentary support for HFP. It will send back user customizable preset responses to AT commands coming from the vehicle's head unit. This allows mimicking a real cell phone.
nOBEX is built on top of the PyOBEX project by David Boddie. This tool would not have been possible without David's great efforts in making OBEX approachable 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.
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. Both Python 2 and 3 are supported.
In client mode, nOBEX uses BlueZ to query services offered by the server. If it detects that the requested service is available, it connect to the server over RFCOMM on the port specified over SDP. OBEX requests are constructed and sent to the server in accordance with the profile in use. Responses are interpreted and saved to disk. Client modes for PBAP and MAP can be used to clone a real phone.
In server mode, nOBEX advertises the available services over SDP. When a client makes an RFCOMM connection on the advertised port, the server will accept and handle OBEX requests. OBEX responses to requests will be sent using the data on disk. The PBAP and MAP servers serve file/folder structures matching those generated by the respective clients.
The following setup instructions were tested on Fedora 24, 27, and 29. Other recent distributions may also work, but experiences may vary. You may need to install legacy bluez tools (including sdptool) if your distribution does not bundle sdptool. Also be aware that OBEX servers tend to not work inside virtual machines with shared Bluetooth adapters. Either run Linux natively, or have a dedicated USB Bluetooth adapter used only by the VM.
Try probing advertised local services on SDP:
sudo sdptool browse local
If you are running a recent distribution, it will probably fail due to some breaking API changes in BlueZ 5. You can fix it 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:<