JBL Wave Buds 2 — Firmware- & OTA-Reverse-Engineering

Reverse-Engineering-Notizen und reproduzierbare Tooling für die JBL Wave Buds 2 (Bestechnic BES1306, PID 2100): das On-Flash-Layout, das OTA-Container- Format bis aufs Byte, das BLE/GATT-Kommando-Protokoll und den verschlüsselten BES-„TOTA v2"-Transport, die Vertrauensgrenzen auf Geräte- und App-Seite, die Factory-Konsole sowie eine reproduzierbare Methode, um ein selbstgebautes Image auf ein Gerät zu laden, das Sie besitzen.

Die Analyse umfasst zwei Builds — das IDA-analysierte wavebuds.elf (Apr 2025) und das Distributionspaket 2.9.0 (Sep 2026) —, einen vollständig spezifizierten 8-Stream-OTA-Container (verifiziert durch byte-identisches Repack), das CRC-32- Integritätsmodell, bestätigt auf App- und Geräteseite, eine Factory-Kommandotabelle mit 54/59 Einträgen, 12 OTA-RAM-Zustandsvariablen, eine Enumeration von 7.960 Funktionen und ein build-übergreifendes Differential. Die semantische Wiederherstellung ist für die OTA-/Flash-/CRC-/Factory-Subsysteme tiefgehend und ansonsten auf Enumeration beschränkt — siehe den Vollständigkeits-Audit.

[!WARNING] Dies ist vom Eigentümer durchgeführte Hardware-Forschung, kein offizielles JBL-Update. Das Flashen eines modifizierten Images ist irreversibel: Die Download-Phase ist gestaffelt und brick-sicher, aber die Aktivierung eines CRC-gültigen, jedoch defekten Images hat keinen offengelegten Wiederherstellungspfad. Lesen Sie SAFETY.md, bevor Sie etwas reproduzieren.

Türkische Version: README.tr.md

Hardware-Ergebnis am getesteten Gerät: Nachdem die OTA-Pipeline aus App + User-CA-MITM validiert wurde, verbinden sich beide Ohrhörer, melden 100 %, und jede App-Steuerung (ANC/Ambient, Gesten, EQ) funktioniert. Das um ein Byte modifizierte Image wurde auf dieselbe Weise akzeptiert, und das Gerät blieb voll funktionsfähig.

Bestätigte Erkenntnisse

Die Adressen stammen aus dem analysierten Build (wavebuds.elf); siehe das Adressverzeichnis und die Provenienz.

• Das OTA-Image ist nicht kryptografisch signiert. Die geräteseitige Integrität beruht ausschließlich auf CRC-32 — der Handler 0x2C0918BC prüft die Konfiguration, jedes Segment und das gesamte Image mit der CRC-32-Routine 0x2C0CE944 (Tabelle 0x2C0F5218) plus einer "BEST"-Magic. Ein CRC-gültiges Image mit einem modifizierten Byte wurde akzeptiert und gebootet.
• Der RSA-2048-Verifier der App (com.jbl.counterfeit.Rsa2048DynamicVerifier) dient der Fälschungserkennung (Geräteauthentizität), nicht der Firmware-Signierung.
• Die App pinnt ihre OTA-Endpunkte nicht; eine vom Benutzer installierte CA genügt, um die OTA-Konfiguration abzufangen und umzuschreiben.
• OTA ist gestaffelt: Das neue Image wird an die Flash-Basis 0x28120000 kopiert, während die laufende Anwendung unberührt bleibt, sodass die Download-Phase brick-sicher ist.
• Eine externe BLE-Zentrale kann OTA nicht steuern: Die Handler sind an einen internen TWS-/Verbindungszustand gekoppelt (0x2C0905E4: MEMORY[0x20026BA0] ∈ {2,4}).
• Der BES-TOTA v2-Transport leitet seinen AES-128-Sitzungsschlüssel vollständig clientseitig ab; es gibt kein Server-/Gerätegeheimnis.
• Eine Factory-/Engineering-Konsole (59 Befehle im analysierten Build, 54 in 2.9.0) kann die Geräteidentität (MAC/BLE-Adresse), den Quarz-Abgleich und den BT-Link-Key lesen/schreiben. Ihre Erreichbarkeit über Funk ist UNRESOLVED.
• Die beiden Builds sind separat kompiliert und relokiert: gleiches Produkt, verschobene Adressen, 59 → 54 Factory-Einträge. Siehe das Differential.

Getestete Modifikation

Die Modifikation ist bewusst minimal — ein Byte des dekomprimierten Images. Sie ändert den RTX-Kernel-String RTX V5.5.1 → V5.5.2 bei dekomprimiertem Offset 64096, und die Container-CRC-32 wird neu berechnet. Sie ist designbedingt kosmetisch: Es geht darum zu beweisen, dass das Gerät ein modifiziertes, aber CRC-gültiges Image akzeptiert, nicht darum, das Verhalten zu ändern.

Base (owner-supplied; not redistributed)
  official 2.9.0 package   549,558 bytes   SHA-256 836cb251f9fb2261dde14f39ba18d358c48018817f3c3d1b527e1ac5f3ab7ba2
  decompressed image       955,596 bytes   SHA-256 489663e80b76f20f4c94671064908569fac5f4e3df10ab6d7369baffe094f67d
  container CRC-32          A0C7CCEC (valid), input range [0x0, 0x862AD)

Das Repository enthält absichtlich keine JBL-Firmware. Stellen Sie Ihr eigenes rechtmäßig erworbenes Paket bereit und reproduzieren Sie:

python3 tools/ota_unpack.py  <official_2.9.0_package.bin> --extract image.bin
python3 tools/ota_repack.py  make-test <official_2.9.0_package.bin> test.bin
python3 tools/ota_unpack.py  test.bin      # exactly one decompressed byte differs; CRC valid

Die exakten Bytes des neu gepackten Containers hängen vom LZMA-Encoder ab; das Gerät verifiziert CRC-32, nicht einen Paket-Hash (siehe docs/04), und der einbyteige dekomprimierte Diff ist deterministisch. Die Auslieferung über die App wird in docs/08 beschrieben.

Diagramme

Flash-Karte	2-MB-NOR-Partitionierung
OTA-Befehlablauf	die Sequenz und ihre CRC-32-Prüfpunkte
Vertrauensgrenzen	was jede Stufe verifiziert und worauf das Vertrauen in die Images beruht

Dokumentation