再署名された APK がまだインストールできる理由とリスクが残る場所

インストールではブランドの認証ではなくパッケージが検証されます

Android は、APK の構造と署名の一貫性を検証します。 DEX、リソース、またはマニフェストを変更した後、攻撃者はその結果に別の証明書で署名し、技術的に完全なパッケージを作成する可能性があります。

システムが承認されても、正式な出版 ID が付与されるわけではありません。インストールチェックでは、チャネルが正当であるかどうか、アカウントがサインインできるかどうか、またはリスクの高い API リクエストを続行する必要があるかどうかは判断されません。

通常、インプレースアップグレードには署名の継続性が必要です。別の証明書で署名されたパッケージは、単に公式インストールを置き換えることはできず、パッケージ名の変更、アンインストール、または個別のインストールが必要になる場合があります。

クリーンインストールと製品バージョンからのアップグレードの両方をテストします。インストール画面のみをテストすると、署名の継続性、保持されたデータ、チャネル構成が失われます。

クライアントはパッケージ、バージョン、署名、およびプラットフォームの整合性シグナルを提示できますが、それらは絶対的な真実ではありません。高リスクの操作は、アカウント、法的バージョン、デバイスのリスク、およびリクエストの動作コンテキストに基づいてサーバー側で決定する必要があります。

このポリシーには、展開、誤検知への対応、緊急復旧も必要です。サーバーがバージョンと署名 ID を無視した場合、クライアント保護は、変更されたパッケージによる実際のビジネス API の呼び出しを阻止できません。

すべての候補のビルドソース、パッケージ名、バージョン、署名証明書ダイジェスト、ファイルダイジェスト、およびチャネル順序を記録します。静的チェック、インストール、アップグレード、およびビジネス回帰は、同じファイル ID を参照する必要があります。

再構築、再署名、またはチャネルの変更により、新しい候補が作成されます。別のファイルの結論を継承するのではなく、検証に戻る必要があります。

Yudun が焦点を絞った保護と互換性のレビューを推奨できるように、スタック、クリティカルパス、ターゲットシステム、および現在の候補を提供します。