English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
古い署名の多チャネルパッケージの原理
前書き
Android7.0が新しい署名メカニズムを発表し、署名の強化を強化しました。その結果、新しい署名メカニズムでは、美团式の方法で多チャネルパッケージを続けることができなくなりました。しかし、新しい署名メカニズムがパッケージングプランに与える影響について言及する前に、
影響となぜ影響するのかを理解する前に、まずパッケージングの原理とサインがパッケージングプロセス全体でどのような役割を果たすのかを簡単に理解する必要があります。
Androidのパッケージングプロセス
Androidのパッケージングプロセスは大まかに図のように示されています。このプロセス全体は、Javaコード、リソースファイル、サードパーティライブラリを統合してAPKファイルにし、統合後のファイルにサインと最適化を適用することです。このプロセス全体は簡単に
以下のステップに分けられます：
APKの生成プロセスは大体こんな感じです。私たちは詳細な実装について気にする必要はありません。これらのプロセスを概要で理解すれば、後で話すパッケージングプランの原理を理解できます。もちろん、これを見るとAPK
これは非常に神秘的なファイルで、インストールおよび実行ができます。実際、APKは特別な.zipファイルの一種に過ぎませんが、それは私たちのAndroid機器で認識され、アプリケーションとしてインストールされることができます。APKファイルを解凍して中身を見ることはできます。
ファイルの内容は前に話したことと基本的に一致していますが、次に最も重要なフォルダーを見てみましょう。これは第三章の図にあるファイルで、これらのファイルはすべてMETAにあります。-INFフォルダー内、これがサインプロセス中にAPKのユニークな識別子として追加されるファイルです。それがパッケージの最適化に対してどのような意味があるのか、ここではまだ保留にしておき、少し後に話すことにしましょう。このことを理解する前に、まずサインのことについて説明する必要があります。
署名の作用と原理
署名の作用
Android Appは開発中にユニークな識別子を持っており、これをパッケージ名と呼びます。例えば、大客户端のパッケージ名はcom.Quanrです。パッケージ名は身分証明書の番号のように、一人ひとりに対応しています。Appをインストールする際には、機器もパッケージ名を通じてアプリケーションを識別します。機器内には同じパッケージ名のアプリが存在しないことが保証されています。これがAppの機器内での唯一性です。Appをアップグレードする際に、例えば覆盖インストールを行う場合、パッケージ名を通じて識別および対応を行うことで、Appが他のAppを覆盖せずに順調にアップグレードできることを保証します。同様に、他のAppのパッケージ名が異なるため、私たちのAppを覆盖することもできません。Androidはパッケージ名認識メカニズムを提供していますが、パッケージ名だけでは十分ではありません。例えば、他の人が私たちのパッケージ名を使って新しいAppを作成し、私たちのAppを覆盖しようとする場合や、犯罪者が私たちの
Appは自分自身の内容を追加し、例えば内蔵広告で利益を得たり、改ざんされたAppをユーザーに覆盖インストールさせたりすると、私たちは大きな損失を受ける可能性があります。もちろん、このようなことは起こりません。Googleは各Appに署名メカニズムを追加しており、銀行で業務を処理する際に、身分証明書を提供するだけでなく、署名をし押印する必要があります。身分証明書の番号は誰にでも見えるが、署名をし押印するのは自分自身のみです。他人は模倣できません。Appはこのメカニズムを通じて、唯一性と安全性を保証しています。
では、署名はどのようにこれらを実現するのでしょうか。
署名の原理
APKに署名するためのツールはいくつかありますが、原理はほぼ同じです。ここではsignapkツールを例に取り、APKに署名するには、このツールに付属するパラメータと私钥ファイルを使うだけで完了できます。ツールを使った署名は非常に簡単ですが、私たちはその原理や具体的な実現方法に注目する必要があります。これにより、从中打渠道包の秘密を見つけることができます。署名ツールを使用する前に、署名に必要な秘密鍵と公開鍵（a–(秘密鍵)–>b–(公開鍵）–>a、画像で説明すると良いでしょう）を準備し、その後APKに署名します。署名プロセスは、APK内に新たにMETA-INFフォルダ内に3つのファイルを生成し、これらのファイルが署名の鍵および検証の根拠となります。
図から見て取れるように、3つのファイルは以下の通りです：
次に、これらの3つのファイルがどのように生成されるのか説明します。
MANIFEST.MF
まずその内容を見てみましょう。Nameに対応するSHA値が見えます。1の値は、簡単にこのファイルがどのファイルが対応するユニークな値を保存しているかがわかります。MANIIFEST.MFファイルの機能は、先ほど言った通り、APKに署名する際に、まず各ファイルに対してデジタルコードを適用し、ユニークなSHA値を生成します。1の値も異なります。異なるファイルの内容が異なるSHA1の値も異なります。したがって、ファイルの内容が改ざんされた場合、対応するSHA1の値も変わります。APKに署名する際には、自分の各ファイルを確認し、対応するSHA1値を保存し、これらの内容を新しいMANIFEST.MFファイルに保存し、このファイルをMETA-INFディレクトリ下で、最初の署名ファイルの生成が完了しました。
CERT.SF
MANIFEST.MFファイルが生成された後、各ファイルのユニークな値を記録することができ、ファイルが改ざんされないことを保証します。これにより、MANIFESTに記録されたファイルのセキュリティが保証されますが、自身のセキュリティを保証することはできません。他人が既存のファイルを修正して対応するSHA1値を変更する前にMANIFESTファイルを修正するため、MANIFESTを強化する必要があります。これにより、セキュリティを確保します。最初のファイルが生成された後、署名ツールが二つ目のファイルを生成し始めます。このファイルはCERT.RSAです。このステップでは、前ステップで生成されたファイルに対して再度デジタルコードを施し、結果を新たに生成されたCERT.RSAファイルのヘッダに保存します。さらに、MANIFEST.MFファイル内の各属性ブロックに対して再度デジタルコードを施し、CERT.SFファイルの属性ブロックに保存します。
CERT.RSA
このファイルはすべてバイナリ形式です。CERT.SFファイルが生成された後、私钥を使用してCERT.SFを暗号化し、署名を計算し、得られた署名と公鍵のデジタル証明書の情報を一緒にCERT.RSAに保存します。署名プロセスはこれで終了です。
以下にAPKインストールプロセス中の確認手順を簡単に説明します。これは署名ファイル生成のプロセスと似ています：
上記のプロセスから、明らかに問題が見られます。このプロセスでは、META-INFフォルダ内のすべてのファイルに対してデジタルコードと暗号化が行われます。なぜなら、このフォルダは署名時に生成されるため、最初のファイルMANIFEST.MFが生成された際には、このフォルダ内のすべてのファイルに対してデジタルコードが行われていないからです。なぜなら、このフォルダは必ず空であるからです。二つ目のファイルは最初のファイルに基づいて生成され、三つ目のファイルは二つ目のファイルに基づいて生成されるため、このプロセス全体で、このMETA-INFフォルダは制御範囲を外れています。そこにファイルを追加することで署名プロセスを避けることができます。これが美团の多チャネルパッケージ方案の突破口です。
美团は署名の原理を利用して多チャネルパッケージを完成させます
前面のパッケージングプロセスの理解から、多チャネルパッケージを素早く作成するには、パッケージングの段階をスキップしてApkファイルを直接修正する方法を見つける必要がありますが、これはAndroidの署名検証ルールに挑戦する必要があります。しかし、ちょうど前に署名プロセスを分析したように、META-INFフォルダにファイルを任意に追加して署名ルールのチェックを避けることで、新しい方案が生まれます。パッケージング後にチャネルが無いApkファイルを生成した後、このApkをコピーし、META-INFにファイルを追加し、ファイル名でチャネル番号を決定する。異なるApkではMETA-INFに異なるチャネル名のファイルを追加することで、異なるチャネルを確定できます。その後、必要な際にはこのファイルから直接取得することで、パッケージングプロセスを完全にスキップできます。この方案の時間はどのくらいですか？これは単にApkファイルの上にファイルをコピーし、ファイル名でチャネル番号を決定するだけで、このアクションは高性能のコンピュータでは1分でできます。900回。したがって、この時点でチャネルパッケージを1つ作成するには4分、打100のチャネルパッケージでも4分加え、もちろん、これは限界ではありません。もし900のチャネルの場合、それぞれのチャネルパッケージのパッケージングには900x4分、美团の方案では5分、数百倍の効率を向上させました。言い換えれば、美团の方案は古い署名では非常に完璧です。
新しい署名方法が既存のスキームに与える影響
Androidにおいて 7.0以降、Googleは署名の安全性を強化するために新しい署名検証ルールを採用し、各ファイルに対してデジタルコーディングを行うのではなく、図のように：
新しい署名方法はzipファイル構造に基づいて署名を行い、Apkファイルは本質的に.zipファイルであり、図のように署名される前に3つの内容に分けることができます。
下図の青い部分はZIPエントリのコンテンツを、ピンクの部分は中央ディレクトリを表しています。
File Entryはファイルエンティティを表し、圧縮ファイルには複数のファイルエンティティがあります。
ファイルエンティティはヘッダーとファイルデータで構成されており（圧縮されたデータで、圧縮アルゴリズムはヘッダーに記述されています）
Central Directoryは複数のFile headerで構成されており、各File headerはファイルエンティティのオフセットを保存しています。
ファイルは「End of central directory」という構造で終わります。
さらにEnd of Central Directoryの役割を見てみましょう。それはCentral Directoryがヘッダーに対するオフセット位置を記録しており、私たちの新しい署名データApk Signing BlockはContents of ZIPエントリとCentral Directoryの間に配置されています。これは未署名のZIPファイルの3つのモジュールのすべての内容をエンコードして署名した後、生成されたユニークなデータです。前述の数字エンコードに従って理解できます。これらの3つの部分のいずれかの内容が変更された場合、生成されたこのデータは異なります。したがって、署名後、Apkのいかなる内容も変更することができません。ただし、私たちは以前にApk署名以外の内容を変更したことはありません。したがって、この時点でApk Signing Blockの内容を変更することを考慮することはどうでしょうか。私たちは後に小さなアンダートーンを追加します。明らかに、この方法もうまくいきません。以前に述べたように、最後にEnd of Central Direcotryという部分があります。それはCentral DirectoryがZIPファイルの先頭位置に対するオフセットを記録しており、APK Signing BlockはCentral Directoryの前に位置しています。APK Signing Blockの長さを変更すると、Central Directoryのヘッダーに対するオフセットが変更され、内容がEnd of Central Directoryに記録された内容と一致しなくなり、整个のApkパッケージが破壊されます。このオフセットを変更することはできますか？明らかに、それはできません。オフセットを変更すると、APK Signing Blockも変更され、署名ファイルを持つ開発者のみが正しいAPK Signing Blockデータを得ることができます。このデータを改ざんしようとする人はただ望みを持ち続けるだけです。これが新しい署名メカニズムの作用原理です。この新しいメカニズムの下で、私たちの古い署名は適切な修正が必要になるかもしれません。
改善方案の考え方
以前に述べたように、私たちの新しいパッケージ化プランは新しい署名メカニズムの下で再び窮地に陥ります（もちろん、あなたが古い署名を使用している場合、この問題を考慮する必要はありません）、ただし、Googleには良策があり、私たちは壁を越える方法もあります~
以前に述べたように、チャネルパックを追加する方法はいくつかあります：
先ほど分析したように、zipファイルの任何のモジュール内容を変更すると、APK Signing Blockが変更され、署名メカニズムを迂回することができなくなります。
ただし、これは問題ありません。署名メカニズムは、私たちのAPKのセキュリティを保護するためのものであり、私たちはAppを悪意を持って変更するつもりはありません。私たちは開発者であり、署名ファイルの秘密鍵と公開鍵を持ちます。署名メカニズムを迂回することができない場合は、直接APKパッケージを修正し、再署名することで解決できます。この方法の効率は署名メカニズムを迂回する方法よりも低いですが、数分のパッケージプロセスに比べて、これらの時間は受け入れられます。再署名には大概3、4秒かかります。4分のパッケージプロセスに比べて、これは受け入れられ、使用し続けることができます。
もちろん、これは私たちの署名メカニズムに基づいた一つの案ですが、先ほどパッケージと署名の全体の流れとメカニズムについて分析しました。もっと良い方法が見つかるかもしれません。これは私たちのアイデアを集約して考える必要があります。これらのプロセスと原理を詳細に分析し、思考し、もっと良い解決策を見つけることができるかもしれません。これにより、パッケージの最適化を続けることができます~
まとめ
これでAndroidに関する全ての内容が終わりました。7.0の新しい署名が多チャネルパッケージに与える全ての影響内容17238；この記事の内容がAndroid開発者に少しでも役立つことを願っています。疑問があれば、コメントを残してください。
声明：この記事の内容はインターネットから取得しており、著作権者は所有者であり、インターネットユーザーが自発的に貢献し、自己でアップロードしています。このサイトは所有権を持ちません。また、人工編集もなく、関連する法的責任も負いません。著作権侵害が疑われる内容を見つけた場合は、notice#wまでメールを送ってください。3codebox.com（メール送信時、#を@に変更して報告してください。関連する証拠を提供してください。一旦確認が取れたら、このサイトは即座に侵害疑いのコンテンツを削除します。）