ttlock-sdk-js
ttlock-sdk-js copied to clipboard
kind3r
Get Passcode Reverse
Since you guys seem to have really figured out how the TTLock locks behave I wanted to ask if you have already found a method to reverse engineer what the server of TTLock is doing when you call https://open.ttlock.com/doc/api/v3/keyboardPwd/get
The description of the call can be found here.
I think it would be very interesting, since this allows to generate passcodes without having a connection to the lock itself.
Thanks for your amazing work thus far!
That call just adds a new passcode (the server generates it, but the principle is the same). At the moment the SDK only supports permanent passcodes, but limited validity ones should be possible to implement, I just have not got around to doing that at the moment since I want to implement the same configuration for all credential types (passcode, cards and fingerprints) and they have slightly different options.
But still, the call you mention would require a connection to the lock to add the new passcode (either via your phone or a gateway) because the list of passcodes is stored on the lock.
Thanks for the quick answer, however I think there is a misunderstanding. The add call requires a connection to the lock but the get call does not. When you call it it will generate a passcode from the information that you provided, which will then work with the lock - no connection required. I always wondered how they do that, but I have tried it myself: With this call you are able to generate a new passcode for a lock that is not connected via bluetooth or gateway.
Oh, I see. That is interesting indeed, and maybe that's what the pwdInfo generated during initial pairing is for, since I found no other use for it ... yet. But since I don't recall seeing this functionality in the Android SDK there are slim chances of implementing it in my port. It could be a server side only thing that they keep under wraps. Nevertheless, I will take another look, now that you got me curious :)
Yes it's not in any SDK, which is what makes it really interesting. Interestingly these codes have to be used once within 24 hours or otherwise they lose their validity. Also: When you generate two passcodes with the same specs (i.e. same start and end date) it always generates the same code, so I guess these times are somehow encoded within the passcodes, maybe together with the pwdInfo you've mentioned.
Anyways I was not able to figure it out, but since you seem to be really good in reverse engineering their stuff I wanted to ask. Thanks for checking it out :)
@kind3r @S3basuchian these values can be passed to the lock in order to add different types of codes:
Passcode type
| Type | Value |
|---|---|
| Permanent | 1 |
| One-Time | 2 |
| Period | 3 |
| Cyrcle | 4 |
When passcode type is cycle you should specify the cycle type as one of the following values:
Cycle type
| Cycle | Value |
|---|---|
| Weekend | 1022 |
| Daily | 1046 |
| Workday | 1070 |
| Monday | 1094 |
| Tuesday | 1118 |
| Wednesday | 1142 |
| Thursday | 1166 |
| Friday | 1190 |
| Saturday | 1214 |
| Sunday | 1238 |
Unfortunately I do not have currently some free time to create a PR with support of the different type of passcodes, but I will be more than happy to see such support in next lib releases. I want to use it as basis for a modern and clear mobile SDKs.
Hi @L3K0V , the cyclic passwords are pretty clear for me in the Android SDK and I will implement them at some point, but the complexity will be on the UI side :) Feel free to open a new issue about this so others can vote.
But @S3basuchian is talking about the possibility of actually generating passwords without actually storing them on the lock (as in completely offline, with no connection to the lock). This is probably based on an algo similar to HOTP/TOTP.
Hello, I've just started to work with ttlock on Android and I'm trying to implement the "no-need-connection-to-lock passcode generation". Does anybody have any update on this matter?
Hello, I've just started to work with ttlock on Android and I'm trying to implement the "no-need-connection-to-lock passcode generation". Does anybody have any update on this matter?
Hi ☺️
I looking for solution in this question too, do you have any information about it?)
I was also looking for this. Probably is a HOTP or TOTP based on PWD info from the lock init and the time of the lock, but no further info or success on the topic. I know that if the time of the lock is out of sync the offline codes does not work.
Hi,
I have a simple question: how safe is this? This means the lock has to have a long list of codes, that are always acceptable (once, or permanently, whatever). Without connection, you could reverse engineer the algorithm and potentially find a way to unlock all locks. The codes should be always valid since pairing I guess.
I just realised I don't need BT (or even be in the same country) to add a PIN that works, hence it's interesting. Brute force might be a possible target if the codes have similarity, or even worse, if the lock actually generates a HUGE list of codes. 8 numbers is not much and although this attack vector is less useful then just picking the lock/door itself, still an interesting subject to me (yes, I watch way too much defcon).
Edit: I just checked and permanent, one-time, recurring and timed pins can be "generated" offline. So the code itself contains the validation period, which narrows down the available combinations a lot (?)
I think it is calculate automatically when you send to them: lock id (generated when you init lock via app) Start date End date Date Now
So all of you need is actual time and date on lock I think lock can caclculate same pin codes as a server because time on lock and time on server is same
пт, 8 мар. 2024 г., 05:08 Re4zOon @.***>:
Hi,
I have a simple question: how safe is this? This means the lock has to have a long list of codes, that are always acceptable (once, or permanently, whatever). Without connection, you could reverse engineer the algorithm and potentially find a way to unlock all locks. The codes should be always valid since pairing I guess.
I just realised I don't need BT (or even be in the same country) to add a PIN that works, hence it's interesting. Brute force might be a possible target if the codes have similarity, or even worse, if the lock actually generates a HUGE list of codes. 8 numbers is not much and although this attack vector is less useful then just picking the lock/door itself, still an interesting subject to me (yes, I watch way too much defcon).
— Reply to this email directly, view it on GitHub https://github.com/kind3r/ttlock-sdk-js/issues/9#issuecomment-1984815633, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFRZZOQO2UYQ7HQHNOWULGTYXD6QJAVCNFSM4YOZCTX2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJYGQ4DCNJWGMZQ . You are receiving this because you commented.Message ID: @.***>
I know it calculates it based on times and the aes key, but that means theres potentially thousands of pins, that can open the lock at any given time, that I dont know of. Also you can pass a really long code as long as the pin is in there somewhere, so even brute force seems easy, just try a random 999 char long pin, it might actually contain a valid pin. Or just start writing pi :D
I think it is calculate automatically when you send to them: lock id (generated when you init lock via app) Start date End date Date Now So all of you need is actual time and date on lock I think lock can caclculate same pin codes as a server because time on lock and time on server is same пт, 8 мар. 2024 г., 05:08 Re4zOon @.***>:
But when you enter it on the lock offline, you do not know the start and end date, right?
I choose it before entering pin code And if it is actual, lock will be opened
вс, 10 мар. 2024 г., 17:20 Asen Lekov @.***>:
I think it is calculate automatically when you send to them: lock id (generated when you init lock via app) Start date End date Date Now So all of you need is actual time and date on lock I think lock can caclculate same pin codes as a server because time on lock and time on server is same пт, 8 мар. 2024 г., 05:08 Re4zOon @.***>:
But when you enter it on the lock offline, you do not know the start and end date, right?
— Reply to this email directly, view it on GitHub https://github.com/kind3r/ttlock-sdk-js/issues/9#issuecomment-1987208242, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFRZZOTU3DZ2NRBPT5D2IITYXRFZTAVCNFSM4YOZCTX2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJYG4ZDAOBSGQZA . You are receiving this because you commented.Message ID: @.***>