Hello there, ('ω')ノ
🔐 主なセキュリティ機能一覧
| 機能名 | 目的 |
|---|---|
| ASLR（アドレス空間配置のランダム化） | 攻撃者によるメモリ内のコード位置特定を困難にする |
| DEP（Data Execution Prevention） | データ領域（スタックなど）でのコード実行を防止 |
| SEAndroid（SELinux for Android） | OSレベルでのアクセス制御 |
| Verified Boot | 改ざんされたOSの起動を防止 |
| サンドボックス | アプリごとの実行空間を分離 |
| パーミッションモデル | アプリが扱える情報・機能を制限 |
| 実行時パーミッション（runtime permission） | インストール時ではなく、使用時に確認する仕組み |
🧠 ASLR（Address Space Layout Randomization）
✔ 役割：
実行時にライブラリやスタックの位置をランダムに配置して、リターンアドレスなどを予測できなくする
✔ 診断時の影響：
ROP（Return-Oriented Programming）やバッファオーバーフローの攻撃成功率が下がる → ただし、古い端末や非PIEバイナリではASLRが弱いこともあります
🚫 DEP（Data Execution Prevention）
✔ 役割：
スタックやヒープなど、データ用のメモリ領域でコードの実行を完全に禁止 → 「コード注入してスタック上から実行」は原則できない
✔ 診断時の影響：
昔ながらのシェルコード注入では失敗する → その代替手段がROPやJOP（Jump-Oriented Programming）
🛡 SEAndroid（SELinux on Android）
✔ 役割：
Linuxの**SELinux（強制アクセス制御）**をAndroidに応用したもの。 プロセスごとに「できること／できないこと」をポリシーで厳密に制御。
✔ 実例：
- アプリが他アプリの内部ファイルにアクセス不可
- システム領域の読み書き・実行制限
logcatへのアクセス制限（非rootアプリは読めない）
✔ 診断時の影響：
- SEAndroidポリシーを変更しない限り、rootを取ってもできない操作がある
- 一部ツール（Drozer等）でSEAndroidによる制限を受けることもある
🔍 Verified Boot（ブート検証）
✔ 役割：
起動時にOSイメージの整合性を検証し、改ざんがあれば起動しないようにする → root化やROM改造が難しくなる
✔ 診断時の影響：
- Android 7以降はこの機能が強化され、診断用のroot取得に一手間かかる
- 非公式ROMやカスタムリカバリ（TWRP）で回避するケースが多い
🧱 サンドボックス（アプリ分離）
✔ 役割：
各アプリは**独立したユーザーID（UID）**で動作することで、他アプリのデータやプロセスに干渉できないようにする
✔ 診断時の影響：
- 他アプリのデータベースやファイルは、root化しない限りアクセスできない
- 同一署名アプリを使った診断（sharedUserId）などが例外的に可能
✅ 実行時パーミッション（Runtime Permission）
Android 6以降では、ユーザーが実行中に権限を許可／拒否できる仕様に変わりました。
✔ 診断時のポイント：
- ユーザーが拒否してもアプリが機能するか？（フェールセーフ設計）
- 許可した直後に情報を抜かれる設計ではないか？（悪用リスク）
✅ 診断時に確認すべき視点
| 項目 | 質問 |
|---|---|
| ASLR/DEPが有効か？ | 実行ファイルのビルド方法、OSバージョン |
| SELinuxはPermissiveか？ | adb shell getenforce で確認 |
| アプリは適切にパーミッション制御されているか？ | 不要な権限が要求されていないか？ |
| Rootなしでも診断できるか？ | 動的解析がどこまで可能か評価 |
✅ まとめ
- Androidは多数の多層防御（Defense-in-Depth）機能を実装している
- ASLRやDEPはバイナリ攻撃への防御、SEAndroidはOSレベル制御
- セキュリティ診断では、それらが無効化／不適切に設定されているかを確認することも重要
- 防御機構を理解することで、攻撃が“なぜ通るのか”／“なぜ防がれているのか”の理解が深まる
Best regards, (^^ゞ
