Hey, any updates on this?
I just called Lockly and the Z-Wave edition isnāt actually released yet. They told me ~Q2.
Iāve been pretty busy lately, and donāt have much time to work on this in the foreseeable future. Itās still a high priority on my personal project list, though.
Wouldnāt updating the wifi hub to use Matter solve this problem? What the heck are Lockly waiting on?
Can anyone share a cyberchef example of decoding an anonymous payload? I cant get it to work. How did you get the public/private key @hacker1024 ?
Everything about lockly locks is awesome, except they are such a damn closed ecosystem. Way back when, Pin Genie sold their first lock via Kickstarter. Pin Genie was later sold. Anyway, IFTTT was promised but clearly they gave up on that.
Iām not sure what they gain from having such a closed ecosystem. I would not be buying lockly locks now if I was starting from scratch. No idea what I would buyā¦ But Iād want something with some way of integrating in some sort of home automation system (no, I donāt use or consider Alexa/OK Google to be home automation. I have no interest in having mics listening to everything said.
Anyway, any hope of someone, not me, I canāt program my way out of a dumpster, can figure out a way to make this work?
Thanks
I managed to control the lock from hass by using the Google Assistant SDK integration.
I also set up Google Home automation to flip a hass switch every time the lock locks/unlocks.
Unfortunately this does not work as the lock does not report these events to Google Home.
I believe the lock and the hub need software updates to report all the events to the cloud integrations in real time.
@liviu that sounds right, but unfortunately the unlocking procedure requires the PIN. Did you manage to pass the PIN via Google Assistant SDK: Send text command
You can provide the pin like this:
service: google_assistant_sdk.send_text_command
data:
command:
- open the front door
- āxxxxā
Perfect, thanks
@mickeydee293 Implementing this in CyberChef is a little tricky due to how the data is split into chunks.
Hereās a rough implementation, but it does not trim output blocks correctly leading to zero bytes where there shouldnāt be.
You can find my Dart implementation that does not have any such issues here.
As for how I got the keys, I extracted them from the Android app at runtime using Frida. Much of the encryption code is written in C/C++ and shipped in native libraries, which makes it quite hard to reverse engineer, so dynamic analysis tends to be the easier route. I did use IDA Pro to reverse-engineer the chunk-splitting process statically, though.
Any chance on using this for the BT portion so that the hub isnāt needed at all, and we can communicate with the lock directly? @hacker1024
The Lockly app performs most of its functions by sending encrypted Bluetooth packets to the hub over the Internet, which are then forwarded to the lock. Responses from the lock are then received by the hub and published over MQTT.
By reverse-engineering the app, we can study the Bluetooth packets and eventually send them manually over BLE.
Any further advice on achieving this or dealing with the encrypted BT packets? Happy to help dig through logs/files if at all beneficial, but ye skipping the hub all together was my main goal.
I did trace a few calls via the app in wireshark to some relevant packets but couldnāt get further than that.
I do not have much experience with decoding binary structures, so rather than intercepting and deciphering packets, my plan is to reverse-engineer the app to learn how they are formed.
If that fails, once I work out how the encryption works, I hope to be able to use a Wi-Fi packet sniffer to quickly see what buttons in the app make what packets. Hopefully, we will still be able to do things over Bluetooth even if we donāt understand the message format. This is less than ideal, though, as authentication will be difficult.
Both approaches require decrypting the encrypted packets, so that is what needs to be done next. It is no trivial feat, as much of the encryption is done in native libraries (way harder to reverse-engineer than Android bytecode), and unlike the other forms of encryption used by the app, it is not decrypted anywhere.
The encryption algorithm has been inlined (so no identifiable algorithm names from imported functions). I have some friends in cybersecurity who might be able to identify it, but even they might not be able to work it out as all there is to look at is hundreds of lines of unstructured bit-bashing.
Looks like the Z-Wave stuff is going to be in their āProā line which you canāt buy without talking to them directly and Iām sure its going to be more expensive than the regular stuff like we have. If they update their WiFi - BT bridge with Matter then less people will buy the āProā line because they can buy the āRegularā version for less $$$ and get the same functionality.
I installed a pair of Lockly locks and Iām pretty happy with the hardware but very disappointed with the software and integration. I have them added to both google and alexa and have made a script in google to sync their state with a smartthings virtual lock. Unfortunately, and I donāt know if itās a regional thing or not but I can only lock the door with google/alexa/smartthings and I donāt have the choice to unlock the door. I can unlock the door with a google voice command that brings up a pin on my phone but thatās about the limit of how I can integrate it into my home. Iām about to set up HA this week and I guess Iāll have the same issue then. I can understand that there are concerns that an automation may do something to unlock my doors at the wrong time or someone could hack one of my services but thatās a risk that I should be able to choose to take. The other issue is the lock seems to show as being offline in Google a fair bit and although it mostly syncs the smartthings virtual switch when the state changes at the lock, sometimes there is a fair old delay.
At the moment Iām playing around with a tasker routine that unlocks my phone and then using simulated button presses opens the lockly app and unlocks the door. This is about the only workaround to locklyās poor integration that I can think off. Iām thinking that my presence detection should fire off that Iām home well before I get to my front door and this should give tasker time to do its thing.
Lockly told me via email that home assistant integration is scheduled for Q1 2024. Please email them and ask to help drive them! Lockly Australia <[email protected]
Iāve found the software to not be very good. But the lock itself is. Desperation for home assistant Integration
Just confirming that I emailed them as well and go the same details that Q1 24 is expected to release a HA integration. I ask for any technical details but the lady was very nice but not able to provide anything more than the canned response.