![\"Switchbot](\"https://neodyme.io/blog/switchbot/switchbot_amazon.png\")
Tobias, Aaron, Justin and Ruben · Neodyme · October 26, 2026
\nWe’ve identified multiple vulnerabilities in devices of the popular SwitchBot Lock Pro smart lock series.\nThe most critical, a cryptographic flaw in their bluetooth communication, allows everyone to silently open smart locks in a software-only attack.\nNo physical tampering is required.\nBelow is a video of the attack in action.
\nSmart locks have become very popular in recent years.\nEspecially 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.\nSo when it came to selecting targets for our regular IoT hacking team event, smart locks were a natural choice.
\nAfter some research we cam across the highly praised Switchbot Lock Pro Combo, including a key actuator, pin pad and smartphone app.\nIt is one of the best-rated and most-sold smart locks on Amazon.\nFor 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.
\nFeatures aside, our main interest was, of course, the device’s security.\nSo we ordered one and had a look.\nHere is what we found out.
\nAs usual when inspecting IoT devices, we wanted to get our hand on the firmware.\nBut before we dive into that, let’s first look into the target’s features and architecture.
\nThe bundle comes with two hardware devices, an actuator and a key pad. The lock can further be controlled and configured via a smartphone app.
\nSwitchbot Pro Lock Bundle on Amazon
\nThe actuator is mounted onto the inside of the door and encloses the door’s key.\nWhen the door is supposed to open, the actuator simply turns the key in the lock.
\n![\"Switchbot](\"https://neodyme.io/blog/switchbot/actuator.jpg\")
Switchbot Pro Lock Actuator Promotional Material
\nThe key pad is kept outside the door and communicates with the actuator over Bluetooth Low Energy (BLE).\nA person can authenticate itself to the system either using a smart card/key fob, using a fingerprint, or - most commonly - by supplying a PIN.\nThe whole system can also be added to a WiFi network, making it possible to control the lock over the Internet.
\nNow that we have an idea of the feature set, we can start digging.
\nWhen hacking a device, it is usually a good idea to first get your hands on its firmware.\nThere are various techniques for accomplishing this, FLASH Dumping for example.\nBefore starting to desolder chips, however, it makes sense to scrape the web for firmware artifacts.
\nWith SwitchBot we got lucky, as the Android app contained the URL for a public S3 bucket containing firmware files.\nDownloading and analysing these files we found two surprising architectural choices.\nFirst, the key pad on the outside of the door actually controls the actuator on the inside, not the other way around.\nMeaning that the key pad decides if a PIN, fingerprint or key fob is valid and then issues an “UNLOCK” command to the actuator.\nSecondly, the communication between the key pad and actuator relies on an unprotected, clear-text BLE connection.\nAuthentication between key pad and actuator is done solely on the application level using a home-brewed mechanism.
\nWhile the first point already yields a significant attack surface (i.e. let’s dump the key pad and open the door), the second offers a code smell too good to pass up.\nSo we focussed our main energy on exploiting the BLE communication between key pad and actuator.
\nOnce the key pad and actuator are paired, they communicate using unprotected BLE.\nMeaning that all security of the system depends on application-level protections.\nSo let’s find out how these protections work.
\nUpon pairing, the key pad and actuator agree on a secret key.\nThen, everytime the key pad becomes active, it requests a so-called “nonce” value from the actuator.\nFor our attack this does not matter.\nIt is noteworthy however, that the nonce is supposed to provide “freshness” between invocations of the protocol but that this implementation uses the same nonce for an entire “session” which can last for multiple commands.\nAfter the nonce is received, the key pad encrypts a command, using the secret key and nonce, and sends said command over the BLE connection.\nSuch a command could, for example, be “lock the door”.
\nThe following diagram illustrates how the BLE communication works.
\n![\"Communication](\"https://neodyme.io/blog/switchbot/Comms_Switchbot.png\")
Communication between key pad and actuator (simplified)
\nSimply by looking at the communication diagram we can see a potential problem: We might be able to simply replay previous “unlock” commands that we have captured.\nHowever, that would require us to be within Bluetooth range, sniff the command, and then somehow replay it before the session ends.\nSince we aren’t writing an academic paper but do actual research: This is boring.
\nWe want to be able to open the lock, first shot, without any physical tampering and without leaving traces.
\nAnd, as it turns out, we can accomplish this. But first need some more background on the implementation.
\nSo the key pad/actuator communication is protected using secret-key encryption and a nonce.\nDigging further into the implementation, and with the help of community-developed libraries, we found out how the encryption is done.
\nThe commands are encrypted using the AES block cipher in counter (CTR) mode.\nNow, counter mode is an interesting choice, because it doesn’t actually offer any integrity protection.\nFurthermore, because of its design, turning a block cipher into a stream cipher, bit flips propagate 1:1 from ciphertext to plaintext.
\n![\"Counter](\"https://neodyme.io/blog/switchbot/CTR.png\")
Counter mode encryption
\nMeaning that: If we change a bit in a ciphertext, upon decryption by the actuator, this exact bit will also be changed in the decrypted plaintext.\nThis is a little-known, but often encountered vulnerability class.\nSo, let’s exploit this fact and open some doors!
\nA key observation helps us to mount our attack.\nThe key pad’s lock button always sends an encrypted LOCK command, even if the door is already locked.\nExploiting the fact that AES CTR is used, we only need to compute the difference between an encrypted LOCK and UNLOCK command.\nWhen we XOR this difference (flipping all corresponding bits) into an encrypted LOCK command, the result will be a validly encrypted UNLOCK command.\nIt’s important to note here that this difference has to be computed only once, as it is identical across sessions and devices!\nWe therefore split the attack into a setup phase, run once, and an attack phase that opens a specific lock.
\nAfter the one-time setup, the attack works as follows:
\nAs we suspect a lot of vulnerable devices out there, we won’t publish our full exploit here.\nBut using an individual example, you can see why our attack works.\nSo, let’s work through it.
\nUsing one pair of encrypted LOCK and UNLOCK commands, intercepted via BLE, we can compute their XOR difference.\nThis difference is identical across all sessions and all locks using the same firmware.\nTherefore, we can use this difference as a sort of “master key” to open all SwitchBot Pro locks.
\nSniffing an encrypted LOCK and UNLOCK command is done easily using our acquired lock.\nThen, we simply compute:
\ndiff = ENCRYPTED_LOCK_COMMAND ^ ENCRYPTED_UNLOCK_COMMANDApplying (XORing) this difference diff to the encryption of any LOCK command, independent of secret key and nonce, will yield an encrypted unlock command, which we can then send to the actuator.
CRAFTED_ENCRYPTED_UNLOCK = ENCRYPTED_LOCK ^ diffSo, simply by applying our pre-computed, lock-independent, difference vector, we can turn every SwitchBot Pro LOCK command into an UNLOCK command.\nAnd we can always capture encrypted LOCK commands on any key pad, simply by pressing the lock button.\nNeat!
\nWe’ve recorded our attack in action.\nThe video shows the components and our Bluetooth antenna used for sniffing the encrypted LOCK command.\nOn the left you can see the Python script applying the difference to the encrypted LOCK command and sending the crafted encrypted UNLOCK command.\nThe right side of the screen shows that the attack worked:\nFirst, a LOCK command is issued by pressing the lock button.\nThen, the crafted UNLOCK command is send and the actuator turns the key, opening the door \\o/.
It all happens very fast, so maybe you have to re-watch a couple of times to grasp everything.
\nIn accordance with our responsible disclosure guidelines, we notified the SwitchBot team of our findings.\nThey were very responsive (kudos!) and seemed to take the vulnerability seriously.\nThey awarded us a 100€ Amazon voucher for our work.
\nBefore they rolled out a firmware patch, they allowed us to have a look at the updated firmware files.
\nAfter we reversed the new firmware, we discovered that they now append a “checksum” to every command.\nWe reimplemented the checksum computation in Python:
\ndef calculate_checksum(command, key, nonce):\n\ndata_to_hash = command.encode('utf-8') + key.encode('utf-8') + nonce.encode('utf-8')\n\nhash_object = hashlib.md5(data_to_hash)\n\nfull_hash_bytes = hash_object.digest()\n\nreturn full_hash_bytes[:2]\n\nfull_command = COMMAND_UNLOCK + calculate_checksum(COMMAND_UNLOCK, self._encryption_key, self._nonce)\n\nsend_encrypted_bluetooth_command(full_command)So the system now calculates an MD5 hash of the command, secret key and nonce.\nThe first two bytes of this hash then serve as verification tag.\nThis construction is sometimes referred to as YOLO hash and rarely a good idea.\nHere in particular, the truncation to two bytes allows us to, in principle, brute force all 65,536 possible verification tags.\nHowever, this is not necessary.
\nBecause, to our surprise, just the communication between the key pad and actuator got updated.\nThe smartphone app still does not use a verification tag.\nWhich means that our attack still works 1:1, we just need to compute (once!) the difference between a key pad’s encrypted LOCK command and a smartphone issued UNLOCK command.\nWe can then mount our attack using this difference vector, as the actuator then thinks the UNLOCK command comes from a smartphone and does not check the verification tag.\nWe have verified that this variant of our attack works.
\nWhen we reported this bypass, SwitchBot provided the following context:
\n\nThe test firmware pushed to you only includes updates for the Keypad and Lock. The APP has not yet been updated with the new encryption method. We are currently working on implementing encryption upgrades for both the APP and the backend, and the Lock will no longer be compatible with the old encryption method. We need to ensure that this update does not affect other products bound to the APP […].
Backward compatibility is always challenging, especially when it comes to security and IoT devices out in the field.
\nAs we were happy with our full compromise, we did not look too much into other avenues of attack.\nNoteworthy, however, was that the key pad uses MIFARE Classic 1K key fobs.\nThese are long broken and can be trivially cloned, e.g., using a Flipper Zero.\nIn order to mount this cloning attack, you’d have to get close to a key fob first.
\nAdditionally, while testing the Bluetooth attack, we noticed that the key pad has a tamper detection.\nIf it is removed from the wall, it will play a loud alarm sound and inform the owners via their smartphone.\nThis is implemented using a Hall effect sensor on top of the key pad and can therefore be defeated using a strong magnet.\nWe recommend Neodymium magnets for such purposes ;).
\n![\"Switchbot](\"https://neodyme.io/blog/switchbot/keypad_tamper.png\")
Switchbot Keypad Components
\n| Date | Action |
|---|---|
| 15.07.2025 | Initial Report is sent |
| 15.07.2025 | SwitchBot replies with additional questions |
| 15.07.2025 | More context is provided |
| 17.07.2025 | SwitchBot offers us to beta-test their patch |
| 06.08.2025 | SwitchBot pushes the update to our account |
| 13.08.2025 | We report our patch circumvention |
| 18.08.2025 | We report multiple more patch circumventions |
| 27.08.2025 | SwitchBot informs us, that it will take 6 months for them to update the rest of their ecosystem |
| 12.09.2025 | SwitchBot sends us an Amazon voucher 🎉 |
| March 2026 | SwitchBot makes an updated version available |
| 02.04.2026 | SwitchBot shares an updated version with us; we confirm that the described vulnerability does not work anymore |
| 09.10.2026 | CVE published |
According to SwitchBot, the following versions should have the relevant fixes installed.
\nLock:
\nKeypad:
\nApp:\nSwitchBot App: V9.18 and later
\nSecurity is hard and IoT devices often times lack good protections.\nWe have to give credit to SwitchBot for even trying to secure their system.\nMany IoT manufacturers don’t even do that.\nHacking this smart lock was a good reminder about the threats IoT devices can pose.\nEven the more expensive, highly sought after products, are not necessarily immune to attack.
\nVulnerabilities like these arise from developers’ mistaken assumptions.\nIn fact, misusing crypto primitives like AES-CTR, aka. cryptographic failure, is one of the most common software security vulnerabilities according OWASP.\nAs it turns out, we offer a cutting-edge Black Hat training on crypto vulnerabilities and audits and testing to help with exactly that!
\nOriginally published at Neodyme.
","headings":[{"level":1,"text":"Keyless Entry: Hacking SwitchBot Smart Locks","id":"keyless-entry-hacking-switchbot-smart-locks"},{"level":2,"text":"TL;DR","id":"tl-dr"},{"level":2,"text":"Introduction","id":"introduction"},{"level":2,"text":"Reversing the Lock","id":"reversing-the-lock"},{"level":3,"text":"The Switchbot Pro Lock","id":"the-switchbot-pro-lock"},{"level":3,"text":"Firmware Reversing","id":"firmware-reversing"},{"level":3,"text":"Key Pad Communications","id":"key-pad-communications"},{"level":3,"text":"Communication Protection","id":"communication-protection"},{"level":2,"text":"Exploiting the Lock","id":"exploiting-the-lock"},{"level":3,"text":"Setup Phase","id":"setup-phase"},{"level":3,"text":"Attack Phase","id":"attack-phase"},{"level":3,"text":"Proof of Concept Exploit","id":"proof-of-concept-exploit"},{"level":3,"text":"Responsible Disclosure and Insufficient Fix","id":"responsible-disclosure-and-insufficient-fix"},{"level":2,"text":"Further Attack Surface","id":"further-attack-surface"},{"level":2,"text":"Disclosure timeline","id":"disclosure-timeline"},{"level":2,"text":"Fixed Versions","id":"fixed-versions"},{"level":2,"text":"Conclusion","id":"conclusion"}]}}