1625-5 王子昂 總結《2017年12月3日》 【連續第429天總結】
A. JarvisOJ-Re-軟體密碼破解-3（2）
B.
看來短時間還搞定不了這題了……
上回說到題目中最後計算了一個區域的值的長度，準備研究它的來源

通過查詢交叉引用發現了這個地方：

OD跟蹤也可以發現確實是這裡在負責寫入

裡面有一些機制來判斷數字範圍，例如必須為十六進位制大寫數字，否則將直接return結束該函式

利用這個機制倒是可以寫出長度為8的字串，例如123456780xxxxxxx
但是此時確定按鈕又不可用了，原因出在最後

return strlen(byte_571458) != 8
 

而這個函式的返回值被用在有效性的設定上

    v5 = sub_4017C0(MultiByteStr) != 0;
    v6 = CWnd::GetDlgItem(v1, 1);
    CWnd::EnableWindow(v6, v5);

因此這就陷入了一個矛盾的境地–“確定”按鈕可用需要長度非8，成功提示則需要長度為8
len和test cl, cl的原理是相同的，因此沒有漏洞可以利用

從另一方面來考慮，由於FLAG的唯一性，所以自由組合的flag肯定是不可能的，這裡必然不是真正的解題點

首先存在很多反調，這個我發現了，但是由於沒什麼影響所以沒太在意
另一方面關鍵函式是sub_401970，而我雖然在交叉引用中看到這個函式對關鍵區域有讀寫，但是卻根本沒有注意它

學著對其下斷，整個執行過程中也沒有呼叫
正當我自暴自棄地繼續執行的時候，發現當程式走向錯誤路徑時

這裡[edx]的內容是輸入的第2、3個字元，所以jmp必然會引起錯誤

而之前執行的時候從來沒有異常結束的情況

於是執行，發現程式在sub_401970的地方斷下了！
說明這是個SEH（異常處理結構）

於是在OD中檢視SEH鏈

果然其中有一些函式插入的程式，這點是我大意沒有注意到

但是sub_401970的呼叫堆疊中也沒有看到與SEH鏈中相重合的內容……

雖然可以確定sub_401970的呼叫方式肯定是SEH，但是還沒搞明白是誰在呼叫，怎麼呼叫的，下一步研究這一點
另一方面sub_401970對關鍵區域的讀寫還需要進一步分析，從而得到flag

C. 明日計劃
軟體密碼破解-3（3）