Android 7Die Auswirkungen der neuen Signatur in .0 auf die Multikanal-Packung im Detail

Prinzip der alten Signatur für die Multikanal-Paketierung

Einleitung

aufgrund von Android7Version 0 hat ein neues Signaturmechanismus veröffentlicht, der die Stärke der Signatur verstärkt, was dazu führt, dass es unter dem neuen Signaturmechanismus nicht mehr möglich ist, wie mit dem Meituan-Style weiter Pakete für mehrere Kanäle zu erstellen. Allerdings beeinflusst das neue Signaturmechanismus die Paketierungsstrategie
Bevor wir die Auswirkungen und warum sie unser ursprüngliches Paketierungsmechanismus beeinflussen, müssen wir zunächst die Prinzipien der Paketierung und die Rolle der Signatur im gesamten Paketierungsprozess verstehen.

Android-Paketierungsprozess

Der Android-Paketierungsprozess ist wie im Diagramm gezeigt, der gesamte Prozess besteht darin, Java-Code, Ressourcendateien und Drittanbieter-Libraries in eine APK-Datei zu integrieren und die integrierten Dateien zu signieren und zu optimieren. Der gesamte Prozess kann

Der Prozess der Single wird in folgende Schritte unterteilt:

1. Vorauskompilierung der Ressourcen Für jede nicht-assert-Ressource wird eine ID generiert und in einer R-Datei gespeichert.
2. Kompilierung der Java-Dateien Die manuell geschriebenen Java-Dateien und die Java-Dateien, die in den vorangegangenen Schritten generiert wurden, werden kompiliert, um .class-Dateien zu erstellen.
3. Generierung der Dex-Datei Die zuvor generierten class-Dateien und die class-Dateien der Drittanbieter werden integriert, um eine .dex-Datei zu erstellen, die als Indexliste aller .class-Dateien dient und jede .class-Datei finden kann.
4. Paketierung der Ressourcen Die Ressourcen werden optimiert, und alle Ressourcen mit ID werden in die resource.arsc-Datei aufgenommen, die als Indexliste der Ressourcen dient.
5. Generierung der APK-Datei Die zuvor generierten .dex-Dateien und die resource.arsc-Dateien sowie die Ressourcendateien (res-Dateien, die einige bereits kompilierte binäre Dateien wie Layout-Dateien enthalten und einige nicht kompilierte binäre Dateien wie Bilder) und die Dateien ohne zugewiesene ID (assert-Dateien) werden integriert, um eine APK-Datei (eine spezielle .zip-Datei) zu erstellen.
6. Signatur Die generierte APK wird signiert, um eine einzigartige Identifikation hinzuzufügen, um sicherzustellen, dass sie normal installiert und installiert werden kann, ohne bösartig überdeckt zu werden, und um die Herkunft und den Besitzer der APK zu erklären.
7. Ausrichten und Verarbeiten Die Positionen der binären Ressourcen in der APK werden angepasst, um die Geschwindigkeit der APK während der Laufzeit zu beschleunigen.

Die Schritte zur Generierung von APK sind ungefähr so, wir müssen uns nicht um die Details kümmern, sondern nur die allgemeinen Prozesse verstehen, um die Prinzipien unserer Paketierung zu verstehen. Natürlich, so gesehen, würde APK

Es ist eine sehr magische Datei, die installiert und ausgeführt werden kann. Tatsächlich ist APK nur eine spezielle .zip-Datei, die von unseren Android-Geräten erkannt und als Anwendung installiert werden kann. Wir können die APK-Datei entpacken und einen Blick auf den Inhalt werfen.

Man kann sehen, dass der Dateiinhalt im Wesentlichen mit dem übereinstimmt, was wir gesagt haben, also schauen wir uns den wichtigsten Ordner an, den wir im Kapitel 3-Bild finden, und die Dateien in META.-Im dem INF-Ordner, das ist der Datei, die wir im Signaturprozess hinzufügen, um die APK einzigartig zu kennzeichnen. Was hat das für uns bei der Paketoptimierung zu bedeuten? Diesen Zweifel behalten wir erst einmal bei, ich werde später darauf eingehen. Bevor wir das verstehen, müssen wir zunächst das Thema Signatur klären.

签名的作用和原理

Zweck und Prinzip der Signatur

Zweck der Signatur
Apps fügen manchmal Inhalte hinzu, wie z.B. eingebettete Werbung, um zu profitieren, und senden die manipulierten Apps an die Benutzer, um sie zu überschreiben zu installieren, wir könnten große Verluste erleiden. Natürlich wird so etwas nicht passieren, Google hat für jede App ein Signaturmechanismus hinzugefügt, wie wir Bankgeschäfte abwickeln, nicht nur müssen wir einen Personalausweis vorlegen, sondern auch unterschreiben, der Personalausweis kann von jedem gesehen werden, aber die Unterschrift kann nur von uns selbst gemacht werden, andere können sie nicht nachahmen, Apps gewährleisten durch dieses Mechanismus ihre Einzigartigkeit und Sicherheit. Android-Apps haben alle eine eindeutige Identifikation, die wir als Paketnamen bezeichnen, z.B. der Paketname des großen Clients ist com.Quanr, der Paketname ist wie der Personalausweis, er entspricht jedem einzelnen, wenn wir Apps installieren, erkennt das Gerät die Anwendung auch durch den Paketnamen, es können in einem Gerät keine zwei Anwendungen mit dem gleichen Paketnamen existieren, das ist die Einzigartigkeit der Apps im Gerät. Wenn wir Apps aktualisieren, z.B. eine Überstreichung installieren, erkennen und entsprechen wir durch den Paketnamen, um sicherzustellen, dass die Apps problemlos aktualisiert werden können und andere Apps nicht überschrieben werden, und genauso, andere Apps mit verschiedenen Paketnamen können unsere Apps nicht überschreiben. Obwohl Android ein Paketnamenserkennungssystem bereitstellt, reicht es aus, nur den Paketnamen zu haben? Stell dir vor, jemand verwendet unseren Paketnamen, um eine neue App zu erstellen, um unsere App zu überschreiben oder Kriminelle, um unsere

Dann, wie erreicht die Signatur das?

Wie erreicht die Signatur das?

Prinzip der Signatur-INF-Ordner und dort drei Dateien generieren, diese drei Dateien sind der Schlüssel für die Signatur und die Überprüfung. Es gibt mehrere Werkzeuge zum Signieren von APKs, aber der Prinzip ist im Wesentlichen gleich, hier nehmen wir das Werkzeug signapk als Beispiel, um APKs zu signieren, reicht es aus, dieses Werkzeug mit einigen Parametern und unserem eindeutigen Signaturdatei zu verwenden, das Signieren mit dem Werkzeug ist sehr einfach, wir müssen uns mehr um das Prinzip und die spezifische Implementierung kümmern, um uns zu helfen, die Geheimnisse der渠道包 zu finden. Bevor wir das Signaturwerkzeug verwenden, müssen wir die privaten und öffentlichen Schlüssel vorbereiten, die für die Signatur erforderlich sind (a–(Privatschlüssel)–>b–(Öffentlicher Schlüssel)–>a, es ist am besten, ein Bild zu verwenden), dann verwenden wir das Signaturwerkzeug, um die APK zu signieren, und nach der Signatur wird der Prozess eine neue META-Datei in der APK erstellen

Von dem Bild kann man sehen, dass die drei Dateien sind:

1. MANIFEST.MF
2. CERT.RSA
3. CERT.SF
   

Nächste, wie diese drei Dateien generiert werden.

MANIFEST.MF

Schauen wir uns zunächst den Inhalt an, wir können sehen, dass es einige Namen und zugehörige SHA gibt1Der Wert, es ist leicht zu erkennen, dass diese Datei die für jeden Datei eindeutige Werte speichert. Die Funktion der Datei MANIFEST.MF ist wie gesagt, beim Signieren von APKs, wird zunächst jede Datei mit einer numerischen Codierung versehen, um eine eindeutige SHA zu generieren1Werte, da verschiedene Dateiinhalte unterschiedliche SHA1Werte sind unterschiedlich, daher wenn jemand die Dateiinhalte manipuliert, so ändern sich die entsprechenden SHA1Werte ändern, beim Signieren des APKs wird jedes eigene Datei überprüft und die entsprechenden SHA1Werte und speichern diese Inhalte in einer neu erstellten MANIFEST.MF-Datei und legen diese Datei in das META-Im INF-Verzeichnis wurde die Erstellung der ersten Signaturdatei abgeschlossen.

CERT.SF

Nachdem eine MANIFEST.MF-Datei erstellt wurde, können wir die einzigartigen Werte jeder Datei aufzeichnen und sicherstellen, dass die Datei nicht manipuliert wird. Obwohl dies die Sicherheit der in MANIFEST aufgezeichneten Dateien gewährleistet, kann die Sicherheit selbst nicht gewährleistet werden, da andere die Datei nachträglich ändern und die entsprechenden SHA1Werte und dann das MANIFEST-Datei zu ändern, daher müssen wir MANIFEST verstärken, um die Sicherheit zu gewährleisten. Nachdem der erste Datei erstellt wurde, beginnt das Signierungstool mit der Erstellung der zweiten Datei, das ist CERT.RSA. In diesem Schritt wird eine weitere digitale Kodierung der Datei fortgesetzt, die im vorherigen Schritt erstellt wurde, und das Ergebnis wird im Header der neu erstellten CERT.RSA-Datei gespeichert. Anschließend wird eine weitere digitale Kodierung der verschiedenen Attributblöcke der MANIFEST.MF-Datei durchgeführt und in einem Attributblock der CERT.SF-Datei gespeichert.

CERT.RSA

Diese Dateien sind binär. Nachdem die CERT.SF-Datei erstellt wurde, berechnen wir den Signaturenwert mit dem Privatschlüssel und speichern den erhaltenen Signaturenwert zusammen mit den Informationen des öffentlichen Zertifikats in CERT.RSA. Der Signaturprozess ist damit abgeschlossen.

Nächste einfach die Validierungsschritte im Apk-Installationsprozess beschreiben, das ist im Prinzip ähnlich wie der Schritt zur Generierung der Signaturdatei:

1. Zunächst wird überprüft, ob die digitale Kodierung aller Dateien im Apk mit der digitalen Kodierung in MANIFEST.MF übereinstimmt
2. Überprüfen Sie, ob die Signaturinformationen der Datei CERT.SF und der Inhalt von CERT.RSA übereinstimmen
3. Die entire Datei MANIFEST.MF wird im Header-Attribut der Datei CERT.SF signiert. Ob die Werte übereinstimmen und die Signatur der verschiedenen Attributblöcke der Datei MANIFEST.MF im CERT.SF übereinstimmt

Aus dem obigen Prozess kann man leicht erkennen, dass es in diesem Prozess niemals um die digitale Kodierung von META-Jegliche Datei im INF-Ordner wird digital kodiert und verschlüsselt, da dieser Ordner beim Signieren erstellt wird. Beim Erstellen der ersten Datei MANIFEST.MF wurden keine Dateien im Ordner digital kodiert, da dieser Ordner unbedingt leer sein muss. Die zweite Datei wird auf der ersten Datei basiert, die dritte Datei wiederum auf der zweiten. Daher wird der META-INF文件夹几乎是在控制范围之外的。我们可以在里面添加一些文件从而躲过签名这个过程。这就是美团多渠道包方案的突破口。

美团通过利用签名原理来完成多渠道打包

通过前面打包过程的了解，可以知道想快速打多渠道包，就得跳过打包的阶段直接想办法对Apk文件进行修改，但这得挑战Android的签名校验规则了，不过正好，通过刚才我们对签名过程的分析，我们发现可以在META-INF文件夹中随意添加文件从而躲过签名规则的检查，这时候新方案就孕育而生了，在打包生成了一个没有渠道的Apk文件后，我们copy这个Apk并在在META-INF中添加一个文件，然后通过文件名来确定渠道号，不同的Apk里就在META-INF中添加不同的渠道名文件，即可确定不同的渠道了，之后要做的就是在我们需要渠道参数的时候直接去这个文件里拿就行了，完美的跳过了打包这个过程。那么这种方案的耗时呢？仅仅就是基于一个Apk文件的基础上复制并插入一个文件而已，这样的动作在高配的电脑里一分钟可以做900次。所以，这时候打一个渠道包要4分钟，打100个渠道包也只要四分钟加一个小零头，当然，这还不是极限，如果有900个渠道的话，一个个渠道包打包需要900x4分钟，美团方案只要5分钟，提高了好几百倍的效率，可以说美团方案在老签名下是非常完美的。

新签名方式对现有方案的影响

在Android 7.0之后，Google为了增强签名的安全性，采用了新的签名验证规则，不是针对每个文件进行数字编码了，如图所示：

新的签名方式是根据zip文件结构来进行签名的，Apk文件本质上就是一个.zip文件，如图所示，在被签名前可以分为三块内容。

1. 压缩文件实体数据 包含所有的元素具体数据
2. 核心目录数据 包含所有元数据的相对偏移量
3. 目录结束标志 包含目录数据的偏移位置和相关目录详情记录

下图中蓝色的部分代表ZIP条目的内容，粉色的部分代表中央目录。

File Entry表示一个文件实体，一个压缩文件中有多个文件实体。

A file entity consists of a header and file data (compressed, the compression algorithm is explained in the header)

The Central Directory is composed of multiple File headers, each of which saves the offset of a file entity

The file ends with a structure called End of central directory.

Let's take a look at the role of End of Central Directory, which records the offset position of the Central Directory relative to the header. Let's also take a look at our new signature data Apk Signing Block, which is placed between the Contents of ZIP entries and the Central Directory. It is a unique data produced after encoding and signing all the contents of the three modules of the unsigned ZIP file. It can be understood according to the numerical encoding mentioned earlier. Any change in the content of these three blocks will produce a different piece of data. Therefore, after signing, it is not possible to modify any content of the Apk. However, we haven't modified the content outside the Apk signature before, so at this point, isn't it possible to consider modifying the content of the Apk Signing Block? We will add a small tail at the end. Clearly, this method is also not feasible. As mentioned earlier, there is a part called End of Central Direcotry at the end, which records the offset of the Central Direcotry relative to the start of the ZIP file. The APK Signing Block is located in front of the Central Direcotry. If the length of the APK Signing Block is changed, the offset of the Central Direcotry relative to the header will change, and the content will be different from the one recorded in the End of Central Directory, and the entire Apk package will be destroyed. So can we modify this offset? Clearly, it is not possible. After modifying this offset, the APK Signing Block will also change, and only developers who have the signature file can get the correct APK Signing Block data. Those who want to tamper with it can only sigh in vain. This is the principle of the new signing mechanism. Under this new mechanism, our old signature may need to be appropriately modified.

The idea of improving the scheme

As mentioned earlier, our new packaging scheme will again be at a disadvantage under the new signing mechanism (of course, if you still use the old signature, then you don't need to consider this issue), but Google has a good plan, and we have a way to climb over the wall~

I have mentioned before that there are several ways to add channel packages:

1. Directly modify the code, modify the code for one channel package at a time, and then package it
2. Verändern Sie nicht direkt den Code, sondern geben Sie einen Kanalparameter vor, der vor dem Packen dynamisch geändert wird und dann gepackt wird
3. Fügen Sie Kanalnummern hinzu, indem Sie die Signaturprüfung überspringen und die Dateien nach dem Packen ändern
4. Jetzt funktionieren diese drei Methoden nicht mehr. Kein Problem, wir haben noch eine vierte Methode.
   

Zuvor wurde analysiert, dass sich der APK Signing Block ändert, wenn der Inhalt eines Moduls der zip-Datei geändert wird, und der Umweg über den Signaturmechanismus ist nicht mehr möglich.

Aber das ist nicht schlimm, der Signaturmechanismus dient nur dazu, die Sicherheit unserer APK zu gewährleisten. Wir möchten natürlich nicht, dass jemand unseren App missbräuchlich manipuliert. Wir sind Entwickler und haben den privaten und öffentlichen Schlüssel der Signaturdatei in der Hand. Da der Signaturmechanismus nicht umgangen werden kann, können wir einfach die APK-Pakete ändern und neu signieren. Obwohl die Effizienz nicht so hoch ist wie der Umweg über den Signaturmechanismus, ist diese Zeit im Vergleich zum Packprozess von mehreren Minuten dennoch akzeptabel. Eine Neusignatur dauert etwa 3 bis 4 Sekunden, was im Vergleich zu unserem 4-minütigen Packprozess noch akzeptabel ist und fortgesetzt werden kann.

Natürlich, das ist nur eine von uns ausgedachte Lösung basierend auf unserem Signaturmechanismus. Zuvor haben wir den gesamten Prozess und Mechanismus der Paketierung und Signatur analysiert und möglicherweise gibt es bessere Möglichkeiten, aus ihnen zu gewinnen. Das erfordert unsere Kreativität. Eine sorgfältige Analyse und Überlegung dieser Prozesse und Prinzipien kann Ihnen helfen, eine bessere Lösung zu finden, um unsere Paketierungsstrategie weiter zu optimieren~

Zusammenfassung

Das ist alles, was es über Android gibt7.0 neue Signatur beeinflusst alle Inhalte des Packens über mehrere Kanäle17238; ich hoffe, dass der Inhalt dieses Artikels den Android-Entwicklern ein gewisses Maß an Hilfe bietet. Bei Fragen können Sie Kommentare hinterlassen und miteinander kommunizieren

Erklärung: Der Inhalt dieses Artikels wurde aus dem Internet entnommen und gehört dem Urheberrechtlichem Eigentümer. Der Inhalt wurde von Internetnutzern freiwillig und eigenverantwortlich hochgeladen. Diese Website besitzt keine Eigentumsrechte und hat den Inhalt nicht manuell bearbeitet. Sie übernimmt auch keine rechtlichen Verantwortlichkeiten. Wenn Sie urheberrechtlich fragliche Inhalte finden, freuen wir uns über die E-Mail-Benachrichtigung an: notice#oldtoolbag.com (Bitte ersetzen Sie # durch @, wenn Sie eine E-Mail senden, um zu melden, und fügen Sie relevante Beweise bei. Wenn die Inhalte überprüft werden, wird diese Website die fraglichen urheberrechtlichen Inhalte sofort löschen.)