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

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)

src/hardware-physical-access/firmware-analysis/README.md

@@ -4,6 +4,12 @@
 
 ## **Introdução**
 
+### Recursos relacionados
+
+{{#ref}}
+synology-encrypted-archive-decryption.md
+{{#endref}}
+
 Firmware é um software essencial que permite que dispositivos operem corretamente, gerenciando e facilitando a comunicação entre os componentes de hardware e o software com o qual os usuários interagem. Ele é armazenado em memória permanente, garantindo que o dispositivo possa acessar instruções vitais desde o momento em que é ligado, levando ao lançamento do sistema operacional. Examinar e potencialmente modificar o firmware é um passo crítico na identificação de vulnerabilidades de segurança.
 
 ## **Coleta de Informações**
@@ -13,7 +19,7 @@ Firmware é um software essencial que permite que dispositivos operem corretamen
 - A arquitetura da CPU e o sistema operacional que ele executa
 - Especificações do bootloader
 - Layout de hardware e folhas de dados
-- Métricas da base de código e locais de origem
+- Métricas de código e locais de origem
 - Bibliotecas externas e tipos de licença
 - Históricos de atualização e certificações regulatórias
 - Diagramas arquitetônicos e de fluxo
@@ -148,7 +154,7 @@ Com o sistema de arquivos extraído, a busca por falhas de segurança começa. A
 
 - **etc/shadow** e **etc/passwd** para credenciais de usuário
 - Certificados e chaves SSL em **etc/ssl**
-- Arquivos de configuração e scripts em busca de vulnerabilidades potenciais
+- Arquivos de configuração e scripts para potenciais vulnerabilidades
 - Binários incorporados para análise adicional
 - Servidores web e binários comuns de dispositivos IoT
 
@@ -164,7 +170,7 @@ Tanto o código-fonte quanto os binários compilados encontrados no sistema de a
 
 ## Emulando Firmware para Análise Dinâmica
 
-O processo de emular firmware permite **análise dinâmica** tanto da operação de um dispositivo quanto de um programa individual. Essa abordagem pode enfrentar desafios com dependências de hardware ou arquitetura, mas transferir o sistema de arquivos raiz ou binários específicos para um dispositivo com arquitetura e endianness correspondentes, como um Raspberry Pi, ou para uma máquina virtual pré-construída, pode facilitar testes adicionais.
+O processo de emular firmware permite a **análise dinâmica** tanto da operação de um dispositivo quanto de um programa individual. Essa abordagem pode enfrentar desafios com dependências de hardware ou arquitetura, mas transferir o sistema de arquivos raiz ou binários específicos para um dispositivo com arquitetura e endianness correspondentes, como um Raspberry Pi, ou para uma máquina virtual pré-construída, pode facilitar testes adicionais.
 
 ### Emulando Binários Individuais
 
@@ -188,7 +194,7 @@ Para binários ARM, o processo é semelhante, com o emulador `qemu-arm` sendo ut
 
 ### Emulação de Sistema Completo
 
-Ferramentas como [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware Analysis Toolkit](https://github.com/attify/firmware-analysis-toolkit) e outras, facilitam a emulação completa de firmware, automatizando o processo e auxiliando na análise dinâmica.
+Ferramentas como [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware Analysis Toolkit](https://github.com/attify/firmware-analysis-toolkit) e outras, facilitam a emulação completa de firmware, automatizando o processo e ajudando na análise dinâmica.
 
 ## Análise Dinâmica na Prática
 
@@ -221,7 +227,7 @@ Fluxo de ataque típico:
 * Pegue-a do portal de download público do fornecedor, CDN ou site de suporte.
 * Extraia-a de aplicativos móveis/escrita acompanhantes (por exemplo, dentro de um APK Android em `assets/firmware/`).
 * Recupere-a de repositórios de terceiros, como VirusTotal, arquivos da Internet, fóruns, etc.
-2. **Carregar ou servir a imagem para o dispositivo** através de qualquer canal de atualização exposto:
+2. **Carregar ou servir a imagem para o dispositivo** via qualquer canal de atualização exposto:
 * UI da Web, API de aplicativo móvel, USB, TFTP, MQTT, etc.
 * Muitos dispositivos IoT de consumo expõem endpoints HTTP(S) *não autenticados* que aceitam blobs de firmware codificados em Base64, decodificam-nos no lado do servidor e acionam a recuperação/atualização.
 3. Após o downgrade, explore uma vulnerabilidade que foi corrigida na versão mais nova (por exemplo, um filtro de injeção de comando que foi adicionado posteriormente).
@@ -234,7 +240,7 @@ Host: 192.168.0.1
 Content-Type: application/octet-stream
 Content-Length: 0
 ```
-No firmware vulnerável (rebaixado), o parâmetro `md5` é concatenado diretamente em um comando shell sem sanitização, permitindo a injeção de comandos arbitrários (aqui – habilitando o acesso root baseado em chave SSH). Versões posteriores do firmware introduziram um filtro básico de caracteres, mas a ausência de proteção contra rebaixamento torna a correção irrelevante.
+No firmware vulnerável (rebaixado), o parâmetro `md5` é concatenado diretamente em um comando de shell sem sanitização, permitindo a injeção de comandos arbitrários (aqui – habilitando o acesso root baseado em chave SSH). Versões posteriores do firmware introduziram um filtro básico de caracteres, mas a ausência de proteção contra rebaixamento torna a correção irrelevante.
 
 ### Extraindo Firmware de Aplicativos Móveis
 

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}}
+
+## Overview
+
+Vários dispositivos Synology (DSM/BSM NAS, BeeStation, …) distribuem seu firmware e pacotes de aplicativos em **arquivos PAT / SPK criptografados**. Esses arquivos podem ser descriptografados *offline* com nada além dos arquivos de download públicos, graças a chaves codificadas embutidas dentro das bibliotecas de extração oficiais.
+
+Esta página documenta, passo a passo, como o formato criptografado funciona e como recuperar completamente o **TAR** em texto claro que está dentro de cada pacote. O procedimento é baseado na pesquisa da Synacktiv realizada durante o Pwn2Own Irlanda 2024 e implementado na ferramenta de código aberto [`synodecrypt`](https://github.com/synacktiv/synodecrypt).
+
+> ⚠️  O formato é exatamente o mesmo para os arquivos `*.pat` (atualização do sistema) e `*.spk` (aplicativo) – eles diferem apenas no par de chaves codificadas que são selecionadas.
+
+---
+
+## 1. Grab the archive
+
+A atualização do firmware/aplicativo pode normalmente ser baixada do portal público da Synology:
+```bash
+$ wget https://archive.synology.com/download/Os/BSM/BSM_BST150-4T_65374.pat
+```
+## 2. Despeje a estrutura PAT (opcional)
+
+`*.pat` imagens são, elas mesmas, um **pacote cpio** que incorpora vários arquivos (carregador de inicialização, kernel, rootfs, pacotes…). A ferramenta gratuita [`patology`](https://github.com/sud0woodo/patology) é conveniente para inspecionar esse wrapper:
+```bash
+$ python3 patology.py --dump -i BSM_BST150-4T_65374.pat
+[…]
+$ ls
+DiskCompatibilityDB.tar  hda1.tgz  rd.bin  packages/  …
+```
+Para `*.spk` você pode pular diretamente para o passo 3.
+
+## 3. Extraia as bibliotecas de extração da Synology
+
+A verdadeira lógica de descriptografia está em:
+
+* `/usr/syno/sbin/synoarchive`               → wrapper CLI principal
+* `/usr/lib/libsynopkg.so.1`                 → chama o wrapper da interface do DSM
+* `libsynocodesign.so`                       → **contém a implementação criptográfica**
+
+Ambos os binários estão presentes no rootfs do sistema (`hda1.tgz`) **e** no init-rd comprimido (`rd.bin`). Se você tiver apenas o PAT, pode obtê-los desta forma:
+```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. Recuperar as chaves codificadas (`get_keys`)
+
+Dentro de `libsynocodesign.so`, a função `get_keys(int keytype)` simplesmente retorna duas variáveis globais de 128 bits para a família de arquivos solicitada:
+```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** → Chave pública Ed25519 usada para verificar o cabeçalho do arquivo.
+* **master_key**    → Chave raiz usada para derivar a chave de criptografia por arquivo.
+
+Você só precisa despejar essas duas constantes uma vez para cada versão principal do DSM.
+
+## 5. Estrutura do cabeçalho e verificação de assinatura
+
+`synoarchive_open()` → `support_format_synoarchive()` → `archive_read_support_format_synoarchive()` realiza o seguinte:
+
+1. Ler mágica (3 bytes) `0xBFBAAD` **ou** `0xADBEEF`.
+2. Ler little-endian 32-bit `header_len`.
+3. Ler `header_len` bytes + a próxima **assinatura Ed25519 de 0x40 bytes**.
+4. Iterar sobre todas as chaves públicas incorporadas até que `crypto_sign_verify_detached()` tenha sucesso.
+5. Decodificar o cabeçalho com **MessagePack**, resultando em:
+```python
+[
+data: bytes,
+entries: [ [size: int, sha256: bytes], … ],
+archive_description: bytes,
+serial_number: [bytes],
+not_valid_before: int
+]
+```
+`entries` permite que o libarchive verifique a integridade de cada arquivo à medida que é descriptografado.
+
+## 6. Derivar a sub-chave por arquivo
+
+A partir do blob `data` contido no cabeçalho MessagePack:
+
+* `subkey_id`  = little-endian `uint64` no deslocamento 0x10
+* `ctx`        = 7 bytes no deslocamento 0x18
+
+A chave de **stream** de 32 bytes é obtida com libsodium:
+```c
+crypto_kdf_derive_from_key(kdf_subkey, 32, subkey_id, ctx, master_key);
+```
+## 7. Backend **libarchive** personalizado da Synology
+
+A Synology agrupa uma libarchive corrigida que registra um formato "tar" falso sempre que o magic é `0xADBEEF`:
+```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)
+```
+O `tar_hdr` descriptografado é um **cabeçalho TAR POSIX clássico**.
+
+### 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
+```
+Cada **nonce de 0x18 bytes** é precedido ao bloco criptografado.
+
+Uma vez que todas as entradas são processadas, libarchive produz um **`.tar`** perfeitamente válido que pode ser descompactado com qualquer ferramenta padrão.
+
+## 8. Decrypt everything with synodecrypt
+```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` detecta automaticamente PAT/SPK, carrega as chaves corretas e aplica toda a cadeia descrita acima.
+
+## 9. Armadilhas comuns
+
+* Não troque `signature_key` e `master_key` – eles servem a propósitos diferentes.
+* O **nonce** vem *antes* do texto cifrado para cada bloco (cabeçalho e dados).
+* O tamanho máximo do bloco criptografado é **0x400000 + 0x11** (tag libsodium).
+* Arquivos criados para uma geração do DSM podem mudar para chaves codificadas diferentes na próxima versão.
+
+## 10. Ferramentas adicionais
+
+* [`patology`](https://github.com/sud0woodo/patology) – analisar/dump arquivos PAT.
+* [`synodecrypt`](https://github.com/synacktiv/synodecrypt) – descriptografar PAT/SPK/outros.
+* [`libsodium`](https://github.com/jedisct1/libsodium) – implementação de referência de XChaCha20-Poly1305 secretstream.
+* [`msgpack`](https://msgpack.org/) – serialização de cabeçalho.
+
+## Referências
+
+- [Extração de arquivos criptografados da Synology – Synacktiv (Pwn2Own IE 2024)](https://www.synacktiv.com/publications/extraction-des-archives-chiffrees-synology-pwn2own-irlande-2024.html)
+- [synodecrypt no GitHub](https://github.com/synacktiv/synodecrypt)
+- [patology no GitHub](https://github.com/sud0woodo/patology)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-web/command-injection.md

@@ -117,6 +117,28 @@ powershell C:**2\n??e*d.*? # notepad
 ../linux-hardening/bypass-bash-restrictions/
 {{#endref}}
 
+### Node.js `child_process.exec` vs `execFile`
+
+Ao auditar back-ends em JavaScript/TypeScript, você frequentemente encontrará a API `child_process` do Node.js.
+```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()` gera um **shell** (`/bin/sh -c`), portanto, qualquer caractere que tenha um significado especial para o shell (back-ticks, `;`, `&&`, `|`, `$()`, …) resultará em **injeção de comando** quando a entrada do usuário for concatenada na string.
+
+**Mitigação:** use `execFile()` (ou `spawn()` sem a opção `shell`) e forneça **cada argumento como um elemento de array separado** para que nenhum shell esteja envolvido:
+```javascript
+const { execFile } = require('child_process');
+execFile('/usr/bin/do-something', [
+'--id_user', id_user,
+'--payload', JSON.stringify(payload)
+]);
+```
+Caso real: *Synology Photos* ≤ 1.7.0-0794 era explorável através de um evento WebSocket não autenticado que colocava dados controlados pelo atacante em `id_user`, que mais tarde eram incorporados em uma chamada `exec()`, alcançando RCE (Pwn2Own Irlanda 2024).
+
 ## Lista de Detecção de Força Bruta
 
 {{#ref}}
@@ -125,7 +147,9 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/command_inject
 
 ## Referências
 
+- [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)
+- [Extração de arquivos criptografados da Synology – Synacktiv 2025](https://www.synacktiv.com/publications/extraction-des-archives-chiffrees-synology-pwn2own-irlande-2024.html)
 
 {{#include ../banners/hacktricks-training.md}}