基地dll地址總是不同和散列不匹配

我做了一個程序，從一個進程的加載的DLL（模塊）中讀取X字節，並散列它們以將它們與硬編碼的乾淨散列進行比較。該模塊的基地址是總是相同（在XP和7上由不同的人在幾個不同的計算機上測試），並且哈希也總是相同。基地dll地址總是不同和散列不匹配

但是對於一個人來說，基地址總是不同的，散列也總是不同的（每次運行都不相同）。他正在使用Windows 7旗艦版。

我的問題是：

爲什麼模塊的基本地址總是不同？我知道DLL可以在不同的地址加載，但是觸發這種行爲的是什麼？（Is DLL always have the same Base Address?）基地址始終是0x02XXXXXX類型，而其他人獲得的永不改變的地址是0x6F000000。
爲什麼散列不匹配？即使模塊被加載到不同的地址，我仍然從base + someoffset中讀取相同數量的字節。不僅散列不同，每次運行程序時都不相同。正因爲如此，我懷疑這個基地址實際上是錯誤的，而且有些可怕的事情正在發生。我比較了我的dll和他的dll的MD5，它們是相同的，所以加載的庫是非常相似的。
1. 獲取的處理句柄（CreateToolhelp32SnapshotProcess32Next，）（GetModuleFileNameEx
2. 枚舉加載的模塊（EnumProcessModules）
3. 查找名稱的特定模塊：
的代碼中的所採取的步驟）並獲取句柄
向模塊基地址添加一個偏移量（模塊內的偏移量）
讀取X與ReadProcessMemory(hProcess, base_of_module+some_additional_offset, dllBuffer_to_read_into, 0x100000, &numRead)其中的0x100000確實從模塊字節不溢出模塊尺寸

什麼這個節目做的是比較反對一個「乾淨」的哈希發現篡改內存中的DLL內容惡意軟件/黑客/等。

來源

2014-07-08 cen

」該程序正在做的是將內存中的dll內容與「乾淨」哈希進行比較，以發現惡意軟件/黑客入侵等。 - 如果有人鉤住了GetModuleFileNameEx這個例子，那麼你的工具就沒用了。 – user2120666

尋找不同的解決方案。黑客可能知道你在做什麼，並使第一個X字節與你的DLL匹配。一個更好的方法可能是調用DLL中傳遞一些「隨機」信息的方法，並讓方法計算一些關於隨機數據的信息，然後檢查它是否正確。（這會稍微難以破解） –

我知道系統並不完美，無論如何也不可能，但我現在只需要它就可以工作。 – cen

其他一些配置爲在每個進程中加載的DLL在該系統上加載。這可以例如如果您安裝網絡攝像頭或鼠標軟件，會發生這些情況，這會迫使他們的DLL在每個進程中加載。當然，如果將此DLL加載到防止使用您的首選基地址的地址，您的DLL將被重新定位。
搬遷。加載DLL時，加載程序會解析.reloc節，並將絕對地址的更正直接寫入所加載的DLL映像。爲了創建正確的散列，您還必須讀取重定位目錄並糾正這些DLL的加載器修改。

來源

2014-07-08 14:14:40 Erik

因此，如果我做我的轉儲和他的轉儲的差異，我會看到相同的dll「代碼」，但所有地址都糾正爲新的基地打破哈希？得到了正確的？ – cen

是的，如果僅比較只讀部分，那麼這是您應該期望的。然而，比較一個讀寫數據部分不會工作。 – Erik

我檢查了差異和是啊..它基本上是一樣的東西，但碎片一直在打破它。這將需要很多努力。 – cen

你的方法不能希望成功。 DLL的基址只是加載程序的指南。加載器可以選擇在該地址加載DLL。如果這樣做，它不需要修復任何絕對引用。但是，如果請求的地址不可用（進程中的其他內容已經保留了請求的地址範圍），或者加載程序選擇不使用請求的地址（例如ASLR），則該DLL將在一些其他地址。然後重定位表將用於修改絕對引用。

爲了讓您的散列計算更加健壯，您需要考慮重定位問題。原則上，您可以讀取重定位表，並在執行散列計算時考慮重定位。然而，這可能是非常棘手的正確。

來源

2014-07-08 14:15:24

最可能的原因是來自Microsoft的增強型緩解體驗工具包EMET。

EMET所做的一件事就是強制執行ASLR（地址空間佈局隨機化），即強制所有DLL以隨機地址加載，即使它們未配置爲使用ASLR。這使得攻擊者利用漏洞更加困難。「

來源

2014-07-08 23:27:24

基地dll地址總是不同和散列不匹配

回答

相關問題