Hacking a Fingerprint Safe Lock

One night, while lazily scrolling through posts on the Lock Pickers United discord, I found a post asking about good “beginner level” electronic locks for hardware hacking. The replies recommended a Chinese fingerprint lock, which had a number of known vulnerabilities that could be found and exploited. I like locks, I also like random hardware hacking projects, so I did what any sane person with an already too big pile of half finished projects would do — I bought two of them.

My original plan for these locks was to do a “proper” hardware reversing exercise, model the PCB, document all the vulnerabilities and see if I could find any secrets in the firmware. As usual, things didn’t quite go to plan.

Here is the lock in all its Chinesium glory.

This is sold on eBay as “Fingerprint Safe Lock Gold Keypad Replace S&G Lock With Override 2 Keys”, and shipped directly from China. I also received some badly translated instructions. For those not familiar with safe locks, the grey piece of metal is the actual lock, this would be mounted inside the safe, the dial (the gold part) is mounted on the outside. A cable runs between the two to allow data and power to reach the lock body. If the correct pin or fingerprint is provided, the lock will open. The little red button is a reset mechanism, this is intended to be mounted inside the safe but is often mounted in a place where it can be reached from the outside (using a piece of wire, for example). This presents our first possible attack — simply resetting the dial and using the factory default pin. Two key are also provided as an override mechanism. I don’t want to focus too much on picking locks here, but let’s just say the lock used here is not hard to pick.

Let's take a look inside that lock body.

The board has a microcontroller, a driver chip for the motor, and some other ancillary components. The motor moves a piece of metal which allows the bolt to move. The key override moves the entire carriage that the motor is attached to, also causing the bolt to move. (The bolt is the piece of metal sticking out of the lock body, which would keep the safe closed). Looking at the right hand side of the image, we can see two big header pins, which are connected to the motor. This presents our second obvious attack, as we can almost certainly reach those through the keyway and apply power directly to the motor.

Moving on, the keypad contains some more components. In addition to the keypad, we also have another PCB, to which the fingerprint reader is attached. Here’s the fully assembled unit:

And a shot with the ribbon cable still connected, this connects the keypad on the front of the dial.

For the curious, here’s the chip underneath the fingerprint reader.

There is almost certainly a vulnerability here. We can access the fingerprint reader from outside of the “locked” container. The reader likely stores the fingerprint data and checks the presented finger. It may well be possible to simply swap the reader from a “known” lock to a “target” one. I’ve not tested this, but stranger things have happened…

At this point I spent a little while taking photos of the PCB, loading it into KiCad and rapidly running out of patience. Here’s a better shot of the PCB, this time removed from the lock body.

Having exhausted my patience for KiCad, i went back to what I do best; randomly poking stuff and hoping something starts to make sense. I fired up the oscilloscope and started looking at the data flowing over the cable between the keypad and the lock body. Yes, the logic analyser would be a better tool for this job, but it was in the cupboard…

One day I will figure out how to capture screenshots from this thing, but for now, poor quality photos it is. Looking at the trace we can see some data exchange happening. Repeating this capture a couple of times suggested that the same signal may be being sent each time the lock was opened (using the fingerprint reader). This wasn’t really a surprise, I had assumed that the lock would send a code to the lock body which would be verified, and it would make sense for a cheap lock not to try and encrypt that code in transit.

I didn't recognise the data encoding used above. I wanted to understand how the code was sent and try and determine if it was based on something like a serial number which we might be able to deduce from a “locked”safe. Time to connect the logic analyser.

My go-to here is usually the fancy probes, but there just wasn’t enough room to get a proper connection on all 4 terminals.

I tried connecting to the back of the cable connector with clips, but that was also a bit of a mess. I ended up soldering wires directly to the pads on the board. Ignore the probes attached to the motor connector, I was trying to work out which way voltage was applied. (Yes, this was the only photo I remembered to take of the setup…).

The photo above also shows the override lock, in all its “badly made glory”.

With everything connected, it was into Logic2 to capture some data. When we first present a finger to the lock, the keypad sends a signal to the lock body.

The body then responds, with the same signal.

The keypad then sends another signal.

To which the body response.

Hopefully it’s fairly obvious that there is a pattern here. We can assume the first wide up-down pulses are used to wake up the microcontroller and signal the start of a data transmission. The smaller pulses follow a pattern for both transmissions, with a different sequence at the end.

Let's look at the second lock (there is a reason I bought two of these…). I set these up to recognise different fingerprints, so I’d have a way to compare data between two different locks.

First, the initial data exchange:

And then the unlock command:

Notice the pattern? The last few “bits” are the same between lock 1 and lock 2. This got me thinking, what would happen if I used the wrong keypad on the wrong lock body? Would it just send an “open the lock” command after verifying the fingerprint? I connected the keypad from lock 2 to the body of lock 1 and… nothing, well, except for some angry beeping from the lock.

Back in Logic2, let's look at the data exchange when the wrong keypad is used. First, the sent data.

And the reply.

If you’re thinking that reply looks familiar, that’s because the same reply is also sent when the correct keypad talks to the lock body. Let’s recap what we know so far:

• The keypad and the lock are paired — we cant connect a random keypad
• The keypad always sends the same command to the lock body
• The commands only partially differ between locks
• The lock body will reply with the command it is expecting, regardless of what command it receives

And there it is, an exploit allowing a universal bypass for this lock. We can send a random unlock command to the lock body (remember, the cable is accessible from outside the container), capture the response, strip out the part that is unique to the particular lock body, add the unlock command sequence and send it back.

I spent a lot of time trying to figure out the encoding method used by the lock, before I realised it really doesn’t matter. If we treat each wide pulse as a ‘1’ and each narrow pulse as a ‘0’, we can express the commands in binary. As long as we replay the code in the same way (wide and narrow pulses of positive voltage), everything will work.

With that figured out, the next step was to figure out which part of the “code” was the unique identifier, and which was the command. When viewing the captured data in its “binary” form, this becomes much easier. (Seriously, why doesn’t Logic2 have the ability to compare traces from different captures in the same window…). We end up with the following codes for lock and unlock:

[Unique identifier (17 bits)] + [command (7 bits)]

With a lot of help from Chat GPT, i started writing an Arduino sketch to perform the exploit.

[embed]

By far the hardest part of this code was capturing the response from the lock body accurately. I had to use an interrupt based system to capture pulses, but this was also being triggered by data transmission, even though the pins were not connected (electronics really are the best >.<). With that problem solved, all that was left to do was test the exploit. I made a YouTube video to show that working:

[embed]

In summary, the exploit sends a random stream of data to the lock body, the lock responds with the data it’s expecting, which includes the unique ID we need to continue communicating. We capture that data, add the “unlock” command, and send it back to the lock.

I went into this project hoping to have some fun finding already known vulnerabilities in this lock, what I ended up with is a completely non-destructive, universal bypass for any of this lock model (as far as I know anyway).

Before I call this done, I want to point out something in the eBay listing for this lock. The listing has the following title: “Fingerprint Safe Lock Gold Keypad Replace S&G Lock With Override 2 Keys”. S&G stands for “Sargent and Greenleaf”, a company well known for making safe locks, including both electronic and combination dials. Under no circumstances should you consider replacing an S&G lock with this product, or any other Chinese safe lock. If you really must have an electronic lock, get one from a reputable manufacturer, like S&G or lagard.