Les signatures des gapps provenant des zips sont-elles vérifiées ?

Toutes les applications Android sont signées.

Android n'exécutera pas une application non signée. En outre, les signatures sont liées aux autorisations de l'application, de sorte que si la signature est erronée, les autres applications ne pourront pas dialoguer avec elle, et vous ne pourrez pas recevoir de mises à jour de Google Play.

La signature Android est abordée de manière plus approfondie dans Signer vos applications dans la documentation destinée aux développeurs Android, dont les informations ci-dessus ont été tirées.

Si vous êtes paranoïaque et que vous voulez vérifier la signature d'une application vous pouvez utiliser l'option jarsigner inclus dans l'utilitaire Kit de développement Java (JDK) . Par exemple :

jarsigner -verify -verbose -certs Vending.apk

• Si vous avez obtenu vos gapps de goo.im Si vous n'êtes pas sûr, vous pouvez vérifier manuellement si le MD5sum du fichier .zip que vous avez téléchargé est correct. Cela vous garantira que le fichier n'a pas été altéré.

• Si vous flashez via ClockworkMod Recovery, il y a cette option : install zip from sdcard > toggle signature verification .

Comme le dit la réponse utile de Michael Hampton, toutes les applications Android sont signées. Cela signifie :

• le système Android s'assurera que chaque application qu'il tente d'exécuter a été signée par quelqu'un .
• Quand Android met à jour une application, la nouvelle application doit être signée par la même clé qui a signé l'application originale. Sinon, la mise à niveau échouera. Si la clé change, le nom de l'application doit également changer.

Tout cela ne signifie pas qu'une console de récupération comme TeamWin ou ClockworkMod recovery vérifiera correctement les signatures de ces clés, ni qu'une rom provient de Google simplement parce que quelqu'un signé correctement.

Les roms courants vérifient-ils les signatures des fichiers zip ? Oui, elles le font

• Heureusement, il semble que La récupération TeamWin vérifie . Si j'ai bien compris, le code source (voici les installation y vérification portions) de TeamWin recovery vérifie qu'un fichier zip dans son intégralité a été signé en utilisant une clé privée qui correspond à l'une des clés publiques dans /res/keys. Il le fait si on lui demande de vérifier la signature d'un fichier zip signé, ce qui est différent de la vérification de la somme de contrôle md5 du fichier. Dans ma version (v2.7.0.0), je peux voir une option "Zip file signature verification" sur l'écran d'installation, qui je suppose active cette fonctionnalité.

• ClockworkMod recovery vérifie aussi les signatures des fichiers zip . Le code source (voir le code d'installation y le code de vérification ) se comporte de manière très similaire à celle de TeamWin : un fichier zip sera considéré comme vérifié s'il est signé avec une clé privée dont l'"autre moitié" publique se trouve dans le fichier /res/keys

Peut-on être sûr que les applications proviennent de google grâce à cette signature ? Probablement pas !

• Il ressort de cet article de blog y cet article que la plupart des roms de récupération ont au moins une clé dans /res/keys dont la version privée est connue publiquement (c'est ma déduction basée sur ce que disent les liens et ma connaissance de ce que fait le code de vérification de la rom). Cela signifie que les contrôles de validité sont essentiellement sans valeur puisque toute clé dans /res/keys peut être utilisé pour signer .

Alors que les signatures des fichiers APK sont vérifiées, il apparaît que les applications système (= applications installées à /system/ ) ont des contrôles plus souples. Cela permet d'inclure des fichiers supplémentaires dans un fichier APK et de passer les contrôles de vérification.

J'ai posté les détails sur cette page l'essentiel est que le code de validation dans PackageParser.java (fait partie de platform_frameworks_base) vérifie uniquement les fichiers énumérés dans le fichier manifeste par rapport au certificat du fichier APK. Les autres fichiers contournent la validation.

Les images d'usine de Nexus incluent Google Apps sans l'autorisation spéciale. classes.dex (au lieu de cela, ils ont un fichier .odex "optimisé" dans un sous-répertoire à côté du fichier .apk). Cela signifie que n'importe qui pourrait créer un APK contenant un fichier de type classes.dex qui est en fait malveillant. Soyez prudent avec les fichiers provenant de sources non fiables !