Moving from Hacking IoT Gadgets to Breaking into One of Europe's Highest Hotel Suites

## Overview

Ray (20-year Chaos Computer Club member, lock-picking researcher) and Michael Hubler (40-year lock sport enthusiast, electronic engineer) presented methodology for analyzing and attacking Bluetooth Low Energy IoT devices, from cheap padlocks to hotel key systems. Core problem: BLE ecosystem—smart locks connected via Bluetooth to smartphone apps communicating with backend APIs—presents multiple attack surfaces. Research demonstrates that most commercial BLE lock implementations use poor cryptography, hardcoded keys, plaintext transmission, or security-by-obscurity protocols; many vulnerable to replay attacks, magnetic manipulation, or reverse engineering of mobile apps. Presentation goals: democratize attack methodology (demonstrating HCI sniffing, Wireshark analysis, APK decompilation, protocol reversal); show real-world case studies (Noke keypad lock 2015-2017, Master Lock magnet bypass, cheap Alibaba padlocks); discuss responsible disclosure challenges with vendors who ignore security issues.

## BLE Analysis Toolkit and Attack Methodology

**Bluetooth Low Energy Fundamentals**: BLE designed as low-power alternative to classical Bluetooth for battery-operated IoT devices. Security model weak: link layer often unencrypted, application layer expected to provide security. Secure options available (out-of-band pairing with manual key entry, elliptic curve cryptography) but uncommonly used; most devices rely on unencrypted BLE with encrypted application payloads—vulnerable if encryption implemented poorly.

**HCI Snoop Capture and Analysis**: Android: enable debug mode, activate HCI snoop log to record all BLE in/out traffic; iOS: install Bluetooth debug certificate from Apple (temporary). Timestamp app interactions (note when lock opened, etc.) for later correlation with captured data. Download HCI capture file, analyze using Wireshark (pcap format). Wireshark has native BLE protocol support, decodes Bluetooth packets, identifies reads/writes to characteristic handles, displays data payloads. Useful for identifying encryption, replay patterns, session IDs.

**Over-The-Air Sniffing Tools**: (1) Ubertooth One, Bluefruit LE sniffer, other common sniffers listen to single BLE channel at a time—insufficient for reliable real-attack scenarios (device may hop channels before connection captured). (2) LittleJack (by Damien Willis, Black Hat release)—flashes firmware to cheap devices (BBC Micro:bit, ~$15 price point)—supports 3 simultaneous channel listeners enabling comprehensive sniffing; additional capabilities include man-in-the-middle and traffic analysis. Practical setup: homemade version with duct tape/creative mounting, or Raspberry Pi battery-powered mobile sniffer (fits in smoke detector, deposited near target location).

**Mobile App Analysis and Decompilation**: Android apps written in Java, compiled to bytecode; decompile using online tools back to readable Java source (comparative ease). Search for Bluetooth keywords (AndroidBluetoothAES, crypt, etc.) to locate lock-communication code. Watch for hardcoded keys—e.g., "ABCDEFGH" visible in source indicates static encryption key. Obfuscated code (stripped symbols, renamed variables) requires refactoring tools (Android Studio) to find unobfuscated strings (e.g., "access_key_data") and trace back to original functionality. Note: obfuscation slows analysis but does not prevent attackers—vendors deceiving themselves; cryptographic robustness superior to code obfuscation.

**Backend Traffic Interception**: Smartphone-to-server communication typically HTTPS (few devices still use HTTP). Intercept via man-in-the-middle with rooted Android device (hard-code root CA into system trust store) or older Android versions (pre-6.0). Alternative for non-rooted devices: modify APK manifest to trust user-store certificates (non-trivial but feasible). On iOS: easier setup with built-in mitmproxy/Burp certificate installation. Tools: mitmproxy (CLI), Charles Proxy (GUI), Burp Suite, Fiddler. Some apps implement TLS certificate pinning (rejecting rogue CAs)—use Frida framework or objection to bypass by JavaScript patching or modifying function calls at runtime (return fake certificates). Vendor advice: certificate pinning doesn't protect against traffic analysis, only against man-in-the-middle; focus instead on robust cryptography.

## Real-World Vulnerability Case Studies

**Cheap Alibaba Padlock**: Backend traffic sent over plain HTTP—password visible in captured traffic. 16-byte array labeled "lock_key" (likely AES-128 key) transmitted unencrypted. Bluetooth traffic encrypted with AES-128, but using static key visible in app source (trivial key: "01020304..."). Protocol analysis via Wireshark: identify command packets and responses; session replay possible because no replay protection; attacker sniffs passcode on-air, directly re-uses it to open lock without any hacker tools. Assessment: cryptographic system by design failure, vendor intentionally avoided security (HTTP backend suggests indifference to encryption).

**Noke Keypad Lock (2015-2017 Firmware)**: First-generation smart padlock from 2014 Kickstarter campaign. Positive aspects: uses actual AES-128 implementation (not home-brew crypto), distinct secrets for owner vs. friends, time-based restrictions. Vulnerabilities: (1) time restrictions enforced only in app layer, not on backend—bypass by manipulating backend traffic; (2) session key generation in "secret handshake" using hardcoded pre-shared key (1234567890...). Attack flow: both parties send 32-bit nonce X and Y, XOR nonce values together, shift bit to 128-bit value, add to pre-shared key to derive session key. Cryptographic failure: session key derivable from sniffed nonces even without knowing handshake protocol; disassembly reveals hardcoded key and XOR derivation math. Responsible disclosure 2016; firmware update 2017 with new protocol. Lesson: hardcoded keys fatal; even claimed AES encryption vulnerable to weak key derivation and security-by-obscurity handshakes.

**Master Lock Bluetooth Padlock**: Electronic lock defeated via magnetic manipulation ($60-80 device). Motor inside lock normally activated by electronic signal; magnet attachment and polarity rotation causes motor to turn mechanically, opening lock. Unconventional attack vector (not cryptographic but physical) disclosed to manufacturer on conference floor; vendor response unknown, no follow-up confirmation of fix.

**2013 Def Con Prior Research (Rosen/Ramsey)**: 12 of 16 Bluetooth locks tested vulnerable to simple attacks (replay, key extraction, open by electronic command); 2 locks (Noke, Mesh Master Lock) remained unbroken—later analysis revealed security tradeoffs and vulnerabilities despite relatively stronger design.

**Hotel BLE Key Systems**: Self-check-in via mobile phone reduces front-desk crowding, attractive to hotel chains. Challenges: (1) secure pairing difficult without out-of-band channels (unlike home devices receiving pairing code), (2) complex ecosystem (hotel chain, app developer, lock vendor, third-party SDK integrators) each introducing potential vulnerabilities, (3) retrofit old hardware with new BLE modules—older cryptographic chips, non-recent protocols. Research incomplete in transcript but establishes BLE hotel keys as ongoing target for attack methodology application.

## Organizational and Vendor Implications

**Responsible Disclosure Challenges**: Vendors with known vulnerabilities and zero technical capability (e.g., cheap padlocks using HTTP without encryption) cannot be meaningfully disclosed to—they are aware of lack of security and chose not to implement defenses. For vendors with update capability (Noke), disclosure process lengthy (2016-2017, ~1 year) but eventually resulted in firmware fix. Open responsibility question: how long to wait for vendor response before public disclosure; what if vendor ignores; what if hardware cannot be updated.

**Democratization of Attack Capability**: Cheap sniffing hardware (BBC Micro:bit, $15), free decompilation tools, public Wireshark analysis enable security researchers to audit IoT ecosystem. Vendors relying on obscurity or user ignorance exposed to community analysis. Commercial viability of weak-security devices in low-cost market (Alibaba padlocks) suggests consumer base prioritizes price over security.

**Cryptographic Implementation vs. Design**: Vendors claiming AES-128 but implementing weak key derivation or using hardcoded keys provide false confidence. Proper cryptography requires: unpredictable session keys, no security-by-obscurity, out-of-band secure pairing. Obfuscation of code offers no protection against determined attackers with reverse-engineering tools.