Androids 8-Byte-Crash: Warum eine lautlose SMS Handys alle 90 Sekunden rebootet – und wie Du Deine Daten rettest

Das Smartphone liegt völlig unberührt auf dem Tisch, als das Display schlagartig schwarz wird. Kein Klingeln kündigte den Vorfall an, keine Push-Benachrichtigung ploppte auf, und im Posteingang der SMS-App existierte schlicht kein neuer Eintrag.
Exakt fünf Byte in einer präparierten WAP-Push-Nachricht genügen, um Androids Telefonie-Dienst aus der Ferne reproduzierbar abzuschießen. Nach wenigen Minuten sitzt das Gerät in einer 90-Sekunden-Reboot-Schleife fest – und treibt Betroffene im Wiederherstellungsmenü direkt in die Datenlöschung.
Schnelle Fakten & Notfall-Hilfe
- Der Angriffsvektor: Lautloser Zero-Click-Angriff über Port 2948 via WAP-Push; die Daten-Nachricht wird unsichtbar im Systemhintergrund verarbeitet.
- Das Schadensbild: Der Systemdienst
com.android.phonestürzt sofort ab, aktive Anrufe und Notrufe (112) brechen mit dem StatusCS_DEATHab.- Tödliche Schleife: Weil das Gerät den Empfang nicht quittieren kann, stellt der Netzbetreiber das Paket tagelang neu zu; nach mehreren Crashs erzwingt Androids RescueParty den Recovery-Modus.
- Kein „Wipe Data“: Wähle im Recovery-Menü keinesfalls den Werksreset, sondern stoppe den Loop über den SIM-Karten-Kniff oder die gezielte ADB-Bereinigung.
Die Mechanik: Wie fünf Byte einen negativen Speicher erzwingen
Die Schwachstelle liegt tief im Android-Telephony-Stack unter frameworks/opt/telephony in der Kernkomponente WapPushOverSms.java. Trifft eine eingehende Daten-PDU auf das Modem, liest die Methode decodeWapPdu() die Header-Länge über pduDecoder.getValue32() als vorzeichenlosen 64-Bit-Wert (uintvar) ein.
Direkt danach leistet sich Android einen fundamentalen Schnitzer: Das System castet diesen Wert ohne jede Plausibilitätsprüfung hart in einen vorzeichenbehafteten 32-Bit-Integer.
// WapPushOverSms.java: Fehlende Bereichsprüfung vor Typumwandlung
int headerLength = (int) pduDecoder.getValue32();
byte[] header = new byte[headerLength]; // wirft NegativeArraySizeException
Schickt der Angreifer die Byte-Folge 88 80 80 80 00, dekodiert die Routine den Hexadezimalwert 0x80000000. Im 32-Bit-Signed-Integer entspricht dieser Wert exakt -2147483648.
Der anschließende Speicheraufruf new byte[-2147483648] wirft auf dem Haupt-Thread der Telefonie sofort eine ungefangene NegativeArraySizeException. Der Prozess com.android.phone stirbt augenblicklich ab und kappt die gesamte Mobilfunkanbindung.
Messprotokoll aus dem Labor: Systemverhalten und Netzbetreiber-Dynamik
In Testreihen mit aktuellen Google Pixel- und Samsung Galaxy-Smartphones lag die Trefferquote des Exploits bei glatten 100 Prozent.
| Messgröße / Parameter | Normalbetrieb | 1 WAP-Push-Paket | Serie (~20 Pakete) |
Status com.android.phone | Aktiv (stabile PID) | Crash & Neustart (1,5 s Ausfall) | Dauerhafter Dienstabsturz |
| Laufende Telefonate | Stabil | Abbruch (CS_DEATH) | Keine Verbindung herstellbar |
| Notruffunktion (112) | Voll verfügbar | Signalverlust | Blockiert durch Recovery-Loop |
| RescueParty-Intervall | Deaktiviert | Keine Aktion | Reboot in Recovery alle ~90 s |
| Benutzeroberfläche | Vollständig | 0 Benachrichtigungen | Stummes Sterben im Hintergrund |
Warteschlange content://sms/raw | Leer | 1 blockierende PDU | Persistente Gift-Einträge |
Besonders perfide ist das Zusammenspiel mit der Netzinfrastruktur: Da das abstürzende Smartphone dem Mobilfunknetz keine Empfangsbestätigung übermitteln kann, liefert das SMS-Center des Providers das Paket tagelang unerbittlich neu aus. Selbst ein Geräteneustart hilft nicht, da die unvollständige Nachricht in der Systemtabelle verharrt und das Parsen bei jedem Systemstart von vorn anstößt.
Notfall-Leitfaden: Bootloop stoppen und Daten retten
Befindet sich ein Smartphone bereits im Wiederherstellungsmodus, verhindert die folgende Reihenfolge den unwiderruflichen Verlust persönlicher Fotos und Dokumente.
1. Physischen SIM-Karten-Trick anwenden
Nimm bei einer physischen SIM-Karte die Karte sofort aus dem betroffenen Android-Gerät und lege diese in ein einfaches Tastentelefon oder ein iPhone ein.
Das Ersatzgerät empfängt das WAP-Push-Paket fehlerfrei, quittiert den Empfang gegenüber dem SMS-Center des Netzbetreibers und stoppt die automatisierte Neuzustellung aus dem Mobilfunknetz sofort.
2. Gift-Pakete per ADB aus dem Speicher tilgen
Um das Gerät aus der lokalen Boot-Schleife zu befreien, verbinde es per USB mit einem PC, auf dem die Android Platform Tools eingerichtet sind. Nutze das kurze Zeitfenster unmittelbar nach dem Start (sys.boot_completed == 1):
- Der Shell temporär Schreibrechte für die SMS-Provider-Datenbank gewähren: Bash
adb shell cmd appops set com.android.shell WRITE_SMS allow - Die blockierenden Rohdaten-Einträge aus der Inbound-Queue löschen: Bash
adb shell "content delete --uri content://sms/raw" - Die Berechtigung der Android-Shell wieder auf den Normalzustand zurücksetzen: Bash
adb shell cmd appops set com.android.shell WRITE_SMS default - Ultima Ratio bei anhaltendem Hänger: Sollte die Tabelle weiterhin blockiert sein, setzt folgender Befehl den gesamten SMS/MMS-Speicher zurück, ohne persönliche Gerätedaten zu löschen: Bash
adb shell pm clear com.android.providers.telephony
3. Patch-Level überprüfen
Navigiere unter Einstellungen zu Sicherheit & Datenschutz > Sicherheitsupdate.
Geräte ab dem Stand 1. Oktober 2026 sind geschützt. Google hat mit Commit 735d967 zwar keine explizite Bereichsprüfung nachgereicht, fängt die Runtime-Exception nun jedoch ab und tilgt fehlerhafte PDUs automatisch aus der Inbound-Warteschlange.
Ein gefährliches Update-Vakuum für Millionen Geräte
Dass eine fehlende Bereichsprüfung über Jahre hinweg unbemerkt im Fundament des meistgenutzten Betriebssystems der Welt überleben konnte, offenbart bedenkliche Lücken im Sicherheitsaudit.
Viel schwerer wiegt jedoch Googles Verteilungspolitik: Das Sicherheitsupdate für Oktober 2026 schützt ausschließlich Android 14, 15, 16 und 17. Die Versionen Android 12 und 13 teilen exakt denselben fehlerhaften Code, erhalten jedoch keinen offiziellen Patch mehr.
Wer ein älteres Modell ohne monatliche Softwarepflege nutzt, bleibt einem lautlosen Angriff schutzlos ausgeliefert – es sei denn, die jeweiligen Mobilfunkbetreiber greifen ein und filtern fehlerhafte WAP-Push-Header direkt auf Vermittlungsebene heraus.
Schmidtis Blog zu Deiner bevorzugten Quelle bei Google hinzufügen
Links mit einem * sind Partner-Links. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalte ich eine kleine Provision. Für euch ändert sich am Preis nichts. Danke für eure Unterstützung!

Durchaus interessanter Artikel, wenn dem wirklich so sein sollte.
Wenn, dann aber bitte mehr Sorgfalt (!!) beim Text (oder KI-texten lassen)!?!?!?
In der Überschrift sind es 8 Byte, im Text 5 Byte … Ja was nun ?
Leider oft genug solche Fauxpas wie z.B. hier …
https://www.schmidtisblog.de/ds-n7-fahrbericht-elektro-suv-test-1818166/
„Übeltäter sind die großflächigen 20-Zoll-Lyrae-Felgen, deren Abrollgeräusche ungedämpft im Innenraum dröhnen…“
Ähm … wirklich, FELGEN verursachen ABROLLGERÄUSCHE ?
Ich dachte bisher, es sind die REIFEN, die ABROLLgeräusche machen.
Vielleicht hilft es ja, auf die Felgen auf Reifen zu montieren, bevor man mit dem Auto fährt?
Felgen machen max. Wind/LuftWirbelgeräusche …
Wie ich bereits sagte, etwa MEHR SORGFALT beim texten!