SITCON 2022 R0 模糊測試哪裡模糊 [8Gb4b-tqLqY].srt

1
00:00:00,000 --> 00:00:04,000
接下來的議程是由林觀明帶來的

2
00:00:04,000 --> 00:00:06,000
模糊測試哪裡模糊

3
00:00:06,000 --> 00:00:08,000
讓我們歡迎林觀明

4
00:00:13,000 --> 00:00:15,000
好 歡迎大家

5
00:00:15,000 --> 00:00:17,000
先講一下

6
00:00:17,000 --> 00:00:21,000
因為這場議程我在 COSCUP 其實有講過一場

7
00:00:21,000 --> 00:00:22,000
Fuzzing Test

8
00:00:22,000 --> 00:00:24,000
基本上是一樣的東西

9
00:00:24,000 --> 00:00:25,000
只是名字換掉

10
00:00:25,000 --> 00:00:26,000
對

11
00:00:26,000 --> 00:00:27,000
好

12
00:00:27,000 --> 00:00:29,000
那我們就直接開始

13
00:00:29,000 --> 00:00:32,000
因為今天如果要講的東西一樣

14
00:00:32,000 --> 00:00:34,000
但是我只有 20 分鐘而已

15
00:00:34,000 --> 00:00:37,000
所以可能會帶的稍微快一點

16
00:00:37,000 --> 00:00:39,000
好 那我們就開始吧

17
00:00:39,000 --> 00:00:43,000
這場議程主要是跟各位

18
00:00:43,000 --> 00:00:46,000
介紹模糊測試的基本觀念

19
00:00:46,000 --> 00:00:50,000
跟介紹 AFL

20
00:00:50,000 --> 00:00:57,000
然後因為我研究所是讀模糊測試的

21
00:00:57,000 --> 00:01:00,000
大家好 我是林觀明

22
00:01:00,000 --> 00:01:04,000
今年是剛畢業 剛進職場

23
00:01:04,000 --> 00:01:08,000
之前是在陽交大的 SQLab

24
00:01:08,000 --> 00:01:13,000
然後論文也是做跟 fuzz 有相關的

25
00:01:13,000 --> 00:01:15,000
然後下面是我的 GitHub

26
00:01:15,000 --> 00:01:17,000
然後 Mail

27
00:01:17,000 --> 00:01:18,000
然後跟各位澄清一下

28
00:01:18,000 --> 00:01:20,000
我論文沒有用抄的

29
00:01:20,000 --> 00:01:23,000
我不像某一位

30
00:01:23,000 --> 00:01:26,000
前市長 對

31
00:01:26,000 --> 00:01:28,000
好

32
00:01:28,000 --> 00:01:31,000
我好像講到什麼關鍵字喔

33
00:01:31,000 --> 00:01:33,000
慘了 我們的議程要被 Ban 掉了

34
00:01:33,000 --> 00:01:35,000
大家可以去吃點心了

35
00:01:35,000 --> 00:01:36,000
好啦 我們不開玩笑了

36
00:01:36,000 --> 00:01:38,000
我們直接進入議程

37
00:01:38,000 --> 00:01:39,000
好

38
00:01:39,000 --> 00:01:40,000
那我接下來會介紹

39
00:01:40,000 --> 00:01:42,000
Fuzzing Test 的主要觀念

40
00:01:42,000 --> 00:01:47,000
與 AFL 的一些主要觀念

41
00:01:47,000 --> 00:01:50,000
對 就是這兩個東西

42
00:01:50,000 --> 00:01:53,000
那什麼是 Fuzzing Test

43
00:01:53,000 --> 00:01:57,000
Fuzzing Test 主要是做測試嘛

44
00:01:57,000 --> 00:01:59,000
然後它的主要觀念就是

45
00:01:59,000 --> 00:02:02,000
它可以自動去生成一個

46
00:02:02,000 --> 00:02:04,000
可以輸入的

47
00:02:04,000 --> 00:02:06,000
可以餵進去的輸入

48
00:02:06,000 --> 00:02:09,000
然後我們去跑 target

49
00:02:09,000 --> 00:02:10,000
看它有沒有一些 crash

50
00:02:10,000 --> 00:02:13,000
或是一些可以利用的東西

51
00:02:13,000 --> 00:02:15,000
但是我們這邊的

52
00:02:15,000 --> 00:02:18,000
洞不包括一些邏輯的問題

53
00:02:18,000 --> 00:02:20,000
它只是要去檢查說

54
00:02:20,000 --> 00:02:22,000
我的程式到底會不會 crash

55
00:02:22,000 --> 00:02:24,000
會不會莫名其妙

56
00:02:24,000 --> 00:02:26,000
你餵了一個東西進去之後

57
00:02:26,000 --> 00:02:30,000
它就掛掉了

58
00:02:30,000 --> 00:02:35,000
那我們可以來找找

59
00:02:35,000 --> 00:02:38,000
這段程式有什麼問題

60
00:02:38,000 --> 00:02:40,000
這是一個簡單的範例

61
00:02:40,000 --> 00:02:43,000
然後因為時間關係

62
00:02:43,000 --> 00:02:45,000
所以就繼續好了

63
00:02:45,000 --> 00:02:47,000
這邊最大的問題就是

64
00:02:47,000 --> 00:02:49,000
我們的 malloc

65
00:02:49,000 --> 00:02:53,000
不可以隨便去用任意大小

66
00:02:53,000 --> 00:02:54,000
它會爆掉

67
00:02:54,000 --> 00:02:57,000
就是會造成程式的 crash

68
00:02:57,000 --> 00:02:59,000
大概是這樣

69
00:02:59,000 --> 00:03:01,000
然後這個問題

70
00:03:01,000 --> 00:03:03,000
其實在我們日常生活中

71
00:03:03,000 --> 00:03:05,000
其實還蠻容易看見的

72
00:03:05,000 --> 00:03:07,000
像是我們處理一些

73
00:03:07,000 --> 00:03:09,000
JPG 檔或是 PNG 檔

74
00:03:09,000 --> 00:03:14,000
通常它的檔案的格式

75
00:03:14,000 --> 00:03:16,000
都會有一個長度

76
00:03:16,000 --> 00:03:18,000
但是我們這個長度

77
00:03:18,000 --> 00:03:21,000
就是我們不可以隨便讓 PNG

78
00:03:21,000 --> 00:03:23,000
就是裡面的人亂設

79
00:03:23,000 --> 00:03:24,000
如果我們亂設的話

80
00:03:24,000 --> 00:03:25,000
它就會爆掉

81
00:03:25,000 --> 00:03:27,000
就是很多程式的漏洞

82
00:03:27,000 --> 00:03:29,000
都是這樣子來的

83
00:03:29,000 --> 00:03:30,000
所以我們程式的邏輯

84
00:03:30,000 --> 00:03:32,000
應該要先去檢查

85
00:03:32,000 --> 00:03:34,000
它的長度是否正常

86
00:03:34,000 --> 00:03:35,000
比如說我長度

87
00:03:35,000 --> 00:03:37,000
就隨便給它一個超大的值

88
00:03:37,000 --> 00:03:39,000
它就會掛掉

89
00:03:39,000 --> 00:03:40,000
這樣是不行的

90
00:03:40,000 --> 00:03:42,000
其實有很多 [DJPG]

91
00:03:42,000 --> 00:03:44,000
或是處理 PNG 的檔案

92
00:03:44,000 --> 00:03:45,000
都有這些問題

93
00:03:45,000 --> 00:03:48,000
當然都已經被修復了

94
00:03:48,000 --> 00:03:52,000
就是有還蠻多 CVE 可以看的

95
00:03:52,000 --> 00:03:54,000
所以我們再 review 一次好了

96
00:03:54,000 --> 00:03:56,000
什麼是 Fuzzing test

97
00:03:56,000 --> 00:03:59,000
就是我們去生成一個 input

98
00:03:59,000 --> 00:04:00,000
然後怎麼生成

99
00:04:00,000 --> 00:04:02,000
我們等一下會提到

100
00:04:02,000 --> 00:04:04,000
然後我們去跑 target

101
00:04:04,000 --> 00:04:06,000
然後到底會不會有問題呢

102
00:04:06,000 --> 00:04:07,000
如果有 crash

103
00:04:07,000 --> 00:04:10,000
或是有其他的一些問題的話

104
00:04:10,000 --> 00:04:11,000
它就會

105
00:04:11,000 --> 00:04:12,000
就可能會變成

106
00:04:12,000 --> 00:04:14,000
可以利用的漏洞

107
00:04:15,000 --> 00:04:17,000
好

108
00:04:17,000 --> 00:04:18,000
以上的 Fuzzing test

109
00:04:18,000 --> 00:04:21,000
有幾個 issue 要解決

110
00:04:21,000 --> 00:04:22,000
第一個問題就是

111
00:04:22,000 --> 00:04:26,000
如果我隨機產生輸入的話

112
00:04:26,000 --> 00:04:28,000
那我今天的程式

113
00:04:28,000 --> 00:04:30,000
邏輯寫好一點

114
00:04:30,000 --> 00:04:32,000
我們 format 檢查的

115
00:04:32,000 --> 00:04:33,000
有檢查 format

116
00:04:33,000 --> 00:04:35,000
但是這樣子

117
00:04:35,000 --> 00:04:37,000
隨機生成的輸入

118
00:04:37,000 --> 00:04:39,000
往往就找不到更深層的邏輯

119
00:04:39,000 --> 00:04:41,000
所以我們有一個

120
00:04:41,000 --> 00:04:43,000
簡單的概念是變異測試

121
00:04:43,000 --> 00:04:45,000
這個後面會介紹

122
00:04:45,000 --> 00:04:48,000
但是

123
00:04:48,000 --> 00:04:50,000
我們沒有辦法知道程式的狀態

124
00:04:50,000 --> 00:04:53,000
譬如說我們今天去測一個 binary

125
00:04:53,000 --> 00:04:55,000
但是它沒有告訴我們

126
00:04:55,000 --> 00:04:56,000
這筆測資

127
00:04:56,000 --> 00:04:58,000
這個輸入

128
00:04:58,000 --> 00:05:01,000
它的出來的結果

129
00:05:01,000 --> 00:05:03,000
到底是好還是不好的

130
00:05:03,000 --> 00:05:06,000
所以我們又想到了一個方法

131
00:05:06,000 --> 00:05:09,000
我們可以去做一些插樁的東西

132
00:05:09,000 --> 00:05:12,000
然後去想辦法去記錄 code coverage

133
00:05:13,000 --> 00:05:15,000
然後利用這些 code coverage

134
00:05:15,000 --> 00:05:18,000
去引導我們的 fuzzer 去做更多的事情

135
00:05:18,000 --> 00:05:21,000
然後其實現在很多 fuzzer 都有這樣的概念

136
00:05:21,000 --> 00:05:25,000
只是可能大家的概念不太一樣

137
00:05:25,000 --> 00:05:27,000
有些可能是用 code coverage

138
00:05:27,000 --> 00:05:29,000
有些可能是用 memory

139
00:05:29,000 --> 00:05:31,000
或是在不同的應用上

140
00:05:31,000 --> 00:05:35,000
RESTful API 也有相關的應用

141
00:05:35,000 --> 00:05:38,000
然後接下來會來介紹

142
00:05:38,000 --> 00:05:41,000
Google 開發的 AFL

143
00:05:41,000 --> 00:05:43,000
好 AFL

144
00:05:43,000 --> 00:05:47,000
它是 Google 在 2013 年開發的模糊測試工具

145
00:05:47,000 --> 00:05:49,000
當然各位可以現在 Google

146
00:05:49,000 --> 00:05:53,000
也是找到它是 open source 的

147
00:05:53,000 --> 00:05:55,000
然後它已經沒有再更新了

148
00:05:55,000 --> 00:05:59,000
因為 Google 最近在某一年

149
00:05:59,000 --> 00:06:01,000
我忘記是哪一年了

150
00:06:01,000 --> 00:06:04,000
它之後有推出一個 AFL++

151
00:06:04,000 --> 00:06:06,000
基本上也是承接著 AFL

152
00:06:06,000 --> 00:06:09,000
但是會有更多不一樣的觀念在裡面

153
00:06:09,000 --> 00:06:11,000
然後今天不會介紹啦

154
00:06:11,000 --> 00:06:13,000
然後它使用的觀念就是

155
00:06:13,000 --> 00:06:14,000
我們剛才使用的

156
00:06:14,000 --> 00:06:16,000
編譯測試跟 code coverage guide

157
00:06:16,000 --> 00:06:18,000
然後還有一個 forkserver

158
00:06:18,000 --> 00:06:20,000
但是今天的時間可能會不夠

159
00:06:20,000 --> 00:06:23,000
所以 forkserver 會跳得非常的快

160
00:06:23,000 --> 00:06:25,000
好 那它的流程是什麼

161
00:06:25,000 --> 00:06:28,000
它的流程就是

162
00:06:28,000 --> 00:06:31,000
我們現在有一個 initial seed

163
00:06:31,000 --> 00:06:32,000
這個 initial seed

164
00:06:32,000 --> 00:06:35,000
比如說你今天要測處理圖片的檔案

165
00:06:35,000 --> 00:06:36,000
我們就這個 initial seed

166
00:06:36,000 --> 00:06:38,000
就是一個正常的圖片檔案

167
00:06:38,000 --> 00:06:40,000
它會放在一個 queue 裡面

168
00:06:40,000 --> 00:06:42,000
然後我們去做 mutate

169
00:06:42,000 --> 00:06:45,000
然後去 run 整個 target

170
00:06:45,000 --> 00:06:47,000
然後去看它的 code coverage 有沒有增加

171
00:06:47,000 --> 00:06:48,000
如果有增加的話

172
00:06:48,000 --> 00:06:50,000
這個 seed 就代表說

173
00:06:50,000 --> 00:06:51,000
它是好的

174
00:06:51,000 --> 00:06:53,000
它是可以再被利用的

175
00:06:53,000 --> 00:06:56,000
它就會繼續放在 queue 裡面

176
00:06:56,000 --> 00:06:57,000
如果它很爛的話

177
00:06:57,000 --> 00:06:59,000
它就會被丟掉

178
00:06:59,000 --> 00:07:02,000
好 所以剛才有提到一個 mutate 的部分

179
00:07:02,000 --> 00:07:03,000
這個 mutate 的部分就是

180
00:07:03,000 --> 00:07:07,000
我們使用者要去給它一個 initial seed

181
00:07:07,000 --> 00:07:09,000
然後這個 initial seed 就是

182
00:07:09,000 --> 00:07:12,000
就是正常 format 的一個 seed

183
00:07:12,000 --> 00:07:15,000
就是它應該要可以跑正常的東西

184
00:07:15,000 --> 00:07:19,000
然後用這個 seed 去創造出更多的 seed

185
00:07:19,000 --> 00:07:21,000
但是這些更多的 seed

186
00:07:21,000 --> 00:07:22,000
其實是系統裡面

187
00:07:22,000 --> 00:07:24,000
fuzzer 裡面自己去生成的

188
00:07:24,000 --> 00:07:25,000
好 它的變異策略

189
00:07:25,000 --> 00:07:28,000
今天也不會細講

190
00:07:28,000 --> 00:07:30,000
然後大概是這五種

191
00:07:30,000 --> 00:07:31,000
Bitflip

192
00:07:31,000 --> 00:07:32,000
Arithmetic

193
00:07:32,000 --> 00:07:33,000
跟 Interest

194
00:07:33,000 --> 00:07:34,000
Dictionary

195
00:07:34,000 --> 00:07:36,000
跟 Havoc

196
00:07:37,000 --> 00:07:38,000
好 時間

197
00:07:38,000 --> 00:07:39,000
好 應該還可以

198
00:07:39,000 --> 00:07:41,000
Bitflip 就是

199
00:07:41,000 --> 00:07:43,000
做 bit 的反轉

200
00:07:43,000 --> 00:07:45,000
然後運算就是去

201
00:07:45,000 --> 00:07:48,000
可能是某一個 bit

202
00:07:48,000 --> 00:07:49,000
做加加減減

203
00:07:49,000 --> 00:07:50,000
Interest 就是

204
00:07:50,000 --> 00:07:53,000
它可能會去拿 int

205
00:07:53,000 --> 00:07:54,000
int 的極大或極小

206
00:07:54,000 --> 00:07:56,000
去做一些測試

207
00:07:56,000 --> 00:07:57,000
然後 Dictionary 也是

208
00:07:57,000 --> 00:07:58,000
裡面會去做

209
00:07:58,000 --> 00:08:01,000
它裡面有一個地方可以

210
00:08:01,000 --> 00:08:02,000
設定它的 Dictionary

211
00:08:02,000 --> 00:08:04,000
你想要餵什麼東西進去

212
00:08:04,000 --> 00:08:05,000
然後它可以設定

213
00:08:05,000 --> 00:08:06,000
在一個地方裡面

214
00:08:06,000 --> 00:08:08,000
然後 Havoc 就是

215
00:08:08,000 --> 00:08:10,000
這上面的綜合體

216
00:08:10,000 --> 00:08:12,000
好 然後這邊的

217
00:08:12,000 --> 00:08:13,000
最重要的觀念就是

218
00:08:13,000 --> 00:08:15,000
一個 initial seed

219
00:08:15,000 --> 00:08:17,000
基本上就是要餵一個

220
00:08:17,000 --> 00:08:18,000
可以正常運作的

221
00:08:18,000 --> 00:08:21,000
initial seed

222
00:08:21,000 --> 00:08:23,000
好 接下來介紹

223
00:08:23,000 --> 00:08:25,000
code coverage

224
00:08:25,000 --> 00:08:27,000
然後 code coverage

225
00:08:27,000 --> 00:08:28,000
如果有在做

226
00:08:28,000 --> 00:08:29,000
Unit-test 的話

227
00:08:29,000 --> 00:08:31,000
應該會比較熟悉

228
00:08:31,000 --> 00:08:35,000
就是它會看成

229
00:08:35,000 --> 00:08:37,000
就是你現在這筆測資

230
00:08:37,000 --> 00:08:39,000
這筆這個輸入

231
00:08:39,000 --> 00:08:40,000
它會

232
00:08:40,000 --> 00:08:41,000
它跑到的程式的比例

233
00:08:41,000 --> 00:08:42,000
會有多少

234
00:08:42,000 --> 00:08:44,000
然後現在很多的

235
00:08:44,000 --> 00:08:45,000
模糊測試工具

236
00:08:45,000 --> 00:08:46,000
都是以這個為基準

237
00:08:46,000 --> 00:08:49,000
去看這個 seed 是好是壞

238
00:08:49,000 --> 00:08:52,000
然後 AFL 裡面

239
00:08:52,000 --> 00:08:54,000
AFL 裡面是使用插樁的方法

240
00:08:54,000 --> 00:08:56,000
去實作這個功能

241
00:08:56,000 --> 00:08:59,000
它就是去在程式的

242
00:08:59,000 --> 00:09:01,000
程式的某一個地方

243
00:09:01,000 --> 00:09:03,000
這邊也不會細講

244
00:09:03,000 --> 00:09:04,000
這個細講起來

245
00:09:04,000 --> 00:09:06,000
要講非常久

246
00:09:06,000 --> 00:09:08,000
然後它主要是在做

247
00:09:08,000 --> 00:09:10,000
就是把它插到某一個地方

248
00:09:10,000 --> 00:09:12,000
就比如說 function 的最一開始

249
00:09:12,000 --> 00:09:15,000
或是 if-else 的最一開始之類的

250
00:09:15,000 --> 00:09:18,000
它會去記錄它

251
00:09:18,000 --> 00:09:19,000
有沒有跑到這邊

252
00:09:19,000 --> 00:09:22,000
然後它如果跑到這邊的話

253
00:09:22,000 --> 00:09:23,000
它就會記錄起來

254
00:09:23,000 --> 00:09:26,000
然後去跟 fuzzer 溝通

255
00:09:26,000 --> 00:09:27,000
然後這邊有一段

256
00:09:27,000 --> 00:09:29,000
簡單的範例 code

257
00:09:29,000 --> 00:09:31,000
就是

258
00:09:31,000 --> 00:09:32,000
這個也沒有什麼

259
00:09:32,000 --> 00:09:33,000
就是讓它

260
00:09:33,000 --> 00:09:35,000
讓那個 a 等於 100 的時候進 f

261
00:09:35,000 --> 00:09:37,000
其他就進 g 嘛

262
00:09:37,000 --> 00:09:38,000
g-function

263
00:09:38,000 --> 00:09:40,000
然後我想要給大家看的是

264
00:09:40,000 --> 00:09:42,000
這個是沒有插樁的 code

265
00:09:42,000 --> 00:09:43,000
就是大家可以看到

266
00:09:43,000 --> 00:09:45,000
它就是一個 GCC 編出來

267
00:09:45,000 --> 00:09:47,000
非常正常的一個

268
00:09:47,000 --> 00:09:49,000
的

269
00:09:49,000 --> 00:09:51,000
那個組合語言

270
00:09:51,000 --> 00:09:53,000
然後這邊是有插樁的 code

271
00:09:53,000 --> 00:09:55,000
然後他們插樁是

272
00:09:55,000 --> 00:09:57,000
會自己再去寫

273
00:09:57,000 --> 00:09:59,000
就是用自己的 compiler

274
00:09:59,000 --> 00:10:01,000
就是他們有那種

275
00:10:01,000 --> 00:10:03,000
LLVM 或是

276
00:10:03,000 --> 00:10:05,000
對 LLVM 可以使用

277
00:10:05,000 --> 00:10:06,000
然後我們可以看到

278
00:10:06,000 --> 00:10:07,000
這邊就有一個

279
00:10:07,000 --> 00:10:09,000
afl maybe log

280
00:10:09,000 --> 00:10:10,000
它就會 call 這個

281
00:10:10,000 --> 00:10:12,000
然後去記錄說

282
00:10:12,000 --> 00:10:14,000
記錄說現在

283
00:10:14,000 --> 00:10:16,000
記錄說它要跑到這邊

284
00:10:16,000 --> 00:10:18,000
它如果有

285
00:10:18,000 --> 00:10:19,000
如果進這個 function 之後

286
00:10:19,000 --> 00:10:21,000
有跑到

287
00:10:21,000 --> 00:10:23,000
這個的 afl maybe log

288
00:10:23,000 --> 00:10:24,000
它就會去記錄

289
00:10:24,000 --> 00:10:25,000
說它要跑到這邊

290
00:10:25,000 --> 00:10:27,000
然後再去跟 fuzzer 溝通說

291
00:10:27,000 --> 00:10:30,000
它要跑到這邊

292
00:10:30,000 --> 00:10:31,000
整體的概念大概是這樣

293
00:10:31,000 --> 00:10:33,000
當然實作的細節

294
00:10:33,000 --> 00:10:35,000
大家其實可以去 trace call

295
00:10:35,000 --> 00:10:41,000
或是可以討論之類的

296
00:10:41,000 --> 00:10:43,000
所以整個的流程

297
00:10:43,000 --> 00:10:44,000
大概是剛才講的那樣

298
00:10:44,000 --> 00:10:45,000
但是我們好像還有一個

299
00:10:45,000 --> 00:10:47,000
很重要的問題是說

300
00:10:47,000 --> 00:10:49,000
那我們要怎麼去

301
00:10:49,000 --> 00:10:50,000
run 這個 target

302
00:10:50,000 --> 00:10:52,000
我們一般熟悉的

303
00:10:52,000 --> 00:10:55,000
熟悉的去 run 一個 target

304
00:10:55,000 --> 00:10:57,000
就是用 fork 加 esec 沒錯

305
00:10:57,000 --> 00:10:59,000
但是這樣子的話

306
00:10:59,000 --> 00:11:00,000
fork 加 esec

307
00:11:00,000 --> 00:11:03,000
這樣子的 overhead 會太大

308
00:11:03,000 --> 00:11:05,000
它的效率不好

309
00:11:05,000 --> 00:11:07,000
所以

310
00:11:07,000 --> 00:11:09,000
這邊就是它效率不好的原因

311
00:11:09,000 --> 00:11:12,000
就是因為它會先釋放資源

312
00:11:12,000 --> 00:11:14,000
再重載回來

313
00:11:14,000 --> 00:11:16,000
但是我們要使用的資源

314
00:11:16,000 --> 00:11:17,000
基本上是一樣的

315
00:11:17,000 --> 00:11:19,000
就是執行同一段程式

316
00:11:19,000 --> 00:11:21,000
所以我們現在要想一個方法

317
00:11:21,000 --> 00:11:24,000
說我們就設一個點

318
00:11:24,000 --> 00:11:26,000
有一個 checkpoint

319
00:11:26,000 --> 00:11:29,000
讓它可以繼續從這邊執行就好了

320
00:11:29,000 --> 00:11:33,000
然後 AFL 想到的方法是

321
00:11:33,000 --> 00:11:35,000
就是在 Libc.man 裡面

322
00:11:35,000 --> 00:11:39,000
有一個機制叫做 constructor

323
00:11:39,000 --> 00:11:42,000
這個東西會在 man 之前執行

324
00:11:42,000 --> 00:11:45,000
所以我們只要設一個 constructor

325
00:11:45,000 --> 00:11:48,000
它會在 man 之前執行

326
00:11:48,000 --> 00:11:49,000
我們只要在這邊

327
00:11:49,000 --> 00:11:51,000
在 fork 出一個 trial process

328
00:11:51,000 --> 00:11:53,000
trial process 會去跑

329
00:11:53,000 --> 00:11:55,000
我們所謂的搜尋程式

330
00:11:55,000 --> 00:11:57,000
然後 parents 就會回去

331
00:11:57,000 --> 00:11:59,000
回去去等

332
00:11:59,000 --> 00:12:01,000
就是 trial process 會去跑

333
00:12:01,000 --> 00:12:03,000
然後我們可以看一下下面的

334
00:12:03,000 --> 00:12:05,000
下面的一張流程圖

335
00:12:05,000 --> 00:12:10,000
我們 fuzzer 會先去 initial for server

336
00:12:10,000 --> 00:12:14,000
然後這邊基本上就會把 pipe 都接好

337
00:12:14,000 --> 00:12:18,000
之後如果當程式需要跑的時候

338
00:12:18,000 --> 00:12:20,000
fuzzer 希望我要搜尋程式了

339
00:12:20,000 --> 00:12:22,000
然後他就會去把這個

340
00:12:22,000 --> 00:12:25,000
他就會去寫東西過去 pipe 裡面

341
00:12:25,000 --> 00:12:27,000
然後跟他說你可以 fork 了

342
00:12:27,000 --> 00:12:28,000
我現在已經準備好了

343
00:12:28,000 --> 00:12:31,000
然後他就會 fork 出一個 trial process

344
00:12:31,000 --> 00:12:33,000
trial process 就會去跑搜尋程式

345
00:12:33,000 --> 00:12:36,000
然後 parents 就會回去去等

346
00:12:36,000 --> 00:12:38,000
等那個 read

347
00:12:38,000 --> 00:12:40,000
他會 hand 在那邊等下一次的

348
00:12:40,000 --> 00:12:43,000
mutate and run 的時候

349
00:12:43,000 --> 00:12:45,000
他才會繼續跑

350
00:12:45,000 --> 00:12:49,000
整體的流程大概是這樣

351
00:12:49,000 --> 00:12:52,000
因為今天時間的關係

352
00:12:52,000 --> 00:12:54,000
所以我 demo 的部分

353
00:12:54,000 --> 00:12:56,000
我準備了幾張圖

354
00:12:56,000 --> 00:12:59,000
然後如果各位有興趣的話

355
00:12:59,000 --> 00:13:01,000
回去可以那個 [geekron]

356
00:13:01,000 --> 00:13:03,000
[geekron.af] 有下來

357
00:13:03,000 --> 00:13:05,000
或是我有寫一個腳本

358
00:13:05,000 --> 00:13:08,000
在那個 reference 下面有一個腳本

359
00:13:08,000 --> 00:13:10,000
大家可以直接跑這個腳本

360
00:13:10,000 --> 00:13:12,000
他是 run 得起來的

361
00:13:12,000 --> 00:13:13,000
然後這個是

362
00:13:13,000 --> 00:13:14,000
大家可能會想說

363
00:13:14,000 --> 00:13:16,000
那我今天在插樁的時候

364
00:13:16,000 --> 00:13:18,000
他到底有沒有插進去

365
00:13:18,000 --> 00:13:19,000
那其實插進去的時候

366
00:13:19,000 --> 00:13:21,000
其實我們就看得到了

367
00:13:21,000 --> 00:13:22,000
他就會長得像這樣

368
00:13:22,000 --> 00:13:24,000
他不會跟你一般編譯

369
00:13:24,000 --> 00:13:25,000
編譯程式一樣

370
00:13:25,000 --> 00:13:28,000
就是可能就是幾行過去

371
00:13:28,000 --> 00:13:30,000
但是他會顯示一些

372
00:13:30,000 --> 00:13:32,000
afl 的主特的東西

373
00:13:32,000 --> 00:13:34,000
所以大家可以看

374
00:13:34,000 --> 00:13:35,000
看說有沒有

375
00:13:35,000 --> 00:13:39,000
這樣就是有插樁到

376
00:13:39,000 --> 00:13:41,000
然後接下來是

377
00:13:41,000 --> 00:13:43,000
這個是 fuzzer 跑起來的畫面

378
00:13:43,000 --> 00:13:45,000
然後基本上

379
00:13:45,000 --> 00:13:47,000
runtime 的部分就是

380
00:13:47,000 --> 00:13:50,000
就是可以看跑的時間

381
00:13:50,000 --> 00:13:53,000
然後他會有一個

382
00:13:53,000 --> 00:13:55,000
cycle down 就是

383
00:13:55,000 --> 00:13:56,000
這個 queue

384
00:13:56,000 --> 00:13:58,000
你的 queue 裡面被跑了幾次

385
00:13:58,000 --> 00:13:59,000
然後 total payoff

386
00:13:59,000 --> 00:14:00,000
基本上就是你現在的

387
00:14:00,000 --> 00:14:02,000
seed 有幾個

388
00:14:02,000 --> 00:14:04,000
然後如果有 crash 的話

389
00:14:04,000 --> 00:14:05,000
如果有 crash 的話

390
00:14:05,000 --> 00:14:06,000
這邊就會顯示

391
00:14:06,000 --> 00:14:09,000
然後他會放在一個目錄下面

392
00:14:09,000 --> 00:14:11,000
然後這邊可以看他的

393
00:14:11,000 --> 00:14:13,000
code coverage

394
00:14:13,000 --> 00:14:15,000
這邊就是這個 map 的部分

395
00:14:15,000 --> 00:14:18,000
然後整體的

396
00:14:18,000 --> 00:14:19,000
比較有用的大概就這幾個

397
00:14:19,000 --> 00:14:21,000
其他就還好

398
00:14:21,000 --> 00:14:23,000
好

399
00:14:23,000 --> 00:14:24,000
差不多

400
00:14:24,000 --> 00:14:26,000
我控制得還不錯

401
00:14:26,000 --> 00:14:27,000
好

402
00:14:27,000 --> 00:14:29,000
那

403
00:14:29,000 --> 00:14:32,000
我就先看 Q&A 的部分好了

404
00:14:32,000 --> 00:14:34,000
等一下