Can a locked digital lockset be opened by an attacker who arrives at the door with nothing but a Bluetooth radio? A field assessment, and the current validity of the published Sciener/TTLock CVE‑2023 exploits.
We tested whether a current-production McGrath NX5 digital lockset, locked and installed in the field, can be opened by a “walk-up” attacker — someone with physical and Bluetooth proximity to the door and nothing else. No credentials, no cloud account, no enrolment access, and no captured traffic from the legitimate user.
Finding: no walk-up opening technique was found. After systematically exercising the lock across its entire command space, and after attempting to reproduce every walk-up-relevant vulnerability in the published literature, we could not open the lock. In every path we tested, the lock either refused the request or required a secret that a walk-up attacker cannot obtain.
SCIENER authorisation bypass described in public analysis of this
platform (a command that grants user authorisation merely because the message contains the text
SCIENER) does not exist in the firmware we tested. Two complete sweeps of the entire
command space, in two protocol header flavours, found nothing.We deliberately did not exercise the unauthenticated firmware-update pathway (CVE-2023-7017, CVSS 9.8), because a failed attempt risks permanently disabling the device. That pathway is declared as untested and is covered in Section 9. We recommend it be assessed on a sacrificial unit.
We want to be precise about what this report does and does not say. It does not say these locks are unbreakable, and it does not say the published vulnerabilities were never real — they were valid against the versions the original researchers tested (Kontrol Lux firmware 6.5.x, Gateway G2 6.0.0, TTLock app 6.4.5), which are substantially older than the current release. What this report shows is that, for the current production configuration we tested, an attacker in a walk-up position cannot open the door, and that several widely-cited exploits no longer reproduce.
The NX5 is a Bluetooth Low Energy (BLE) digital lockset built on the Sciener/TTLock platform, controlled by the TTLock mobile app.
Without any authentication, a nearby radio can already see:
Sciener), model string, hardware revision and firmware version. This is how we
read the firmware version quoted above without any authentication, and operators should be aware it is
disclosed to any nearby device.Commands are framed binary messages with a command byte, a flag byte, a payload and a checksum. The lock answers on the notify characteristic; the answer echoes the command byte, a status byte and a result code.
Authorisation model, as observed. The lock will not discuss anything sensitive with an unauthenticated peer. To reach the point where it will even issue a challenge, a client must first present a valid administrator credential. To open the lock, the client must then present a value derived from a fresh per-connection challenge and a long-lived secret. Both secrets are per-lock, and neither is derivable from anything a walk-up attacker can observe. That is the structural reason this lock resists a walk-up attack.
A weak negative result is worthless if the tester simply did not know what to send. So we did not test this lock as an ignorant stranger. Our protocol knowledge — the exact frame layout, the full command list, the encryption scheme and the checksum algorithm — was derived from our own device during legitimate commissioning, on our own bench. An attacker at a customer’s door has none of that.
Every walk-up test below was then performed blind: no captured user traffic, no credentials, no enrolment access, no cloud account and no prior connection to the target. For the majority of tests we supplied unencrypted commands, which is the only kind an unauthenticated attacker can construct.
Rather than guessing a handful of attack scenarios, we exercised the entire command space. The command byte is one byte wide, so there are 256 possible commands; we tested 254 (two excluded for safety). Each sweep ran against a freshly connected lock, holding a single connection open, and attributed every reply to the command that caused it via the echoed command byte.
| Sweep | Commands | Payload sent | Header flavour |
|---|---|---|---|
| Unencrypted sweep A | 254 | 8-byte unencrypted SCIENER\x01 | application header |
| Unencrypted sweep B | 254 | 8-byte unencrypted SCIENER\x01 | remote-control / initialisation header |
The payload SCIENER\x01 was chosen for two reasons: at 8 bytes it sits inside the known
plaintext-processing window (CVE-2023-7009) so the lock will accept it unencrypted, and it carries the literal string
that public research says the undocumented authorisation bypass tests for.
Two commands were excluded from every sweep: the command that enters firmware-update (DFU) mode, because a malformed attempt risks permanently disabling the unit; and the factory-reset command. This is stated openly because it is the one place where coverage is incomplete, and it matters (Section 9).
To prove our tooling was talking to the lock and that refusals were genuine authorisation refusals rather than a broken harness, we ran a control on a unit we had legitimately enrolled. With correct credentials the same command channel returned successful results. We do not publish those credentials. The control establishes that the “refused” results below are the lock’s decisions, not our errors.
These commands answered without any authorisation. None discloses a credential.
| Command | Response | Assessment |
|---|---|---|
| Device information query | Constant device descriptor (19 bytes) | Not sensitive; no key material |
| Identifier query | The lock’s own BLE address | Already public in the advertisement |
| Clock query | The lock’s internal date and time | Not sensitive |
| Firmware/version query | Version and status bytes | Not sensitive |
Assessment: the lock discloses its identity, model, firmware version and clock to any nearby device. Operators who consider firmware-version disclosure a risk should note it. No credential, key or user data was disclosed by any unauthenticated command.
The commands that would expose user data — the list of valid keypad passcodes, registered cards, registered fingerprints, and the operation/audit log — were probed with multiple payload shapes each. All were refused. We repeated these probes in an authenticated administrator session and in a valid user session, and they were still refused. A further group of commands returned a deterministic “not supported” code, indicating this hardware variant does not implement that subsystem at all.
Assessment: the lock does not disclose stored user credentials or its audit log to a walk-up attacker. This closes the most valuable line of inquiry for such an attacker.
This vulnerability states that some Sciener-based locks will process an unencrypted command of fewer than 16 bytes as though it had been decrypted.
We confirmed this on our unit, and not marginally. Of the 254 commands we sent unencrypted, 249 produced a reply, meaning the lock dispatched our plaintext payloads across essentially its entire command handler. The proof that this is more than papering over a rejection:
Sending an unencrypted administrator-login command returned the lock’s “wrong identifier or password” error.
That error can only be produced by a handler that took our raw bytes, treated them as the credential fields, and compared them against the stored values. The lock is not merely accepting plaintext — it is interpreting it.
Impact assessment: the vulnerability is real and present in current firmware. However, we were unable to convert it into any opening or credential disclosure. Encryption is not the lock’s security boundary; the credential check is. Sending a command unencrypted changes how the message is encoded, not who the lock thinks you are. We therefore classify it on this firmware as a genuine defect with no demonstrated walk-up impact.
The advisory states the unlock challenge is “a random integer between 0 and 65535”, that challenge requests “can be repeatedly prompted and responded to without any limitations”, and that completing the challenge yields a secret that opens the lock. Two independent findings break this attack on the firmware we tested.
(a) The challenge is 32-bit, not 16-bit. We observed it across separate connections:
0x13e65837, 0x171e4e29 and 0x20963730 (three samples, each a fresh connection).
Those are 32-bit values. The published attack searches 65,536 possibilities; the value we measured lives in a space of
roughly 4.29 billion — about 65,000× larger. At the lock’s observed throughput of
roughly 30 attempts per second, the full space would take on the order of 4.5 years of continuous attack, and
about 2.3 years on average. That is not an attack; that is a career.
(b) The attack has no starting point. More fundamentally, the brute force presumes the attacker can obtain a challenge. We could not obtain one without first presenting a valid administrator credential. Every unauthenticated challenge request was refused with the wrong-credential error. A walk-up attacker, who by definition has no credential, never gets to attempt a challenge response at all.
SCIENER authorisation bypass: not presentPublic analysis of this platform describes an undocumented command in the lock firmware that behaves like a
user-authorisation check but instead of validating a time window simply verifies that the message contains the
text SCIENER. Because the comparison is a substring search rather than an equality check, a short,
unencrypted message containing that text was reported to pass user authorisation and return a challenge — an
authorisation bypass requiring no prior knowledge and no captured traffic. This would be the single
most serious walk-up primitive available against this platform.
We did not find it. Both full 254-command sweeps, in both header flavours, sending an unencrypted payload containing exactly that string, produced no challenge request and no authorisation. Every reply was either “command not supported” or a per-command error code.
Public analysis describes a hard-coded AES key used between the lock and an optional wireless keypad, and notes the lock keeps no register of keypads previously connected — so an attacker can impersonate a keypad and inject key presses, allowing PIN guessing at machine speed.
We confirmed the keypad channel is reachable without authentication. The lock distinguishes keypad traffic from app traffic by a single flag byte, and a pairing request on that channel produced a well-formed keypad-flavoured response carrying a 16-byte value. So the channel itself is open to us.
It does not lead to a practical opening, for two reasons.
We also note that on this hardware variant the passcode subsystem did not appear to be implemented at all.
Assessment: the underlying weakness is real and the channel is exposed; the attack is theoretical. We do not consider it a practical walk-up opening technique.
This vulnerability lets a party who impersonates the lock to the app cause the app to fall back to an older, weakly-encoded protocol carrying no meaningful encryption. If it worked, an impersonating device could harvest the unlock secret from the app during a legitimate unlock.
We attempted reproduction with a correct implementation of the older protocol codec — the detail a naive reproduction gets wrong. Our implementation was verified byte-for-byte on the wire: a response encoded in the older format, flagged as such, decodes correctly and is structurally identical to the encrypted response it replaces.
The current app rejected it, at the initial protocol negotiation and mid-session, aborting and retrying the handshake and reporting failure to the user. A corrected attempt whose payload length matched the encrypted response exactly also stalled. Our conclusion is that the current app pins the protocol version associated with the lock rather than trusting the version indicated in the incoming message.
Two caveats, stated plainly. First, this attack is not a walk-up attack — it requires the attacker to be impersonating the lock while a legitimate user unlocks, so it belongs in the out-of-scope class in Section 4 and is included only for completeness. Second, our negative result is against one app version; verifying that the original researchers’ app version (6.4.5) is genuinely affected would require installing that version, which we did not do.
This requires impersonating a specific gateway device at the manufacturer’s server, including knowing that gateway’s BLE address, and is not a walk-up attack on a lock. Not tested. Out of scope.
The advisory rates an unauthenticated firmware-update pathway at CVSS 9.8, describing a challenge request that can be answered with a command to prepare for a firmware update, allowing an attacker in Bluetooth range to install arbitrary firmware.
We did not test it. A malformed or partial update attempt risks irrecoverably disabling the lockset, and we hold only production units. We therefore excluded the firmware-update command from every sweep.
This is the most significant limitation of this report and we state it prominently rather than bury it. Because this pathway is unauthenticated by description, it is the one published issue that would constitute a genuine walk-up attack if still present — although its effect is to compromise or disable the lock rather than to open the door. A reader who needs a conclusive statement about walk-up security should treat CVE-2023-7017 as unresolved until it is tested on a sacrificial unit, which we recommend and intend to do.
An attacker who records a legitimate user’s unlock and replays it is not performing a walk-up attack, and this report makes no claim about that scenario. We note only that the opening value is bound to a fresh, per-connection challenge, which lessens the value of a naively replayed recording. We did not test this class and do not draw conclusions about it.
0,
1, 3 and the maximum — i.e. it is not validated — but since the credential check
fails first, this is not exploitable. No impact.| # | Technique | Status on this firmware | Walk-up opening? |
|---|---|---|---|
| 1 | Unauthenticated enumeration (identity, model, firmware, clock) | Disclosed | No |
| 2 | Credential / keypad / card / fingerprint / audit listing | Refused, authenticated or not | No |
| 3 | CVE-2023-7009 plaintext processing | Confirmed present | No — no demonstrated impact |
| 4 | CVE-2023-7006 challenge brute force | Challenge is 32-bit; unobtainable unauthenticated | No |
| 5 | Undocumented SCIENER authorisation bypass | Not present | No |
| 6 | CVE-2023-7003 wireless keypad channel | Reachable; PIN guessing blocked by alarm and cool-down | No — ~50 days median |
| 7 | CVE-2023-7005 app protocol downgrade | Not reproduced on current app; not a walk-up attack | No |
| 8 | CVE-2023-7007 gateway impersonation | Not tested (out of scope) | No |
| 9 | CVE-2023-7017 unauthenticated firmware update | NOT TESTED — declared gap | Unknown |
| 10 | Replay of a recorded unlock | Not tested (not a walk-up attack) | No |
| 11 | Error oracles, parameter validation, length abuse, other hypotheses | Tested, negative | No |
First, the lock’s security rests where it should: on a credential, not on obscurity. The platform’s encryption is demonstrably weak — we proved the lock will process plaintext commands. But that weakness does not matter, because the lock enforces authorisation independently of how the message was encoded. In our assessment that is a well-designed decision. Practitioners should note the inverse: any deployment that leaks the lock’s administrator credential or long-lived secret is compromised regardless of encryption. The client-side mobile application and the commissioning process, not the radio protocol, are where we would look next.
Second, published vulnerabilities have a shelf life, and this one appears to have expired. The advisory that produced these CVEs lists affected firmware of the 6.5.x series and app version 6.4.5. The unit we tested runs firmware 6.7.12.240731 and app 9.9.260829. Our results are consistent with the vendor having addressed the walk-up-relevant issues in the intervening releases. We are not in a position to state what changed, or that every configuration in the field has been updated — older units, and units not receiving updates, may remain exposed to the original published issues. Owners should confirm their firmware version, noting that we read it from any nearby device without authentication.
This document reports negative results obtained on hardware we own. It contains no credentials, keys, serial numbers or exploit code. It deliberately omits the specific byte-level recipes used, so that it cannot be repurposed as an attack manual. No customer data, no customer device, and no third-party system was involved at any point.
A separate, confidential technical report describing the non-walk-up issues we identified will be provided to the manufacturer and its Australian distributor for their consideration before any public discussion.
SCIENER authorisation bypass, the plaintext-processing defect, the challenge mechanism, the
wireless-keypad design and the PIN-enumeration cost model referenced above are drawn.