a.edenhauser/Shelly-Loqed-Touch
1
1
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

doc0 - 1.6, 1.7/2.3

Browse Source
This commit is contained in:
a.edenhauser
2026-10-21 11:57:05 +02:00
parent 3b450d2a12
commit 70ab0354eb
6 changed files with 773 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Document0-Initial_Information_Gathering.md
+62 -7
View File
@@ -120,24 +120,79 @@ Here you can see:
## 1.6 Collect "Fresh" Firmware Dump
As the lock has been tampered with before, the FW dump is not entirely "fresh."
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 Shelly App. The capture can be found [here](captures/init.pcapng).
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](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](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](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.
### URLs and Endpoints
I used the PreTester to probe all URLs and endpoints, here are some (interesting) findings:
|Endpoint|Ports|TLS|Cipher|
|:-|:-|:-|:-|
|app-ratings.shelly.cloud|22, 80, 443, 8000|v1.2|ECDHE-RSA-AES256-GCM-SHA384|
|changelog-backend.shelly.cloud|22, 80, 443|v1.2|ECDHE-ECDSA-AES256-GCM-SHA384|
|control.shelly.cloud|22, 80|v1.3|TLS_AES_256_GCM_SHA384|
|integrations.loqed.com|80, 443, 8080|v1.3|TLS_AES_128_GCM_SHA256|
|paypal.shelly.cloud|22, 80, 443, 8000|v1.3|ECDHE-RSA-AES256-GCM-SHA384|
|repo.shelly.cloud|22, 80, 443|v1.3|TLS_AES_256_GCM_SHA384|
|shelly-101-eu.shelly.cloud|22, 80, 443, **31234**|v1.3|TLS_AES_256_GCM_SHA384|
|shelly-120-eu.shelly.cloud|22, 80, 443, **6113**|v1.3|TLS_AES_256_GCM_SHA384|
|shelly-infra1-eu.shelly.cloud|22, 80, 443, 8000, **9443**|v1.2|ECDHE-RSA-AES256-GCM-SHA384|
|api.production.loqed.com|80, 443, 8080|v1.3|TLS_AES_128_GCM_SHA256|
|mqtt.production.loqed.com|80, 443, 8080, **8883**|v1.3|TLS_AES_128_GCM_SHA256|
> Includes the old init.
## 1.8 Collect Firmware Dump of Firmware after initial Setup
### Bridge
### Outer Module
## 1.7 && 2.3 Initial setup
## 1.8 Collect Firmware Dump of Firmware after initial Setup
## 1.9 && 2.4 Firmware Update
## 1.10 Collect Updated Firmware Dump
### Bridge
### Outer Module
## 1.11 Collect Firmware Dump after Factory Reset
### Bridge
### Outer Module
## 1.12 (Optional for now) Instantiate Device Model
## 1.13 Collect App APKs