たのしいバイナリの歩き方
- 愛甲健二 著
- 定価
- 3,058円(本体2,780円+税10%)
- 発売日
- 2013.8.22[在庫なし]
- 判型
- A5
- 頁数
- 320ページ
- ISBN
- 978-4-7741-5918-8 978-4-7741-5958-4
サポート情報
概要
「シューティングゲームをチートから守るには?」
「リバースエンジニアリングされないためには?」
「脆弱性を見つけ、権限を奪取するには?」
普通のプログラミングだけでは意識しない低レイヤーの世界は、コンピュータを自在に操れる楽しさでいっぱい。アセンブラの読み方から最新の応用事例まで、技術と考え方が実例を通じてわかります。
こんな方にオススメ
- コンピュータの仕組み/低レイヤーに興味がある方
- セキュリティに興味のある方
目次
第1章 リバースエンジニアリングでバイナリの読み方を身につける
1.1 まずは解析の流れを体感してみよう
- 安全に解析できる環境を作る
- 解析に必要な3つのツール
- プロセスモニターのログから挙動を確認する
- レジストリへのアクセスから読み取れること
- リバースエンジニアリングとは
- コラム リバースエンジニアリングの技術力を競う大会
1.2 静的解析をやってみよう
- 静的解析と動的解析
- コラム StirlingとBZエディタの違い
- バイナリエディタでファイルの中身を眺めてみる
- アセンブラを読めなくても解析はできる
- ソースコードがない状態から動作を把握する
- 逆アセンブルされたソースコードを確認する
1.3 動的解析をやってみよう
- Process Monitorのフィルタルールを設定する
- デバッガの役割とは
- OllyDbgでより詳細な動作を見極める
- 逆アセンブルされた処理を分析する
- コラム レジスタとは
- 解析結果とソースコードを見比べる
- コラム 好みのデバッガを選ぼう
1.4 最低限のアセンブラ命令だけざっくり把握する
- すべてのアセンブラ命令を覚える必要はない
- アセンブラではどのように条件分岐が実現されているのか
- 引数はスタックに積まれる
- アセンブラからC言語のソースコードをイメージできるか
1.5 アセンブラ命令から動作を把握しよう
- 関数にブレイクポイントをセットする
- 逆アセンブルして重要な部分を見ていく
- コラム アセンブラを書こう
第2章 シューティングゲームをチートから守るには
2.1 メモリダンプを読み解く
- シューティングゲームのルール
- たった4バイト書きかえるだけで高得点に
- メモリダンプを取得するには
- プロセスが異常終了した瞬間の状態からクラッシュの原因を探る
- Just-In-Timeデバッグを有効にするには
- ダンプファイルから原因の手がかりを見つける
- コラム パソコン以外のコンピュータを解析することはできるのか
- コラム Java製アプリを解析するには
2.2 動作を解析されないようにするには
- アンチデバッギングの手法
- コラム デバッグを検知するさまざまな手法
- コードを難読化して解析されるのを防ぐ
- コラム 難読化に関する話題
- 実行ファイルを実行できる状態のまま圧縮する
- 圧縮された実行ファイルを展開する ~アンパック
- UPXを手動でアンパックして仕組みを理解する
- ハードウェアブレイクポイントを使ってASPackをアンパックする
- コラム .NET製アプリを解析するには
第3章 ソフトウェアの脆弱性はこうして攻撃される
3.1 バッファオーバーフローを利用して任意のコードが実行される仕組み
- バッファオーバーフローが起こるプログラムの例
- 一般ユーザーが所有者権限でプログラムを実行する仕組み
- どのようにして権限は奪われるのか
- スタックにおけるメモリの使われ方
- こうして攻撃者が用意したコードは実行される
- gdbでコードが実行されてしまう状況にあることを確認する
- 攻撃用コードの例
- shellcodeとして使えるマシン語コードを生成する
- 0x00を使わないように改良する
- コラム printf系関数に起因するフォーマットストリングバグ
3.2 攻撃を防ぐ技術
- アドレスをランダムに決定する ~ASLR
- 実行コードが置かれるメモリ空間以外には、極力実行権限を持たせない ~Exec-Shield
- スタックが破壊されたことを検知するマシン語をコンパイル時に挿入する ~StackGuard
3.3 セキュリティ機能を迂回する技術
- libcの中にある関数を利用して攻撃する ~Return-into-libc
- ランダム化されていないモジュール内にあるアセンブラコードを使って攻撃する ~ROP
- コラム セキュリティがいたちごっこになる理由
第4章 処理を自在に実行させるプログラミングのテクニック
4.1 デバッガを自作して動作を理解する
- 「かんたんなものを作ってみる」ことでたのしく理解を深める
- デバッガはどのような仕組みになっているのか
- 逆アセンブラを実装する
- 改良したデバッガを実行してみる
4.2 他プロセス内で任意のコードを実行させる ~コードインジェクション
- 他プロセスへコードを注入させる3つの方法
- SetWindowsHookExでOSのシステムメッセージをフックする
- レジストリのAppInit_DLLsにDLLのパスを登録しておく
- CreateRemoteThreadで他プロセス内にスレッドを生成する
- 関数を挿入する
4.3 処理を任意のものに置きかえる ~APIフック
- APIフックの2つのタイプ
- DetoursでかんたんにAPIフックを実現
- メッセージのタイトルを変えて動作を確認してみる
- コラム 「ハッキングらしい」技術の象徴がDLLインジェクションとAPIフック?
第5章 ツールを駆使してより深い世界へ
5.1 Metasploit Frameworkで脆弱性を検証/調査する
- Metasploit Frameworkとは
- 脆弱性情報はどこで手に入るのか
- Exploitを試す環境を作る
- 脆弱性を突いてみる
- コラム shellcodeをもっと勉強したいならば
- ROPの実例を見る
5.2 EMETでROP対策の仕組みをのぞく
- EMETとは
- Anti-ROPのアイディアはBlueHat Prizeで入賞したもの
- いかにして攻撃を防ぐか
- ローダーの処理を把握する
- DLLはどのような処理をしているのか
- CALL-RETNをチェックする
- どうやって誤検知を防ぐか
- スタックの正当性をチェックする
5.3 REMnuxでマルウェアを解析する
- REMnuxとは
- パターンデータベースを更新する
- ディレクトリをスキャンする
5.4 ClamAVでマルウェアやExploitを検知する
- ClamAVのパターンファイルの特徴
- .cvdファイルを展開してみる
- 検知したファイルの詳細を知る
- 使われているパッカーやマルウェアらしいものを検出する
5.5 Zero Wine Tryoutsでマルウェアを解析する
- REMnuxとZero Wine Tryoutsの違い
- 動作の仕組み
- ユーザーインターフェースを表示させる
- 解析レポートの情報を確認する
- コラム 自分でツールを開発してみよう
5.6 人の手による解析を極力減らすには ~ヒューリスティック技術
- 1日平均で60000個のマルウェアに対応する限界
- ヒューリスティック技術というイノベーション
- 2つのマルウェアでテストしてみると
Appendix
A.1 IDAをインストールする
A.2 OllyDbgをインストールする
A.3 WinDbgをインストールする
A.4 Visual Studio 2010をインストールする
A.5 Metasploitをインストールする
A.6 解析ツール
- Stirling/BZエディタ
- Process Monitor
- Process Explorer
- Sysinternalsツール
- うさみみハリケーン
A.7 参考文献
プロフィール
愛甲健二
ネットエージェント株式会社で各種ソフトウェアのリバースエンジニアリング、マルウェア解析、ペネトレーションテストなどを担当。2008年7月に取締役に就任。その後、株式会社フォティーンフォティ技術研究所(現 株式会社FFRI)にてソフトウェア解析を中心としたコンピュータセキュリティ技術のリサーチ、ソフトウェア開発を行う。
Black Hat Japan 2008(日本)、HITCON 2011(台湾)などのカンファレンスにて研究成果を発表。2010年よりセキュリティ&プログラミングキャンプ(現 セキュリティキャンプ)にてソフトウェアセキュリティクラスの講師を務める。
著書に『アセンブリ言語の教科書』、『TCP/IPの教科書』(いずれもデータハウス 刊)などがある。
ホームページ:http://07c00.com/・http://ruffnex.oc.to/kenji
Twitter:http://twitter.com/07c00/
著者の一言
はじめに
だれもがコンピュータを使う時代になり、利便性も格段に上がりました。しかしその分、システムは複雑になり、技術者が学ぶべきことは多くなり、同じコンピュータ技術であってもまったく知らないブラックボックスが増えました。
そんな疑問に答えるための味方になってくれるのが、アセンブラなどバイナリレベルの知識です。
時代はWebアプリケーション全盛ですが、バイナリレベルの知識はいまなお活躍の場を失っていません。たとえば
「C/C++で開発中のプログラムに原因不明のバグがあり、ソースコードを眺めてみても、原因がどうしてもわからない」
という場合、アセンブラでコードを書くことはなくとも、読むことができれば、デバッガを立ち上げ、即座にバグの発生個所を特定し、対処できる場合があります。
また、他人が作ったライブラリにバグがあり、ソースコードが手元にない場合でも、内部を解析し、問題個所を回避したり、あるいはライブラリ作成者に詳細を伝えられます。
さらに例を挙げるならば、アセンブラを学ぶことでCPUに近い部分を理解できるため、カーネルやドライバといったブラックボックスになりがちな低レイヤーの問題にも対応できますし、それらを開発する場合にも役立ちます。
ただ正直なところを言うと、「役に立つ/立たない」「人気がある/ない」といったことは、どうでもいい話です。なぜなら私の経験上、「需要がありそう」「役に立ちそう」などと感じて学び始めたことを、実際に習得できたためしがないからです(笑)。私があまり優秀ではなかったからかもしれませんが、学生時代に「勉強しなさい」と言われて、素直に勉強した人がどれだけいるでしょうか? 統計をとったわけではありませんが、実感として全国で1%未満でしょう。
では、ものごとを習得するには、いったい何が必要なのでしょう?
私は中学生の頃にプログラミングを学び始めました。将来プログラマになろうとも、技術でお金を稼ごうとも思っていませんでしたが、当時の私はコンピュータに夢中になり、毎日夜ふかしし、次第に学校の成績も落ち、両親を心配させるほどプログラミングにのめり込みました。
なぜ、あのとき、あれほどまでにコンピュータにハマったのか?
それは「プログラミングがおもしろかったから」。自分の書いたコードが書いたとおりに動くことが、思ったとおりに動かないことが、その理由を探すことが、ただただ楽しかったからだと思います。
私はそういった「楽しい」「もっと知りたい」と思えるような技術書を目指し、本書を執筆しました。そして、無数にあるプログラミング言語の中で、アセンブラが一番「楽しい」を持っている言語だとあらためて思いました。
あなたが「低レイヤーの話っておもしろそうだな」とふと思ってこの本を手に取ったならば、その予想以上に読む価値のある1冊になっている自負しています。
本書を通して、バイナリレベルの世界の楽しさを少しでも感じていただければ幸いです。