A specially crafted message can be sent to the TTLock App that downgrades the encryption protocol used for communication, and can be utilized to compromise the lock, such as through revealing the unlockKey field.

Sciener locks' firmware update mechanism do not authenticate or validate firmware updates if passed to the lock through the Bluetooth Low Energy service. A challenge request can be sent to the lock with a command to prepare for an update, rather than an unlock request, allowing an attacker to compromise the device.

Some Sciener-based locks support plaintext message processing over Bluetooth Low Energy, allowing unencrypted malicious commands to be passed to the lock. These malicious commands, less then 16 bytes in length, will be processed by the lock as if they were encrypted communications. This can be further exploited by an attacker to compromise the lock's integrity.

Sciener server does not validate connection requests from the GatewayG2, allowing an impersonation attack that provides the attacker the unlockKey field.

The unlockKey character in a lock using Sciener firmware can be brute forced through repeated challenge requests, compromising the locks integrity.

The TTLock App does not employ proper verification procedures to ensure that it is communicating with the expected device, allowing for connection to a device that spoofs the MAC address of a lock, which compromises the legitimate locks integrity.

The AES key utilized in the pairing process between a lock using Sciener firmware and a wireless keypad is not unique, and can be reused to compromise other locks using the Sciener firmware.

TTLock App virtual keys and settings are only deleted client side, and if preserved, can access the lock after intended deletion.