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

add: gave up on inner module FW

Browse Source
This commit is contained in:
a.edenhauser
2026-10-29 11:24:15 +01:00
parent 731f5fa2da
commit ebaead60be
1 changed files with 18 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Document0-Initial_Information_Gathering.md
+18 -14
View File
@@ -25,6 +25,19 @@ Common issues for consumers include:
## 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:
@@ -121,11 +134,11 @@ Here you can see:
## 1.6 Collect "Fresh" Firmware Dump
The device has been tampered with before, therefore there is no fresh dump available.
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](network/captures/init.pcapng).
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).
@@ -173,7 +186,6 @@ Some playing around with Metasploit's `check` on these 2 cloud endpoints couldn'
## 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.
@@ -189,7 +201,6 @@ After obtaining the needed HW, I tried snifing the app connection process and se
### 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
@@ -212,10 +223,11 @@ Interesting findings:
### 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 contains repeating binary control structures rather than scrolling text, indicating there is no active console listening in that UART interface.
The boot log contans repeating binary control structures rather than scrolling text, indicating there is no active console listening in that UART interface.
I also wasn't able to obtain the FW using the "Kralle" from the H451 chip or the NOR flash.
It seems the extraction of the motor module FW exceeds this test.
## 1.9 && 2.4 Firmware Update / 1.10 Collect Updated Firmware Dump
@@ -225,13 +237,5 @@ There is no FW update available.
### Bridge
### 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