Reverse Engineering & Analysemethoden

Lernziel

Nach dieser Seite weißt du, wie Sicherheitsforscher BLE-Apps und -Geräte analysieren — von der APK-Dekompilierung über die Binäranalyse bis hin zur strukturierten Schwachstellenbewertung mit CVSS und OWASP.

Was ist Reverse Engineering?

Reverse Engineering bedeutet, ein fertiges Produkt auseinanderzunehmen, um zu verstehen, wie es funktioniert — ohne Zugang zum Quellcode. Stell dir vor, du bekommst einen unbekannten Kuchen und willst das Rezept herausfinden: Du riechst, schmeckst, analysierst die Zutaten. Genauso gehst du bei Software vor.

Bei BLE-Geräten gibt es zwei Hauptziele:

1. Die App verstehen — Welche UUIDs werden genutzt? Wie wird verschlüsselt? Gibt es hardcodierte Schlüssel?
2. Das Gerät verstehen — Wie reagiert es auf welche Befehle? Welche Daten sendet es ungefragt?

Statische Analyse: Die App auseinandernehmen

Statische Analyse bedeutet, Code zu lesen, ohne ihn auszuführen. Du untersuchst die App wie ein Dokument — Seite für Seite.

APK-Dekompilierung mit JADX

Eine Android-App (APK-Datei) ist im Grunde ein ZIP-Archiv. Es enthält:

• classes.dex — kompilierten Java/Kotlin-Code als Dalvik-Bytecode
• lib/arm64-v8a/*.so — native Bibliotheken (kompilierter C/C++-Code)
• AndroidManifest.xml — Berechtigungen und App-Konfiguration
• Ressourcen, Bilder, Strings

Das Tool JADX übersetzt den Dalvik-Bytecode zurück in lesbaren Java-Code. Das Ergebnis ist nicht identisch mit dem Originalcode, aber nah genug, um die Logik zu verstehen.

Was du in einer BLE-App suchst:

• UUIDs — eindeutige Kennungen für GATT-Services und -Charakteristiken (Muster: [0-9a-f]{8}-[0-9a-f]{4}-...)
• Kryptographie-Keywords — AES, SecretKeySpec, Cipher.getInstance, KeyGenerator
• BLE-API-Aufrufe — BluetoothGatt, writeCharacteristic, setCharacteristicNotification
• Hardcodierte Schlüssel — Byte-Arrays wie new byte[]{0x34, 0x52, 0x2A, ...}

Dynamische Analyse: Das Gerät in Aktion beobachten

Dynamische Analyse bedeutet, das System während der Ausführung zu beobachten. Du schaust dem Gerät beim Arbeiten zu, statt nur den Code zu lesen.

Für BLE heißt das: Traffic-Capture. Mit einem Sniffer-Dongle (z. B. nRF52840) und Wireshark kannst du alle BLE-Pakete zwischen App und Gerät mitschneiden.

Was du dabei lernst:

• Welche GATT-Charakteristiken werden wirklich genutzt?
• In welcher Reihenfolge läuft ein Verbindungsaufbau ab?
• Sind die Daten verschlüsselt oder im Klartext?
• Werden Befehle einfach repliziert, wenn man sie wiederholt schickt?

Binäranalyse: Native Bibliotheken unter der Lupe

Hersteller lagern sicherheitskritischen Code manchmal aus dem Java-Teil in native Bibliotheken aus — .so-Dateien für ARM-Prozessoren. Das macht Reverse Engineering schwieriger, aber nicht unmöglich.

Ghidra: Der Maschinencode-Übersetzer

Ghidra ist ein Open-Source-Disassembler und Decompiler, der von der NSA entwickelt und 2019 veröffentlicht wurde. Er kann ARM64-Binärdateien lesen und in C-ähnlichen Pseudocode übersetzen.

JNI-Einstiegspunkte finden: Java Native Interface (JNI) ist die Brücke zwischen Java-Code und nativen Bibliotheken. JNI-Funktionen haben einen charakteristischen Namen: Java_com_example_app_ClassName_methodName. In Ghidra sucht man gezielt nach diesem Muster.

FindCrypt: Dieses Ghidra-Plugin erkennt automatisch bekannte Kryptographie-Konstanten — zum Beispiel die AES S-Box oder SHA-256-Initialisierungswerte. Wenn FindCrypt anschlägt, weiß man sofort: Hier passiert Kryptographie.

Hardcodierte Schlüssel lokalisieren: AES-Schlüssel landen häufig in der .rodata-Section der Binärdatei (read-only data). Nach einem FindCrypt-Treffer folgt man den Datenpfaden im Decompiler, bis man auf ein Byte-Array stößt — das ist oft der Schlüssel.

Schwachstellen bewerten: CVSS 3.1

Gefundene Schwachstellen müssen bewertet werden — wie ernst ist das Problem? Dafür gibt es das Common Vulnerability Scoring System (CVSS) 3.1, entwickelt von FIRST.org.

CVSS erzeugt einen Score von 0,0 bis 10,0, aufgeteilt in fünf Schweregrade:

Die Metrik-Gruppen

Exploitability-Metriken beschreiben, wie leicht eine Schwachstelle ausgenutzt werden kann:

• Attack Vector (AV) — Von wo aus ist der Angriff möglich? Network, Adjacent, Local oder Physical?
• Attack Complexity (AC) — Sind besondere Bedingungen erforderlich? Low oder High?
• Privileges Required (PR) — Braucht der Angreifer vorherige Zugriffsrechte? None, Low oder High?
• User Interaction (UI) — Muss ein Opfer aktiv mitmachen? None oder Required?

Impact-Metriken beschreiben, was ein erfolgreicher Angriff anrichtet:

• Confidentiality (C) — Werden Daten offengelegt?
• Integrity (I) — Können Daten verändert werden?
• Availability (A) — Wird das System unbrauchbar?

Jede Metrik hat die Stufen None, Low oder High.

BLE-spezifische Besonderheit: AV:A

Für BLE-Schwachstellen ist der Attack Vector fast immer Adjacent (AV:A) — denn Bluetooth hat eine begrenzte Reichweite von typischerweise 10–100 Metern. Ein Angreifer muss sich in physischer Nähe befinden. Die CVSS-3.1-Spezifikation nennt Bluetooth explizit als Beispiel für Adjacent Network.

Das bedeutet: Selbst kritische BLE-Schwachstellen erreichen selten einen Score über 8,8, weil AV:A den Score gegenüber AV:N (Network) reduziert. Das ist kein Freifahrtschein — in öffentlichen Räumen wie Cafés oder Zügen sind Dutzende Geräte gleichzeitig in Reichweite.

OWASP IoT Top 10: Die häufigsten IoT-Schwachstellen

Die OWASP IoT Top 10 (2018) ist eine Liste der zehn häufigsten Schwachstellen in IoT-Geräten, erstellt von der Open Web Application Security Project Foundation. Sie dient als Checkliste für Sicherheitstests und -bewertungen.

Für BLE-Geräte sind diese Kategorien besonders relevant:

I1 — Schwache oder hardcodierte Passwörter

Geräte verwenden Standardpasswörter, die nie geändert werden, oder Passwörter die fest im Code stecken. Bei BLE: hardcodierte Pairing-PINs (oft 000000), feste AES-Schlüssel in der App.

I2 — Unsichere Netzwerkdienste

Dienste, die ohne Authentifizierung erreichbar sind. Bei BLE: GATT-Charakteristiken, die ohne Pairing beschreibbar sind.

I3 — Unsichere Schnittstellen

Webinterfaces, APIs oder mobile Apps mit schwacher Zugangskontrolle. Bei BLE: die App-Logik, die Befehle ohne Autorisierungsprüfung akzeptiert.

I6 — Mangelnder Datenschutz

Unverschlüsselte Übertragung oder Speicherung sensibler Daten. Bei BLE: Gesundheitsdaten (Gewicht, Impedanz) im Klartext über Advertisement-Pakete.

I7 — Unsichere Datenübertragung und -speicherung

Fehlende Transportverschlüsselung, unsichere Protokolle. Bei BLE: keine BLE-Sicherheitsmodi aktiviert, keine Ende-zu-Ende-Verschlüsselung.

I9 — Unsichere Standardkonfiguration

Geräte werden mit unsicheren Werkseinstellungen ausgeliefert. Bei BLE: Security Mode 1, Level 1 (keine Sicherheit) als Standard, obwohl höhere Level verfügbar wären.

Der Analyse-Workflow im Überblick

Ein typischer BLE-Sicherheitstest kombiniert alle beschriebenen Methoden:

1. APK beschaffen — über ADB vom Testgerät extrahieren oder aus dem Play Store
2. Statische Analyse — JADX: UUIDs, Krypto-Calls, hardcodierte Werte
3. Traffic-Capture — nRF52840 + Wireshark: reales Kommunikationsverhalten
4. Binäranalyse — Ghidra + FindCrypt: native Bibliotheken, versteckte Schlüssel
5. Korrelation — JADX-Funde mit PCAP-Daten abgleichen
6. Bewertung — CVSS-Score berechnen, OWASP-Kategorie zuordnen

Jede Phase des Guides in der Guide-Sektion folgt genau diesem Ablauf — mit konkreten Befehlen, Screenshots und Beispielen aus echten Geräten.

Zusammenfassung

• Statische Analyse (JADX): App ohne Ausführung untersuchen — UUIDs, Krypto-Calls, hardcodierte Schlüssel finden
• Dynamische Analyse: Traffic-Capture zeigt reales Verhalten und ergänzt den Blick in den Code
• Binäranalyse (Ghidra + FindCrypt): native .so-Bibliotheken auf versteckte Kryptographie und hardcodierte Schlüssel untersuchen
• CVSS 3.1: strukturierte Schwachstellenbewertung, BLE typischerweise AV:A (Adjacent)
• OWASP IoT Top 10: standardisierter Kategorisierungsrahmen für IoT-Schwachstellen — I1, I2, I6, I7, I9 besonders relevant für BLE