Reverse engineering of an OFO smart lock

After the dockless bike sharing firm ofo ceased its service in Milan, both due to the municipality revoking the permissions granted and to vandalism (it has been estimated that around the 10% of the bikes deployed has been damaged), the majority of the bikes has been retired by the company, but a certain number of them - mostly damaged - is still laying around in the city.

These bikes are equipped with a smart padlock which can be unlocked by anyone possessing a smartphone with the firm’s app installed. And here comes the hacker’s curiosity: being always interested in technology, and especially in embedded systems, I always have been wondering what there is under the hood of these padlocks. Thanks to the people belonging to an hackerspace in Milan I satisfied my curiosity: these guys collected some of the now abandoned (and wrecked) ofo bikes with the plan of repairing and then making them available to the other members of the center. Within this process, they detached and put apart the bikes’ padlocks, giving me the ocasion of picking up one of them to do a bit of reverse engineering.

As regards a general description of what’s inside the locking device, this website provides some information: in this page I will extend them with my findings.

Microcontroller’s connections:

The first operation I did was mapping the connections between the nRF51822 microcontroller [1] and the other components, both mounted on the PCB and the ones outside it (motor, buzzer and keypad). The results are summarised here:

Microcontroller’s firmware:

Coming to the software side, the padlock’s microcontroller comes with a code locking mechanism which (in theory) prevents reading the contents of the flash memory using a debugger. However, the nRF51822 microcontrollers are affected by a vulnerability which allows, through a debugger, to get the content of the flash memory even when the locking mechanism is enabled [2]. Luckily a python script is available [3], providing a good tool which allows to dump the content of the flash exploiting the aforementioned vulnerability: it’s only necessary to connect the microcontroller to a PC via a SWD tool, like ST-Link.

Once the content of the flash memory has been retrieved, is time to analyse the binary dump searching for program image(s). These can be found easily exploiting the fact that unwritten flash memory cells have (hex) value 0xFFFFFFFF and knowing that a program compiled for Cortex M architecture must start with a vector table defining the addresses for the various interrupt vectors. Sifting through the binary dump, emerges that the microcontroller’s flash memory contains four vector tables at the addresses 0x0000, 0x1000, 0x18000 and 0x3B000. The table below contains the addresses associated to each vector in each of the four tables:

Currently I’m decompiling and analysing the binary image contained in the flash memory to find what each executable does, I’ll progressively publish here the results.

References:

[1] nRF51822 datasheet

[2] Firmware dumping technique for an ARM Cortex-M0 SoC

[3] Python script for dumping firmware from read-back protected nRF51 chips