紅色警戒2逆向系列：COM服務器
上一篇我們在入口函數(shù)中發(fā)現(xiàn)了主要邏輯，這一篇我們會繼續(xù)分析主要邏輯
因為反匯編出來的代碼有兩百多行，全部放出來大家觀感可能不好，所以我不會全部貼出來。大家感興趣的話可以用Ghidra逆向出來看
首先，一個有意思的代碼是
這是一個空函數(shù)。所以為什么需要一個空函數(shù)呢？放一個空函數(shù)很可能是用于輸出一些調試信息，實際上從這里就能發(fā)現(xiàn)西木的開發(fā)人員很懶，在開發(fā)完成之后有限的刪除了調試信息。這對我們逆向人員是一個好消息。
如果大家按順序接著看，會看見該程序創(chuàng)建了一個互斥體，并且初始化了窗口，這些沒有什么重要意義，我們直接跳過。
接下來我們可以看見，程序讀取了RA2MD.ini；并且設置了視頻緩存和窗體大小。
如果不仔細看，可能會漏掉這行代碼
但是這段代碼是有意義的，它里面進行了COM服務器的注冊和初始化，從這里我們也可以看見，從原版到尤里的復仇，除了功能多了，代碼的結構也進行了優(yōu)化，至少原版的COM服務器初始化代碼是直接寫在主邏輯函數(shù)里的，導致該函數(shù)有1000多行
言歸正傳，該函數(shù)有600多行，如果大家想看的話，我可以貼出來放到網盤里，直接寫在這里太長了。COM服務器是一種進程間通信的方式，是DLL和主程序連接的一種標準化的辦法。所以，我們可以直接看紅色警戒2用了哪些DLL
其中Ares大家都懂，BinwK是一種視頻播放器，可能是用于播放每個關卡前的動畫的。不知道大家玩紅警的時候是不是看到過這個動畫。實際上早期因為網絡速度限制，很多紅警是沒有開場動畫的，這個動畫里面有很多關于劇情的設定，所以大家可以去看看。
Blowfish是一種加密的算法，而EDRAW我們不知道是做什么用的，但是從名字來看，可能提供了某些圖形處理或者繪圖用的DLL。
接下來的程序中大量出現(xiàn)了這段代碼。這里我們可以發(fā)現(xiàn)CoRegisterClassObject實際上是一個注冊COM組件的方法，而如果要連接到COM服務器觀察它做了什么，需要用到CLSID，也就是這里的IID。要知道這里的DAT_007e9520值，我們可以通過斷點和調試來尋找。
于是掏出我們的GDB
然后大家就高興的發(fā)現(xiàn)，游戲卡死了
這很有可能是因為游戲采用了反調試機制，當發(fā)現(xiàn)有程序掛載的時候，會故意制造混亂的邏輯，讓逆向工程師不能獲得任何有用的信息。
當然，這不代表我們就不能調試了，我們要做的是反反調試；不過我們首先需要在反編譯的代碼中尋找到它是如何反調試的。不得不說，西木工作室這一招還是非常成功的，成功給我們添加了巨大的工作量。這是一場跨越20年的對弈了。
如何反反調試可能要下一篇文章才能講了，原因是我尚未發(fā)現(xiàn)反調試的檢測點。我查看了符號表，KERNEL32的反調試函數(shù)中
IsDebuggerPresent：用于檢查當前進程是否被調試器附加。
CheckRemoteDebuggerPresent：用于檢查指定進程是否被調試器附加。
DebugActiveProcess：用于將當前進程附加到指定進程的調試器中。
DebugActiveProcessStop：用于將當前進程從指定進程的調試器中分離。
WaitForDebugEvent：用于等待調試事件的發(fā)生。
都沒有發(fā)現(xiàn)，所以可能沒有使用這些方法，也可能是手動調用了相關的方法，但是更有可能是自己實現(xiàn)了反調試相關的技術。這個程序還使用了大量的動態(tài)調用方法，反正是很難的一件事情，這篇文章我們不可能能夠寫完。
為了防止大家說我太水。這里再加一點對于之前提到的強AI的思考。
雖然我們之前說吊打淋巴的時候口嗨很爽，但是真的在開發(fā)的時候，其實是很困難的?？v觀AI薄殺人類的歷史（DeepMind罪魁禍首）。強化學習技術一直都是被經常用到的。RTS游戲是一個高度復雜性和不確定性的環(huán)境，如果僅通過強化學習讓其收斂是不可能的。因此，我認為首先需要一些啟發(fā)性的算法。很多人覺得神經網絡是一個可行的辦法，實際上，我們能夠獲得的數(shù)據(jù)不多于3000局，而且很多都需要從視頻中推算戰(zhàn)場的數(shù)據(jù)，一是數(shù)據(jù)量太少，二是數(shù)據(jù)質量不高。
這個時候我們可以查看一些非常厲害的玩RTS游戲的AI，Overmind和AlphaStar是DeepMind公司開發(fā)的兩款玩《星際爭霸II》的人工智能程序。其中AlphaStar的啟發(fā)式訓練用到了10萬局的的對局數(shù)據(jù)。之后才采用了自我對弈進行訓練。很顯然，紅色警戒2的戰(zhàn)場數(shù)據(jù)記錄接口都沒有被發(fā)掘出來，很有可能本專欄是第一個發(fā)現(xiàn)這個接口的文章，因此學習AlphaStar是不成立的。Overmind采用了一些手動或者AI生成的自動策略，并且采用CNN來進行游戲中的操作。這個是可行的，因為我們也可以手動設置一些策略。不過Overmind并沒有這么強大，很有可能被淋巴吊打。
ChatGPT覺得在設計這種AI程序的時候，需要考慮到幾點：
資源管理：實時戰(zhàn)略游戲通常需要管理多種資源，如礦物質、氣體、人口等。AI需要學會有效地采集和分配資源以支持其戰(zhàn)略目標。
技能管理：游戲中的單位通常具有特殊技能和能力，如治療、傷害、隱身等。AI需要學會合理使用這些技能來達到戰(zhàn)略目標。
單位控制：實時戰(zhàn)略游戲中通常需要控制多個單位進行戰(zhàn)斗，包括攻擊、移動、保護等等。AI需要學會高效地控制這些單位來執(zhí)行其戰(zhàn)略。
戰(zhàn)術選擇：游戲中通常有多種戰(zhàn)術選擇，如進攻、防御、圍攻等。AI需要學會根據(jù)局勢選擇最佳的戰(zhàn)術。
對手建模：為了制定最佳的戰(zhàn)略和戰(zhàn)術，AI需要學會建立對手的模型，包括其行為和策略。這需要對對手的數(shù)據(jù)進行分析，例如其單位組成、資源分配等等。
這只是一點非常初級的思考，并且我也并不懂人工智能。希望大家能夠和我一起討論
下集預告：GDB反反調試，追蹤DebugLogger()
(PS 接下來一篇發(fā)布的時間不確定，取決于西木工作室做了哪些反調試工作)
