antoinet/obikeReverse engineering of the oBike protocol communication (BLE and HTTP)
This document provides an analysis of the oBike communication protocols as of January 2018.
Results have been presented at the insomni'hack security conference 2019:
as well as at the AREA41 security conference 2018:
The oBike lock consists of a TI CC2541 microcontroller, a power-optimized System on a Chip (SoC) used for Bluetooth Low Energy (BLE) applications. The lock itself has no IP connectivity; it piggybacks the mobile device’s 3G/4G connection to communicate with the oBike backend. The lock communicates via BLE with the oBike app on the mobile device. Protocol messages are then relayed to the oBike backend via a REST API.
The lock has no GPS module of its own. As such, the position reported to the backend is always that of the mobile device, not of the oBike itself.
GPS
|
+---------+ +---------+ +----------+
| oBike | | Mobile | | oBike |
| Lock | +--- BLE ---> | Device | +--- HTTPS ---> | Backend |
+---------+ +---------+ +----------+
oBike Lock (BLE) Mobile Device (HTTPS) oBike Backend
------------+------------------------+---------------------------+--------------
| | |
| [1] hello(lat, lng) | |
| <--------------------- | |
Generate | | |
32bit | [2] keySource | |
Challenge | ---------------------> | [3] unlockPass(keySource) |
| | ========================> | Compute
| | | Response
| [5] | [4] encKey, keys |
| sendKeys(encKey, keys) | <======================== |
!Unlock | <--------------------- | |
Bike! | | |
| | |
Generate | | |
Acknowledge | [6] macKey, index | [7] |
Message | ---------------------> | lockMessage(macKey,index) |
| | ========================> | Register
| | | Ride (start
| | | billing)
Steps:
hello message, push coordinates to lock.keySource, a 32bit value representing the number of
milliseconds since the chip was powered (little endian).unlockPass REST call.encKey (key index) and a 128bit key value in keys.encKey (truncated to 96bits) and the index ( corresponds to
encKey). At that point, the bike will unlock.macKey and index, an acknowledgement that the unlocking was
successful.lockMessage, with the corresponding values (macKey and
index). At that point, the oBike backend will register the ride and start
billing.The BLE protocol components described in the following sections are implemented
in the python module obike.ble_client. In addition, a scanner to detect obike
BLE advertisements is implemented in obike.ble_scanner.py.
6774 0D 86 59AEB6...3931 FD
| | | | |
| | | | +-- Check byte
| | | +----------------- Payload
| | +--------------------- Command type
| +------------------------- Length of payload in bytes
+------------------------------- Command Signature ('gt')
The message both ingoing and outgoing always start with the signature \x67\x74
(ascii gt).
Length of the payload is number of bytes without header/trailer.
The protocol supports different message types identified by a byte. The two most significant bits define the message direction:
0x86 1000 0101 mobile -> obike
0x46 0100 0101 obike -> mobile
The check byte is computed from XORing the command type and the payload bytes:
check_byte = cmdtype ^ b[0] ^ b[1] ^ ... ^ b[N-1]
The maximumn PDU size is 19 bytes (header + payload + trailer). Messages exceeding this size are fragmented.
Command type: 6
These messages are used to manage the "lock record", a data record persisted by
the chip consisting of information from the last ride, such as memberid,
timestamp, oBike identifier, coordinates, etc.
Called without a payload, the command is used to retrieve the saved lock record:
00000000 67 74 00 86 86 |gt...|
If no lock record is available, the lock responds with an empty payload.
00000000 67 74 00 46 46 |gt.FF|
Otherwise, the lock's response contains several values from the last ride, in the following format:
00000000 67 74 46 46 00 00 01 23 45 67 59 9d 72 2a 44 31 |gtFF...#d2Y.r*D1|
00000010 39 33 36 42 33 31 37 2a 72 9d 59 00 34 37 2e 33 |936B317*r.Y.47.3|
00000020 37 32 37 36 30 00 00 00 30 38 2e 35 33 30 38 34 |72760...08.53084|
00000030 32 32 00 00 87 76 f3 7a 8c be 90 f8 4b a4 fa 00 |22...v.z....K...|
00000040 2e ae e3 dc 91 00 00 00 a9 01 8b |...........|
Offset Value Description
-------------------------------------------------------------------------
0004 000001234567 member-id (explicitly coded in decimal,
value is: 1234567)
000a 599d722a UNIX timestamp, 08/23/2017 @ 12:16pm
000e 443139333642333137 obike identifier (D1936B317)
this corresponds to the MAC address without
the first 3 hex digits, in this case:
D4:3D:19:36:B3:17
0017 2a729d59 same UNIX timestamp, little endian
001b 00 transaction type
001c 34372e333732373630000000 latitude (47.372760)
0028 30382e353330383432320000 longitude (08.5308422)
0034 8776f37a8cbe90f84ba4fa002eaee3dc mackey (128 bits)
0044 91 key index
0045 000000 ?
0048 a901 battery voltag level (little endian)
e.g. 4.25V
When used with a payload, this command deletes the current lock record:
00000000 67 74 0d 86 59 d5 ff a4 36 33 39 38 37 37 31 33 |gt..Y...63987713|
00000010 43 14 |C.|
The payload for the delete command consists of the "Bike Trade Number" which was read out previously, i.e. the timestamp when the bike was rented out and the obike identifier:
Offset Value Description
-------------------------------------------------------------------------
0004 59d5ffa4 timestamp (little endian)
000e 3633393837373133 "63987713C" obike identifier