Statische Analyse ist gut darin, Dinge zu finden, von denen du bereits weißt. Du schreibst eine Signatur für Facebooks Werbe-SDK, du matchst sie gegen DEX-Bytecode, du meldest sie. Es funktioniert. Es ist das, was AppXpose seit Tag eins macht, und es erfasst die Mehrheit der eingebetteten Tracker auf jedem beliebigen Handy.

Aber statische Analyse hat eine Decke. Sie findet nur, was du ihr zu suchen aufgetragen hast. Ein verschleiertes SDK, das seine Klassen bei jedem Release umbenennt, rutscht durch. Eine umgepackte APK, die das Signatur-Zertifikat tauscht, aber denselben Code behält, sieht identisch aus. Ein Netzwerk von Apps, die Daten über ein gemeinsames Backend statt über ein gemeinsames SDK teilen, löst gar keine Signatur aus.

Hier kommt Machine Learning ins Spiel. Nicht als Ersatz für statische Analyse, sondern als zweite Schicht, die aus Mustern lernt, die der Signatur-Matcher nicht sehen kann.

Was wir diese Woche ausgeliefert haben

v5.7.0 von AppXpose enthält drei neue Erkennungssysteme, die parallel zum bestehenden DEX-Tracker-Scanner laufen:

APK Integrity Checker liest die rohe Struktur jeder APK-Datei. DEX-Header-Größen, Endian-Tags, Link-Field-Werte, Signing Blocks, Native-Library-Namen. Über 15 Muster, adaptiert vom APKiD-Projekt. Wenn ein Header manuell manipuliert wurde oder ein bekanntes Packer-Tool (Jiagu, DexProtector, Bangcle) seinen Fingerabdruck in der Datei hinterlassen hat, schlägt der Checker Alarm. Das läuft komplett auf deinem Gerät, parallel zum Tracker-Scan, in unter 100 ms.

MalwareBazaar Hash Lookup nimmt den SHA256-Hash jeder gescannten APK und prüft ihn gegen die offene Malware-Datenbank von abuse.ch. Wenn der Hash mit einem bekannten bösartigen Sample übereinstimmt, springt der Risiko-Score auf KRITISCH. Das ist eine einfache, aber mächtige Prüfung: Sie kostet nichts, fügt keine Latenz hinzu (läuft parallel zu anderen Server-Aufrufen) und erfasst jede APK, die bereits von der Sicherheits-Community gemeldet wurde.

AppXpose CertNet ist unsere eigene crowd-sourced Datenbank von Signatur-Zertifikaten. Jeder Scan, der durch AppXpose läuft, speichert den Signatur-Cert-Hash der App in einem zentralen Ledger. Wenn ein zweiter Nutzer dieselbe App scannt, vergleichen wir die Zertifikate. Wenn sie nicht übereinstimmen, wurde eine der beiden Versionen nachsigniert, was einer der stärksten Indikatoren für eine umgepackte oder gefälschte APK ist. Wir haben CertNet mit über 4.200 verifizierten Zertifikaten von F-Droid geseedet, und es wächst mit jedem Scan.

Diese drei Systeme sind deterministisch. Sie nutzen kein Machine Learning. Sie nutzen Pattern Matching, Hash-Vergleich und Zertifikats-Verifikation. Sie sind das Fundament.

Was wir als nächstes trainieren

Zwei ML-Modelle sind in aktiver Entwicklung auf dem Korpus von Scans, den wir bereits haben:

Tracker Permission Linker (M01) lernt, welche Android-Berechtigungen statistisch mit welchen Tracker-SDKs zusammen auftreten. Die Hypothese: Bestimmte Berechtigungs-SDK-Kombinationen sind verdächtig, selbst wenn das SDK selbst bis zur Unkenntlichkeit verschleiert ist. Wenn eine App READ_CONTACTS und RECORD_AUDIO anfordert und eine Klassenstruktur enthält, die der Form eines Attribution-SDKs ähnelt (auch ohne erkennbaren Paketnamen), markiert das Modell sie. Das ist genau in den Fällen nützlich, in denen der statische Signatur-Matcher versagt.

Die Trainingsdaten kommen aus AppXposes eigenem Scan-Korpus. Jeder Scan zeichnet die vollständige Berechtigungsliste, die gematchten Tracker, die unmatched verdächtigen Klassen und den Verschleierungs-Status auf. Mit der Zeit lernt das Modell, welche Kombinationen normal sind (eine Messaging-App mit Kontakten + Kamera + einem bekannten Analyse-SDK) und welche anomal sind (eine Taschenlampen-App mit Kontakten + Audio + einem unerkannten SDK, das strukturell einem Werbenetzwerk ähnelt).

Behavioural Pattern Recognizer (M02) arbeitet auf einer höheren Ebene. Statt eine App nach der anderen zu analysieren, schaut er über den gesamten Korpus nach nicht-offensichtlichen Beziehungen: Apps von verschiedenen Entwicklern, die dieselben Backend-Server teilen. Apps, die dieselbe seltene SDK-Kombination nutzen. Apps, deren Berechtigungsprofile statistisch identisch sind, obwohl sie behaupten, in unterschiedlichen Kategorien zu sein. Das Ergebnis ist ein Graph des Überwachungs-Ökosystems, den kein Single-App-Scanner produzieren kann.

Das ist das Modell, auf das wir am meisten gespannt sind, und das, das die meisten Daten braucht, um nützlich zu sein. Jeder Scan macht es ein kleines bisschen schlauer.

Warum das für Nutzer wichtig ist

Die meisten Android-Sicherheits-Tools heute sind reaktiv. Sie pflegen eine Liste bekannter Bedrohungen und prüfen dagegen. Wenn eine Bedrohung nicht auf der Liste steht, existiert sie nicht. ML verändert diese Dynamik, indem es Mustererkennung einführt, die über das Trainingsset hinaus generalisiert.

Ein konkretes Beispiel: Wenn nächsten Monat ein neues Attribution-SDK mit frischem Paketnamen und ohne öffentliche Dokumentation auf dem Markt erscheint, wird der statische Matcher es komplett übersehen. Wenn dieses SDK aber dieselben Berechtigungen anfordert, dieselbe Klassenstruktur nutzt und mit denselben Begleit-Bibliotheken zusammen auftritt wie drei bekannte Attribution-SDKs, wird der Tracker Permission Linker es als „strukturell ähnlich zu bekannten Trackern” markieren, bevor irgendein menschlicher Analyst eine Signatur dafür schreibt.

Das ist kein Ersatz für Signaturen. Es ist ein Frühwarnsystem, das Zeit kauft, bis die Signaturen aufgeholt haben.

Die Datenfrage

ML-Modelle sind nur so gut wie ihre Trainingsdaten, und Trainingsdaten im Bereich Mobile Security sind überraschend schwer zu bekommen. Die meisten Datensätze sind entweder:

  1. Akademisch (groß, aber eingeschränkt, wie AndroZoo, das auf Forschungseinrichtungen begrenzt ist und kommerzielle Nutzung verbietet)
  2. Kommerziell (VirusTotal, das Google gehört und hinter teuren Enterprise-Stufen verriegelt ist)
  3. Veraltet (öffentliche Malware-Sample-Sammlungen, die Bedrohungen von vor mehr als 3 Jahren repräsentieren)

AppXpose ist in einer ungewöhnlichen Position: Jeder Nutzer, der eine App scannt, trägt einen Datenpunkt zum Korpus bei. Keine persönlichen Daten (wir erheben keine), aber strukturelle Daten: welche Klassen existieren, welche Berechtigungen angefordert werden, welche Tracker vorhanden sind, ob die APK verschleiert ist, wie das Signatur-Zertifikat aussieht. Diese strukturellen Daten, aggregiert über tausende von Scans, sind genau das, was die ML-Modelle brauchen.

Je mehr Leute scannen, desto schlauer werden die Modelle. Und je schlauer die Modelle werden, desto nützlicher werden die Scans. Es ist ein Schwungrad, das nicht erfordert, dass wir Datensätze kaufen oder Drittquellen scrapen. Die Daten kommen aus dem Produkt selbst.

Was als nächstes kommt

Der Tracker Permission Linker ist am nächsten dran, ausgeliefert zu werden. Wir erwarten, dass er innerhalb der nächsten paar App-Updates in Produktion geht, zunächst als sekundäres Signal neben dem statischen Matcher (nicht als Ersatz). Der Behavioural Pattern Recognizer braucht mehr Daten, bevor er handlungsfähige Ergebnisse produziert. Wir geben ihm Zeit, statt ein Modell zu überstürzen, das False Positives meldet.

Beide Modelle werden auf unserer Methodik-Seite (appxpose.app/how-it-works) dokumentiert, bevor sie ausgeliefert werden, genauso wie wir die 10 Pre-Score-Faktoren und die Erkennungs-Pipeline dokumentiert haben. Wenn du nicht lesen kannst, wie das Modell funktioniert, solltest du seinem Output nicht vertrauen.

Jeder Scan hilft. Wenn du dein Handy in letzter Zeit nicht gescannt hast, wäre jetzt ein guter Zeitpunkt.