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

schwarzer Android-Schriftzug und grüner Androide auf weißem Hintergrund
Quelle: Google
Verpasse keine News, folge mir auf WhatsApp, Mastodon oder Google News

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.phone stürzt sofort ab, aktive Anrufe und Notrufe (112) brechen mit dem Status CS_DEATH ab.
  • 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 / ParameterNormalbetrieb1 WAP-Push-PaketSerie (~20 Pakete)
Status com.android.phoneAktiv (stabile PID)Crash & Neustart (1,5 s Ausfall)Dauerhafter Dienstabsturz
Laufende TelefonateStabilAbbruch (CS_DEATH)Keine Verbindung herstellbar
Notruffunktion (112)Voll verfügbarSignalverlustBlockiert durch Recovery-Loop
RescueParty-IntervallDeaktiviertKeine AktionReboot in Recovery alle ~90 s
BenutzeroberflächeVollständig0 BenachrichtigungenStummes Sterben im Hintergrund
Warteschlange content://sms/rawLeer1 blockierende PDUPersistente 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):

  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
  2. Die blockierenden Rohdaten-Einträge aus der Inbound-Queue löschen: Bash adb shell "content delete --uri content://sms/raw"
  3. Die Berechtigung der Android-Shell wieder auf den Normalzustand zurücksetzen: Bash adb shell cmd appops set com.android.shell WRITE_SMS default
  4. 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.

Google bevorzugte Quelle Schmidtis Blog 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!

Ein Kommentar

  1. 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!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert