題:
反向自修改惡意軟件
rustam Shirinov
2017-10-23 01:19:54 UTC
view on stackexchange narkive permalink

最近,我得到了一個示例,該示例可以自我修改其 .text 部分。因此,我在寫操作的 .text 部分上放置了一個斷點,然後繼續。我發現它會將 .text 部分歸零,然後將解密的代碼寫入該部分,然後調用解密的OEP。我使用Scylla來糾正OEP並轉儲 .exe 文件。

Scylla_output

它表明該程序僅導入 kernel32.dll

PEBear_output

這是轉儲的 PEBear 中的code> .exe 文件。

ImmunityDBG_output

這是我得到的我嘗試在 ImmunityDbg 中打開轉儲的文件。

我獲得的導入內容與 Scylla 給我的文件也大不相同+轉儲的程序沒有運行它立即崩潰。我在做什麼錯了?

謝謝。

您能否提供文件的sha256哈希?
防血壓1604 YB 431
ImmunityDbg是OllyDbg的一個分支,有時兩者都難以識別未包裝部分的代碼。在Olly中,您可以右鍵單擊這些無法識別的代碼,然後單擊“分析”>“分析代碼”。我建議您遵循[此答案](https://reverseengineering.stackexchange.com/a/91/18698)中提到的Igor步驟。請記住這一點,您通常很難製作一個解壓縮的文件可執行文件。
謝謝您的建議,順便說一句,即使我做相同的事情,每次執行相同的過程時,我都會忘記提及哈希值,但是我卻忘了提及。
使用反調試方法是否可能存在惡意軟件?
有一個對`IsDebuggerPresent`的調用,但是我已經對其進行了修補。
二 答案:
peter ferrie
2017-10-27 20:51:10 UTC
view on stackexchange narkive permalink

首先在入口點本身上放置一個斷點,該斷點可能根本不在.text部分中,而是完全在另一個部分中。您將看到該程序可以動態地解析其自身的導入,可能是通過在kernel32.dll中搜索LoadLibrary和GetProcAddress。

通過頂層的跟踪,您還將發現解密何時完成並進行了傳輸。對解密的代碼進行控制。如果在那一刻轉儲文件,然後反彙編結果,則可能能夠看到崩潰的原因-可能是反調試機制,在此列出了太多的可能性(但是 http://pferrie.host22.com/papers/antidebug.pdf中的常用選項)。

謝謝。即使我的問題是IAT,我也會投票贊成詳細答案。
rustam Shirinov
2017-10-28 00:16:53 UTC
view on stackexchange narkive permalink

感謝所有回答。 IAT是問題所在。我發現的OEP是指向解壓縮代碼的真實OEP。但是轉儲的可執行文件不可運行,因為IAT已損壞。在Scylla中修復IAT之後。現在可以運行了。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...