Carbonara The MediaTek exploit nobody served

src/SUMMARY.md

@@ -828,6 +828,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)
+  - [Mediatek Xflash Carbonara Da2 Hash Bypass](hardware-physical-access/firmware-analysis/mediatek-xflash-carbonara-da2-hash-bypass.md)
   - [Synology Encrypted Archive Decryption](hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md)
   - [Windows Seh Overflow](binary-exploitation/stack-overflow/windows-seh-overflow.md)
 - [Array Indexing](binary-exploitation/array-indexing.md)

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

@@ -19,6 +19,10 @@ synology-encrypted-archive-decryption.md
 android-mediatek-secure-boot-bl2_ext-bypass-el3.md
 {{#endref}}
 
+{{#ref}}
+mediatek-xflash-carbonara-da2-hash-bypass.md
+{{#endref}}
+
 Firmware is essential software that enables devices to operate correctly by managing and facilitating communication between the hardware components and the software that users interact with. It's stored in permanent memory, ensuring the device can access vital instructions from the moment it's powered on, leading to the operating system's launch. Examining and potentially modifying firmware is a critical step in identifying security vulnerabilities.
 
 ## **Gathering Information**
@@ -192,9 +196,9 @@ Both source code and compiled binaries found in the filesystem must be scrutiniz
 
 Many IoT hubs fetch their per-device configuration from a cloud endpoint that looks like:
 
-- [https://<api-host>/pf/<deviceId>/<token>](https://<api-host>/pf/<deviceId>/<token>)
+- `https://<api-host>/pf/<deviceId>/<token>`
 
-During firmware analysis you may find that <token> is derived locally from the device ID using a hardcoded secret, for example:
+During firmware analysis you may find that `<token>` is derived locally from the device ID using a hardcoded secret, for example:
 
 - token = MD5( deviceId || STATIC_KEY ) and represented as uppercase hex
 

src/hardware-physical-access/firmware-analysis/mediatek-xflash-carbonara-da2-hash-bypass.md

@@ -0,0 +1,51 @@
+# MediaTek XFlash Carbonara DA2 Hash Bypass
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Summary
+
+"Carbonara" abuses MediaTek's XFlash download path to run a modified Download Agent stage 2 (DA2) despite DA1 integrity checks. DA1 stores the expected SHA-256 of DA2 in RAM and compares it before branching. On many loaders, the host fully controls the DA2 load address/size, giving an unchecked memory write that can overwrite that in-memory hash and redirect execution to arbitrary payloads (pre-OS context with cache invalidation handled by DA).
+
+## Trust boundary in XFlash (DA1 → DA2)
+
+- **DA1** is signed/loaded by BootROM/Preloader. When Download Agent Authorization (DAA) is enabled, only signed DA1 should run.
+- **DA2** is sent over USB. DA1 receives **size**, **load address**, and **SHA-256** and hashes the received DA2, comparing it to an **expected hash embedded in DA1** (copied into RAM).
+- **Weakness:** On unpatched loaders, DA1 does not sanitize the DA2 load address/size and keeps the expected hash writable in memory, enabling the host to tamper with the check.
+
+## Carbonara flow ("two BOOT_TO" trick)
+
+1. **First `BOOT_TO`:** Enter the DA1→DA2 staging flow (DA1 allocates, prepares DRAM, and exposes the expected-hash buffer in RAM).
+2. **Hash-slot overwrite:** Send a small payload that scans DA1 memory for the stored DA2-expected hash and overwrites it with the SHA-256 of the attacker-modified DA2. This leverages the user-controlled load to land the payload where the hash resides.
+3. **Second `BOOT_TO` + digest:** Trigger another `BOOT_TO` with the patched DA2 metadata and send the raw 32-byte digest matching the modified DA2. DA1 recomputes SHA-256 over the received DA2, compares it against the now-patched expected hash, and the jump succeeds into attacker code.
+
+Because load address/size are attacker-controlled, the same primitive can write anywhere in memory (not just the hash buffer), enabling early-boot implants, secure-boot bypass helpers, or malicious rootkits.
+
+## Minimal PoC pattern (mtkclient-style)
+
+```python
+if self.xsend(self.Cmd.BOOT_TO):
+    payload = bytes.fromhex("a4de2200000000002000000000000000")
+    if self.xsend(payload) and self.status() == 0:
+        import hashlib
+        da_hash = hashlib.sha256(self.daconfig.da2).digest()
+        if self.xsend(da_hash):
+            self.status()
+            self.info("All good!")
+```
+
+- `payload` replicates the paid-tool blob that patches the expected-hash buffer inside DA1.
+- `sha256(...).digest()` sends raw bytes (not hex) so DA1 compares against the patched buffer.
+- DA2 can be any attacker-built image; choosing the load address/size allows arbitrary memory placement with cache invalidation handled by DA.
+
+## Notes for triage and hardening
+
+- Devices where DA2 address/size are unchecked and DA1 keeps the expected hash writable are vulnerable. If a later Preloader/DA enforces address bounds or keeps the hash immutable, Carbonara is mitigated.
+- Enabling DAA and ensuring DA1/Preloader validate BOOT_TO parameters (bounds + authenticity of DA2) closes the primitive. Closing only the hash patch without bounding the load still leaves arbitrary write risk.
+
+## References
+
+- [Carbonara: The MediaTek exploit nobody served](https://shomy.is-a.dev/blog/article/serving-carbonara)
+- [Carbonara exploit documentation](https://shomy.is-a.dev/penumbra/Mediatek/Exploits/Carbonara)
+- [Penumbra Carbonara source code](https://github.com/shomykohai/penumbra/blob/main/core/src/exploit/carbonara.rs)
+
+{{#include ../../banners/hacktricks-training.md}}