Bitdefender Labsの研究者は、細工したアプリをインストールするだけで、Androidスマートフォンがクラッシュのループに陥る可能性があることを突き止めました。アプリを一度も開かず、権限を1つも付与していなくても発生します。このアプリにはコードが含まれておらず、実行される必要もありません。
インストール後、システムの中核プロセスがクラッシュと再起動を繰り返し、端末はブートループに陥ります。再起動しても、セーフモードを使っても解決しません。
端末を復旧するには工場出荷時リセットが必要で、ユーザーのデータはすべて消去されます。USBデバッグがたまたま有効になっていた場合は、ADB（Android Debug Bridge）を使うコンピュータから、端末が再起動する前に該当ファイルを削除できる可能性があります。
調査のきっかけは、2026年8月12日でした。実環境で入手したAPKが、当社の解析基盤にあるエミュレータをクラッシュさせたのです。このサンプルは、一度も実行されないままインストール中にクラッシュした、バンキング型ドロッパーでした。
原因を詳しく調べると、問題はマルウェアではなくAndroid自体にあることが分かりました。Androidは、ZIPエントリ内の2つのフィールド、つまり圧縮方式と宣言された非圧縮サイズを正しく扱えていません。こうしたエントリを読み込むと、そのファイルに触れたプロセスでSIGBUSが発生します。SIGBUSとは、無効なメモリ領域へアクセスしたプロセスを止めるため、CPUが送るシグナルです。
当社はこの問題をGhostMapと名付けました。不正な形式のエントリにより、Androidは割り当てられていないメモリ領域にまたがってファイルをマッピングします。そして、プロセスがその空の領域から読み込もうとした時点でクラッシュが起きます。
検証の結果、このバグのリスクは重大だと考えています。理論上、攻撃者はこの手法を偽アプリに仕込んで被害者の端末を使用不能にできます。工場出荷時リセットとデータ消失の脅威を材料に、恐喝を図ることも考えられます。また、不正な形式のAPKは、Androidアプリを検査するツールの動作を妨害する可能性もあります。ただし、これらのシナリオを実環境で確認したことはありません。
主な調査結果
- 一度も開かないアプリが、スマートフォンを使用不能にする可能性があります。細工したアプリをインストールするだけで、クラッシュのループが始まります。このアプリは権限を一切要求せず、実行可能なコードも含みません。
- 再起動しても解決しません。クラッシュのループは再起動後も続き、セーフモードでも止まりません。復旧には工場出荷時リセットが必要になる場合があり、端末内に保存したデータは消去されます。
- 最新のAndroidでも発生します。研究者は、2026年8月5日のセキュリティパッチを適用したAndroid 17搭載のPixel 10で、この障害を再現しました。影響を受けるのは、Android 10以降のすべてのバージョンです。
- 発端は、実環境で見つかったAPKです。このAPKがBitdefenderの解析用エミュレータをクラッシュさせ、調査が始まりました。その後、研究者は持続的なクラッシュのループを示すデモを作成しました。
- Googleは、セキュリティ修正の対象外と判断しました。Bitdefenderは2026年8月20日と8月25日に調査結果を報告しました。Googleの2度目の回答によると、この問題はセキュリティアップデートでは対処されず、将来のバージョンでの検討に向けて機能担当チームに回されました。
このバンキング型ドロッパーは、パッカーで包まれていました。パッカーとは、リバースエンジニアリングツールで読み取れないよう、APKの内部構造を書き換えるツールです。最近のAndroidマルウェアでは、ごく一般的に使われています。
今回は、この書き換えによって、インストール時にアプリを解析するAndroidのコンポーネントも壊れました。これが、インストールがそもそもクラッシュした理由であり、当社のエミュレータが失敗した理由です。幸い、このファイルが何かをクラッシュさせると作成者が知っていたことをうかがわせる点は、サンプルには見当たりません。
このサンプルが引き起こしたのは、インストールの失敗だけでした。しかし、根本的な欠陥はもっと深刻です。同じミスを、インストーラではなく中核のシステムサービスに向けることもできると分かりました。その場合は前述のクラッシュのループが発生し、工場出荷時リセット以外に復旧手段はありません。この段階への拡張は当社独自の成果であり、誰かに対して悪用された例は確認していません。
根本的な問題は、AndroidがAPKファイル内のサイズ情報や圧縮情報をどう信用するかにあります。不正な形式のZIPファイルに限った話ではありません。
開示の経緯とGoogleの対応
当社はこの問題を、Android & Devices Vulnerability Reward Programを通じてGoogleに2度報告しました。2度目の報告は、追加検証で持続的なシステムのクラッシュループを確認したうえで、内容を拡充したものです。
2026年8月12日：最初の発見。実環境で入手したAPKが、解析基盤のエミュレータをインストール中にクラッシュさせました。調査の結果、原因はZIPエントリの圧縮方式と宣言された非圧縮サイズに対するAndroidの扱いにあると判明しました。
AndroidのネイティブAPIでAPKを解析するアプリも、読み込み時にクラッシュしうることも分かりました。
バグを再現するうちに、さらに次の事実が明らかになりました。このAPKをインストールしようとするたびにOSがクラッシュし、再起動が起きました。
- ネイティブAPIを使うサードパーティ製アプリ（当社のBMSを含む）がこのファイルをAPKとして解析すると、解析プロセスがクラッシュしました。
- ファイルマネージャーのプロセスも解析しようとしてクラッシュするため、ADBなしではファイルを削除できませんでした。セーフモードでも同様です。
2026年8月20日：Googleへの最初の報告。インストール時のクラッシュと、不正な形式のAPKを解析するアプリの障害を記録し、調査結果を提出しました。Googleは間もなく、ステータスWon’t Fix (Not Reproducible)でこの報告をクローズしました。付随する回答では、同プログラムの対象範囲外だと説明されていました。
さらなる調査：持続的なサービス拒否。当社は検証を続け、インストールには成功するものの、システムサービスがアプリのリソースを自動的に読み込む際にクラッシュするAPKを発見しました。その結果生じるクラッシュのループにより、インターフェースにアクセスできなくなり、セーフモードでも続きました。復旧には工場出荷時リセットが必要になる場合があります。
そこで、調査をさらに進めました。インストール時には解析されない他のファイルも不正な形式にでき、Androidのシステムサービスの一部がそれらを自動的に解析しようとすることが分かりました。つまり、クラッシュ、再起動、再解析という通常の流れでループが続き、再びブートループに陥ります。
当社が引き起こしたブートループは、セーフモードへのアクセスも使えなくします。確認できた復旧方法は、工場出荷時リセットか、限られた条件下でsystem_serverのクラッシュと競合させるADBベースのスクリプトだけでした。
興味深いことに、Googleはこの欠陥の弱いバージョンをすでに修正しています。2016年11月のセキュリティ情報にあるCVE-2016-6724は、次のように説明されています。
Input Manager Serviceのサービス拒否の脆弱性により、ローカルの悪意あるアプリが端末を繰り返し再起動させる可能性があります。この問題は、修正に工場出荷時リセットを要する一時的なサービス拒否であるため、深刻度は「中」と評価されています。
深刻度は「中」で、Android 4.4.4から7.0まで修正されました。2016年当時のGoogleは、工場出荷時リセットを要する状態を一時的なものと位置付けていました。当社の理解では、Googleが現在公開している深刻度のガイドラインは、こうした状態を持続的なものとして扱い、「高」と評価しています。
2026年8月25日：Googleへの2度目の報告。動作するPoC（概念実証）と再現手順を含む、拡充した調査結果を提出しました。報告では、このアプリが権限を必要とせず、実行可能なコードを含まず、起動すらされなくてよいことを説明しました。
Googleは間もなく回答し、この問題はセキュリティアップデートによる修正の対象外だと判断したと伝えてきました。また、調査結果を関連チームに転送し、将来のバージョンアップデートへの反映を検討すると述べています。
既視感のある問題
パーサー差異の脆弱性とも呼ばれるこの種のバグは、Androidが10年以上前から抱えてきた課題です。
2014年、セキュリティ研究者らがLeaving our ZIP undone: How to abuse zip to deliver malware appsと題する論文を発表しました。この論文は、APKファイルに加えることで一般的なアンチウイルスエンジンの展開処理を回避できる不正な形式などを取り上げています。つまり、Androidのエコシステムにとって未知の問題ではありません。
APKの実体はZIPファイルです。ZIPファイルは、サイズやオフセット、圧縮フラグといった同じ情報を複数の場所に保存しますが、それらが一致しているかは確認しません。
Androidは、APKを何度も読み込みます。署名の検証、インストール、リソースの読み込み、コードの実行、そしてセキュリティツールがスキャンするたびにです。これらは別々のコードであり、同じ読み方をするよう強制するものはありません。
2つのコードが同じバイト列について異なる結論に達すると、今回のようなセキュリティ上のバグが生まれます。
Master Key（2013年、CVE-2013-4787）。同じ名前のファイルを2つ含むAPKが対象でした。Androidは最初のファイルの署名を検証し、2番目のファイルをインストールしました。そのため、有効な署名のもとで悪意あるコードが入り込みました。
Janus（2017年、CVE-2017-13156）。1つのファイルが、有効なAPKであると同時に有効なDEXでもありえました。署名の検証はZIPエントリだけを見て、ファイル先頭に追加された余分なバイトを無視しました。その後、システムはそのバイトを実行しました。検証側とローダー側で、ファイルの開始位置そのものについて認識が食い違っていたのです。
BadPack（2024年）。マルウェアの作者は、ZIPヘッダを意図的に破損させます。すると解析ツールはファイルを開けませんが、スマートフォンは問題なくインストールします。このタイプは、同じAndroid端末内の2つのパーサーの差異を突くものではありません。狙うのは、AndroidがAPKのインストールに使うパーサーと、アナリストやセキュリティ製品がAPKの審査に使う他のパーサーとの差異です。
Palo Alto NetworksのUnit 42は、1年間でこうしたサンプルを約9,200件確認しました。Anatsa、Cerberus、BianLianなどのバンキング型トロイの木馬が使っています。今回のサンプルが使っていたのも、この種のパッキングです。
今回のバグも似た食い違いから生じますが、何かをすり抜けさせるために使われるわけではありません。食い違いの結果、ファイルを読もうとしたプロセスがクラッシュします。
クラッシュが起きる仕組み
ZIPファイル内のエントリはそれぞれ、格納方法とサイズを記録しています。Androidは、エントリを2通りの方法で格納します。バイト列をそのまま保持する*stored*と、圧縮されていて読み込み時に展開が必要な*deflated*です。
各エントリには2つのサイズがあります。ファイルに実際に格納されたバイト数を示す圧縮サイズと、展開後に得られるバイト数を示す非圧縮サイズです。storedのエントリでは両者が等しく、deflatedのエントリでは非圧縮サイズのほうが大きくなります。
AndroidがAPKを開くと、libziparchiveというライブラリがこれらの記録を読み、妥当性を検査します。検査の1つは、エントリの非圧縮サイズが、ファイルに実際にある領域より大きいと主張していないかの確認です。ただし、この検査が実行されるのはstoredのエントリだけです。
// system/libziparchive/zip_archive.cc
if (data->method == kCompressStored &&
data->uncompressed_length > cd_offset - data_offset) {
return kInvalidOffset; // reject
} それ以外の格納方法では、この検査は省略されます。deflatedのエントリではそれで問題ありません。非圧縮サイズは一時バッファの大きさを決めるだけで、ファイルから読み込むデータは圧縮サイズで制限されるからです。
問題は、methodフィールドが取りうる値が*stored*と*deflated*だけではない点です。このフィールドは16ビットの数値なので、どんな値でも入ります。Androidが対応するのはそのうち2つで、残りはZIP形式では許容されています。
さらに、2つ目のライブラリであるlibandroidfwがエントリをリソースとして読み込む際には、別の問いを立てます。*stored*かどうかは確認せず、*deflated*かどうかを確認し、それ以外はすべてstoredとして扱います。
// frameworks/base/libs/androidfw/AssetsProvider.cpp
if (entry.method == kCompressDeflated) {
// map compressed_length, then decompress
} else {
// map entry.uncompressed_length directly <-- never bounds-checked
} 2つのライブラリは、エントリを異なる基準で分類しています。libziparchiveは、エントリが*stored*とマークされている場合にだけ、非圧縮サイズを検査します。libandroidfwは、エントリが*deflated*とマークされていなければ、非圧縮サイズでファイルをマッピングします。storedでもdeflatedでもない別のmethodが指定されたエントリは、この2つの規則の隙間に落ちます。deflatedではないためlibandroidfwは非圧縮サイズでマッピングし、storedではないためlibziparchiveはそのサイズを一度も検査しません。
最後の手順がメモリマップです。Androidはエントリをメモリにコピーせず、ファイルをマッピングします。つまり、ファイルの一部をメモリのように見せるようカーネルに要求します。ファイルより大きいマッピングも要求でき、カーネルは許可します。余分な領域の裏には何もないだけだからです。
その領域が読み込まれるまで、問題は起きません。Androidがファイルの実際の末尾を超えて初めて読み込んだ時点で、プロセッサがフォールトを起こします。この経路にはフォールトを処理する仕組みがないため、カーネルはSIGBUSでプロセスを強制終了します。
Pixel 10では、クラッシュの記録（プロセスの終了時にAndroidが書き出すトゥームストーン）が、このマップ領域の読み込みをそのまま指し示していました。
#00 __memcpy_aarch64_simd libc.so
#01 android::_FileAsset::read libandroidfw.so
#02 android::NativeAssetReadChar libandroid_runtime.so
#03 art_jni_trampoline boot-framework.oat
#04 AssetManager$AssetInputStream.read (framework) 同じ記録から、理由も分かります。数キロバイトのAPKが16MBのメモリ領域にマッピングされ、フォールトアドレスはファイルの末尾をはるかに超えた、宣言サイズが作り出した空の領域にありました。読み込みがファイルの外へ踏み出し、カーネルが止めたのです。
過大なマッピングがクラッシュを招く経路は、コードの読み方によって2通りあります。
1つ目は、上のトゥームストーンに示した経路です。プロセスがエントリを少しずつ読み込みます。各読み込みは宣言サイズでしか制限されないため、実際のファイル末尾を超えて読み続け、いずれ空の領域に触れてフォールトを起こします。
2つ目は、プロセスがエントリ全体を1つのメモリブロックとして一度に要求する場合です。AndroidがXMLリソースやアプリのアイコンを読み込むときが、これに当たります。ブロックを渡す前に、マップされたバイト列がプロセッサの必要とするアラインメントに合っているかを確認します。
合っていればそのまま渡します。合っていなければ、アラインメントを整えたコピーを作ります。宣言された長さと同じ大きさのバッファを確保し、その分のバイト数をコピーします。
// frameworks/base/libs/androidfw/Asset.cpp (_FileAsset::ensureAlignment)
unsigned char* buf = new unsigned char[mLength]; // mLength = the declared size
memcpy(buf, data.unsafe_ptr(), mLength); // copy runs past the end of the file 宣言された長さは偽の値なので、コピーはファイルの末尾を超えてフォールトを起こします。この場合は、バッファから読み込むときではなく、バッファを埋めるときに起きます。
2つの経路は、失敗する関数こそ違いますが、理由は同じです。両者を合わせると、Androidがエントリを読む2通りの方法、つまり少しずつストリームで読む方法と、丸ごと読み込む方法をカバーしています。エントリを丸ごと読み込む経路は、リソースやアイコンが通る道であり、次の段階を可能にします。
Androidがこの判断を解決できていなかったわけではありません。他の2か所では、同じ判断を正しく行っています。libziparchiveは非圧縮サイズを正しく検証しますが、対象はstoredのエントリだけで、数行のコードがそれ以外では検査を飛ばしています。
ZIPエントリをマッピングする3つ目のライブラリであるZipFileROは、安全な選択をしています。非圧縮サイズを使うのはstoredのエントリだけで、それ以外には圧縮サイズを使います。例外はlibandroidfwです。*stored*かどうかではなく*deflated*かどうかで分岐するため、libziparchiveが一度も検査していないエントリを非圧縮サイズでマッピングします。ただし、最善の解決策は、storedとdeflateだけを許可し、それ以外を無効として拒否することです。
フォールトを起こすコードは、特定のプロセスに限られません。Androidの多くの部分がアプリのリソースを読み込みます。インストール時、システムの動作中、別のアプリが検査するときなどです。そのどれもが、不正な形式のエントリを読む側になりえます。どのプロセスがクラッシュするかは、アプリ内のどのファイルが不正で、誰が読むかで決まります。これが、1つのバグを攻撃者が狙える対象に変えます。
インストーラ。マニフェストは、Androidがアプリのインストール時に最初に読むファイルです。そのため、マニフェストが不正だとインストーラがクラッシュし、インストールは失敗します。アプリは端末に入りません。調査の発端となったサンプルが行ったのはこれだけで、インストールに失敗し、何も残りませんでした。
中核のシステムサービス。アプリには、インストール時ではなくインストール後にAndroidが読み込むファイルも含まれます。これらは、中核のシステムサービスがインストール済みアプリの一覧をたどる際に解析する、小さなリソースです。その1つを不正な形式にすると、それを読むサービスはAndroidの大部分をホストするプロセスであるsystem_serverの中で動いているため、そこでクラッシュが起きます。
クラッシュするとAndroidがsystem_serverを再起動し、再起動後にサービスはインストール済みアプリを再びたどって同じファイルを読み、再びクラッシュします。端末は起動を完了できません。これがクラッシュのループです。アプリは一度も開かれず、どのアプリが原因かを示す表示も画面にないまま、system_serverが数秒ごとに停止と再起動を繰り返します。
再起動しても直らず、唯一の脱出口が閉ざされます。端末がループしている間は、ADBで接続したコンピュータがクラッシュの合間にファイルを削除できる場合がありますが、事前に開発者モードを有効にしておく必要があります。しかも、最初にカーネルごと完全に再起動すると、その手段も使えなくなります。クラッシュが起動順序のごく早い段階で起きるためです。セーフモードも役に立ちません。サービスは、セーフモードが有効になる前にファイルを読み込むからです。
呼び出し元のプロセス。インストーラやシステムサービスである必要すらありません。同じコードは、APKを読み込むあらゆるプロセスで動きます。不正な形式のエントリを持つAPKを読んだプロセスが、クラッシュします。
元のサンプルがクラッシュさせたのはインストーラだけでした。当社は、最新のハードウェアで持続型（クラッシュのループ）を再現して計測しましたが、誰かに対して悪用された例は確認していません。
攻撃者による悪用の可能性
端末の無効化。システムサービスが読み込むリソースを不正な形式にすると、クラッシュがsystem_serverで発生します。これは前のセクションで説明したクラッシュのループです。端末は使える状態では二度と起動せず、工場出荷時リセットでしか解消できません。リセットすれば、端末内のすべてが消去されます。
理論上、この方法で作ったアプリは端末を使用不能にし、持ち主に工場出荷時リセットか、使えない端末かの二択を迫れます。こうした能力は、恐喝の材料として悪用されるおそれがあります。
悪意あるアプリを削除不能にする。この手口では、端末は文鎮化しません。動作する悪意あるアプリが、自身のアイコンを不正な形式にします。端末は動き続けますが、ランチャー、設定のアプリ一覧、アプリ自身の情報画面は、そのアイコンを描画しようとしてクラッシュします。これらは、ユーザーがアンインストールのために開く画面です。削除へのあらゆる経路がその手前でクラッシュするため、アプリはインストールされたままになり、マルウェアは動作し続けます。
セキュリティツールの無力化。悪意あるアプリは、この不正な形式を持たせることで、検査するものをすべてクラッシュさせられます。新しいAPKをスキャンするセキュリティアプリ、解析用サンドボックス、自動化されたパイプラインは、いずれも同じAndroidの解析コードにファイルを渡し、同じクラッシュを起こします。
通常のエラーではなくネイティブのフォールトであるため、スキャナーはそれを捕捉して処理を続けることができません。スキャナーは落ち、アプリは検出されず、端末に残り続けます。
アップデートによる配布。理論上、不正な形式のファイルは最初の審査時点で存在している必要はなく、後のアプリアップデートで持ち込めます。その場合、多数の端末が一度に影響を受けかねません。このシナリオについて、これ以上の詳細は提供しません。
このバグが起こすのはプロセスのクラッシュです。コードの実行、データの読み取り、付与されていない権限の取得はできません。サービス拒否の問題であり、ここに挙げたのはバグが可能にする用途であって、実環境で確認した攻撃ではありません。
検出と防御
これはAndroid自体の欠陥であり、公開時点で修正は提供されていません。そのため、端末上で防げる手段は限られます。最も現実的な防御は、バグが発動する前にファイルを見分けることです。
それが可能なのは、不正な形式がファイルの構造から見て取れるからです。アプリをインストールしたり実行したりしなくても、検査すれば足ります。スキャナーは、ファイルを実行せずに調べるだけで、細工されたファイルと通常のファイルを区別できます。
当社の検証では、Bitdefender Mobile Securityは、この不正な形式を持つアプリが端末に届いた時点で、ダウンロードしたファイルでもインストール済みのアプリでも検出し、ユーザーに警告します。ただし、Androidのセキュリティモデルでは、サードパーティ製アプリが単独でインストールを阻止したり、他のアプリを削除したりすることはできません。そのため、警告を受けた後の対応はユーザー次第です。他のセキュリティ製品も、同様の保護を提供している可能性があります。
当社は、この脅威をAndroid.Riskware.Ghostmap.rAとして検出します。
警告の利点は、細工されたファイルが読み込まれる前に届くことです。警告されたダウンロードファイルはインストール前に削除でき、警告されたアプリは端末がまだ使える間に削除できます。しかし、これは目ざといユーザーと、Android端末の解析速度との競争です。アプリは実行される必要がないため、ユーザーが対応できる時間はほとんどありません。
付録：証拠
2026年8月5日のセキュリティパッチを適用したAndroid 17搭載のPixel 10で再現しました。ビルドはgoogle/frankel/frankel:17/CP2A.260805.005/15828068:user/release-keysです。この脆弱性は古いリリースでも検証し、Android 10以降のバージョンで再現できました。
クラッシュ。system_serverが停止した際にAndroidが書き出したトゥームストーンです。
signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0x… (read)
#00 __memcpy_aarch64_simd libc.so
#01 android::_FileAsset::read libandroidfw.so
#02 android::NativeAssetReadChar libandroid_runtime.so
#03 art_jni_trampoline boot-framework.oat
#04 AssetManager$AssetInputStream.read (framework) 記録は、このフォールトを読み込みとして示しています。フォールトを起こしたマッピングは、過大なマップを直接示しています。ディスク上のAPKは数キロバイトでしたが、エントリはファイルが主張したサイズでマッピングされ、フォールトはファイルの実際の末尾よりはるか先で発生しました。
file on disk: 8,408 bytes
mapped region: ~16,781,312 bytes (≈ 16 MB, the size the entry declared)
fault address: ~197,000 bytes past the end of the file ファイルが提供していないメモリを、どのバッファにも対応する書き込みなしに読み込んでいます。これはメモリ破壊ではなく、オーバーリードです。
サードパーティ製アプリでも同じフォールト。クラッシュはsystem_serverに限られません。権限を持たない通常のインストール済みアプリが、スキャナーも行う標準のgetPackageArchiveInfo()でこのファイルを読むと、呼び出しの内部で落ちます。
signal 7 (SIGBUS), code 2 (BUS_ADRERR) (read)
#00 __memcpy_aarch64_simd libc.so
#01 android::_FileAsset::getIncFsBuffer(bool) libandroidfw.so
#02 android::NativeOpenXml libandroid_runtime.so
#04 android.content.res.ApkAssets.openXml (framework)
#05 ApkLiteParseUtils.parseApkLiteInner (framework)
#14 PackageManager.getPackageArchiveInfo (framework) このアプリは呼び出しをcatch (Throwable)で囲んでいましたが、それは機能しませんでした。ネイティブのSIGBUSはJavaの例外ではないため、プロセスはそのまま落ちました。フレーム#01は、先に説明した2つ目のフォールト箇所（アラインメント調整コピーの経路で、getIncFsBufferはensureAlignmentがインライン展開されたもの）です。したがって、両方のクラッシュ経路が、推論だけでなく実際に確認されました。
ループ。クラッシュのたびに再起動と次のクラッシュが数秒間隔で続き、そのつど新しいsystem_serverプロセスが立ち上がります。
08:24:32 Fatal signal 7 (SIGBUS) in system_server (pid 14536)
08:24:33 Zygote: system server (pid 14536) has terminated
08:24:38 Fatal signal 7 (SIGBUS) in system_server (pid 15070)
08:24:39 Zygote: system server (pid 15070) has terminated
08:24:42 Fatal signal 7 (SIGBUS) in system_server (pid 15586)
08:24:43 Zygote: system server (pid 15586) has terminated セーフモード。セーフモードに入っても解決しません。クラッシュは同じサイクルで起き、セーフモードのフラグが立った後、有効になる前に発生します。
WindowManager: SAFE MODE ENABLED
libc: Fatal signal 7 (SIGBUS), code 2 (BUS_ADRERR) in system_server (pid 23886) セーフモードでの実行でも、同じ流れが72回のクラッシュサイクルにわたって繰り返されました。
持続性。アプリのインストールから最初のクラッシュまでは約1秒でした。ある記録では、そのサイクルが110回繰り返されました。その間、画面はずっとブートアニメーションのままでした。
法的通知
この記事は、ユーザー、研究者、セキュリティ専門家が、ここで説明する問題を理解して防御する助けとなるよう、情報提供と研究の目的に限ってBitdefenderが公開するものです。記載内容は公開日時点での当社の調査結果と評価を反映しており、Googleが修正をリリースした場合や追加情報を提供した場合などには、変更されることがあります。内容は「現状のまま」提供され、いかなる種類の保証もなく、法的、技術的、または専門的な助言を構成するものではありません。
説明している攻撃シナリオは仮定のものであり、この問題の潜在的な影響を示す目的でのみ提示しています。この情報を、許可なく端末やシステムにアクセスし、妨害し、または損害を与えるために用いることは禁じられており、違法となる場合があります。Bitdefenderは、準拠法で認められる範囲において、この記事の情報の悪用について責任を負いません。
Googleの評価と回答に関する記述は、Android & Devices Vulnerability Reward Programを通じて受け取った連絡についての当社の理解を反映したものであり、Googleの内部プロセスを説明する意図はありません。Bitdefender Mobile Securityの検出結果は、公開時点での当社の社内テストに基づいており、端末、設定、バージョンによって異なる場合があります。
Android、Google、PixelはGoogle LLCの商標です。その他のすべての商標はそれぞれの所有者に帰属し、識別の目的でのみ使用しています。その使用は、推奨や提携を意味するものではありません。Android Open Source Projectからのコード抜粋の著作権は The Android Open Source Project に帰属し、解説のためにApache License 2.0に基づいて転載しています。
翻訳元: https://www.bitdefender.com/en-us/blog/labs/ghostmap-android
