Experiment Description
In this experiment, we will study how to analyze the security of the OKLOK smart lock, as well as analyze the Android app, dynamic code debugging, and BLE analysis control, ultimately achieving remote control of the smart lock using our code. We will first interact with the smart lock using a BLE adapter and Gatttool, exploring the services and characteristics present on the device. Then, we will reverse-engineer the Android app using JEB to understand the meanings of the services and characteristics. Next, we will investigate the BLE traffic between the Android app and the smart lock. We can use the Android BLE logging feature to view the BLE traffic, or use Ubertooth or any other BLE sniffer. The analysis of BLE traffic and the mobile application will reveal that the communication uses AES encryption. Finally, we will use instrumentation on the Android app to find the encryption keys and other values, which we will use to write an automated script to take over the smart lock and unlock it without any authentication.
Required Resources
Hardware
● Smart Door Lock (OKLOK)
● BLE Adapter
● Android Phone (with OKLOK app installed)
● Ubertooth (optional)
Software
● Wireshark
● Bettercap/Bleah
● Android Device 1 Ubertooth-tools
● JEB
● OKLOK.apk
● OKLOK_gadget.apk
Introduction to OKLOK Smart Lock
OKLOK is a smart padlock with Bluetooth Low Energy (BLE) capabilities. Among other features, it can be operated remotely from a phone using the OKLOK app available for Android and iOS. In this experiment, we will analyze the Android application to understand how to combine it with BLE exploitation methods to control the smart lock. The lock supports unlocking using the fingerprint of registered users, but here we will focus solely on the remote unlocking feature via BLE. By default, the lock is in sleep mode, meaning the Bluetooth scanner cannot see the lock and it does not respond to BLE commands. To use it, it must be activated by touching the fingerprint sensor on the lock body. Once activated, the lock automatically returns to sleep mode after a few seconds of inactivity.
OKLOK Analysis
Preliminary Analysis
To analyze the smart plug, the first thing we need to do is find the address of the target smart lock. To do this, we will first ensure that the BLE Bluetooth is connected. Run hciconfig to see if the smart lock Bluetooth has been successfully connected to the VM.
Now that we have connected the smart lock Bluetooth to the VM, let’s find out the address of the target Smart Lock.
Hcitool detects our Bluetooth name as BlueFPL (blue fingerprint lock) with the Bluetooth address F8:33:31:DC:10:1F. We can also run hcitool leinfo to get more information about the BLE device, as shown below.
The hcitool toolkit can control Bluetooth, with toolkit parameters divided into two parts: one for normal Bluetooth device debugging, and the other for low energy, i.e., BLE devices. The tool parameters are as follows:
Now use Gatttool to connect to the device and explore the list of services and characteristics present on the device. Using hcitool is for managing the connection to the device, while for fine management of BLE data, gatttool is needed. The operations for sending commands to Bluetooth devices using gatttool are much more comprehensive than those of hcitool. The usage of gatttool is divided into two types: directly using parameters to control the Bluetooth device, or entering interactive mode with the -I parameter to control the Bluetooth device.
sudo gatttool -i hci-interface -b device-address -I
Now, we can use the primary command to list all the services present on the device.
Similarly, we can use the characteristics command to view all characteristics.
Where handle is the characteristic’s handle, char properties are the characteristic’s attribute values, char value handle is the handle of the characteristic value, and uuid is the identifier of the characteristic;
We can also use automation tools such as Bleah (changed to Bettercap) to enumerate all different characteristics, their properties, and stored values. To do this, we will use the following command.
$ bleah -b F8:33:31:DC:10:1F -e
Bleah scans for nearby BLE devices to find the device with the specified MAC address. Once found, it will connect to the device and enumerate all services and characteristics. To understand the purpose of the services and their characteristics, we need to analyze the Bluetooth traffic and the Android application.
Analyzing BLE Traffic Using Android Device
We need to capture the Bluetooth communication generated when the application sends the unlock command. We can use packet sniffing techniques on a computer, or use the built-in BLE logging feature of the Android smartphone. Android provides the “HCI Listening Log” feature to capture Bluetooth traffic from the smartphone. Enter the app, click on “Fingerprint Settings”, and then click to send the unlock request.
The captured Bluetooth traffic will be stored in a file named 1.pcap, which we can transfer to the PC for further analysis. The service with UUID fee7 has two characteristics – UUID 36f5 and 36f6 handle 0x3 and 0x6 respectively, with corresponding attributes WRITE and NOTIFY. Open the 1.pcap file in Wireshark and apply the filter (btatt.opcode == “Write Request” && btatt.handle == 3)
Using the filter with handle 0x6, we can see that the data is encrypted.
Decrypting Traffic
To proceed, we need to decrypt the traffic to understand how the remote unlocking process works. We use the JEB decompiler to analyze the Android application.
The BLEUtils class within the package com.coolu.blelibrary.utils contains two methods Encrypt and Decrypt, which need to be analyzed closely from a security perspective as these methods take two byte arrays as parameters.
The first array contains plaintext/ciphertext, and the second array contains the key. The encryption used is AES in ECB mode, without padding.
Next, we need to install the instrumented application on the phone, connect the phone to the Bluetooth lock, and perform the unlocking operation to see the output results of the instrumentation.
The AES key is
210358453708121F305B503D3A5A5037. Its size is 16 bytes, which means the password is AES-128. Using this key, we can decrypt the packets we captured in Wireshark. We will use the script oklok-decrypt.py to decrypt the AES encrypted values. Running the script on our encrypted packets, we get the following results.
Let’s take a look at the first decrypted write request. It starts with 0601, which is 1537 in decimal. Analyzing the decompiled code, we can find a class Order in the package com.coolu.blelibrary.mode that contains the mapping of these values. 1537 represents the GET_TOKEN command.
The second command is 0201 or 513 in decimal. This is the GET_BATTERY command. (InputDeviceCompat.SOURCE_DPAD == 513). The third command is 0501 or 1281 (in decimal), which is the OPEN_LOCK command. The names of the commands themselves clearly indicate their purposes.
In the BLE traffic we captured, there are also 4 NOTIFY packets that contain responses to the sent commands.
Similar to the WRITE data packets, the first two bytes of each packet indicate the packet type, with the difference being that their values are one more than the corresponding WRITE data packets. For example, the ID for GET_TOKEN is 0601 for WRITE and 0602 for NOTIFY. Checking the package com.coolu.blelibrary for the CMDAPI class, we can find the purpose of these messages.
Unlocking
Understanding the Unlock Process
By studying the traffic, we can infer that the Android application sends commands by writing to handle 0x3, and the corresponding padlock responds by sending notifications on handle 0x6. From the Gatttool output (and Bleah), we know that handle 0x3 corresponds to UUID 000036f5-0000-1000-8000-00805f9b34fb, while handle 0x6 corresponds to 000036f6-0000-1000-8000-00805f9b34fb.
We can verify our findings using the decompiled code of the BLEService class in the package com.coolu.blelibrary.
The TX_UUID and RX_UUID correspond to the write and notify handles respectively. The following diagram shows how the unlocking process of our target smart lock works.
First, the application obtains a token from the device, which is then used in subsequent commands. As mentioned, all requests and responses are encrypted using AES-128 in ECB mode. To bypass the application and implement our own unlocking, we need to follow the same logical flow.
For simplicity, we will omit the second step of obtaining the current battery level, as this is unnecessary for our purposes. Both requests and responses are 16 bytes, with the first two bytes indicating the command type. To understand how to construct the command itself, we can again refer to the decompiled classes in the package com.coolu.blelibrary.mode. For the GET_TOKEN command, we have a corresponding class GetTokenTxOrder.
The add method called from the constructor appends two 01 bytes to the command buffer after 0601. The remaining part of the buffer (12 bytes) is filled with random values in the generateString method. From the decompiled code of the LockInfoActivity class in the package com.oklok.y.activity.lock, it is evident that the response to the command on notify handle 0x6 will contain a four-byte token.
Similarly, for the OPEN_LOCK command, we have a corresponding class OpenLockTxOrder.
The first two bytes will contain the command type 0501, followed by 06. The next six bytes contain some kind of password, which we always set to 0x30 in our tests, regardless of the lock password set on the application. The next four bytes contain the token obtained in the previous step. The remaining three bytes are filled with random values.
Remote Unlocking
With all this information, we can write a script to connect to the smart lock and handle the packets, encrypting them and sending them to the device to unlock it without any authentication regarding a specific device instance.
First, let’s introduce a third-party Python library—bluepy.
bluepy
bluepy is a great open-source Bluetooth project on GitHub (https://github.com/IanHarvey/bluepy), primarily designed to implement BLE interfaces on Linux using Python.
Refer to the official instructions for the installation process. The official documentation also provides detailed information about using this library.
(http://ianharvey.github.io/bluepy-doc/)
Writing Code
First, we need to scan for nearby BLE devices using the Scanner class from bluepy.
According to the official documentation, the Scanner object is used to scan LE devices that are broadcasting advertisement data. In most cases, this will provide a set of devices available for connection. (However, note that Bluetooth LE devices can accept connections without broadcasting advertisement data or can broadcast advertisement data but not accept connections).
After the scan, we can retrieve the scanned devices using the getDevices() method, looking for the Bluetooth lock we need to connect to.
for dev in s.getDevices(): if dev.getValueText(0x9) == 'BlueFPL': print '[+] Found OKLOK' connect(dev.addr) breakOnce found, we need to use the Peripheral class to connect to the Bluetooth lock.
According to the official documentation, this class encapsulates the connection to Bluetooth LE peripheral devices. A peripheral object can be created directly by specifying its MAC address. Once the connection is established, the services and characteristics provided by the device can be discovered and read or written.
Next, we use the getCharacteristics method to obtain the list of characteristic objects for the device.
p = Peripheral(addr)write_char = p.getCharacteristics(uuid='000036f5-0000-1000-8000-00805f9b34fb')[0]notify_char = p.getCharacteristics(uuid='000036f6-0000-1000-8000-00805f9b34fb')[0]Then, we send the command to unlock using the previously obtained AES encryption.
if d.token != None: cipher = AES.new(AESKEY.decode('hex'), AES.MODE_ECB) # Send unlock command pt = '050106303030303030'.decode('hex') + d.token + '\x00\x00\x00' write_char.write(cipher.encrypt(pt)) print '[+] Sent unlock command'And that’s how we complete the unlocking.
Original Source: ChaMd5 Security Team
