Wie AppXpose
wirklich funktioniert.
Datenschutz-Versprechen sind leicht gemacht und schwer zu verifizieren. Diese Seite dokumentiert die komplette Pipeline: jeden Schritt, jeden Scoring-Faktor, jede Datenquelle und alles, was wir nicht anfassen. Wenn hier etwas falsch ist, schreib an mahere@appxpose.app und wir korrigieren es.
Du wählst eine App
AppXpose listet jede auf deinem Gerät installierte App über die Android PackageManager API. Du tippst eine an. Vorher passiert nichts.
Wir entpacken die APK lokal
Der PackageManager liefert uns den Dateipfad der installierten APK. Wir lesen den DEX-Bytecode und das AndroidManifest im selben Prozess auf Dispatchers.IO. Die Bytes verlassen dein Handy nie.
Abgleich mit bekannten Tracker-Signaturen
Klassennamen und Paket-Pfade werden gegen ein kuratiertes Signatur-Set geprüft (Quelle: Exodus Privacy, eigene Ergänzungen und community-entdeckte Patterns). Transitive Dependencies von Parent-SDKs werden dedupliziert, sodass die Zählung tatsächlich eigenständige Tracker widerspiegelt. Das ist deterministisches Pattern Matching, keine KI. Siehe II. Erkennungs-Methodik unten.
Erst deterministisch scoren, dann KI-Analyse
Die lokalen Ergebnisse gehen (HMAC-signiert, an einen Geräte-Fingerprint gebunden, ohne Namen oder Konto) an unsere Cloudflare Edge. Ein deterministischer Pre-Score wird aus mehreren Risikofaktoren berechnet. Dann erzeugt ein LLM das finale Score-Breakdown, das Entwickler-Profil, die Paywall-Analyse und die natürlichsprachlichen Erklärungen. Siehe III. Risk-Scoring-Modell.
Du bekommst einen Score und eine Geschichte
Nicht nur eine Zahl. Was gefunden wurde, warum es zählt, wer die App gemacht hat, wohin die Daten fließen und was sich seit dem letzten Scan geändert hat. Du kannst den Report speichern, teilen oder für die Community abstimmen.
Alles landet im App-Index
Jedes Scan-Ergebnis wird in einer lokalen Datenbank gespeichert — Risikobewertungen, Tracker-Listen, Berechtigungs-Audits, alles mit Zeitstempel. Der App-Index lässt dich deine installierten Apps an einem Ort durchsuchen, finden und vergleichen. Filtere nach Risikostufe, sortiere nach letztem Scan-Datum, erkenne welche Apps sich über die Zeit verschlechtert haben. Sie verwandelt einzelne Scans in ein strukturiertes Protokoll dessen, was auf deinem Gerät läuft.
Wie wir Tracker im Bytecode finden.
Die Tracker-Erkennung in AppXpose ist deterministisches Pattern Matching, keine KI. Das LLM entscheidet nie, ob ein Tracker vorhanden ist. Eine Signatur trifft entweder zu oder nicht.
Signatur-Quellen
Match-Typen
- →Paket-Pfad-Präfix: z. B.
com.facebook.appevents,com.adjust.sdk. Wenn eine Klasse im DEX mit diesem Pfad beginnt, ist das ein Match. Jede Signatur wird beim App-Start zu einem Regex kompiliert. - →Präfix-Deduplizierung: wenn ein Parent-SDK (z. B.
com.google.android.gms.ads) matched, werden Sub-Packages wiecom.google.android.gms.ads.doubleclicknicht separat gezählt. Bekannte transitive Dependencies (z. B. Firebase Analytics, das durch AdMob reinkommt) werden unterdrückt, wenn der Parent bestätigt ist. - →Erkennung verdächtiger Klassen: Klassen, die wie SDKs aussehen, aber keine bekannte Signatur matchen, werden gemeldet und an den Server zur community-basierten Entdeckung gesendet (siehe unten).
Community-Tracker-Entdeckung
Jeder Scan trägt zum Wachstum der Signatur-Datenbank bei. Wenn der DEX-Scanner Klassen findet, die wie Third-Party-SDKs aussehen, aber keine bekannte Signatur matchen, werden sie anonym an den Server gemeldet. Sobald derselbe unbekannte Klassen-Präfix in 3 oder mehr verschiedenen Paketen von verschiedenen Geräten auftaucht, wird er automatisch als neue Tracker-Signatur bestätigt. Bestätigte Signaturen werden täglich über einen Background-Worker an alle Geräte synchronisiert — kein App-Update nötig. Das bedeutet: die Detection-Engine wird mit jedem Scan der Community besser.
Hinweis: Geschätzte Tracker-Informationen in der KI-Analyse nutzen LLM-Wissen und sind immer mit „(geschätzt)" markiert. Nur DEX-verifizierte Tracker werden ohne Einschränkung gemeldet.
Zwei-Phasen-Scoring: erst deterministisch, dann KI.
Phase 1: Deterministischer Pre-Score
Bevor das LLM überhaupt Daten sieht, läuft eine deterministische Scoring-Funktion auf dem Server. Sie bewertet mehrere Risiko-Signale: Berechtigungs-Analyse (kontext-abhängig über 45 Play-Store-Kategorien), Update-Historie, Installationsquelle, APK-Integrität, Breach-Historie, Tracker-Präsenz, Signing-Zertifikats-Verifikation und Abgleich gegen Known-Malware-Datenbanken. Positive Signale (saubere Historie, keine Tracker, aktuelle Updates) reduzieren den Score.
Der Pre-Score erzeugt eine Baseline von 0 bis 100. Risiko-Stufen: LOW (0-29), MEDIUM (30-59), HIGH (60-79), CRITICAL (80-100). Die genauen Gewichtungen und Schwellenwerte sind Teil unserer proprietären Scoring-Engine und werden mit der Detection-Engine Open Source gehen.
Kontext-abhängiges Scoring
Berechtigungen, die in einer Kategorie normal sind, sind in einer anderen verdächtig. Eine Wetter-App, die nach Standort fragt, wird anders bewertet als eine Taschenlampe, die dasselbe verlangt. Unsere Scoring-Engine mappt erwartete Berechtigungen über 45 Play-Store-Kategorien und passt das Risiko entsprechend an. Dieses Mapping wird kontinuierlich durch eine datengetriebene Baseline verfeinert, die aus echten Scan-Daten lernt.
Phase 2: KI-gestützte Analyse
Der Pre-Score und alle Rohdaten (Berechtigungen, Tracker, Breach-Status, App-Metadaten) gehen an ein LLM, das das nutzerseitige Breakdown erzeugt. Das LLM produziert sechs Kategorie-Scores, die in der App sichtbar sind:
- Bekannte Datensammel-Praktiken
- Mutterkonzern & geopolitisches Risiko
- Geschätzte Tracker & Werbenetzwerke
- Verschlüsselung & Datenübertragung
- Update-Frequenz & Patch-Verhalten
- Regulatorische Compliance & Transparenz
Das LLM erzeugt zusätzlich: das Entwickler-Profil (Firma, Server-Standorte, DSGVO-Lage), die Paywall- und Monetarisierungs-Analyse, die Wahrscheinlichkeits-Schätzungen für Daten-Weitergabe und die natürlichsprachlichen Erklärungen neben jedem Befund. Alle KI-geschätzten Daten sind in der App explizit mit „(geschätzt)" markiert.
KI erzeugt
- → Risk-Score-Breakdown (6 Kategorien)
- → Paywall- und Monetarisierungs-Analyse
- → Entwickler-Profil (Firma, Server, DSGVO)
- → Wahrscheinlichkeits-Schätzungen zur Daten-Weitergabe
- → Natürlichsprachliche Erklärungen
- → Alles mit „(geschätzt)" markiert, wo zutreffend
KI macht nicht
- → Tracker erkennen (das ist Pattern Matching)
- → Breaches prüfen (das ist HIBP)
- → Berechtigungen auflisten (das ist die Android-API)
- → Inhalte oder Daten deiner Apps lesen
- → Außerhalb des Scans auf dein Gerät zugreifen
- → Die finale Tracker-Zahl bestimmen (das macht DEX)
Wir erfassen nie
- E-Mail-Adressen oder Accounts
- Google Advertising ID (AppXpose selbst liest sie nie; AdMob kann sie für Free-Nutzer lesen, die freiwillig eine Rewarded Ad anschauen)
- IMEI, Telefonnummer, SIM-Daten
- Standort, Kontakte, Fotos
- App-Inhalte oder Nachrichten
- Persistente Kennungen über Neuinstallationen hinweg
Wir erfassen sehr wohl
- Geräte-Fingerprint-Hash (rotiert bei Neuinstallation)
- Quota-Zähler (5 Scans/Woche im Free-Tier)
- Anonyme Community-Stimmen (keine Autor-Identität)
- Scan-Rohdaten für ML-Training (Paketname, Berechtigungen, Tracker-Matches, verdächtige Klassen — keine persönlichen Daten, dient der Verbesserung der Erkennungsgenauigkeit)
- APK-Signing-Zertifikat-Hashes (für CertNet Trust-on-First-Use-Verifikation)
Alles zwischen Handy und Edge läuft über HTTPS plus HMAC-SHA256. Der HMAC-Key ist ein serverseitiges Secret, das unabhängig von App-Updates rotiert werden kann — mit einer Grace Period, in der alter und neuer Key gleichzeitig akzeptiert werden. Der „Geräte-Fingerprint" ist ein Einweg-Hash stabiler Hardware-Merkmale. Er lässt sich nicht zu einer Person zurückrechnen und wird bei Neuinstallation oder Werksreset zurückgesetzt.
Closed Source. Hier ist warum, und wann sich das ändert.
AppXpose ist ein Solo-Projekt, das noch in heftiger Entwicklung steckt. Die Scan-Pipeline wurde in den letzten Monaten mehrfach umgeschrieben, sobald neue Erkennungs-Ansätze aufgetaucht sind. Den Code heute zu veröffentlichen, hieße ein bewegliches Ziel zu veröffentlichen, das nächste Woche kaputt ist. Das ist für niemanden nützlich.
Der Plan: sobald die Schnittstellen der Detection-Engine stabil sind (das Signatur-Format, die Eingaben des Scoring-Modells, die Pipeline-Grenzen), wird die Engine geöffnet. Nicht die ganze App, sondern der Teil, der zählt: die Komponente, die Bytecode liest und entscheidet, was ein Tracker ist. Das ist der Teil, den die Community auditieren, hinterfragen und verbessern können sollte.
Bis dahin dokumentiert diese Seite alles, was der Code tut, und wie. Der Code ist geschlossen. Die Methodik nicht. Wenn du eine Lücke in dieser Dokumentation findest, schreib uns, und wir schließen sie.
Was übersehen?
Sicherheits-Behauptungen sollten widerlegbar sein. Wenn du eine Lücke in dieser Methodik siehst, einen Faktor, den wir nicht berücksichtigen, oder eine Aussage, die nicht der Realität entspricht, sag uns Bescheid. Wir korrigieren es und erwähnen dich in den nächsten Release Notes.
mahere@appxpose.app