プロジェクト

全般

プロフィール

CTF Pwn » 履歴 » バージョン 12

kanata, 2025/05/19 07:26

1 1 kanata
# CTF Pwn
2
3 4 kanata
{{last_updated_at}}
4
5 1 kanata
むぅ。攻撃手法について、ぜんぜん体系化できん。。もうちょっと理解が必要だ。
6
7
{{toc}}
8
9
# Linuxにおけるソフトウェアの脆弱性とセキュリティ機構まとめ
10
11
がんばって整理してみる。
12
13 6 kanata
![fig01.png](fig01.png)
14
15
16 1 kanata
17 6 kanata
18 9 kanata
19 1 kanata
### Pwnable の流れ
20
21
ユーザからの入力は、ローカル変数(stack)、グローバル変数(.data、もしくは、.bss)、ヒープ領域(heap)のいずれかに格納される。
22
23
| C言語における変数の種類  | 格納される領域       | 格納される方向                         |
24
|--------------------------|----------------------|----------------------------------------|
25
| ローカル変数             | stack                | アドレスの値が大きいほうから小さい方へ |
26
| グローバル変数           |.data、もしくは、.bss | アドレスの値が小さいほうから大きい方へ |
27
| malloc関数で確保した領域 | heap                 | アドレスの値が小さいほうから大きい方へ |
28
29
もし仮に、 Stack buffer over flow の脆弱性があった場合、ユーザからの入力はローカル変数で定義したサイズを超えて、stack内のメモリ領域を書き換える事ができる。
30
書き換える内容を工夫することで、以下ができる。
31
32
* 他の領域(heapや.bss等々)を読みこんだり書き換えたりできる。
33
* プログラムの流れを変え、任意の命令を実行できる。
34
35
# Linux kernelのメモリ管理
36
37
## 全セクション
38
39
調査方法
40
41
~~~
42
# readelf -S /bin/ls
43
~~~
44
45
~~~
46
# gdb /bin/ls
47
(gdb) b exit
48
(gdb) r
49
(gdb) i files
50
(gdb) i proc
51
(gdb) shell cat /proc/[PID]/maps
52
~~~
53
54
| セクション名     | 開始アドレス(サンプル)| NX bit | 説明 |
55
|------------------|-----------------------|--------|------|
56
| .interp          | 0x00400238 | r-xp | 実行形式のロードと動的リンクを行う共有ライブラリ(/lib64/ld-linux-x86-64.so.2とか)を指定 [ゆずさん研究所](http://d.hatena.ne.jp/yz2cm/20131012/1381610473)
57
| .note.ABI-tag    | 0x00400254 | r-xp | このセクションは、何らかの方法でファイルに印をつける情報を保持している [ゆずさん研究所](http://d.hatena.ne.jp/yz2cm/20131013/1381614214)
58
| .note.gnu.build-id| 0x00400274 | r-xp | ビルドされたファイルに対するユニークなIDが入っている。core dumpに含まれる [わらばんし仄聞記](http://warabanshi.hatenablog.com/entry/2013/05/18/231628)
59
| .gnu.hash        | 0x00400298 | r-xp | シンボル名の検索を高速化するための .dynsym に関連付けられたハッシュテーブル[ゆずさん研究所](http://d.hatena.ne.jp/yz2cm/20131013/1381662391)
60
| .dynsym          | 0x004002d0 | r-xp | 動的リンク用のシンボルテーブル。[わらばんし仄聞記](http://warabanshi.hatenablog.com/entry/2013/05/18/231628) [ゆずさん研究所](http://d.hatena.ne.jp/yz2cm/20131014/1381702665)
61
| .dynstr          | 0x00400f30 | r-xp | .dynsymセクションヘッダのsh_nameが参照する文字列(シンボル名)を格納している [わらばんし仄聞記](http://warabanshi.hatenablog.com/entry/2013/05/18/231628) [ゆずさん研究所](http://d.hatena.ne.jp/yz2cm/20131014/1381705567)
62
| .gnu.version     | 0x004014ec | r-xp | .dynsymで定義されるシンボルに対応するバージョンの一覧 [わらばんし仄聞記](http://warabanshi.hatenablog.com/entry/2013/04/11/040554)
63
| .gnu.version_r   | 0x004015f8 | r-xp | .gnu.versionが指すバージョン値についての情報が示されているセクション [わらばんし仄聞記](http://warabanshi.hatenablog.com/entry/2013/05/18/231628)
64
| .rela.dyn        | 0x00401688 | r-xp | リロケータブルなシンボルを dynamic に解決するためのセクション [新千葉 ガーベージ・コレクション](http://ryos36.hatenablog.com/entry/20100922/1285145438)
65
| .rela.plt        | 0x00401760 | r-xp | 動的リンクのために書き替えが必要なアドレスのリスト。アドレスとシンボルをペアにして関連付けている [七誌の開発日記](http://7shi.hateblo.jp/entry/2013/05/25/103050) [わらばんし仄聞記](http://warabanshi.hatenablog.com/entry/2013/05/18/231628)
66
| .init            | 0x00402228 | r-xp | このセクションにはプロセスが実行される前に実行される実行可能な命令が格納されます。プログラムの実行が始まるときに、OSはメインプログラムエントリー(C言語ではmain関数)をコールする前にこのセクションのコードを実行します。
67
| .plt             | 0x00402250 | r-xp | 遅延リンクのために使われる。関数本体へのジャンプコードの集合 [わらばんし仄聞記](http://warabanshi.hatenablog.com/entry/2013/05/18/231628)
68
| .text            | 0x00402990 | r-xp | プログラムのうち、機械語の部分を格納するためのセクション
69
| .fini            | 0x0041295c | r-xp | プロセスの実行終了時に実行される実行可能な命令が格納される。プログラムが正常終了するときにOSはこのセクションのコードを実行する。
70
| .rodata          | 0x00412980 | r-xp | プログラムのうち、定数(const)を格納するためのセクション。C言語では、「プログラム中の文字列定数」「const宣言された定数」などが格納される。[セクションとか.textとか](http://www.ertl.jp/~takayuki/readings/info/no02.html)
71
| .eh_frame_hdr    | 0x00416650 | r-xp |  C++のランタイムが eh_frame にアクセスするためのコードが入るセクション [メモ書き](http://nsaito-nmiri.hateblo.jp/entry/2015/05/22/201534)
72
| .eh_frame        | 0x00416d98 | r-xp | 例外をサポートしている言語の場合、情報を保持しておくセクション。バックトレース(スタックトレース)をとるための情報が入ったフレーム [わらばんし仄聞記](http://warabanshi.hatenablog.com/entry/2013/05/18/231628)
73
| .init_array      | 0x0061a320 | r--p | 関数のアドレスが格納された配列になっている。.initセクション実行の後に、順番に実行される。
74
| .fini_array      | 0x0061a328 | r--p | 関数のアドレスが格納された配列になっている。.finiセクション実行よりも前に、順番に実行される。
75
| .jcr             | 0x0061a330 | r--p | Java Class Reference らしい。
76
| .data.rel.ro     | 0x0061a340 | r--p | RELRO関係??
77
| .dynamic         | 0x0061ada8 | r--p | 動的リンクに必要な情報を集めたテーブル
78
| .got             | 0x0061afa8 | r--p | 動的リンクされた関数などのアドレステーブル。ここをインタプリタで書き替えることにより、動的リンクを実現する。
79
| .got.plt         | 0x0061b000 | rw-p | 動的リンクされた関数などのアドレステーブル。ここを書き替えることにより、動的リンクを実現する。Full RELROの場合は、存在しない。 [七誌の開発日記](http://7shi.hateblo.jp/entry/2013/05/25/103050)
80
| .data            | 0x0061b3c0 | rw-p | プログラムのうち、初期値を持つ変数を格納するためのセクション。C言語では、「0以外の初期値を持つ大域変数」「0以外の初期値を持つ静的局所変数」がここに置かれる。データとして初期値を持ち、プログラムローダは書き込み可能なメモリを確保した後、初期値を書き込む。
81
| .bss             | 0x0061b600 | rw-p | プログラムのうち、初期値を持たない変数を格納するためのセクション。C言語では、「初期値が指定されない大域変数」「初期値が0の大域変数」「初期値が指定されない静的局所変数」「初期値が0の静的局所変数」が格納される。C言語の規約では、「この領域はすべて0で初期化されなければならない」と規定されているため、プログラムローダは書き込み可能なメモリを確保した後、すべて0で初期化する。
82
| [heap]↓         | 0x0061c000-0x0063e000     | rw-p     | C言語におけるmalloc関数等で確保した領域が配置される
83
| shared-object    | 7ffff0415000-7ffff7ffa000 | 以下参照 | 共有ライブラリ(.soのファイル)のメモリ配置場所
84
| [vdso]           | 7ffff7ffa000-7ffff7ffc000 | r-xp     | ここ([[CTF Pwn#vDSO - 仮想 ELF 動的共有オブジェクトの概要]])参照
85
| shared-object    | 7ffff7ffc000-7ffff7fff000 | 以下参照 | 共有ライブラリ(.soのファイル)のメモリ配置場所
86
| [stack]↑        | 7ffffffea000-7ffffffff000 | rw-p     | C言語における関数呼び出し元のアドレス退避先、及び、ローカル変数のメモリ配置先
87
| [vsyscall]       | ffffffffff600000-ffffffffff601000 | r-xp |  カーネル空間の実行コードをユーザ空間から参照できる [int0x80 と sysenter を切り替える vsyscall](https://github.com/hiboma/hiboma/blob/master/Linux%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E8%A7%A3%E8%AA%AD%E5%AE%A4/Linux%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E8%A7%A3%E8%AA%AD%E5%AE%A4-5-3.md)
88
| kernel-area      |  |  | カーネルが使うところ
89
90
> NX bit
91
92
>>r = read
93
>>w = write
94
>>x = execute
95
>>s = shared
96
>>p = private (copy on write)
97
98
> shared-object の NX bit の例 (soによって中身が4分割されてNX bitを設定されたり、まちまち)
99
100
~~~
101
7ffff0415000-7ffff693c000 r--p 00000000 fd:00 181108739                  /usr/lib/locale/locale-archive
102
7ffff693c000-7ffff6952000 r-xp 00000000 fd:00 72515859                   /usr/lib64/libpthread-2.17.so
103
7ffff6952000-7ffff6b52000 ---p 00016000 fd:00 72515859                   /usr/lib64/libpthread-2.17.so
104
7ffff6b52000-7ffff6b53000 r--p 00016000 fd:00 72515859                   /usr/lib64/libpthread-2.17.so
105
7ffff6b53000-7ffff6b54000 rw-p 00017000 fd:00 72515859                   /usr/lib64/libpthread-2.17.so
106
7ffff6b54000-7ffff6b58000 rw-p 00000000 00:00 0 
107
7ffff6b58000-7ffff6b5c000 r-xp 00000000 fd:00 72518875                   /usr/lib64/libattr.so.1.1.0
108
7ffff6b5c000-7ffff6d5b000 ---p 00004000 fd:00 72518875                   /usr/lib64/libattr.so.1.1.0
109
7ffff6d5b000-7ffff6d5c000 r--p 00003000 fd:00 72518875                   /usr/lib64/libattr.so.1.1.0
110
7ffff6d5c000-7ffff6d5d000 rw-p 00004000 fd:00 72518875                   /usr/lib64/libattr.so.1.1.0
111
7ffff6d5d000-7ffff6d60000 r-xp 00000000 fd:00 72515794                   /usr/lib64/libdl-2.17.so
112
7ffff6d60000-7ffff6f5f000 ---p 00003000 fd:00 72515794                   /usr/lib64/libdl-2.17.so
113
7ffff6f5f000-7ffff6f60000 r--p 00002000 fd:00 72515794                   /usr/lib64/libdl-2.17.so
114
7ffff6f60000-7ffff6f61000 rw-p 00003000 fd:00 72515794                   /usr/lib64/libdl-2.17.so
115
116
117
118
~~~
119
120
ELFの動的リンク
121
http://www.slideshare.net/7shi/startprintf2-elf
122
123
Github - torvalds/linux/Documentation/x86/x86_64/mm.txt
124
https://github.com/torvalds/linux/blob/master/Documentation/x86/x86_64/mm.txt
125
126
Linux メモリ管理を理解したい
127
https://qiita.com/kimullaa/items/998c2599c9f51bac5be4
128
129
130
131
## 主要なセクション
132
133
CTFだけ考えるなら、以下を押さえておけば、だいたいなんとかなる。
134
135
| セクション名     | 開始アドレス(サンプル) | NX bit | ざっくり説明 |
136
|------------------|------------------------|--------|--------------|
137
| .plt             | 0x00402250             | r-xp   | ここ([[CTF Pwn#PLT(Procedure Linkage Table)とGOT(Global Offset Table)]])参照
138
| .text            | 0x00402990             | r-xp   | 実行される機械語のところ
139
| .rodata          | 0x00412980             | r-xp   | プログラム中の文字列定数、const宣言された定数
140
| .got             | 0x0061afa8             | r--p   | ここ([[CTF Pwn#PLT(Procedure Linkage Table)とGOT(Global Offset Table)]])参照 
141
| .got.plt         | 0x0061b000             | rw-p   | ここ([[CTF Pwn#PLT(Procedure Linkage Table)とGOT(Global Offset Table)]])参照。Full RELROの場合は、存在しない。
142
| .data            | 0x0061b3c0             | rw-p   | 初期値を持つ変数
143
| .bss             | 0x0061b600             | rw-p   | 初期値を持たない変数
144
| [heap]↓         | 0x0061c000-0x0063e000  | rw-p   | malloc関数を実行した際のメモリ確保先
145
| shared-object    | 7ffff0415000-7ffff7fff000         | いろいろ | 共有ライブラリ
146
| [stack]↑        | 7ffffffea000-7ffffffff000         | rw-p     | 関数呼び出し元のアドレス退避先、ローカル変数のメモリ配置先
147
| kernel-area      |                                   |          |
148
149
## PLT(Procedure Linkage Table)とGOT(Global Offset Table)
150
151
libc.soなどにある外部関数のアドレスを動的に求める機構。
152
.pltセクションが外部アドレスを解決し、.got.pltに保存(キャッシュ)する。スタティックリンクだと存在しない。
153
154
Partial RELROの場合、遅延バインドという動作になる。
155
共有ライブラリにある関数アドレスに対して、初回呼び出し時に、.got.pltにキャッシュする方式。
156
そのため、.got.pltセクションは書き込み可能な状態で存在し、GOT overwriteという攻撃を受けるリスクがある。
157
158
![fig02.png](fig02.png)
159
160
例えば、C言語でputs関数を呼び出すコーディングをした際の動きは、以下の通り。
161
162
* ①.textセクションにputs関数を呼び出す機械語が書かれている。puts関数の呼び出し先アドレスは、.pltセクションのputs関数がエントリされている部分になる。
163
* ②呼び出された.pltセクションのputs関数の箇所は、さらに .got.pltセクションのputs関数がエントリされているアドレスを呼び出す。
164
* ③.got.pltセクションは、本物の共有ライブラリ(libc.so)のputs関数を呼び出す。
165
166
Full RELROの場合は、.got.pltセクションは存在しない。
167
遅延バインドを使わず、プロセス起動時に外部アドレスを解決して.gotセクションに書き込む。書き込み後にNXによりリードオンリーにする。
168
動きは、.got.pltが、.gotに代わる以外は、Partial RELROの場合と同様である。
169
170
![fig03.png](fig03.png)
171
172
173
174
175
176
PLTエントリはELF中の固定アドレスであり、ASLRが有効であってもアドレスは固定。
177
PIEが適用されている場合はアドレスがランダムとなる。
178
179
### 参考
180
181
ψ(プサイ)の興味関心空間 - ELFの再配置シンボルの解決
182
http://ledyba.org/2014/06/13093609.php
183
184
脱力系日記 GOT、PLTとIAT
185
http://tkmr.hatenablog.com/entry/2017/02/28/030528
186
187
188
189
## vDSO - 仮想 ELF 動的共有オブジェクトの概要
190
191
一部のアーキテクチャの時間関数などは、高速化のためカーネル空間に切り替わらず、vsyscallのみで実現している。
192
vsyscallに必要な関数群をユーザー空間のアプリケーションに提供する仕組み。
193
194
[Man page of VDSO](https://linuxjm.osdn.jp/html/LDP_man-pages/man7/vdso.7.html)
195
196
## スタックとスタックフレームの仕組み
197
198
![fig04.png](fig04.png)
199
200
黄色の部分は SSP による canary値。後述する。
201
202
[ELF Auxiliary Table](http://articles.manugarg.com/aboutelfauxiliaryvectors)
203
要はカーネルから渡される各種値のテーブル。アンチデバッグとして、稀にこの値が利用されることがある。
204 12 kanata
205
206
207
208
209
# 参考:Mohit Mishra
210
211
{{rawhtml(<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Memory Segmentation Cheatsheet <a href="https://t.co/fI1hX3pxFO">pic.twitter.com/fI1hX3pxFO</a></p>&mdash; Mohit Mishra (@chessMan786) <a href="https://twitter.com/chessMan786/status/1912121847107465628?ref_src=twsrc%5Etfw">April 15, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
212
213
{{rawhtml(<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Diagram with Each Section and Details to it <a href="https://t.co/H1AaX1FPLv">pic.twitter.com/H1AaX1FPLv</a></p>&mdash; Mohit Mishra (@chessMan786) <a href="https://twitter.com/chessMan786/status/1921939038157865272?ref_src=twsrc%5Etfw">May 12, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
214
215
{{rawhtml(<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Memory Segment <a href="https://t.co/j8abA4T0kB">pic.twitter.com/j8abA4T0kB</a></p>&mdash; Mohit Mishra (@chessMan786) <a href="https://twitter.com/chessMan786/status/1921581295773331667?ref_src=twsrc%5Etfw">May 11, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
216
217
{{rawhtml(<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Physical vs Virtual Memory Map <a href="https://t.co/fHDsNlsCd6">pic.twitter.com/fHDsNlsCd6</a></p>&mdash; Mohit Mishra (@chessMan786) <a href="https://twitter.com/chessMan786/status/1909255590989451502?ref_src=twsrc%5Etfw">April 7, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
218
219
{{rawhtml(<blockquote class="twitter-tweet"><p lang="en" dir="ltr">This process repeats continuously, allowing the CPU to execute programs efficiently. <a href="https://t.co/SeHPCUGK9q">pic.twitter.com/SeHPCUGK9q</a></p>&mdash; Mohit Mishra (@chessMan786) <a href="https://twitter.com/chessMan786/status/1921975947739463721?ref_src=twsrc%5Etfw">May 12, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
220
221
{{rawhtml(<blockquote class="twitter-tweet"><p lang="zxx" dir="ltr"><a href="https://t.co/2NcUtm92VY">pic.twitter.com/2NcUtm92VY</a></p>&mdash; Mohit Mishra (@chessMan786) <a href="https://twitter.com/chessMan786/status/1923381436058386617?ref_src=twsrc%5Etfw">May 16, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
222
223
{{rawhtml(<blockquote class="twitter-tweet"><p lang="zxx" dir="ltr"><a href="https://t.co/WzwhcfgFVH">pic.twitter.com/WzwhcfgFVH</a></p>&mdash; Mohit Mishra (@chessMan786) <a href="https://twitter.com/chessMan786/status/1923779599084769727?ref_src=twsrc%5Etfw">May 17, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
224
225
{{rawhtml(<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Normal Stack vs Stack with Buffer Overflow <a href="https://t.co/ZMYMFgIIUq">pic.twitter.com/ZMYMFgIIUq</a></p>&mdash; Mohit Mishra (@chessMan786) <a href="https://twitter.com/chessMan786/status/1923766880688538092?ref_src=twsrc%5Etfw">May 17, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
226
227
{{rawhtml(<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Amend version with dynamic linking <a href="https://t.co/ciFkvHRxt6">pic.twitter.com/ciFkvHRxt6</a></p>&mdash; Jemmy (@Jemmy__Wong) <a href="https://twitter.com/Jemmy__Wong/status/1923794709685862445?ref_src=twsrc%5Etfw">May 17, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247 1 kanata
248
# Linuxのセキュリティ機構
249
250
## NX bit
251
252
プロセスの全てのメモリ領域において、読み・書き・実行が可能だと、セキュリティ上良くない。
253
セクション毎に、読み・書き・実行の権限を制御できるようにしたのが、NX。
254
255
Microsoft Windows的には **DEP** と呼ばれている。
256
257
## ASLR
258
259
通常、同じプログラムであれば、関数のアドレスや、変数の格納先アドレス等、何度実行しても変化することはない。
260
この「変化しない」という性質を利用して、任意の関数を呼ばれたりして悪意のある攻撃につながってしまう。
261
262
ASLRは、heap領域以降のアドレスをランダム化(アドレス空間配置のランダム化)することで、これらの攻撃を防ぐのが目的。
263
ASLRだと起動するたびにheap領域以降のアドレスが変化する。
264
265
ただし、ランダム化されるのheap領域以降と限定されるため、アドレスが固定化されている部分を利用した攻撃に対するリスクは残っている。
266
267
通常のheapの開始アドレスは、0x0804XXXXとかになるが、ASLRだと0xfXXXXXXXで始まるアドレスになる。
268
269
## SSP(GCC Stack-Smashing Protector)
270
スタックバッファオーバーフローを防ぐセキュリティ機構の一つ。
271
SSPを有効にすると、関数の呼び出し時にスタックにcanaryと呼ばれる値が置かれる。
272
関数から出る時(リターン前)に、canaryが変更されていないか検証(__stack_chk_fail関数の呼出)され、書き換えられていたら強制終了する。
273
274
### master canaryはどこにあるか
275
276
master canary というスタックに置かれた値との比較元は、どこにあるか。
277
278
* THREAD_SET_STACK_GUARD にて決められている。
279
 * 7アーキテクチャにて定義
280
 * canaryがTLS(thread local storage)に入る。TLSはヒープ領域に格納される。
281
 * 定義されていないならmaster canaryは.bssへ
282
 * ヒープも.bssセクションも、通常は書き込み権限があるので、書き換え可能。
283
 * canaryは、バイナリが再起動するまで変化しない。
284
285
### 参考
286
287
[@potetisensei](https://twitter.com/potetisensei?lang=ja)の[CODE BLUE](http://codeblue.jp/)の時の発表が神解説。
288
https://www.youtube.com/watch?v=UTC2iWxQ4qc&feature=youtu.be&a
289
http://www.slideshare.net/codeblue_jp/master-canary-forging-by-code-blue-2015
290
https://github.com/potetisensei/MasterCanaryForging-PoC
291
292
## RELRO
293
294
外部ライブラリ(共有オブジェクト *.so)を利用するとき、それらはアドレス空間の色々なところにマッピングされている。
295
これらで提供されている関数のアドレスを毎回計算で求めるのは大変なので、一度計算したら保存しておくテーブルがあると便利。
296
そのテーブルのことをGOT(Global Offset Table)と呼び、アドレス固定領域に存在している。
297
298
このGOTテーブルが、もし書き換えられると任意の関数を実行できてしまう。
299
それを防ぐ手段として、Partial RELRO と Full RELRO の二種類がある。
300
301
| 種類          | 遅延バインド | 説明                                                                 |
302
|---------------|--------------|----------------------------------------------------------------------|
303
| Partial RELRO | 有効         | .got.pltセクションが存在し、一部書き換え可能
304
| Full RELRO    | 無効(起動時間が遅くなる) | .got.pltセクションは無い。リードオンリーな .gotセクションのみがある。
305
306
**遅延バインド**について
307
308
普通、遅延バインドと言うと、Partial RELRO の時の動きを言うんだと思う。
309
310
| 種類          | 説明 |
311
|---------------|------|
312
| RELRO 無し    | オブジェクトがロードされた時(プログラムの起動時)に、dynamic linkerが全てのGOTのエントリに本当の関数のアドレス(libc.soのputsなど)を埋める。
313
| Partial RELRO | オブジェクトがロードされた時(プログラムの起動時)には、.got.pltセクションに特別な値を入れておき、本当の関数のアドレス調査を、その関数の初回呼び出し時まで遅延する
314
| Full RELRO    | 遅延BINDしない。プログラム実行開始時に.gotセクションを全部書き換える。全部書き換え終わったら、.gotセクションを書き込み禁止にする
315
316
## PIE
317
ASLRが有効な場合、スタック領域・ヒープ領域や共有ライブラリが置かれるアドレスは一定の範囲の中でランダムに決められる。
318
一方、実行ファイルそのものが置かれるアドレスは基本的には固定であるが、PIE (Position-Independent Executables) となるようにコンパイル・リンクすることでランダムなアドレスに置けるようにできる。
319
320
321
322
## ASCII-armor
323
324
共有ライブラリをメモリ上に配置するときにNULL(0x00) を含むアドレスへ配置するようにする。
325
strcpy 等を利用してのメモリ書き換えを防止するため。
326
327
# Vulnerabilities(脆弱性)
328
329
## Stack Buffer Overflow(スタックバッファオーバーフロー)
330
331
![wikipedia_StackBufferOverflow.png](wikipedia_StackBufferOverflow.png)
332
333
入力値チェックの無い変数にサイズオーバーで値を詰めると、スタックの底の方を書き換えられる。
334
スタックの底には、call時に関数復帰先のアドレスが設定される。
335
336
書き換える内容にシェルコードを含めておき、復帰先は、そこに飛ぶようにうまく上書きすれば、スタックの中だけでexploit処理が完結できる。ただし、NX bitで、この方法を無効にできる。
337
338
NTTデータ先端技術株式会社 - CTFで学ぶ脆弱性(スタックバッファオーバーフロー編・その1)
339
http://www.intellilink.co.jp/article/column/ctf01.html
340
341
## Heap Buffer Overflow(ヒープバッファオーバーフロー)
342
343
NEC 古賀さんによるありがたい解説
344
http://www.soi.wide.ad.jp/class/20040011/slides/19/45.html
345
https://www.nic.ad.jp/ja/materials/security-seminar/20041004/3-koga.pdf
346
347
Github - yannayl / GlibC Malloc for Exploiters
348
https://github.com/yannayl/glibc_malloc_for_exploiters
349
350
>かなり綺麗にまとまっている
351
352
353
### ヒープの仕組み
354
355
1. ヒープはフリーリストという構造になっている。
356
2. この1つの要素を共有する状態を作る。
357
3. 共有すると要素が抱える次の要素と前の要素を指すポインタを書き換えることができる。
358
4. 書き換えられれば、指し先をスタックにして、任意の値を書き込むことで、任意コードの実行まで出来る。
359
360
図を入れる。入れたい。
361
362
malloc(3)のメモリ管理構造
363
http://www.valinux.co.jp/technologylibrary/document/linux/malloc0001/
364
365
mallocの旅(glibc編)
366
http://www.slideshare.net/kosaki55tea/glibc-malloc
367
368
>神解説
369
370
371
### Use After Free
372
373
mallocで一度確保され解放された後に、尚そのアドレスに書き込むことが可能な場合に起きる。
374
既にそのアドレスは別の用途に転用されている場合、そのアドレスのデータを書き換え可能。
375
376
### Double Free
377
378
free()での二重解放。
379
解放されているアドレスを解放されていないものと思い込んで使い続けると、ヒープ内のデータが破損する可能性がある。
380
381
NEC 古賀さんによるありがたい解説
382
http://www.soi.wide.ad.jp/class/20040011/slides/19/61.html
383
384
### off-by-one error
385
386
NEC 古賀さんによるありがたい解説
387
http://www.soi.wide.ad.jp/class/20040011/slides/19/59.html
388
389
### House of XXXシリーズ
390
391
bataさんによる神解説
392
https://pastebin.com/raw/mrFNd19w
393
394
CTFするぞ - House of Corrosionの解説
395
https://ptr-yudai.hatenablog.com/entry/2019/10/19/002039
396
397
398
399
400
## Race Condition(リソース競合)
401
402
排他書が正しく実装されてなかったりした時、Use After FreeやDouble Free,もしくはスタックBOF/ヒープBOFに繋がる。
403
404
## Format String Bug (FSB)
405
406
### 参考
407
408
sekai013's blog - Format String Attack でメモリの中身を書き換える Mac OS X 10.10
409
http://sekai013.hatenablog.com/entry/2015/08/20/195649
410
411
NEC 古賀さんによるありがたい解説
412
http://www.soi.wide.ad.jp/class/20040011/slides/19/67.html
413
414
CTFするぞ - Format String Exploitを試してみる
415
https://ptr-yudai.hatenablog.com/entry/2018/10/06/234120
416
417
## Time-of-check-Time-of-use Race Condition (TOCTOUリソース競合)
418
419
ある処理AとBの間に、別の動作を無理やり割り込ませて、想定外の動作を引き起こす方法。
420
421
# Exploit Techniques - メモリ領域を上書きする
422
423
## .got overwrite
424
425
.gotセクションは外部関数アドレスのキャッシュであるため、ここを任意の関数のアドレスに書き換えることで、任意の関数が実行できる。
426
RELROにより、セクション内の書き込み権限がない場合は、成立しない。
427
428
ユーザの入力をそのまま受け付ける以下の関数があれば、.gotをsystem()に書き替えておくと,呼び出された時system(user_input)になる。
429
430
- strlen()
431
- strcmp()/memcmp()
432
- atoi()/strtol()
433
- free()
434
435
## Heap Buffer Overflow(ヒープバッファオーバーフロー)からの Unlink Attack と fastbins Unlink Attack
436
437
### Unlink Attack
438
439
ヒープバッファオーバーフローで,直下がfree済みチャンクの際,fd/bkメンバを上書き。
440
ただし、2004年以降のlibcにおけるfree()では、チェック機構が加わり、このUnlink Attackは起きない。
441
442
### fastbins Unlink Attack
443
444
fastbinsは、高速化のため実装された機構
445
fastbinsに入る小さなチャンクが直下にある状態で、ヒープバッファオーバーフローし、fdメンバを上書きできる
446
これによりfastbins UnlinkAttackができてしまう可能性がある。
447
448
### 参考
449
450
katagaitai CTF勉強会 #1 pwnables編 - DEFCON CTF 2014 pwn1 heap
451
http://www.slideshare.net/bata_24/katagaitai-ctf-1-57598200
452
453
> bataさん神
454
455
456
## ネットワークソケットを利用したシェル起動
457
458
(整理中)
459
ここに置くのが適切かわからん。。。
460
461
462
## _IO_jump_t overwrite
463
464
(整理中)
465
ここに置くのが適切かわからん。。。
466
467
468
469
470
471
# Exploit Techniques - 任意のアドレス(またはアドレスにある値)を漏洩させる
472
473
## DT_DEBUG,dl_runtime_resolve
474
475
dl_runtime_resolveやDT_DEBUGを利用することで、libc内のアドレスを動的に求めることができる。
476
477
dl_runtime_resolve
478
>PLTで使われる,外部関数のアドレスを動的解決する関数
479
480
481
482
483
484
485
# Exploit Techniques - セキュリティ機構を回避する
486
487
## byte-by-byte bruteforceによるSSP回避(x86)
488
489
1バイトずつブルートフォースすれば、256*4回の試行でStack Canaryを特定できる
490
(x64なら256*8回)
491
Stack Canaryは,TLS(Thread local storage)に格納されている
492
x86ではgs+0x14,x64ではfs+0x28にポインタが存在する
493
この値を書き換えられるなら,Stack Canaryは無効化できる
494
495
## Improper Null Terminationを利用したSSP回避
496
497
(作成中)
498
499
500
501
## Partial overwrite
502
503
ASLRおよびPIEが有効な場合、.textセクションもランダム化される。
504
しかしリトルエンディアン環境においては、リターンアドレスなどの下位バイトのみを書き換えることで付近のコードにジャンプさせることが可能となる。
505
506
リトルエンディアンの場合0x12345678はスタック上で 0x78563412と格納されている。
507
よってBOFなどにより例えば0x78の下位2バイトのみを書き換える事で、近いアドレスにジャンプさせる事ができ る。
508
飛ばせる先が限られている(他の手法と組み合わせ て使う場合が多い)、リトルエンディアンでしか使えない。
509
510
## Heap spray
511
512
(作成中)
513
514
515
516
# Exploit Techniques - 命令を実行する
517
518
(作成中)
519
520
はて、どうやって整理したものか
521
522
## ret2系
523
524
(作成中)
525
526
| 種類        | 説明 |
527
|-------------|------|
528
| ret2libc    | NX bitによる実行制御を回避するため、libcにあるsystem関数にretするようスタックを書き換える。いい感じにスタックポインタも操作して、書き換えた"/bin/sh"を指すようにする。ASLRやPIEでランダム化されると、厳しい。
529
| ret2esp     | スタック中にjmp espや、call espに復帰するようなアセンブラコードを仕込む。当然ながらjmp espやcall espがコード中に無ければ成立しない。
530
| ret2plt     | PLTを引数/戻り先と一緒にスタックへ仕込めば,通常の関数呼出と区別できない。
531
| ret2pop     | pop,pop,pop,pop,pop,pop,ret 等のガジェットを見つけて、スタックを減らして、次に実行したい関数と引数を積む技。
532
| ret2strcpy  | 
533
| ret2resolve |
534
535
## ROP系
536
537
(作成中)
538
539
{{rawhtml(<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">意地でもROPを理解させるという強い意志の動画です <a href="https://t.co/eGzrwGCoyc">pic.twitter.com/eGzrwGCoyc</a></p>&mdash; kurenaif🪄🗝@VTuber (@fwarashi) <a href="https://twitter.com/fwarashi/status/1657790229590478848?ref_src=twsrc%5Etfw">May 14 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>)}}
540
541
↓けっこう参考になる
542
543
ROP 輕鬆談
544
http://www.slideshare.net/hackstuff/rop-40525248
545
546
ASLRは、通常実行体まではランダム化されないため、実行体の中の小さな命令(ROP gadgetsと言う)を集めてシェルコードを作る。
547
スタックにある関数復帰先のアドレスを制御し続けることで成し得る。  
548
549
例えば、main関数から関数funcを読んだ先に脆弱性があったとする。
550
スタックが書き換えられるが、リターンの先をmainからgadgetに書き換える。
551
gadgetもretするが、その復帰先は、次のgadgetを指すようにする。
552
これを繰り返す。
553
554
PIEまでやられて、実行体もランダム化されると、この方法によるシェル奪取が難しくなる。
555
556
557
558
### ROP系小技
559
560
* __libc_csu_init gadgets
561
562
スタックからレジスタへ値を入れられる汎用ガジェットがある
563
564
* alarm(x)
565
566
x86/x64で、EAX/RAXレジスタにROPで任意の値を入れたいケース
567
ROPガジェットを探索しても、pop eax/raxが見つからない場合がよくある
568
alarm()を使うと、代替可能
569
ret2pltでalarm(x)-> alarm(0)と2回行えば、EAX/RAXレジスタにxが入る
570
571
* ROP stager
572
573
攻撃に使える領域のサイズが制限されている場合、readなどの関数を用いて再度メモリに書き込む方法をstagerと呼ぶ。
574
575
* DROP(Dynamic ROP)
576
577
漏洩させたlibcのアドレスを元に,***libc内のガジェット***を利用してROPを構築
578
.textのガジェットが少ない場合の対処法
579
相手環境のlibcがわかっていることが前提
580
581
* One-gadget-RCE
582
583
DragonSectorの資料
584
http://j00ru.vexillium.org/?p=2485
585
586
>x64でsystem("/bin/sh")を呼ぶ場合、条件付き(x64かつxinetd型でのみ有効)だが8バイトの書き込みで代替する方法がある
587
588
### SROP(Sigreturn-oriented Programming)
589
590
vdsoには、シグナル割り込みから復帰する際に、ユーザーランドのスタック上に作成したsignal frameに保存している値を全てのレジスタへ戻すsigreturnという命令が存在する。つまり、popadが廃止されたx64においても、sigreturnによってスタック上の値を複数のレジスタにセットすることができる。これによって、任意のシステムコールを呼び出すことが可能となるほか、関数の呼び出しがレジスタ渡しの場合においてもROPが容易になる。なお、vsyscallはASLRが有効であっても固定アドレスである。
591
ulimit -s unlimitedを用いてvdsoのマッピングアドレスを固定できる場合はCTFでも活用できそうだ。
592
593
### JOP(Jump-oriented programming) と COP(Call-oriented programming)
594
595
通常、retの次にはそのサブルーチンを呼び出したcallの次の命令が存在する。そこで、コールスタックを辿ることでROPによってretが使われていないか検出するROPguardが考案された。ROPguardはMicrosoftの脆弱性対策ツールであるEMET 3.5の根幹を成す理論だった。
596
そこで、retの代わりにjmpを用いるJump-oriented programmingが考案された。また、retやjmpの代わりにcallを用いるCall-oriented programmingも可能である。例えば以下のコードスニペットにおいて、callはjmpと実質的に等価である。
597
598
~~~
599
pop esi;
600
ret;
601
push eax;
602
call esi;
603
604
; call先
605
pop esi ;retアドレスを除去
606
;eaxを用いる処理
607
~~~
608
609
COPでは、pushのような表現力の高い命令を用いることができる。
610
611
# Exploit Techniques - シェルコードを置くメモリ領域を確保する
612
613
## Stack pivot
614
615
スタックのサイズ上、リターンアドレスの下にROP chainを構築できないような場合、xchg esp,eaxなどのgadgetを用いてスタックのアドレスを移動させる方法をstack pivotと呼ぶ。
616
617
スタックアドレスの設定先は、.bssセクションが使える(write権限がある)。.bssの先頭付近ではなく,中間ぐらいに設定するとよい(スタックの頭打ちを防ぐため)。
618
619
## Stager
620
621
BOFにより、書き換えられる量が少ない場合
622
623
* 短いアセンブリコードをBOFで送り込む
624
* これを最初に実行させ,shellcodeを追加読込をさせる
625
* 追加読み込みした部分へ制御を移す
626
627
と言う流れで対応することをstagerと言う。
628
629
# Command gadgets
630
631
katagaitai ctf study session - setup
632
http://pastebin.com/dWUV06ug
633
634
## 各種PLT/GOTを調査
635
636
```
637
$ objdump -d -M intel /bin/cat|grep "@plt>:" -A1
638
00000000004015b0 <__uflow@plt>:
639
  4015b0:       ff 25 62 aa 20 00       jmp    QWORD PTR [rip+0x20aa62]        # 60c018 <__sprintf_chk@plt+0x20a608>
640
--
641
00000000004015c0 <getenv@plt>:
642
  4015c0:       ff 25 5a aa 20 00       jmp    QWORD PTR [rip+0x20aa5a]        # 60c020 <__sprintf_chk@plt+0x20a610>
643
--
644
00000000004015d0 <free@plt>:
645
  4015d0:       ff 25 52 aa 20 00       jmp    QWORD PTR [rip+0x20aa52]        # 60c028 <__sprintf_chk@plt+0x20a618>
646
--
647
648
.
649
.
650
.
651
652
653
0000000000401a00 <iconv_open@plt>:
654
  401a00:       ff 25 3a a8 20 00       jmp    QWORD PTR [rip+0x20a83a]        # 60c240 <__sprintf_chk@plt+0x20a830>
655
--
656
0000000000401a10 <__sprintf_chk@plt>:
657
  401a10:       ff 25 32 a8 20 00       jmp    QWORD PTR [rip+0x20a832]        # 60c248 <__sprintf_chk@plt+0x20a838>
658
```
659
660
## 関数アドレスの調査
661
662
まず利用しているlibcのパスを調べる
663
664
```
665
$ ldd /bin/cat
666
        linux-vdso.so.1 =>  (0x00007fff3c3e2000)
667
        libc.so.6 => /lib64/libc.so.6 (0x00007fc824120000)
668
        /lib64/ld-linux-x86-64.so.2 (0x00007fc8244ed000)
669
```
670
671
libc内のsystemのオフセット調査
672
673
```
674
$ objdump -d /lib64/libc.so.6|grep "system>:"
675
0000000000041f00 <do_system>:
676
00000000000423d0 <__libc_system>:
677
```
678
679
## 固定文字列のアドレス調査
680
681
```
682
$ strings -tx /lib64/libc.so.6 |grep '/bin/sh'
683
 17b249 /bin/sh
684
685
```
686
687
## アドレス固定のRW領域(.data)調査
688
689
IDA Proでもできます。
690
691
```
692
$ readelf -S ropasaurusrex |fgrep .data
693
```
694
695
## gdb-pedaインストール手順
696
697
CentOS7の場合(既存のgdbを潰さない方法)
698
699
```
700
# yum install python-devel texinfo ※他に足りないパッケージがあったら、同じく入れる(たぶん大丈夫)
701
# su - user
702
$ mkdir /home/user/gdb-peda
703
$ cd /home/user/gdb-peda
704
$ wget http://ftp.gnu.org/gnu/gdb/gdb-7.9.tar.gz
705
$ tar pxzf gdb-7.9.tar.gz
706
$ cd gdb-7.9
707
$ ./configure --with-python=python && make
708
$ yum install git
709
$ git clone https://github.com/longld/peda.git /home/user/gdb-peda/peda
710
$ echo "source /home/user/gdb-peda/peda/peda.py" >> gdbinit
711
```
712
pedaの動作チェック
713
起動したら’start’と打ち,カラフルな画面が出てきたらインストール成功
714
715
```
716
$ /home/user/gdb-peda/gdb-7.9/gdb/gdb -q /bin/ls --data-directory=/home/user/gdb-peda/gdb-7.9/gdb/data-directory -x /home/user/gdb-peda/gdbinit
717
```
718
719
なので、こういう起動シェル作っとけば、既存のgdbと共存できる
720
721
gdb-peda.sh
722
723
```
724
#!/bin/bash
725
/home/user/gdb-peda/gdb-7.9/gdb/gdb -q ${1}  --data-directory=/home/user/gdb-peda/gdb-7.9/gdb/data-directory -x /home/user/gdb-peda/gdbinit ${2} ${3} ${4} ${5} ${6} ${7} ${8} ${9}
726
```
727
728
----
729
ちな、Ubuntu(x64)の場合(参考)
730
731
```
732
$ apt-get install libncurses5-dev g++ python-dev texinfo
733
$ cd /tmp
734
$ wget http://ftp.gnu.org/gnu/gdb/gdb-7.9.tar.gz
735
$ tar pxzf gdb-7.9.tar.gz
736
$ cd gdb-7.9
737
$ ./configure --with-python=python2 && make && make install
738
$ apt-get install git
739
$ git clone https://github.com/longld/peda.git ~/peda
740
$ echo "source ~/peda/peda.py" >> ~/.gdbinit
741
```
742
743
pedaの動作チェック
744
起動したら’start’と打ち,カラフルな画面が出てきたらインストール成功
745
746
```
747
$ gdb -q /bin/ls
748
```
749
750
### pop×Nガジェットを調査(rp++の方が精度がいい)
751
752
```
753
$ gdb ./binary –q
754
gdb-peda $ start
755
gdb-peda $ ropgadget
756
```
757
758
## gdb-dashboardインストール手順
759
760
[ここ](https://github.com/cyrus-and/gdb-dashboard)から、.gdbinitをダウンロード
761
gdbinit_gdb-dashbordと名前を変える。
762
763
起動用シェルを作る。
764
765
```
766
$ vi gdb-dashboard.sh
767
+ gdb ${1} ${2} ${3} ${4} ${5} ${6} ${7} ${8} ${9} -x /home/user/gdbinit_gdb-dashboard
768
769
$ chmod ugo+x gdb-dashboard.sh
770
```
771
772
## rp++インストール手順
773
774
```
775
$ wget https://github.com/downloads/0vercl0k/rp/rp-lin-x86
776
$ wget https://github.com/downloads/0vercl0k/rp/rp-lin-x64
777
```
778
779
### ROPガジェットの抽出
780
781
```
782
$ rp-lin-x86 --file=binary --unique --rop=5
783
```
784
785
## Metasploit Framework インストール手順
786
787
```
788
$ sudo apt-get -y install \
789
  build-essential zlib1g zlib1g-dev \
790
  libxml2 libxml2-dev libxslt-dev locate \
791
  libreadline6-dev libcurl4-openssl-dev git-core \
792
  libssl-dev libyaml-dev openssl autoconf libtool \
793
  ncurses-dev bison curl wget postgresql \
794
  postgresql-contrib libpq-dev \
795
  libapr1 libaprutil1 libsvn1 \
796
  libpcap-dev \
797
  libsqlite3-dev
798
799
$ sudo apt-get install ruby1.9.3       # rvmを使う代わりに直接インストール
800
$ cd /opt
801
$ sudo git clone https://github.com/rapid7/metasploit-framework.git
802
$ cd metasploit-framework
803
$ sudo gem install bundler --no-ri --no-rdoc
804
$ bundle install
805
```
806
807
### EIPまでのオフセットを計算 (pattern_create.rb pattern_offset.rb)
808
809
ユニークな文字列生成
810
811
```
812
$ /opt/metasploit-framework/tools/pattern_create.rb 200
813
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
814
```
815
816
コマンド引数に渡したりして、落ちる所を確認
817
818
```
819
$ gdb -q a.out
820
Reading symbols from /home/user/tmp/a.out...(no debugging symbols found)...done.
821
(gdb) r
822
Starting program: /home/user/tmp/a.out
823
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
824
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
825
826
Program received signal SIGSEGV, Segmentation fault.
827
0x64413764 in ?? ()
828
(gdb) quit
829
```
830
831
EIPが0x64413764で落ちている。0x64413764が、生成した文字列のどの部分か調べる。
832
833
```
834
$ /opt/metasploit-framework/tools/pattern_offset.rb 0x64413764
835
[*] Exact match at offset 112
836
```
837
838
112バイト目からの4バイトがEIPになっている。
839
840
## socatサーバ化ワンライナー
841
842
```
843
$ socat TCP-LISTEN:4444,reuseaddr,fork exec:./binary&
844
```
845
846
## objdumpのdiffをいい感じに取る
847
848
```
849
$ diff -u1 -F '>:$' -I '[0-9a-f]\{6,\}' <(objdump -d test1 | cut -f2-) <(objdump -d test2 | cut -f2-)
850
```
851
852
詳細は、[ももいろテクノロジー objdumpのdiffをいい感じに取る方法のメモ](http://inaz2.hatenablog.com/entry/2016/04/30/073738)参照
853
854
855
## LD_PRELOAD環境変数によるライブラリ関数フック
856
857
詳細は、[ももいろテクノロジー LD_PRELOAD injectionでOpenSSLによる暗号化処理を覗いてみる](http://inaz2.hatenablog.com/entry/2016/03/15/192125)参照
858
859
ここも
860
861
しゃろの日記 - rev問のソルバを書くときとかに使えるかもしれない小テク
862
http://charo-it.hatenablog.jp/entry/2016/12/15/084701
863
864
865
866
867
868
# 動的デバック環境
869
870
## fork-server型とxinetd型について
871
872
fork-server型
873
874
 - バイナリ内にbind→listen→acceptがある
875
 - gdbではset follow-fork-mode childを設定する
876
 - 親プロセスが残り続けてしまうので、都度親プロセスのkillする工夫が必要
877
878
xinetd型
879
880
 - バイナリ内にbind→listen→acceptがない
881
 - xinetdにのせるのは、面倒なので、socatで代用する
882
883
## xinetd型のための、socatとgdb-serverの利用
884
885
socatとgdb-serverを利用して、3つのTerminalをうまく使う
886
887
### 待ち受け側 - TerminalA
888
889
```
890
$ vimain.sh
891
gdbserver localhost:1234 ./a.out
892
$ chmod +x main.sh
893
$ socat TCP-LISTEN:1025,reuseaddr,fork EXEC:"./main.sh"
894
```
895
896
### 攻撃側 - TerminalB
897
898
```
899
$ perl -e'print "A"x140 ."BBBB"'|nc localhost 1025
900
```
901
902
### デバッグ側 - TerminalC
903
904
```
905
vi cmd
906
file ./a.out
907
target remote localhost:1234
908
c
909
$ gdb ./a.out -q -x cmd
910
```
911
912
913
914
915
916
917
918
919
# x86/x64以外のアーキ
920
921
Learning ARM Exploit Development
922
https://owlinux1000.github.io/ARM_Exploit/
923
924
# Study
925
926
NEC 古賀さんによるありがたい解説
927
http://www.soi.wide.ad.jp/class/20040011/slides/19/
928
https://www.nic.ad.jp/ja/materials/security-seminar/20041004/3-koga.pdf
929
930
Shellphishによるheap exploitのテクニック解説
931
https://github.com/shellphish/how2heap
932
933
katagaitai CTF勉強会資料
934
http://www.slideshare.net/bata_24/presentations
935
936
杨坤:掘金CTF ——CTF中的内存漏洞利用技巧, Geekon 2015
937
http://netsec.ccert.edu.cn/blog/2015/10/29/1093 http://netsec.ccert.edu.cn/wp-content/uploads/2015/10/2015-1029-yangkun-Gold-Mining-CTF.pdf
938
939
>スライドの攻撃手法がまとまっていてよさ
940
941
h_nosonの日記 - pwn challenges list baby, easyについて
942
http://h-noson.hatenablog.jp/entry/2017/12/22/000000
943
944
>pwn challenges listのbabyとeasyの一部を解いて、どんな問題が多かったか、何に躓いたかなど
945
946
947
ハリネズミ本 ~pwn編~
948
https://hackmd.io/GwBgHGBmCcDGYFowBMAsj0GZZNgU0RBFnzxD1UmQCYg=?view#
949
950
Linux Reverse Engineering CTFs for Beginners
951
https://osandamalith.com/2019/02/11/linux-reverse-engineering-ctfs-for-beginners/amp/?__twitter_impression=true
952
953
swisskyrepo/PayloadsAllTheThings
954
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/README.md
955
956
guyinatuxedo/nightmare
957
https://github.com/guyinatuxedo/nightmare/tree/master/modules
958
959
>過去のCTF のリバース、Pwn 問題がジャンル別にまとめられています
960
961
趣味と実益のスタック破壊
962
http://web.archive.org/web/20010910201811/linux.ascii24.com/linux/linuxcom/2000/06/13/465216-001.html
963
964
C++のpwn/revで使うSTLコンテナの構造とバグパターン一覧
965
https://ptr-yudai.hatenablog.com/entry/2021/11/30/235732
966
967
マルウェア解析は IDAPython にシュッとやらせよう
968
https://blog.nflabs.jp/entry/idapython
969
970
Understanding the Heap - a beautiful mess
971
ヒープを理解する - 美しい混乱
972
https://jackfromeast.site/2023-01/understand-the-heap-a-beautiful-mess.html
973
974
Dirty Pagetableを理解する(m0leCon Finals CTF Writeup)
975
https://ptr-yudai.hatenablog.com/entry/2023/12/07/221333
976
977
Exploit Reversing
978
https://exploitreversing.com
979
980
The toddler’s introduction to Heap exploitation (Part 1)
981
https://infosecwriteups.com/the-toddlers-introduction-to-heap-exploitation-part-1-515b3621e0e8
982
983
ゼロからのハイパーバイザ自作入門
984
https://zenn.dev/hidenori3/books/55ce98070299db
985
986 10 kanata
Reversing for dummies - x86 assembly and C code (Beginner/ADHD friendly)
987
初心者向けリバースプログラミング - x86 アセンブリと C コード (初心者/ADHD 向け)
988
https://0x44.cc/reversing/2021/07/21/reversing-x86-and-c-code-for-beginners.html
989 1 kanata
990
991
# Memo
992
993
## Pwn環境の構築/ツール導入
994
995
【memo】 pwn環境構築の覚書
996
https://smallkirby.hatenablog.com/entry/2020/01/07/234124
997
998
999
1000
## Kernel Exploit
1001
1002
るくすの日記 - カーネルエクスプロイト入門 - Linuxカーネル解析の基礎
1003
http://rkx1209.hatenablog.com/entry/2017/07/13/184358
1004
1005
CTFするぞ - Kernel Exploitで使える構造体集
1006
https://ptr-yudai.hatenablog.com/entry/2020/03/16/165628
1007
1008
sec4b-2023 の driver4b で Linux のカーネルエクスプロイトに入門してみる
1009
https://kashiwaba-yuki.com/ctf-sec4b-kernel-exploit
1010
1011
1012
1013
## Exploit系テクニック
1014
1015
ももいろテクノロジー - Exploit系複合テクニックのメモ
1016
http://inaz2.hatenablog.com/entry/2016/12/17/180655
1017
1018
Modern Binary Exploitation
1019
http://security.cs.rpi.edu/courses/binexp-spring2015/
1020
1021
hama7230 SlideShare
1022
https://www.slideshare.net/hama7230/presentations
1023
1024
OUR BLOG - TOP 10プロセスインジェクションテクニック
1025
https://www.endgame.com/blog/technical-blog/ten-process-injection-techniques-technical-survey-common-and-trending-process
1026
1027
yyy - ROP Emporium Writeup(32bit) 
1028
http://ywkw1717.hatenablog.com/entry/2017/12/07/235405
1029
1030
Harekaze 外部wiki - Pwn・Exploitテクニック一覧
1031
https://harekaze.com/wiki/#!resources/pwn/technics.md
1032
1033
>すばら
1034
1035
各種OSのUserlandにおけるPwn入門
1036
http://nanuyokakinu.hatenablog.jp/entry/2018/12/09/223440
1037
1038
ROP Emporium
1039
https://ropemporium.com/
1040
1041
>x86とx64 binaryがあってスタックの呼び方の比較とかがしやすい
1042
1043
GTFOBins: 攻撃者が悪用できるLinuxコマンドの一覧
1044
https://gtfobins.github.io
1045
1046
>各コマンドから別のコマンドが使えるもの一覧、シェルが直接呼べなくてもコマンド経由で呼べたりする
1047
1048
libcにデバッグシンボルを付ける方法と自動化
1049
https://satoooon1024.hatenablog.com/entry/2022/06/12/libc%E3%81%AB%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E3%82%B7%E3%83%B3%E3%83%9C%E3%83%AB%E3%82%92%E4%BB%98%E3%81%91%E3%82%8B%E6%96%B9%E6%B3%95%E3%81%A8%E8%87%AA%E5%8B%95%E5%8C%96
1050
1051
1052
1053
1054
1055
1056
## ASLRのアドレス特定テクニック
1057
1058
この世にあるlibcをdatabase化すればいいじゃない!!
1059
1060
libcdb.com
1061
http://libcdb.com/
1062
1063
niklasb/libc-database
1064
https://github.com/niklasb/libc-database
1065
1066
## Exploit DataBase
1067
1068
EXPLOIT DATABASE
1069
https://www.exploit-db.com/
1070
1071
## Unpack
1072
1073
サイバーセキュリティ研究所 - アンパック手順 覚え書き
1074
http://www.wivern.com/malware20161101.html
1075
1076
Unpacking Executables - The ESP Trick
1077
https://goggleheadedhacker.com/blog/post/6
1078
1079
> パックされたバイナリを手動でアンパックする「ESP Trick」テクニックについて
1080
1081
株式会社Ninjastars 技術研究部 - リバースエンジニアリング対策 -難読化編パート2-
1082
https://www.ninjastars-net.com/entry/2019/05/20/190000
1083
1084
1085
## Malware解析 - Rev
1086
1087
Malware Unicorn - Reverse Engineering Malware 101 Material
1088
https://securedorg.github.io/RE101/
1089
1090
## Windows関係
1091
1092
Shellcode - Exploit Development Community - Windowsシェルコード作成について 
1093
http://expdev-kiuhnm.rhcloud.com/2015/05/22/shellcode/
1094
1095
Github - MalwareCantFly/Vba2Graph (VBAの解析・可視化)
1096
https://github.com/MalwareCantFly/Vba2Graph
1097
1098
CTFするぞ - 2019年のpwn問を全部解くチャレンジ【前半戦】
1099
https://ptr-yudai.hatenablog.com/entry/2019/07/01/143652
1100
1101
CTFするぞ - 2019年のpwn問を全部解くチャレンジ【後半戦】
1102
https://ptr-yudai.hatenablog.com/entry/2019/12/23/122844
1103
1104
Magical WinDbg 2 - CTF で学ぶユーザモード & カーネルデバッギング - (WEB 版)
1105
https://kashiwaba-yuki.com/magical-windbg-vol2-00