Keyless Entry: Hacking SwitchBot Smart Locks
Researchers found several flaws in SwitchBot Lock Pro, the worst a Bluetooth crypto flaw that lets anyone silently open the lock.
Extract
TL;DR We’ve identified multiple vulnerabilities in devices of the popular SwitchBot Lock Pro smart lock series. The most critical, a cryptographic flaw in their bluetooth communication, allows everyone to silently open smart locks in a software-only attack. No physical tampering is required. Below is a video of the attack in action. Introduction Smart locks have become very popular in recent years. Especially when it comes to AirBnB-style apartment sharing, but also in corporate environments and private accommodation, people enjoy having locks that don’t require physical keys. So when it came to selecting targets for our regular IoT hacking team event, smart locks were a natural choice. After some research we cam across the highly praised Switchbot Lock Pro Combo, including a key actuator, pin pad and smartphone app. It is one of the best-rated and most-sold smart locks on Amazon. For roughly 240€ (at the time of writing) it comes with a lot of features - and the Amazon reviewers are happy to share that it works as intended. Features aside, our main interest was, of course, the device’s security. So we ordered one and had a look. Here is what we found out. Reversing the Lock As usual when inspecting IoT devices, we wanted to get our hand on the firmware. But before we dive into that, let’s first look into the target’s features and architecture. The Switchbot Pro Lock The bundle comes with two hardware devices, an actuator and a key pad. The lock can further be controlled and configured via a smartphone app. Switchbot Pro Lock Bundle on Amazon The actuator is mounted onto the inside of the door and encloses the door’s key. When the door is supposed to open, the actuator simply turns the key in the lock. Switchbot Pro Lock Actuator Promotional Material The key pad is kept outside the door and communicates with the actuator over Bluetooth Low Energy (BLE). A person can authenticate itself to the system either using a smart card/key fob, using a fingerprint, or - most commonly - by supplying a PIN. The whole system can also be added to a WiFi network, making it possible to control the lock over the Internet. Now that we have an idea of the feature set, we can start digging. Firmware Reversing When hacking a device, it is usually a good idea to first get your hands on its firmware. There are various techniques for accomplishing this, FLASH Dumping for example. Before starting to desolder chips, however, it makes sense to scrape the web for firmware …
Explained
What happened
Security researchers at Neodyme looked at the SwitchBot Lock Pro, a best-selling smart lock sold as a bundle of an inside actuator (it turns the key), an outside keypad (PIN, fingerprint or fob) and a phone app. They found several flaws. The worst lets anyone in Bluetooth range open the lock with software alone.
- Firmware was public. The Android app contained the URL of a public S3 bucket with firmware files, so no chip dumping was needed.
- Trust ran the wrong way. The keypad outside the door decides whether a PIN is valid and then sends
UNLOCKto the actuator inside. The device an attacker can reach is the one in charge. - The Bluetooth link was plain text. Keypad and actuator talk over unprotected BLE. All security sits in a home-made application protocol.
- The protocol used AES in CTR mode with no integrity check. After pairing, the keypad asks the actuator for a nonce, then encrypts each command with the shared key and that nonce. The nonce is reused for a whole session.
- Bit flipping. In CTR mode a flipped ciphertext bit flips the same plaintext bit. The keypad's lock button always sends an encrypted
LOCKcommand. An attacker who sees that ciphertext can flip the bits that turnLOCKintoUNLOCKand send it. The actuator decrypts a valid unlock and opens the door, leaving no physical trace.
Why it works
Encryption hides content. It does not prove the content was not changed. AES-CTR turns AES into a stream cipher: ciphertext is plaintext XOR keystream. If you know or can guess the plaintext (here a fixed command), you can change it to any other value of the same length without knowing the key.
The fix has been standard for years: use authenticated encryption such as AES-GCM or ChaCha20-Poly1305, or add a MAC over the ciphertext, and use a fresh nonce per message. Combined with the backwards trust model, the missing integrity check turned a design smell into a full break.
The bigger pattern
This is ciphertext malleability, a well-known class that keeps showing up in IoT and in custom protocols. Related mistakes appear together:
- home-grown crypto on top of an insecure transport
- nonce reuse across many messages
- the less trusted, exposed component making the security decision
- secrets or firmware reachable from a mobile app
Nothing here is new cryptography. What stands out is how a popular, well-reviewed product still shipped the textbook mistake.
What it means in practice
- Never use bare CTR or CBC for messages that carry commands. Use an AEAD mode and reject anything that fails authentication.
- Treat nonce reuse as a bug. Generate a unique nonce per message, or use a counter that is never repeated.
- Put the security decision on the side the attacker cannot touch. Verify credentials server-side, not in the client, the edge device or the browser.
- The same rule applies to backend tokens: signed cookies, webhook payloads and job queue messages need a MAC or signature, not just encryption.
- Audit what your mobile apps expose: bucket URLs, API keys and debug endpoints are easy to extract.