add: FW quick check
This commit is contained in:
@@ -125,7 +125,7 @@ The device has been tampered with before, therefore there is no fresh dump avail
|
||||
|
||||
## 1.7 && 2.3 Initial setup
|
||||
|
||||
The initial setup is done using the Shelly app. The capture can be found [here](captures/init.pcapng).
|
||||
The initial setup is done using 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).
|
||||
|
||||
@@ -143,15 +143,15 @@ As the bridge has a built in ESP32 supporting WiFi, I suspect the communication
|
||||
|
||||
<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.
|
||||
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](captures/old_init.pcapng).
|
||||
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](pretester_reports/old_init_report.md) can be found here.
|
||||
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.
|
||||
@@ -161,8 +161,8 @@ Once again, it reported no critical or high findings.
|
||||
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](nmap/shelly-101-eu-shelly-cloud.nmap) revealed no more information
|
||||
- 6113 on shelly-120-eu.shelly.cloud: [Nmap scan](nmap/shelly-120-eu-shelly-cloud.nmap) found ports 6115, 6022, 8007, 6114
|
||||
- 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
|
||||
@@ -174,7 +174,7 @@ Some playing around with Metasploit's `check` on these 2 cloud endpoints couldn'
|
||||
|
||||
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](toothfairy_reports/gatt_FF-EC-EE-E7-32-E5_20261023_085131.json) and a very incomplete [test report](toothfairy_reports/toothfairy_report_FFECEEE732E5_20261023_085351.json), due to a lack of hardware.
|
||||
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 hardware.
|
||||
|
||||
However, ToothFairy labelled `WRLS-FUZZ-002` as `FAIL`, due to the target not recovering after malformed packets were sent.
|
||||
|
||||
@@ -182,7 +182,34 @@ However, ToothFairy labelled `WRLS-FUZZ-002` as `FAIL`, due to the target not re
|
||||
|
||||
### Bridge
|
||||
|
||||
### Outer Module
|
||||
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.
|
||||
|
||||
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).
|
||||
Interesting findings:
|
||||
- Lock state tracking (`GO_TO_STATE_INSTANTOPEN`, `MOTOR_STALL`, ...)
|
||||
- Confirmed cloud communication via MQTT and lock communication via BLE
|
||||
- Contains embedded RSA and EC Private Key structural markers
|
||||
- Implements `secure_boot_v1`
|
||||
- Uses `mbedtls` for modern ciphers
|
||||
- Exposes path from dev's machine (his name seems to be Pierre, lol) `/home/pierre/bridge/components/button_driver/iot_button.c`
|
||||
- Runs FreeRTOS
|
||||
- Uses SPIRAM
|
||||
|
||||
### Inner Module
|
||||
|
||||
Using UART with a baud rate of 15200, I was able to log the boot process, you can find it [here](firmware/inner_module/boot.txt).
|
||||
|
||||
In picocom, the device didn't react to any text-based commands.
|
||||
|
||||
The boot log contans repeating binary control structures rather than scrolling text, indicating there is no active console listening in that UART interface.
|
||||
|
||||
## 1.9 && 2.4 Firmware Update / 1.10 Collect Updated Firmware Dump
|
||||
|
||||
@@ -192,11 +219,13 @@ There is no FW update available.
|
||||
|
||||
### Bridge
|
||||
|
||||
### Outer Module
|
||||
### Inner Module
|
||||
|
||||
## 1.12 (Optional for now) Instantiate Device Model
|
||||
|
||||
## 1.13 Collect App APKs
|
||||
|
||||
The Shelly app can be found [here](app_apks/shelly.apk).
|
||||
|
||||
## 2.5 Inspection of Device During Normal Usage
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user