1. Module in Apps
George Burns konnte sich
noch an die Zeit erinnern, als die Luft sauber und Sex schmutzig war.
Ich kann mich noch an die Zeit erinnern, als eine Android-App mit 200 kB als »riesiges Monster« empfunden wurde. Heutzutage sind wir schon froh, wenn die Größe im einstelligen Megabyte-Bereich bleibt.
Woher kommt aber dieses immense Wachstum? Ein häufiger Grund ist die Verwendung von Frameworks und Bibliotheken, die teils recht umfangreich ausfallen. So wird etwa eine in Flutter oder React Native geschriebene App selten kleiner als 5 Megabyte ausfallen, da allein schon die »nativen« Basis-Bibliotheken hier mehrere Megabyte umfassen.
Viele dieser Bibliotheken (Module) stellen häufig verwendete Funktionalitäten zur Verfügung – etwa für das Logging, für Netzwerk-Zugriffe, für die Gestaltung von Buttons, Widgets, Lade-Bildschirmen, Datums-, Sprach- oder Farbauswahl, das Anzeigen von Listen oder Bildern, die Erfassung von Daten mittels Formularen, und so weiter. Eine gute Sache – da Entwickler sich somit auf die eigentliche Funktionalität ihrer App konzentrieren können, und nicht das Rad ständig neu erfinden müssen.
Allerdings gibt es da auch noch »unschöne« Bibliotheken, die Funktionalitäten mitbringen, die sich negativ auf die Sicherheit und Privatsphäre der Nutzer auswirken. Im vorliegenden Beitrag zeige ich euch, wie ihr diese Tracking- und Werbemodule aufspürt.
Gastbeitrag von Andreas Itzchak Rehberg
Itzchak, auch bekannt als IzzyOnDroid, betreibt sein eigenes F-Droid Repository, bietet Schulungen und Workshops an und ist freier Autor für das ct Magazin.Feedback und Fragen können direkt an ihn gerichtet werden. Er freut sich auch über Spenden für seine Arbeit.
2. Danaer, die Geschenke bringen
[…] timeo Danaos et dona ferentes. [Übersetzt: Ich fürchte die Danaer, auch wenn sie Geschenke tragen.]
sagt Vergils Priester Laokoon in der Aeneis.
Im Deutschen auch gern mit »Hüte dich vor Griechen, die Geschenke bringen« wiedergegeben. War es seinerzeit das Holzpferd, welches die Griechen nach dem Rat Odysseus den Tojanern zum »Geschenk« machten, muss heute leider auch so manche App aus Googles Play Store als »trojanisches Pferd« bezeichnet werden. Etwa haushoch bewertete »Antivirus-Apps«, die im Hintergrund Pornos surfen. Oder weitere Apps des gleichen Herstellers, die unter der Haube Werbebetrug betreiben. Millionenfach heruntergeladen, mit Bewertungen oberhalb der 4,5 Sterne – und nach wie vor im Google Play Store verfügbar (sowie auf etlichen Samsung-Geräten vorinstalliert).
App-Reviews auf etablierten Portalen gehen (mit wenigen Ausnahmen) nur auf Oberflächliches und Vordergründiges ein – etwa wie ansprechend eine App gestaltet ist, welch immensen Funktionsumfang sie mitbringt – oder wie sie uns Wünsche erfüllt, von denen wir noch gar nicht wussten, dass wir sie hatten. Convenience und so. Was hinter den Kulissen passiert, erfährt man dort selten. Die Frage, wie es um die Sicherheit der eigenen Daten bestellt ist, bleibt in der Regel unbeantwortet – und zwar nicht nur in Bezug auf besagte Hintergrund- oder besser »Untergrund-Aktivitäten«, sondern auch bezüglich der Datenübertragung und -speicherung selbst:
- Werden die Daten verschlüsselt übertragen und gespeichert?
- Wo werden sie gespeichert?
- Wer hat noch alles Zugriff darauf?
- Und welche Daten sind überhaupt betroffen?
3. Gefahrenzone: Tracker inside!
Leser des Kuketz-Blogs denken da natürlich sofort an Portale wie Exodus Privacy oder den AppCheck von MobilSicher. Beide bieten Anwendern die Möglichkeit, einen Blick in das Innere von Apps zu werfen und zu erfahren, ob dort bekannte Gefahren lauern. Und erfährt so etwa, dass die Wecker-App Alarmy nicht etwa deswegen ca. 250 MB groß ist, weil da Musik drin ist – sondern weil sie u. a. mindestens 26 Tracker enthält! Darunter etwa 10 Analytics-Module und 10 Werbe-Module. Natürlich ausschließlich zur Verbesserung der »User Experience« integriert…
Der nachfolgende Screenshot listet die am häufigsten verbauten Tracker innerhalb Apps auf:
Exodus Privacy fahndet dabei lediglich nach bekannten Trackern – und ihr könnt einen Scan für nicht vorhandene Apps (oder solche mit veralteten Ergebnissen) auch selbst anstoßen. Bei MobilSicher findet ihr hingegen teilweise sehr detaillierte Berichte über das Verhalten der jeweiligen App. Um nochmal auf Wecker-Apps zurückzukommen: Mit der »Wecker-für-mich-App« geht ein hohes Privatsphäre-Risiko einher, da sie teils recht persönliche Daten an nicht weniger als 12 Drittanbieter überträgt und dabei sogar unverschlüsselte Verbindungen nutzt – der Datenverkehr ist also für Dritte ohne viel Aufwand einsehbar.
Bei MobilSicher könnt ihr übrigens ebenfalls Apps zur Prüfung vorschlagen. Beide Teams findet ihr auch im Fediverse:
Insbesondere wer sich Apps aus dem Google Play Store besorgt, sollte daher vor der Installation bei diesen beiden vorbeischauen. Was den Zweien noch gemein ist: Sie können nur frei verfügbare Apps aus dem Play Store und von F-Droid scannen – Bezahl-Apps und Apps mit regionaler Beschränkung bleiben leider außen vor, ebenso wie Apps aus anderen Quellen. Im Play Store selbst (und ebenso bei den meisten anderen Quellen) sucht man solche Angaben leider vergeblich, bei F-Droid kommt derartiges Gefahrengut entweder gar nicht erst hinein, oder ist zumindest mit einem entsprechenden Etikett versehen (Anti-Features wie »Ads« oder »Tracking« – wobei hier die verwendeten Bibliotheken zumindest FOSS, also Free und Open Source sein müssen, sodass das Verhalten nachvollziehbar bleibt). Im IzzyOnDroid Repo findet ihr beides, die Anti-Features sowie alle identifizierten Bibliotheken – und natürlich auch den Betreiber im Fediverse, @IzzyOnDroid@floss.social.
Nicht im Fokus sind bei beiden (andere) proprietäre Bestandteile von Apps. Proprietär heißt in diesem Zusammenhang: Der Quellcode ist nicht (öffentlich) einsehbar. Wer kann also sagen, was diese Module in der Praxis tun – außer dem, was uns ihre Hersteller versprechen? Nicht einmal der Anbieter der jeweiligen App kann garantieren, dass dabei alles mit rechten Dingen zugeht. Wie auch? Hier muss der Nutzer also nicht nur dem Anbieter der App, sondern auch denen der entsprechenden Module vertrauen. Timeo Danaos:
Diese Module werden großteils von Werbefirmen (allen voran Google) gratis angeboten. Ein Schelm…
Was also tun, wenn eine App bei keiner der genannten Quellen zu finden ist – und/oder man auch bezüglich »proprietärer Bestandteile« informiert sein möchte? Kann man irgendwie selbst herausfinden, was »drin steckt«?
4. Library Scanner to the rescue!
Ein freies Werkzeug, mit dem man selbst eine Prüfung durchführen kann, ist Apktool. Es ist in Java geschrieben – für die Ausführung benötigt man daher eine Java Runtime (JRE oder JDK). Aus dem verlinkten Github-Repo kann man sich die .jar-Datei sowie das zugehörige Shell- bzw. Batch-Skript herunterladen. Ein Aufruf von
./apktool d DateiName.apk
zerlegt sodann die APK-Datei in ihre Bestandteile, welche im gleichnamigen Verzeichnis (ApkName/) abgelegt werden. Das Unterverzeichnis ApkName/smali lässt sich nun nach den enthaltenen Bibliotheken durchforsten – so man weiß, wonach man sucht. So würden sich beispielsweise die Google Mobile Services am Namen AppName/smali/com/google/android/gms erkennen lassen.
Auf diese Weise eine Analyse vornehmen zu wollen, wäre recht umständlich und aufwändig. Leichter ginge es vonstatten, hätte man eine Liste dieser Verzeichnis-Pfade einschließlich ihrer Zuordnung zur entsprechenden Bibliothek – sowie ein Skript, welches das Mapping automatisch vornimmt. Und genau das macht der auch bei F-Droid (und IzzyOnDroid) im Einsatz befindliche »APK Library Scanner«. Zusätzlich zu Apktool setzt dieser die Kommandozeilen-Version von PHP sowie dessen JSON-Unterstützung voraus – und bringt die ein- bis zweimal monatlich aktualisierten Library-Definitionen sowie ein passendes Wrapper-Skript mit. Installation und Nutzung beschreibe ich hier unter einem Debian-basierten Linux.
# Installation der benötigten Pakete sudo apt install php-cli php-json # clonen des Git-Repos git clone https://gitlab.com/IzzyOnDroid/repo.git # Apktool bereitstellen mkdir -p repo/lib/radar/tool cd repo/lib/radar/tool wget -q https://github.com/iBotPeaches/Apktool/releases/download/v2.6.1/apktool_2.6.1.jar wget -q https://github.com/iBotPeaches/Apktool/raw/master/scripts/linux/apktool ln -s apktool_2.6.1.jar apktool.jar chmod u+x apktool # Alias für den einfacheren Aufruf erstellen cd ../../../bin alias scanapk="$(pwd)/scanapk.php"
Jetzt ist der APK Library Scanner einsatzbereit – und wir können beliebige APK-Dateien scannen. Unabhängig von ihrer Quelle. Also zum Beispiel
scanapk com.nagopy.android.aplin_28.apk:
Libraries detected: ------------------- * Android Support v4 (/android/support/v4): Development Framework, Apache-2.0 * Android Support v7 (/android/support/v7): Development Framework, Apache-2.0 * Google Ads (/com/google/ads): Advertisement, LicenseUnknown; Ads * Doubleclick (/com/google/android/gms/ads/doubleclick): Advertisement, Proprietary; Ads,NonFreeDep * Google Mobile Services (/com/google/android/gms): Development Framework, Proprietary; NonFreeDep * Firebase (/com/google/firebase): Utility, LicenseUnknown; NonFreeNet,NonFreeDep * Firebase Analytics (/com/google/firebase/analytics): Mobile Analytics, LicenseUnknown; Tracking * Dagger (/dagger): Utility, Apache-2.0 * RxJava (/io/reactivex): Utility, Apache-2.0 * JavaX Dependency Injection (/javax/inject): Utility, Apache-2.0 * Kotlin (/kotlin): Utility, Apache-2.0 * Reactive Streams (/org/reactivestreams): Utility, MIT * Timber (/timber/log): Utility, Apache-2.0 Offending libs: --------------- * Google Ads (/com/google/ads): Ads * Doubleclick (/com/google/android/gms/ads/doubleclick): Ads,NonFreeDep * Google Mobile Services (/com/google/android/gms): NonFreeDep * Firebase (/com/google/firebase): NonFreeNet,NonFreeDep * Firebase Analytics (/com/google/firebase/analytics): Tracking 5 offenders.
Das Skript hat hier Apktool aufgerufen, um die APK-Datei zu zerlegen – und dann sogleich die erzeugte Verzeichnis-Struktur mit den Library-Definitionen abgeglichen. Das Resultat wird direkt im Terminal ausgegeben, wobei für jede identifizierte Bibliothek folgende Informationen ausgegeben werden:
- deren Name
- die ID (entspricht dem Basis-Pfad)
- die Klassifizierung (z. B. »Mobile Analytics«)
- unter welcher Lizenz die Bibliothek steht (soweit bekannt) – sowie ggf. die zutreffenden »Anti-Features«
- Kritische Module (Tracker, Werbung, proprietäre Bibliotheken) werden zum Abschluss nochmals gesondert aufgeführt
Die Anti-Features entsprechen denen, die ihr wahrscheinlich bereits von F-Droid kennt – mit einem Unterschied: NonFreeDep heißt hier, dass die Bibliothek selbst unfrei, also proprietär, ist. Die ID lässt sich nun auch nutzen, um den Library-Definitionen weitere Details zu entlocken – indem man nach ihr in den Dateien lib/libinfo.txt und lib/libsmali.txt sucht. In letzterer findet sich in der Regel auch ein Link zum entsprechenden Quellcode (sofern offen) bzw. zur Website des jeweiligen Projektes.
Wie beschrieben, werden die Library-Definitionen regelmäßig aktualisiert. Um diese lokal aufzufrischen, wechselt man einfach wieder in das repo/ Verzeichnis und führt dort ein
git pull origin master
aus. Wer nicht mit Git arbeiten mag, kann ein Archiv des Repositories auch über die GitLab Website herunterladen – muss die Aktualisierung dann allerdings immer händisch vornehmen.
Du kannst den Blog aktiv unterstützen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
5. Fazit
Mit dem APK Library Scanner könnt ihr beliebige APK Dateien, unabhängig von ihrer Quelle, nach ihren »Inhaltsstoffen« durchleuchten. Dies ist nicht nur für Anwender interessant, die gern wissen wollen, was sie sich da aufs Gerät holen (oder besser von selbigem fern halten) – sondern auch für Entwickler, die sich und die Nutzer ihrer Apps vor unerwünschten »Ergänzungen« schützen wollen (so manche Bibliothek bringt Abhängigkeiten mit, die nicht explizit benannt sind).
Und so ist dieser Scanner nicht nur bei F-Droid und IzzyOnDroid im Einsatz – sondern wird auch von einigen Entwicklern in ihrem Release-Prozess zur Prüfung vor der Veröffentlichung neuer Versionen verwendet. Es können gern mehr Entwickler auf den Scanner zurückgreifen – die Nutzung steht jedem frei, der Scanner selbst ist natürlich auch FOSS und somit unter einer freien Lizenz verfügbar.
Bildquellen:
Apk: Freepik from www.flaticon.com is licensed by CC 3.0 BY
Über den Autor | Gastbeitrag
Gastbeiträge werden von Autoren verfasst, die nicht zum festen Redaktionsteam des Kuketz-Blogs gehören. Bevor ein Gastbeitrag veröffentlicht wird, findet eine inhaltliche Abstimmung mit mir statt. Dabei übernehme ich die redaktionelle Bearbeitung des Textes, prüfe den Inhalt und bereite den Beitrag sorgfältig für die Veröffentlichung im Blog vor.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test
Sofatutor: Übermittlung personenbeziehbarer Daten von Kindern an TikTok, Facebook und Co.
Zoom: Analyse des Datensendeverhaltens der Android-App
Booking.com: Datenschutzrechtliche Bruchlandung mit Ansage – App-Check Teil4
Abschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.