xctf-simple-check-100

水題一枚

這道題有點坑，給了三個平臺的程序文件，可惜win上面的是錯的。考察的也僅僅只是一個邏輯修改，不過爲了能從這道題學點東西，我把靜態情況下分析的結果利用py寫了個腳本來跑flag，算是對IDA中的算法逆向有了更深一步的理解吧。

算法描述

程序一開始會初始化一個數組，這裏我把它叫做key_data數組，ida自動分析出來的數值不好看把它轉爲16進制的：

然後就是輸出字符提示讓輸入key：

進入check_key函數判斷key是否正確，正確則進入interesting_function函數解碼flag：

check_key函數是一個計算校驗和與正確的校驗和對比的一個函數，ida自動分析出來是這樣：

經過簡單的修改參數類型之後如下，看起來更爲清晰，input_key作爲一個DWORD數組，有5個元素，也就是20個字節的長度：

算法就是將input_key看做一個DWORD數組將其每一項相加得到校驗和，而這個值要爲0xDEADBEEF纔是正確的，根據這個本來想爆破得到key的，可惜耗時太大不行。

再來看interesting_function函數，其參數即爲上面說到的key_data數組v7：
ida自動分析的結果如下：

稍加修改後如下：

這個函數就是解碼flag的過程，可以看出，解碼的數組都和輸入的key沒有關係，所以我們可以寫出解碼的腳本來得到flag，這就是我學習到的地方了。

同上面key_data的賦值來看，爲7個DWORD值，而interesting_function中通過兩層循環先將key_data的值與校驗和0xDEADBEEF(死牛肉，hhh)相異或，然後再將異或後的值一個一個字節與flag_data異或得到flag值，這裏需要注意異或後的值是從高地址處的字節開始異或的，又由於小端存放的原因，所以寫腳本的時候逐字節異或時按照結果從左到右，不要被內層循環的--j給迷惑了。

腳本

#!/usr/bin python
"""
xctf:simple-check-100
"""

key_data = [0xE37EC854,0x9A16C764,0x326511CD,0x43D3E32D,0xD29DA992,0xD32C6DE6,0x6AFEBDB6]

flag_data = [0xDC, 0x17, 0xBF, 0x5B, 0xD4, 0x0A, 0xD2, 0x1B, 0x7D, 0xDA, 0xA7, 0x95, 0xB5, 0x32, 0x10, 0xF6, 0x1C, 0x65, 0x53, 0x53, 0x67, 0xBA, 0xEA, 0x6E, 0x78, 0x22, 0x72, 0xD3]

def decode():
	flag = ""
	for i in range(7):
		tmp = hex(key_data[i] ^ 0xDEADBEEF)
		if len(tmp)<10:
			tmp = '0x'+'0'*(10-len(tmp))+tmp[2:]
		print "The XOR value:"+tmp
		for j in range(4):
			flag += chr(int('0x'+tmp[2*j+2:2*j+4],16)^flag_data[4*i+(3-j)])
	print "flag:"+flag

if __name__ == "__main__":
	decode()
# output
'''
The XOR value:0x3dd376bb
The XOR value:0x44bb798b
The XOR value:0xecc8af22
The XOR value:0x9d7e5dc2
The XOR value:0x0c30177d
The XOR value:0x0d81d309
The XOR value:0xb4530359
flag:flag_is_you_know_cracking!!!
'''

總結

好水的題，關鍵是菜，用OD分析時一直不得結果，原因是win上的程序有問題，在key_data賦值那一段是錯誤的，導致你繞過check_key之後也得不到正確的結果，換成elf文件來看纔是正確的。
最後一篇csdn blog了，在github上搭了新的blog，會抽時間把以前寫的一些有價值的東西遷移上去，應該很少吧！

---

給自己的忠告：多寫代碼，多睡覺！^_^