Sesame, open up? 🔐 There are devices that just beg to be hacked. Smart locks are quite l…

Sesame, open up? 🔐

There are devices that just beg to be hacked. Smart locks are quite logical among them. They should be as protected as possible, but at the same time comfortable. And in trying to make it convenient, manufacturers often forget that security ≠ UX 💀

I recently read great article by Theodoros Danos ( and here here is the translation of the article on Habré ), where he calmly hacked a commercial Bluetooth lock with fingerprint support. No physical access. No complex exploits. Just API, BLE and a little patience 😏

That's how it was 👇

The researcher noticed that the mobile application binds the lock to an account through a regular POST request, where it is enough to specify the MAC address of the device.
No checking to see if the castle is nearby. No user or device authentication. Simple:

POST /lock/bind  


{ "mac": "xx:xx:xx:xx:xx", "userId": 123 }

And the lock is in your account. Even if it's hanging on someone's door on the other side of town 😅

After binding, the application receives encrypted lock data from the API ( encryptedData ). What's inside? Password, encryption key, MAC. Everything you need to give the command to open 🤝

And here's an important point:
The application had a hardcoded AES key ( 58966742920123314112157843194045 ), which was used to decrypt the data. One key for everyone. Algorithm - ECB. Padding - absent. Sounds like an instruction on “how not to make crypto in 2025” 🫡

The BLE protocol was nicely designed:

- 0x36f5 - “lock” command
- 0x36f6 - response “from the castle”

16-byte commands are encrypted using the same lockKey that we pulled out. And this is just great, because you can catch the command once and repeat it whenever you want 🧠

The researcher used the BLE:Bit framework to intercept traffic and resend it. Captured the unlock command → left → returned → sent → lock opened 🪄

No session. No authentication. Just BLE and the "repeat" button...

💥 What went wrong:

— The API allowed binding via MAC without checking whether the lock was nearby
— The key was hardcoded into the application
- AES/ECB/NoPadding
— BLE protocol without MAC, nonce, handshake and everything that makes it secure
— Application without obfu skations, all the logic in the palm of your hand

Well, we've had enough of it, and that's enough. We're smart here. Let's think about how all this could be fixed. I will write my solution below in the post, and you can use the comments under the post. It's very interesting to hear another opinion 🤔

What do I recommend as a solution? Well, first of all, bind only when physically close via BLE. This at least sounds logical. Why do you need the ability to link a device that is located a kilometer away from you? Secondly, you would need to switch from ECB to something sane ( for example AES-GCM ). ECB is one of the simplest implementations of AES, and this is bad for security. And thirdly, obfuscate the application and protect it from Frida ( and adding replay protection would be great ) 🥳

And it’s important to remember that you can’t hope for encryption if everything around it is a sieve. Security doesn't start with AES, but with architecture 🤓

#internet_things
#information_security