243 lines
9.3 KiB
Markdown
243 lines
9.3 KiB
Markdown
## DOCUMENT 0 - INITIAL INFORMATION GATHERING
|
|
|
|
---
|
|
|
|
### Installation of Custom Software
|
|
|
|
TODO:
|
|
- Check if CFW is installable
|
|
|
|
---
|
|
|
|
## 0.1 Services Running on the Device
|
|
|
|
## 0.2 Hardware and Software Specifications
|
|
|
|
## 0.3 Known Vulnerabilities / Problems / Hacks
|
|
|
|
No known vulnerabilities or hacks were found during research or on CVE.
|
|
|
|
Common issues for consumers include:
|
|
- Touch display glitches/freezing
|
|
- Fast battery depletion
|
|
- Insufficient motor power/jams
|
|
- No response from lock/bridge disconnections
|
|
|
|
## 0.4 Collecting APKs
|
|
|
|
Using the rooted Google Pixel and `adb`, I was able to obtain the [Shelly app](app_apks/shelly.apk).:
|
|
|
|
```bash
|
|
adb pull $(adb shell pm path cloud.shelly.smartcontrol | tr -d '\r') ./shelly.apk
|
|
```
|
|
|
|
Additionally, I found out that there is a specific [LOQED app](app_apks/loqed.apk) as well, which I also obtained:
|
|
|
|
```bash
|
|
adb pull $(adb shell pm path com.loqed.keychain | grep base.apk | tr -d '\r') ./loqed.apk
|
|
```
|
|
|
|
|
|
## 1.1 && 2.1 Unpacking
|
|
|
|
The packaging contains:
|
|
- A user and safety guide
|
|
- The guide explains installation without any pictures but uses pictures to explain the app setup - why?
|
|
- [Video installation guide](https://www.youtube.com/watch?v=ajNjStpTIlk&source_ve_path=OTY3MTQ&embeds_referring_euri=https%3A%2F%2Fembed.jotform.io%2F)
|
|
- 8 AA batteries for power supply
|
|
- An outdoor module (touch)
|
|
- Mounting HW (screws, rings, screwdrivers, ...)
|
|
- A lock cylinder
|
|
- A bridge
|
|
- A motor module
|
|
- An indoor module (the lock)
|
|
- The shell
|
|
|
|
The lock is surrounded by a plastic packaging with molds for eah component. Within the box it is kept in place with some cardboard. The box itself is held shut by a small magnet.
|
|
|
|
<img src="img/unpacking.jpg" alt="Contents of the box" width="400">
|
|
|
|
## 1.2 || 2.2 Outer Inspection
|
|
|
|
### Outer Module
|
|
|
|
The outer module is a touch sensor surrounded by a plastic shell with two screws and one cable inside.
|
|
|
|
<img src="img/touch_back.jpg" alt="Back of the touch module" width="400">
|
|
|
|
During installation, the cable is supposed to connect to the motor module.
|
|
|
|
<img src="img/touch_cable.jpg" alt="Cable position of the touch module" width="400">
|
|
|
|
### Inner Module
|
|
|
|
The inner module includes the motor module, which is connected using cables to:
|
|
- the power supply
|
|
- the touch module
|
|
|
|
<img src="img/inner.jpg" alt="The inner module including the motor module" width="400">
|
|
|
|
Unopened, it is surrounded by a metal shell which can easily be removed by pulling a plastic strap, as this is necessary during installation.
|
|
|
|
### Bridge
|
|
|
|
The bridge is to be placed within 3 meters of the lock. It is used to connect the lock to the app.
|
|
It features a reset button.
|
|
|
|
<img src="img/bridge.jpg" alt="The bridge" width="400">
|
|
|
|
## 1.3 && 1.4 Open Casing / HW Inspection
|
|
|
|
### Bridge
|
|
|
|
The plastic enclosure of the bridge can be opened by unscrewing two screws, revealingthe PCB.
|
|
|
|
What you can spot immediately is:
|
|
- UART
|
|
- ESP32 WROVER B
|
|
- WiFi & Bluetooth/BLE capable
|
|
- [Datasheet](docs/esp32_datasheet.pdf)
|
|
|
|
<img src="img/bridge_pcb.jpg" alt="PCB inside the bridge" width="400">
|
|
|
|
Under the PCB is HW for the power supply.
|
|
|
|
<img src="img/bridge_under_pcb.jpg" alt="Power supply beneath PCB" width="400">
|
|
|
|
### Outer Module
|
|
|
|
There are three screws on the back of the touch module, however, it's additonally glued together. It can't be opened without being (probably) permanently damaged.
|
|
|
|
<img src="img/touch_inside.jpg" alt="Back of the touch module with screws removed" width="400">
|
|
|
|
### Inner Module
|
|
|
|
As I'm working with an already opened device, I'm not interiley sure hw many screws were intially needed to open the motor module, but I'm assuming it were four. After unscrewing these the plastic shell can be removed by gently wiggling it until it comes loose.
|
|
|
|
<img src="img/motor_inside.jpg" alt="Inside of the motor module" width="400">
|
|
|
|
Once again you can immedatiely spot UART.
|
|
|
|
After unplugging all cables, the PCB can be leveraged out of the shell with a flat screwdriver, without causing any damage.
|
|
|
|
<img src="img/motor_inside_2.jpg" alt="Other side of the motor module PCB" width="400">
|
|
|
|
Here you can see:
|
|
- UART
|
|
- $I^2C$
|
|
- Most likely an nRF52840
|
|
- A buzzer and a button
|
|
|
|
## 1.5 Software Components from Firmware Analysis
|
|
|
|
#TODO
|
|
|
|
## 1.6 Collect "Fresh" Firmware Dump
|
|
|
|
The device has been tampered with before, therefore there is no "fresh" dump available.
|
|
|
|
## 1.7 && 2.3 Initial setup
|
|
|
|
The initial setup is done using the LOQED app, the lock can then be integrateed into the Shelly app. The capture can be found [here](network/captures/init.pcapng).
|
|
|
|
Additionally, the Shelly app offers to download the data stored on the device, which you can find [here](lock_data/after_init/README.md).
|
|
|
|
Unsure which IP address is most relevant, here are all Shelly-like or LOQED-like addresses:
|
|
- `34.62.47.252`: changelog-backend.shelly.cloud0
|
|
- `34.95.90.149`: control.shelly.cloud
|
|
- `104.155.32.247`: shelly-120-eu.shelly.cloud
|
|
- `34.155.200.196`: integrations.loqed.com
|
|
- `35.205.173.252`: app-ratings.shelly.cloud, paypal.shelly.cloud, shelly-infra1-eu.shelly.cloud
|
|
- `34.79.5.199`: shelly-101-eu.shelly.cloud
|
|
- `35.241.201.25`: repo.shelly.cloud
|
|
|
|
For the PreTester analysis, I chose control.shelly.cloud, as I suspect the lock to communicate to a cloud via the bridge.
|
|
As the bridge has a built in ESP32 supporting WiFi, I suspect the communication looks as follows:
|
|
|
|
<img src="img/sequence_diagram.png" alt="PlantUML sequence diagram of suspected communication flow" width="400">
|
|
|
|
The [PreTester report](network/pretester_reports/init_report.md) didn't find anything unusual.
|
|
It reported no critical or high findings.
|
|
|
|
### Old Initial Setup Capture
|
|
|
|
You can also find an older initial setup capture made by Manu [here](network/captures/old_init.pcapng).
|
|
I tested this in the PreTester as well using integrations.loqed.com, as this seemed to be the most present IP in the capture.
|
|
|
|
The [report](network/pretester_reports/old_init_report.md) can be found here.
|
|
Once again, it reported no critical or high findings.
|
|
|
|
> The old init capture supposedly was the first real fresh setup. As mentioned, the lock has been tempered with before.
|
|
|
|
## 2.6 Port Scan
|
|
|
|
I used the PreTester to probe all URLs and endpoints, here are some (interesting) findings:
|
|
|
|
While most of ports are common for HTTPS and SSH, there are a few interesting ones:
|
|
- 31234 onshelly-101-eu.shelly.cloud: [Nmap scan](network/nmap/shelly-101-eu-shelly-cloud.nmap) revealed no more information
|
|
- 6113 on shelly-120-eu.shelly.cloud: [Nmap scan](network/nmap/shelly-120-eu-shelly-cloud.nmap) found ports 6115, 6022, 8007, 6114
|
|
- It may be important to note that scan took significantly more time (almost 1h) and was eventually aborted
|
|
- **#TODO: RESCAN**
|
|
- 9443 on shelly-infra1-eu.shelly.cloud: widely recognized as an alternative or **administrative** HTTPS port
|
|
- 8883 on mqtt.production.loqed.com: official standard port designated for MQTT over TLS (MQTTS)
|
|
|
|
Some playing around with Metasploit's `check` on these 2 cloud endpoints couldn't find anything either.
|
|
|
|
## 2.7 BLE
|
|
|
|
I ran ToothFairy on the lock. It's advertising name is "Loqed Inside" and it uses a fixed MAC address `FF:EC:EE:E7:32:E5`.
|
|
I obtained the [GATT table](ble/gatt_FF-EC-EE-E7-32-E5_20261023_085131.json) and a very incomplete [test report](ble/toothfairy_report_FFECEEE732E5_20261023_085351.json), due to a lack of HW.
|
|
|
|
However, ToothFairy labelled `WRLS-FUZZ-002` as `FAIL`, due to the target not recovering after malformed packets were sent.
|
|
|
|
### Sniffing
|
|
|
|
After obtaining the needed HW, I tried snifing the app connection process and sent a lock/unlock command, none of which showed ATT protocol packets. This could be due to:
|
|
- Encryption on the link layer
|
|
- The sniffer struggling with frequency hopping (nRF nordic)
|
|
|
|
## 1.8 Collect Firmware Dump of Firmware after initial Setup
|
|
|
|
### Bridge
|
|
|
|
Hooking up the bridge using UART with a baud rate of 15200 revealed its [boot process](firmware/bridge/boot.txt).
|
|
Using an older version of esptool, I was able to obtain the [firmware](firmware/bridge/firmware.bin):
|
|
|
|
```bash
|
|
pipx run --spec esptool==3.3.2 esptool.py -p /dev/ttyUSB1 -b 115200 read_flash 0 0x400000 full_firmware.bin
|
|
```
|
|
|
|
> Writing this down in case I need it again.
|
|
|
|
#### FW Analysis
|
|
|
|
I found an [IoT FW analysis tool](https://github.com/ericyoc/iot_device_firmware_analysis_poc/tree/main) on GitHub, which I used for generating a quick [report](firmware/bridge/report.txt).
|
|
|
|
##### Reverse Engineer Anything
|
|
|
|
Using [REA](https://github.com/morluto/rea), we ran the firmware through Claude Code and received a short [report](firmware/bridge/claude_firmware_analysis.md).
|
|
|
|
### Inner Module
|
|
|
|
Using UART with a baud rate of 115200, I was able to log the boot process & runtime traffic.
|
|
It seems that the UART link is used for displaying text onto the touch module's display, as you can see it writing whatever the touch module is currently showing. E.g.: "Touch To Lock" or "Locking". Inspect the data [here](firmware/inner_module/inner_module_uart.txt).
|
|
|
|
In picocom, the device didn't react to any text-based commands.
|
|
|
|
I also wasn't able to obtain the FW using the test clip from the H451 chip (unknown by mini programmer) or the NOR flash (couldn't grab it).
|
|
|
|
I tried SWD using the j-link mini, but it kept resulting in an error.
|
|
|
|
It seems the extraction of the motor module FW exceeds this test.
|
|
|
|
## 1.9 && 2.4 Firmware Update / 1.10 Collect Updated Firmware Dump
|
|
|
|
There is no FW update available.
|
|
|
|
## 1.11 Collect Firmware Dump after Factory Reset
|
|
|
|
### Bridge
|
|
|
|
## 2.5 Inspection of Device During Normal Usage
|
|
|