diff --git a/Document0-Initial_Information_Gathering.md b/Document0-Initial_Information_Gathering.md
index 641e74e..becec24 100644
--- a/Document0-Initial_Information_Gathering.md
+++ b/Document0-Initial_Information_Gathering.md
@@ -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