English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Principe de production de paquets multi-canaux avec l'ancienne signature
Préambule
en raison de Android7.0 a publié un nouveau mécanisme de signature, a renforcé le renforcement de la signature, ce qui rend impossible de continuer à produire des paquets multi-canaux de la manière de Meituan sous le nouveau mécanisme de signature. Cependant, avant de parler du nouveau mécanisme de signature sur les plans
Avant de comprendre pourquoi et comment cela affecte notre mécanisme de packaging original, nous devons d'abord comprendre le principe de packaging et le rôle de la signature dans le processus de packaging en général.
Processus de packaging Android
Le processus de packaging Android est représenté approximativement comme dans le graphique, le processus entier consiste à intégrer le code Java, les fichiers de ressources et les bibliothèques tierces dans un fichier APK, puis à signer et optimiser l'alignement des fichiers intégrés. L'ensemble du processus peut être résumé en
Le processus est divisé en plusieurs étapes :
Les étapes de génération de l'APK sont généralement comme cela, nous n'avons pas besoin de nous préoccuper des détails de la mise en œuvre, mais une compréhension générale de ces processus nous permettra de comprendre le principe de notre plan de packaging. Bien sûr, en regardant cela, on pourrait penser que l'APK
C'est un fichier très magique, capable d'être installé et exécuté. En réalité, l'APK n'est qu'un type de fichier .zip particulièrement spécial, car il peut être reconnu et installé par notre appareil Android comme une application. Nous pouvons décompresser le fichier APK pour voir son contenu.
On peut voir que le contenu du fichier est assez similaire à ce que nous avons mentionné précédemment, passons maintenant à l'examen du dossier le plus important, celui représenté dans le chapitre III du graphique, ces fichiers se trouvent dans le dossier META-Dans le dossier INF, voici les fichiers que nous ajoutons pendant le processus de signature pour identifier de manière unique l'APK. Alors, que signifie cela pour l'optimisation de notre assemblage ? Laissons ce mystère en suspens et revenons à cela plus tard. Avant de comprendre cela, nous devons d'abord clarifier la question de la signature.
签名的作用和原理
Le rôle et le principe de la signature
Le rôle de la signature
Les applications Android ajoutent souvent leur propre contenu à l'intérieur, par exemple des publicités intégrées pour gagner de l'argent, puis rediffusent l'application modifiée pour que les utilisateurs l'installent par couverture, nous pourrions subir de grandes pertes. Bien sûr, de telles choses ne se produiront pas, Google ajoute un mécanisme de signature à chaque application, comme quand nous allons à la banque pour faire une affaire, non seulement nous devons fournir une carte d'identité, mais aussi signer et attester, le numéro de carte d'identité peut être vu par tout le monde, mais la signature et l'attestation ne peuvent être faites que par nous-mêmes, personne d'autre ne peut les imiter. Les applications garantissent leur unicité et leur sécurité grâce à ce mécanisme. Les applications Android ont un identifiant unique lors de leur développement, nous le nommons nom de paquet, par exemple, le nom de paquet du grand client est com.Quanr. Le nom de paquet est comme un numéro de carte d'identité, il correspond à chaque personne. Lorsque l'application est installée, l'appareil reconnaît l'application à travers le nom de paquet, il ne peut pas y avoir deux applications avec le même nom de paquet dans un même appareil, c'est l'unicité de l'application dans l'appareil. Lorsque nous mettons à jour l'application, par exemple une installation par couverture, nous le faisons par le nom de paquet pour l'identifier et le couvrir, de sorte que l'application puisse être mise à jour sans couvrir d'autres applications. De même, d'autres applications avec un nom de paquet différent ne peuvent pas couvrir notre application. Bien que l'Android fournisse un mécanisme de reconnaissance de nom de paquet, peut-on se contenter uniquement du nom de paquet ? Imaginez que quelqu'un utilise notre nom de paquet pour créer une nouvelle application pour couvrir notre application ou que des criminels décryptent notre
Alors, comment la signature parvient-elle à faire cela ?
Le principe de la signature
Il existe plusieurs outils pour signer des APK, mais les principes sont tous similaires. Prenez par exemple l'outil signapk, pour signer un APK, il suffit d'utiliser cet outil avec quelques paramètres et notre fichier de signature unique. Il est très simple d'utiliser l'outil pour signer directement, mais ce que nous devons plus nous concentrer sur, c'est le principe et la manière dont il est mis en œuvre, car cela nous aidera à découvrir les secrets de la création des packages de distribution. Avant d'utiliser l'outil de signature, nous devons préparer la clé privée et la clé publique nécessaires à la signature (a–(clé privée)–>b–(clé publique)–>a), puis utiliser l'outil de signature pour signer l'APK. Après cela, le processus de signature sera créé dans le fichier APK sous le nom de META.-Le dossier INF et générer trois fichiers à l'intérieur, ces trois fichiers sont la clé de la signature et la base de la vérification.
On peut voir dans l'image que les trois fichiers sont :
Passons maintenant à la création de ces trois fichiers.
MANIFEST.MF
Regardons d'abord son contenu, on peut voir que ce sont des noms correspondant à des SHA1La valeur, il est facile de savoir que ce fichier enregistre une valeur unique correspondant à chaque fichier. Le fichier MANIFEST.MF a la même fonction que ce que nous avons dit précédemment, lors de la signature numérique des APK, il faut d'abord numériser chaque fichier pour générer un SHA unique.1Les valeurs sont différentes, car les contenus des fichiers différents ne sont pas les mêmes, donc si quelqu'un modifie le contenu du fichier, les valeurs SHA correspondantes1Les valeurs sont différentes, donc si quelqu'un modifie le contenu du fichier, les valeurs SHA correspondantes1Les valeurs également changent. Lors de la signature de l'APK, vérifiez chaque fichier et générez les SHA correspondants1Ces contenus sont tous conservés dans un nouveau fichier MANIFEST.MF, et ce fichier est placé dans le dossier META-Sous le répertoire INF, la génération du premier fichier de signature est terminée.
CERT.SF
Après avoir généré un fichier MANIFEST.MF, nous pouvons enregistrer la valeur unique de chaque fichier, assurant ainsi que les fichiers ne peuvent pas être altérés. Bien que cela garantisse la sécurité des fichiers enregistrés dans le MANIFEST, il ne garantit pas la sécurité de celui-ci. Les autres peuvent tout de même modifier les fichiers existants et générer les SHA correspondants1Puis, modifiez le fichier MANIFEST. Nous devons donc renforcer le MANIFEST pour garantir la sécurité. Après la création du premier fichier, l'outil de signature commence à générer le second fichier, qui est CERT.RSA. À ce stade, un codage numérique supplémentaire est effectué sur le fichier généré à l'étape précédente, et le résultat est stocké dans l'en-tête du nouveau fichier CERT.RSA. Ensuite, un codage numérique supplémentaire est effectué sur les blocs de propriétés du fichier MANIFEST.MF et stocké dans un bloc de propriété du fichier CERT.SF.
CERT.RSA
Ces fichiers sont binaires. Après avoir généré le fichier CERT.SF, nous utilisons la clé privée pour chiffrer CERT.SF et calculer la signature. La signature obtenue et les informations du certificat public sont ensuite enregistrées ensemble dans CERT.RSA. Le processus de signature est terminé.
Voici une description simple des étapes de vérification du processus d'installation de l'APK, qui est similaire aux étapes de génération des fichiers de signature :
À partir du processus ci-dessus, il est évident qu'aucun fichier de ce dossier n'a été numériquement codé pendant ce processus.-Tous les fichiers de l'INF sont numériquement codés et chiffrés, car ce dossier est généré lors de la signature. Lors de la création du premier fichier MANIFEST.MF, aucun fichier de ce dossier n'a été numériquement codé, car ce dossier doit être vide. Le second fichier est généré à partir du premier, et le troisième est généré à partir du second. Par conséquent, tout au long du processus, ce META-INF folder is almost out of control. We can add some files to avoid the signing process. This is the breakthrough point of Meituan's multi-channel package scheme.
Meituan completes multi-channel packaging by taking advantage of the signing principle
Through the understanding of the previous packaging process, we can know that to quickly make multi-channel packages, we need to skip the packaging stage and find a way to modify the Apk file directly, but this challenges the Android signing verification rules, but just, through the analysis of the signing process we just did, we found that we can in the META-INF folder to add files at will to avoid the check of the signing rules, at this time, the new scheme is born, after packaging a generated Apk file without channels, we copy this Apk and in the META-INF to add a file, and then determine the channel number through the file name, different Apk files are in the META-INF to add different channel name files, you can determine different channels, and then what we need to do is to directly go to this file when we need channel parameters, which perfectly skips the packaging process. Then how long does this scheme take? It's just based on copying and inserting a file on the basis of an Apk file, and such an action can be done in one minute on a high-end computer900 times. So, at this time, to make a channel package needs4minutes, to print100 channel packages only need four minutes and a little extra, of course, this is not the limit, if there is900 channels, each channel package needs to be packed individually900x4minutes, the Meituan scheme only needs5minutes, improving the efficiency by several hundred times, it can be said that the Meituan scheme is very perfect under the old signature.
Impact of the new signing method on the existing scheme
In Android 7After .0, Google adopted new signing verification rules to enhance the security of the signature, which is not digital encoding for each file as shown in the figure:
The new signing method is based on the structure of the zip file for signing, the Apk file is essentially a zip file, as shown in the figure, which can be divided into three parts before signing.
In the figure below, the blue part represents the Contents of ZIP entries, and the pink part represents the Central Directory.
File Entry represents a file entity, a compressed file contains multiple file entities.
L'entité de fichier se compose d'un en-tête et des données du fichier (comprimées, l'algorithme de compression est indiqué dans l'en-tête)
Le Central Directory est composé de plusieurs en-têtes de fichier, chaque en-tête de fichier sauvegardant l'offset d'une entité de fichier
Le fichier se termine par une structure appelée End of central directory.
Regardons maintenant le rôle de l'End of Central Directory, il enregistre la position de décalage du Central Directory par rapport à l'en-tête, et voyons notre nouveau bloc de signature Apk, qui est placé entre les entrées du contenu ZIP et le Central Directory, c'est un bloc de données unique généré après l'encodage et la signature de tous les modules de contenu du fichier ZIP non signé, qui peut être compris comme précédemment mentionné en termes de codage numérique, et si l'un de ces trois blocs de contenu change, les données de ce bloc ne seront pas identiques, donc après la signature, il est impossible de modifier tout contenu de l'Apk, bien que nous n'ayons pas non plus modifié le contenu en dehors de la signature Apk auparavant, donc à ce moment-là, ne pourrait-on pas envisager de modifier ce contenu du bloc de signature Apk Signing ? Nous ajoutons une petite queue à la fin. Il est évident que cette méthode ne fonctionne pas non plus, comme mentionné précédemment, il y a une partie appelée End of Central Direcotry, qui enregistre la position de décalage du Central Directory par rapport au début du fichier ZIP, et l'Apk Signing Block est exactement avant le Central Directory, si l'on change la longueur de l'Apk Signing Block, la position de décalage du Central Directory par rapport à l'en-tête change, le contenu ne correspondra pas à celui enregistré dans l'End of Central Directory, et l'ensemble du paquet Apk sera endommagé. Alors, peut-on modifier cette décalage ? Il est évident que non, après avoir modifié cette décalage, l'Apk Signing Block changera également, et seules les développeurs possédant le fichier de signature pourront obtenir les données correctes de l'Apk Signing Block, et ceux qui essaient de le falsifier ne pourront que se désespérer. C'est le principe de fonctionnement du nouveau mécanisme de signature. Sous ce nouveau mécanisme, notre ancienne signature pourrait devoir être modifiée de manière appropriée.
Idée de l'amélioration du plan
Comme mentionné précédemment, notre nouvelle méthode de compaction, sous le nouveau mécanisme de signature, est à nouveau en difficulté (bien sûr, si vous continuez à utiliser l'ancienne signature, vous n'avez pas besoin de vous soucier de ce problème), mais Google a une bonne stratégie, et nous avons une échelle de mur de fortune ~
J'ai déjà mentionné que plusieurs méthodes existent pour ajouter des packages de canal :
Nous avons analysé précédemment que si vous modifiez n'importe quel module de contenu du fichier zip, le bloc de signature APK changera, ce qui rendra impossible de contourner le mécanisme de signature.
Cependant, cela n'est pas grave, le mécanisme de signature n'est qu'un moyen de garantir la sécurité de notre Apk, nous ne voulons évidemment pas modifier malicieusement l'App, nous sommes des développeurs, nous avons la clé privée et la clé publique du fichier de signature,既然签名机制绕不过去，那么我们就直接修改Apk包然后重新进行签名就行了。Bien que cette efficacité ne soit pas aussi élevée que contourner le mécanisme de signature, mais par rapport au processus de paquetage de plusieurs minutes, ce temps est tout à fait acceptable. En règle générale, la signature redémarre environ trois à quatre secondes, par rapport à notre processus de paquetage de quatre minutes, il est évidemment acceptable et peut continuer à être utilisé.
Bien sûr, cela ne fait que baser une solution sur notre mécanisme de signature, nous avons analysé précédemment le processus et le mécanisme de paquetage et de signature, peut-être qu'il y a d'autres meilleures façons de les extraire, ce qui nécessite notre imagination collective, analysons et réfléchissons attentivement à ces processus et principes, peut-être que vous pouvez trouver une meilleure solution pour continuer à optimiser notre plan de paquetage~
Résumé
C'est tout ce qui concerne Android7.0 nouvelles signatures affectent tous les contenus de l'emballage multipiste䍖, j'espère que le contenu de cet article peut apporter un certain aide aux développeurs Android, si vous avez des questions, vous pouvez laisser des messages pour échanger
Déclaration : le contenu de cet article est issu du réseau, propriété des auteurs respectifs, le contenu est contribué et téléversé par les utilisateurs d'Internet, ce site ne détient pas de propriété, n'a pas été traité par l'éditeur humain et n'assume pas de responsabilité juridique connexe. Si vous trouvez du contenu suspect de violation de copyright, veuillez envoyer un e-mail à : notice#w3Déclaration : le contenu de cet article est issu du réseau, propriété des auteurs respectifs, le contenu est contribué et téléversé par les utilisateurs d'Internet, ce site ne détient pas de propriété, n'a pas été traité par l'éditeur humain et n'assume pas de responsabilité juridique connexe. Si vous trouvez du contenu suspect de violation de copyright, veuillez envoyer un e-mail à : notice#w