###### tags: `Computer Security`

# HW0x03 Writeup (Reverse)

## 1. fifo

IDA decompile後可以看到main有出現file, path, open等字眼

用gdb設breakpoint在open處看一下file是什麼

接著看到程式寫了一些不知道什麼的東西進去khodsmeogemgoe裡，然後開了一個資料夾，最後mkfifo了一個檔案並open它
那就一樣設breakpoint觀察一下，剛剛mkdir應該是bnpkevsekfpk3這個資料夾，fifo檔案是資料夾裡的aw3movsdirnqw
但題目只給了一個檔案，所以可以推斷會去讀aw3movsdirnqw這個fifo檔案的程式應該是一開始寫的那個khodsmeogemgoe，可以用IDA decompile它確認一下:

確認猜想無誤後，設breakpoint觀察一下兩支程式間交互的行為，會發現fifo會write一些東西，然後khodsmeogemgoe再read它
(這是fifo)
(這是khodsmeogemgoe)

最後khodsmeogemgoe會call sub_1209，在gdb裡可以直接觀察到sub_1209把flag解出來


:::success
:triangular_flag_on_post: FLAG{FIFO_1s_D1sGVsTln9}
:::

### Reference:
1. http://manpages.ubuntu.com/manpages/xenial/zh_TW/man4/fifo.4.html

#### 追記
其實本來看到題目fifo以為會跟queue的操作有關，結果完全不是，後來查了mkfifo才知道fifo檔案是什麼東西，才順利解出來

---

## 2. giveUflag

上課有提到說作業會要我們爬看看DLL，IDA也可以看到程式會去爬InMemoryOrderModuleList，那就先爬看看吧
以下是爬出來的結果:

peb()+0x18 = 315018 = 00007FFA436FA4C0 (Ldr)
00007FF1436FA4C0 + 0x20 = 00000000007C2E80 (table_entry) 

7C2E80 : 7C2CF0 | 7FFA436FA4E0
7C2E80+0x20 = 400000 (giveuflag.exe)
7C2E80+0x60 = 7FFA436FA280

7C2CF0 : 7C3410 | 7C2E80
7C2CF0+0x30 = 7FFA43590000 (ntdll.dll)
7C2CF0+0x60 = 7C2EE0

7C3410 : 7C3A20 | 7C2CF0
7C3410+0x20 = 7FFA43020000 (kenrel32.dll)
7C3410+0x60 = 7FFA436FA260

7C3A20 : 7C4C00 | 7C3410
7C3A20+0x20 = 7FFA40CB0000 (kernelbase.dll)
7C3A20+0x60 = 7FFA436FA180

7C4C00 : 7FFA436DA4E0 | 7C3A20
7C4C00+0x20 = 7FFA42910000 (msvcrt.dll)
7C4C00+0x60 = 7FFA436FA1F0

跟x64dbg爬出來的結果一樣

爬完後開IDA看，可以發現sub_1550是在爬DLL

用x64dbg跟著sub_1550走，可以看到爬出的function是sleep

回到IDA，跟x64dbg比對後就可以知道下面的v5和v4是sleep，而
參數604800000是一個禮拜，下面for迴圈應該就是把flag解出來的東西，


也就是說，只要程式放著三個禮拜flag應該就會吐出來，但當然不可能真的放著等
直接在x64dbg改RIP跳到迴圈前，然後繼續執行:

:::success
:triangular_flag_on_post: FLAG{PaRs1N6_PE_aNd_D11_1S_50_C00111!!!!!111}
:::

#### 追記
一開始打開的時候看到三張圖的連結，發現是1/2/3 week(s) later，又看到參數604800000，就猜應該是sleep了，但還是照著爬了一下確定自己沒有猜錯XD

---

## 3. nani

直接跑程式，只看到Unpack Me和Bye~
丟IDA，確認程式用了packer
用Detect it easy查
嗯，UPX，脫殼

IDA和x64dbg一步一步追程式，可以得知程式的流程大概是這個樣子:

印出"Unpack Me" → 印出"Bye~" → 檢查是否使用Debugger(有就退出程式) → 檢查是否使用VM(有就退出程式) → 丟出overflow error

VM部分本來就沒使用，所以不會有問題，Anti-debug的部分，可以用講義提到的ScyllaHide來迴避偵測:

接著找Handler開逆，IDA Pro好像沒成功爬出來，所以用PE-bear找看看:

會吐exception的在這個區間內

找對應Address並跟著Unwind info的結構看，得到以下資訊:
CountOfCodes=05(column2)，column 5到column E是Unwind Code，column F對齊，所以16FB是Handler

回到IDA找4016FB，確實有一個function，而且看起來很像在解flag

跑完迴圈後看一下4015AF的樣子...結果不是FLAG，只能先繼續往下追
最後return前把4015AF存到6DF4A8，但目前還看不出用途，繼續往下

可以發現程式跳回4015AF的地方跑，代表剛剛Exception Handler裡解出來的東西其實是code
逆一下解出來的code，會發現塞了一些值，然後跟AE XOR，順下來看就看到F、L、A、G幾個字跟著出現
再追一下code，觀察它會把FLAG存在哪裡
迴圈結束後到6DF9F8看，發現完整的FLAG

:::success
:triangular_flag_on_post: FLAG{r3v3rs3_Ma5T3R}
:::
### Reference:
1. https://sentrywhale.com/writeup/redpwn2019-betterdoorthanannt

#### 追記
這題相較上面兩題難度感覺難了許多。其實一開始找到FLAG是讓程式停在結束之前在6DF4A8(因為當初沒看出來放在這邊的用途)附近上下亂翻意外發現的。找到之後才回頭研究到底是哪邊在解FLAG，也是這時候才知道原來4015AF的地方解出來是code。
另外也發現x64dbg的"搜尋匹配特徵"(Ctrl+B)功能可以在資料視窗內用ASCII搜尋hex value。在一些不用使用者輸入的題目中應該多多少少可以拿來用(?)