Werden die Signaturen von Gapps aus Reißverschlüssen überprüft?

Sind die Gapps (zB von goo.im) manipulationssicher signiert? Gibt es eine Möglichkeit zu überprüfen, ob sie mit denen von Google übereinstimmen?

Prüfen alle / die meisten ROMs darauf?

Antworten (4)

Alle Android-Apps sind signiert.

Android führt keine unsignierte App aus. Darüber hinaus sind die Signaturen an die App-Berechtigungen gebunden, sodass andere Apps nicht mit ihr kommunizieren können und Sie keine Updates von Google Play erhalten können, wenn die Signatur falsch ist.

Die Android-Signierung wird ausführlicher unter Signing Your Applications in der Android-Entwicklerdokumentation behandelt, aus der die obigen Informationen stammen.

Wenn Sie paranoid sind und die Signatur einer App überprüfen möchten , können Sie das im Java Development Kit (JDK)jarsigner enthaltene Dienstprogramm verwenden . Zum Beispiel:

jarsigner -verify -verbose -certs Vending.apk
Auf der Seite, auf die Sie verweisen, heißt es: „Android verwendet dieses Zertifikat, um den Autor einer App zu identifizieren, und das Zertifikat muss nicht von einer Zertifizierungsstelle signiert werden. Android-Apps verwenden häufig selbstsignierte Zertifikate.“ Bedeutet dies nicht, dass Android zwar überprüft, ob die App signiert ist, es sich jedoch nicht darum kümmert, WER sie signiert hat? Das würde bedeuten, dass wir keinen Schutz vor einer bösartigen App haben, es sei denn, wir überprüfen irgendwie, ob die Gappps, die wir erhalten, von Google signiert sind. Diese Antwort scheint einige SEHR notwendige Überprüfungsschritte zu beschönigen. Übersehe ich etwas?
@stochastic Wie auf der Seite auch erwähnt, müssen Updates mit genau demselben Schlüssel signiert werden, sonst weigert sich Android, das Update zu installieren. Es spielt keine Rolle, dass der Schlüssel nicht von einer Zertifizierungsstelle signiert wurde, sondern dass er derselbe ist, der ursprünglich zum Signieren der App verwendet wurde.
Danke für den Hinweis! Setzt das aber nicht immer noch voraus, dass es eine gleichnamige App gibt? Wenn Sie beispielsweise über Google Play installieren, ist das in Ordnung, aber wenn Sie eine Zip-Datei von Gapps über ein Wiederherstellungs-ROM installieren, ist es durchaus möglich, dass die Gapps einfach noch nicht vorhanden sind (weshalb sie auf diese Weise installiert werden). Wäre es nicht eine echte Schwachstelle, wenn wir nicht manuell eine Art Schlüsselüberprüfung durchführen würden? Auch wenn das Android-System die von Ihnen beschriebene Überprüfung durchführt, bedeutet das, dass ein Wiederherstellungs-ROM die gleiche Überprüfung durchführt?
  • Wenn Sie Ihre Gapps von erhalten goo.imhaben, können Sie manuell überprüfen, ob die MD5-Summe der heruntergeladenen .zip-Datei korrekt ist. Dies würde Ihnen versichern, dass die Datei nicht manipuliert wurde.

  • Beim Flashen durch ClockworkMod Recovery gibt es diese Option: install zip from sdcard > toggle signature verification.

Ich glaube jedoch nicht, dass die Überprüfung der Zip-Signatur überprüft, ob die Apps (oder andere Inhalte) in der Zip-Datei signiert sind. Es prüft nur, ob die ZIP-Datei selbst signiert ist. In ähnlicher Weise beweist das Überprüfen der md5 der Zip-Datei nicht wirklich etwas über die darin enthaltenen Apps, es sei denn, Sie erstellen Ihre eigene flashbare Zip-Datei mit bekanntermaßen guten Kopien derselben Versionen derselben Apps und md5 sie dann beide (aber warum sollten Sie dann herunterladen es? Sie hätten bereits Ihre eigene flashbare Version)

Wie die hilfreiche Antwort von Michael Hampton sagt, sind alle Android-Apps signiert. Das heisst:

  • Das Android-System stellt sicher, dass jede App, die es auszuführen versucht, von jemandem signiert wurde .
  • Wenn Android eine App aktualisiert, muss die neue App mit demselben Schlüssel signiert werden, der die ursprüngliche App signiert hat. Andernfalls schlägt das Upgrade fehl. Wenn sich der Schlüssel ändert, muss sich auch der Name der App ändern.

All dies bedeutet nicht, dass eine Wiederherstellungskonsole wie TeamWin oder ClockworkMod Recovery die Signaturen dieser Schlüssel ordnungsgemäß überprüft, noch bedeutet es, dass ein Rom von Google stammt, nur weil jemand es ordnungsgemäß signiert hat.

Überprüfen gängige ROMs die Signaturen von Zip-Dateien? Ja, das tun sie

  • Glücklicherweise scheint die TeamWin-Wiederherstellung . Wenn ich es richtig verstehe, überprüft der Quellcode (hier sind die Installations- und Überprüfungsteile ) der TeamWin-Wiederherstellung, ob eine ZIP-Datei vollständig signiert wurde, indem ein privater Schlüssel verwendet wird, der einem der öffentlichen Schlüssel in /res/keys entspricht . Es tut dies, wenn es angewiesen wird, die Signatur einer signierten ZIP-Datei zu überprüfen, was sich von der Überprüfung der md5-Prüfsumme der Datei unterscheidet. In meiner Version (v2.7.0.0) sehe ich auf dem Installationsbildschirm die Option „Zip-Datei-Signaturüberprüfung“, von der ich annehme, dass diese Funktion aktiviert wird.

  • Die ClockworkMod-Wiederherstellung überprüft auch Zip-Datei-Signaturen . Der Quellcode (siehe Installationscode und Verifizierungscode ) verhält sich ganz ähnlich wie der von TeamWin: Eine Zip-Datei gilt als verifiziert, wenn sie mit einem privaten Schlüssel signiert ist, in dessen öffentlicher „anderer Hälfte“ sie lebt/res/keys

Können wir sicher sein, dass die Apps aufgrund dieser Signatur von Google stammen? Wahrscheinlich nicht!

  • Aus diesem Blogeintrag und diesem Artikel geht hervor, dass die meisten Wiederherstellungs-ROMs mindestens einen Schlüssel in /res/keys haben, dessen private Version öffentlich bekannt ist (das ist meine Schlussfolgerung basierend auf den Aussagen der Links und meinem Wissen darüber, was der ROM-Verifizierungscode tut). . Damit sind die Gültigkeitsprüfungen im Grunde wertlos , da mit jeder beliebigen Eingabe /res/keyssigniert werden kann .

Während Signaturen für APK-Dateien überprüft werden, scheint es, dass System-Apps (= installierte Apps auf /system/) entspanntere Überprüfungen haben. Dies ermöglicht das Einfügen zusätzlicher Dateien in eine APK-Datei und besteht dennoch die Verifizierungsprüfungen.

Ich habe die Details auf dieser Seite gepostet , das Wesentliche ist, dass der Validierungscode in PackageParser.java (Teil von platform_frameworks_base) nur Dateien überprüft, die in der Manifestdatei aufgeführt sind, anhand des Zertifikats in der APK-Datei. Andere Dateien umgehen die Validierung.

Die Nexus Factory-Images enthalten Google Apps ohne die spezielle classes.dexDatei (stattdessen haben sie eine „optimierte“ .odex-Datei in einem Unterverzeichnis neben der .apk-Datei). Dies bedeutet, dass jeder ein APK erstellen kann, das eine classes.dexDatei enthält, die tatsächlich bösartig ist. Seien Sie vorsichtig mit Dateien aus nicht vertrauenswürdigen Quellen!