add: FW quick check

Document0-Initial_Information_Gathering.md

@@ -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
+- 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](nmap/shelly-120-eu-shelly-cloud.nmap) found ports 6115, 6022, 8007, 6114 
+- 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