Hello there, ('ω')ノ
🔐 ASLR（アドレス空間配置のランダム化）とは？
✅ 一言でいうと：
「メモリ内の各コード・データの位置を、毎回ランダムに変えることで、攻撃者が“場所を特定できなくなる”ようにする」
🧠 背景：
従来の攻撃（例：バッファオーバーフロー）では、ジャンプ先のアドレスを予測して書き換えるという方法が使われていました。
しかし、ASLRが有効だと…
- 実行ファイル（バイナリ）の読み込まれる位置
- ライブラリ（libc.soなど）のアドレス
- スタックやヒープ領域のアドレス
が、毎回ランダムになるため、攻撃者が正確にジャンプ先を設定できず、攻撃が失敗するのです。
🔍 診断時の確認方法：
cat /proc/[PID]/maps
このコマンドで、現在のプロセスがどのアドレス空間に何を読み込んでいるかを確認できます。 → 同じアプリを何度も起動して、読み込み位置が異なっていれば、ASLRが有効です。
⚠️ 無効なケース：
- Android 4.x 以前ではASLRが未実装または限定的
-no-pieでビルドされた古いバイナリ- NDKの一部ネイティブコードでPIE対応が不十分なもの
🚫 DEP（データ実行防止）とは？
✅ 一言でいうと：
「スタックやヒープなど、“データ用”メモリ上でプログラムを実行することを禁止する」
🧠 背景：
バッファオーバーフロー攻撃の古典的手法は、「シェルコードをスタックに書き込み、リターンアドレスを書き換えてジャンプ」でした。 しかし、DEPが有効だと、スタックは**「実行不可属性」**としてマークされているため、ジャンプしてもクラッシュして終わります。
🔍 診断時の確認方法：
バイナリを以下のようにビルドしているかどうかを見ると、DEPの有無が推測できます。
readelf -l [対象バイナリ] | grep GNU_STACK
出力例：
GNU_STACK 0x0 0x0 0x0 0x0 0x0 RWE
RWE（Read Write Execute）ならDEP 無効RW（Read Write）ならDEP 有効
⚠️ DEPを回避する攻撃とは？
DEPが有効な環境では、スタック上でのコード実行ができません。 → そこで登場するのが ROP（Return-Oriented Programming）！
ROPは、既存のコード片（ガジェット）をつなぎ合わせて処理を実行する手法で、DEPを迂回します。 そのROPを困難にするのがASLRです。 → つまり、ASLRとDEPはセットで使ってこそ強力な防御になるのです。
🧪 実際の診断での見え方
✔ 攻撃が失敗するケース
- ROP攻撃で使うガジェットのアドレスが毎回変わる（ASLR）
- スタックにジャンプしてもクラッシュする（DEP）
✔ 攻撃が成功する条件
- 非PIEバイナリでASLRが無効
- スタックが実行可能（DEPが無効）
.soライブラリの読み込み位置が固定でROPが成立
✅ 診断ポイントのまとめ
| 観点 | チェック方法 |
|---|---|
| ASLRが有効か？ | maps ファイルでアドレスがランダムか確認 |
| PIE対応しているか？ | readelf -h の「Type」が DYN かどうか |
| DEPが有効か？ | readelf -l で GNU_STACK の属性が RWかRWEか |
| ROPが成立する余地は？ | .so に含まれるガジェット、リターン先などを分析 |
✅ まとめ
- ASLR は攻撃者がメモリアドレスを予測できないようにする防御機構
- DEP は「実行すべきでない場所」でのコード実行を防ぐ仕組み
- 両者は バッファオーバーフローやROP攻撃に対する根本的な防御となる
- 診断時には、ASLR/DEPが有効かを確認し、もし無効なバイナリがある場合は注意深く分析しよう
Best regards, (^^ゞ
