AppXpose AppXpose
← All posts ← Alle Beiträge
· AppXpose · Machine Learning · Android Privacy · App Audit · Tracker Detection · Fake APK

How machine learning is changing Android security, and what we're building Wie Machine Learning Android-Sicherheit verändert, und was wir bauen

ML detects what static analysis misses. How we train models on real Android scan data to find tracker-permission combos, fake APKs, and cross-app surveillance. ML erkennt, was statische Analyse verpasst. Wie wir Modelle auf echten Android-Scandaten trainieren, um Tracker-Kombis, Fake-APKs und App-Spionage zu finden.

Static analysis is good at finding things you already know about. You write a signature for Facebook’s ad SDK, you match it against DEX bytecode, you report it. It works. It’s what AppXpose has done since day one, and it catches the majority of embedded trackers on any given phone.

But static analysis has a ceiling. It only finds what you told it to look for. An obfuscated SDK that renames its classes every release will slip through. A repackaged APK that swaps the signing certificate but keeps the same code will look identical. A network of apps that share data through a common backend, not a common SDK, won’t trigger any signature at all.

That’s where machine learning comes in. Not as a replacement for static analysis, but as a second layer that learns from patterns the signature matcher cannot see. If you want to understand how traditional spyware detection on Android works, that’s the baseline ML builds on.

What we shipped this week

AppXpose now includes five detection systems that sit alongside the existing DEX tracker scanner:

APK Integrity Checker runs entirely on your device, parallel to the tracker scan. It inspects DEX headers (magic bytes, endian tags, link fields), signing blocks, native libraries, and file structures. It detects hooking frameworks (Cydia Substrate, Whale/LSPosed, ADBI, BDHook), root tools (su, supersu, busybox, resetprop), debug artifacts (gdbserver, lldb-server, ida.key), repackaging indicators (patched DEX files, original classes backups), and known packer signatures (Jiagu, DexProtector, Bangcle). Findings are severity-classified from LOW to CRITICAL.

MalwareBazaar Hash Lookup takes the SHA256 hash of every scanned APK and checks it against abuse.ch’s open malware database. If the hash matches a known malicious sample, the risk score jumps to CRITICAL. This is a simple but powerful check: it costs nothing, adds no latency (runs parallel to other server calls), and catches every APK that has already been reported by the security community.

Koodous Threat Intelligence checks the same APK hash against Koodous, a community-driven Android threat intelligence platform with millions of analyzed samples. It runs in parallel with MalwareBazaar, so two independent malware databases are queried simultaneously without adding latency. A Koodous detection adds +13 to the risk score.

AppXpose CertNet is our own crowd-sourced database of signing certificates. Every scan that passes through AppXpose stores the app’s signing cert hash in a central ledger. When a second user scans the same app, we compare certs. If they don’t match, one of the two versions was re-signed, which is one of the strongest indicators of a repackaged or counterfeit APK. We seeded CertNet with 4,700+ verified certs from F-Droid, and it grows with every scan.

Community APK Hash Verification is a crowd-sourced APK hash database. Every scan contributes the app’s SHA256 hash. Once 7+ distinct devices report the same hash for a package version, it becomes the verified baseline. If your APK hash differs from the community consensus, the app was likely tampered with or repackaged.

These five systems are deterministic. They don’t use machine learning. They use structural analysis, hash comparison, and certificate verification. They’re the foundation.

What we’re training next

Two ML models are in active development on the corpus of scans we already have:

Tracker Permission Linker (M01) learns which Android permissions statistically co-occur with which tracker SDKs. The hypothesis: certain permission-SDK combinations are suspicious even when the SDK itself is obfuscated beyond recognition. If an app requests READ_CONTACTS and RECORD_AUDIO and contains a class structure that matches the shape of an attribution SDK (even without a recognizable package name), the model flags it. This is useful precisely in the cases where the static signature matcher fails.

The training data comes from AppXpose’s own scan corpus. Every scan records the full permission list, the matched trackers, the unmatched suspicious classes, and the obfuscation status. Over time, the model learns which combinations are normal (a messaging app with contacts + camera + a known analytics SDK) and which are anomalous (a flashlight app with contacts + audio + an unrecognized SDK that structurally resembles an ad network).

Behavioural Pattern Recognizer (M02) works at a higher level. Instead of analyzing one app at a time, it looks across the entire corpus for non-obvious relationships: apps from different developers that share the same backend servers. Apps that use the same rare SDK combination. Apps whose permission profiles are statistically identical despite claiming to be in different categories. The output is a graph of the surveillance ecosystem that no single-app scanner can produce.

This is the model we’re most excited about, and the one that needs the most data to be useful. Every scan makes it marginally smarter.

Why this matters for users

Most Android security tools today are reactive. They maintain a list of known threats and check against it. If a threat isn’t on the list, it doesn’t exist. ML changes that dynamic by introducing pattern recognition that generalizes beyond the training set.

A concrete example: if a new attribution SDK appears on the market next month with a fresh package name and no public documentation, the static matcher will miss it entirely. But if that SDK requests the same permissions, uses the same class structure, and co-occurs with the same companion libraries as three known attribution SDKs, the Tracker Permission Linker will flag it as “structurally similar to known trackers” before any human analyst writes a signature for it.

That’s not a replacement for signatures. It’s an early warning system that buys time until the signatures catch up.

The data question

ML models are only as good as their training data, and training data in the mobile security space is surprisingly hard to come by. Most datasets are either:

  1. Academic (large but restricted, like AndroZoo, which is limited to research institutions and prohibits commercial use)
  2. Commercial (VirusTotal, which is owned by Google and gated behind expensive enterprise tiers)
  3. Outdated (public malware sample collections that represent threats from 3+ years ago)

AppXpose is in an unusual position: every user who scans an app contributes a datapoint to the corpus. Our full research data from 3,745 analyzed apps shows the scale of what we’re working with. Not personal data (we don’t collect any), but structural data: which classes exist, which permissions are requested, which trackers are present, whether the APK is obfuscated, what the signing certificate looks like. That structural data, aggregated across thousands of scans, is exactly what the ML models need.

The more people scan, the smarter the models get. And the smarter the models get, the more useful the scans become. It’s a flywheel that doesn’t require us to buy datasets or scrape third-party sources. The data comes from the product itself. This is also why we’re committed to making our detection pipeline open source.

What’s next

The Tracker Permission Linker is closest to shipping. We expect it to be in production within the next few app updates, initially as a secondary signal alongside the static matcher (not replacing it). The Behavioural Pattern Recognizer needs more data before it produces actionable results. We’re giving it time rather than rushing a model that flags false positives.

Both models will be documented on our methodology page before they ship, the same way we documented the 10 pre-score factors and the detection pipeline. If you can’t read how the model works, you shouldn’t trust its output.

Every scan helps. If you haven’t scanned your phone recently, now would be a good time. Try starting with a popular app like WhatsApp to see the detection pipeline in action.

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.