??前不久實現(xiàn)了經(jīng)典dll注入exe，實現(xiàn)注入到用戶層面進程，比如notepad.exe和wps.exe。（像金山毒霸kxetray.exe有自我保護機制也注入不進去）。特此記錄一下。
??首先什么是反射式注入？它和傳統(tǒng)經(jīng)典注入有什么區(qū)別呢？我這里作個比喻。

經(jīng)典式：
??在目標進程申請一段空間并放入惡意dll，創(chuàng)建遠線程讓目標進程調(diào)用LoadLiabrary函數(shù)加載這段內(nèi)存
??先把病毒扔進鄰居家，告訴鄰居這是個炮仗(病毒dll)，鄰居誤以為真，點燃導火索(創(chuàng)建線程執(zhí)行)，顯然鄰居被騙了
反射式:
?? 在別人的內(nèi)存里調(diào)用自己編寫的dll導出函數(shù) ，自己dll導出函數(shù)里實現(xiàn)自我加載（加載PE的整個過程）
?? 先把病毒扔進鄰居家，然后自己把它直接點燃(調(diào)用dll導出函數(shù))，病毒自己爆炸(dll內(nèi)部實現(xiàn)自己從底層dll遍歷加載函數(shù))，鄰居渾然不知(沒有通過系統(tǒng)LoadLibrary調(diào)用dll，沒有記錄)

區(qū)別是啥
??少了使用LoadLibrary的過程。

反射式注入dll的優(yōu)點

?? 反射式注入方式并沒有通過LoadLibrary等API來完成DLL的裝載，DLL并沒有在操作系統(tǒng)中”注冊”自己的存在，因此ProcessExplorer等軟件也無法檢測出進程加載了該DLL。利用解密磁盤上加密的文件、網(wǎng)絡傳輸?shù)确绞奖苊馕募涞?#xff0c;DLL文件可以不一定是本地文件，可來自網(wǎng)絡等，總之將數(shù)據(jù)寫到緩沖區(qū)即可。
?? 由于它沒有通過系統(tǒng)API對DLL進行裝載，操作系統(tǒng)無從得知被注入進程裝載了該DLL，所以檢測軟件也無法檢測它。同時，由于操作流程和一般的注入方式不同，反射式DLL注入被安全軟件攔截的概率也會比一般的注入方式低。

實現(xiàn)需求

一、注射器
??（將這個DLL文件寫入目標進程的虛擬空間中）實現(xiàn)大部分和傳統(tǒng)注入一樣。但它要做一件很重要的事情，就是獲得病毒dll里的一個最重要的導出函數(shù)，也即是我們要編寫的反射加載自己的函數(shù)ReflectiveLoader的文件偏移。（如果你知道自己dll這個導出函數(shù)文件偏移多少其實也沒必要再用程序讀取）

二、編寫一個邪惡的dll以及它的核心函數(shù)ReflectiveLoader
??要知道ReflectiveLoader函數(shù)運行時所在的DLL還沒有被裝載，它在運行時會受到諸多的限制，例如無法正常使用全局變量等。而且，由于我們無法確認我們究竟將DLL文件寫到目標進程哪一處虛擬空間上，所以我們編寫的ReflectiveLoader必須是地址無關(guān)的。

注射器實現(xiàn)

??1. 將待注入DLL讀入自身內(nèi)存(可以在磁盤上存放一份DLL的加密后的版本，然后將其解密之后儲存在內(nèi)存里)
??2. 利用VirtualAlloc和WriteProcessMemory在目標進程中寫入待注入的DLL文件
??3.利用CreateRemoteThread等函數(shù)啟動位于目標進程中的ReflectiveLoader（要首先獲得ReflectiveLoader的文件偏移地址），獲取的是DLL中反射加載函數(shù)在文件中的偏移，由于這種注入沒有使用LoadLibraryA函數(shù)，所以DLL在內(nèi)存中的狀態(tài)和在磁盤中的狀態(tài)是相同的，要想調(diào)用函數(shù)，我們就需要找到文件偏移。
??線程函數(shù)的地址=緩沖區(qū)的基地址+文件偏移

圖中1264十六進制就是4F0

??4.通過DLL的導出表找到這個ReflectiveLoader并調(diào)用它
?? 將自身合適地展開到虛擬空間中。我們都知道在PE文件包含了許多節(jié)，而為了節(jié)省存儲空間，這些節(jié)在PE文件中比較緊密地湊在一起的。而在廣闊虛擬空間中，這些節(jié)就可以映射到更大的空間中去。（更不用說還存在著.bss這樣的在PE文件中不占空間，而要在虛擬空間中占據(jù)位置的節(jié)）

ReflectiveLoader函數(shù)實現(xiàn)

實現(xiàn)中的問題：

??DLL中可能會用到其他DLL的函數(shù)，裝載一個DLL還需要將這個DLL依賴的其他動態(tài)庫裝入內(nèi)存，并修改DLL的IAT指向到合適的位置，這樣對其他DLL函數(shù)的引用才能正確運作ReflectiveLoader的代碼是地址無關(guān)的，但是該DLL的其他部分的代碼卻并不是這樣的。在一份源代碼編譯、鏈接成為DLL時，編譯器都是假設該DLL會加載到一個固定的位置，生成的代碼也是基于這一個假設。在反射式注入DLL的時候，我們不太可能申請到這個預先設定好的地址，所以我們需要面對一個重定位（Rebasing）的問題。

解決方案

??1.ReflectiveLoader做的第一件事就是查找自身所在的DLL具體被寫入了哪個位置
ULONG_PTR caller( VOID ) { return(ULONG_PTR)_ReturnAddress(); }
借助上文找到的地址，我們逐字節(jié)的向上遍歷，當查找到符合PE格式的文件頭之后，就可以認為找到了DLL文件在內(nèi)存中的地址了。
Caller()函數(shù):獲得當前指令的下條指令的地址。

??2.我們需要的函數(shù)是kernel32.dll中的LoadLibraryA(), GetProcAddress()，VirtualAlloc()以及ntdll.dll中的NtFlushInstructionCache()函數(shù)。我們需要遍歷已經(jīng)加載的模塊，從中找到我們需要的模塊，獲得以上幾個函數(shù)的地址。
#define KERNEL32DLL_HASH 0x6A4ABC5B
#define NTDLLDLL_HASH 0x3CFA685D
#define LOADLIBRARYA_HASH 0xEC0E4E8E
#define GETPROCADDRESS_HASH 0x7C0DFCAA
#define VIRTUALALLOC_HASH 0x91AFCA54
#define NTFLUSHINSTRUCTIONCACHE_HASH 0x534C0AB8
// compute the hash values for this function name
dwHashValue = hash((char *)(uiBaseAddress + DEREF_32(uiNameArray)));
每一個線程都具有一個TEB結(jié)構(gòu)，記錄了相關(guān)線程的一些基本信息。線程運行時，其FS段寄存器記錄了其TEB的位置。
獲取PEB的方法：FS：[0x30]和GS:[0x60],前者為32位系統(tǒng)，后者為64位系統(tǒng)。
這里需要用到之前TEB定位與導出函數(shù)定位的知識。

??3. 分配一片用來裝載DLL的空間。
雖然在ReflectiveLoader運行時，DLL文件已經(jīng)在進程內(nèi)存中了，但是要裝載這個DLL，我們還需要更大的空間。借助在第2）步得到的函數(shù)VirtualAlloc()，我們可以分配一片更大的內(nèi)存空間用于加載DLL。在PE頭中的IMAGE_OPTIONAL_HEADER結(jié)構(gòu)體中的SizeOfImage成員記載DLL被裝載后的大小，我們按照這個大小分配內(nèi)存即可。
uiBaseAddress=(ULONG_PTR)pVirtualAlloc(NULL, ((PIMAGE_NT_HEADERS)uiHeaderValue)->OptionalHeader.SizeOfImage,
MEM_RESERVE|MEM_COMMIT,
PAGE_EXECUTE_READWRITE );
uiBaseAddress記錄了VirtualAlloc的返回值，也就是分配內(nèi)存空間的起始地址。于是uiBaseAddress就成為了DLL被裝載后的基地址。

??4.復制PE文件頭和各個節(jié)
分配了用于裝載的空間后，ReflectiveLoader將DLL文件的頭部(也就是DOS文件頭、DOS插樁代碼和PE文件頭)復制到新的空間的首部。再根據(jù)PE文件的節(jié)表將各個節(jié)復制到相應的位置中。

??5.根據(jù)節(jié)表加載節(jié)

??6. 處理DLL的導入表
被注入的DLL可能還依賴于其他的DLL，因此我們還需要裝載這些被依賴的DLL，并修改本DLL的引入表，使這些被引入的函數(shù)能正常運行。
無論是以什么方式導入，我們都要需要找到對應的函數(shù)，然后將其地址填入FirstThunk指向的IMAGE_THUNK_DATA數(shù)組中。這個跑起來是IAT

??7.對DLL進行重定位
??由于基址改變，所以程序中的一些直接尋址等會出問題，所以要更改重定向表。
??被注入的DLL只有其ReflectiveLoader中的代碼是故意寫成地址無關(guān)、不需要重定位的，其他部分的代碼則需要經(jīng)過重定位才能正確運行。
??我們首先計算得到基地址的偏移量，也就是實際的DLL加載地址減去DLL的推薦加載地址。DLL推薦加載地址保存在NT可選印象頭中的ImageBase成員中，而實際DLL加載地址則是我們在第3）步中函數(shù)VirtualAlloc()的返回值。然后我們將VirtualAddress和Typeoffset合力組成的地址所指向的雙字加上這個偏移量，重定位就完成了。
(DWORD)(VirtualAddress + Typeoffset的低12位) += （實際DLL加載地址 – 推薦DLL加載地址）
??在完成所有的重定位后，我們最后調(diào)用第2）步得到的NtFlushInstructionCache()清除指令緩存以避免問題。
8. 調(diào)用DLL入口點
??至此，ReflectiveLoader的任務全部完成，最后它將控制權(quán)轉(zhuǎn)交給DLL文件的入口點，這個入口點可以通過NT可選印象頭中的AddressOfEntryPoint找到。一般地，它會完成C運行庫的初始化，執(zhí)行一系列安全檢查并調(diào)用dllmain。

用到的底層C++語言編程

??dll遍歷kernel32與ntdll的導出函數(shù)部分用匯編語言更加直接簡短，這部分代碼同樣是大部分加殼程序的殼內(nèi)核心代碼，有時間一定會細心研究一下。
??_rotr函數(shù)，功能是value右循環(huán)移動shift位( unsigned int value, int shift );
??register 關(guān)鍵字請求“編譯器”將局部變量存儲于寄存器中——最快的關(guān)鍵字
??register 這個關(guān)鍵字請求編譯器盡可能的將變量存在CPU內(nèi)部寄存器，而不是通過內(nèi)存尋址訪問，以提高效率。注意是盡可能，不是絕對。
??數(shù)據(jù)從內(nèi)存里拿出來先放到寄存器，然后CPU 再從寄存器里讀取數(shù)據(jù)來處理，處理完后同樣把數(shù)據(jù)通過寄存器存放到內(nèi)存里，CPU 不直接和內(nèi)存打交道。
內(nèi)存 寄存器 CPU
??寄存器其實就是一塊一塊小的存儲空間，只不過其存取速度要比內(nèi)存快得多。CPU從寄存器里拿數(shù)據(jù)比在大內(nèi)存里去尋找某個地址上的數(shù)據(jù)快多了。
??__readgsqword(0x60) 從GS寄存器里讀取數(shù)值

查殺建議

??回想我們注射器實現(xiàn)的過程中所調(diào)用的函數(shù)，與正常的注入似乎沒有太大的區(qū)別，像CreateRemoteProcess這種危險函數(shù)殺軟抓的很嚴，可以被替換掉。整個過程沒有發(fā)現(xiàn)LoadLibraryA函數(shù)。但這個樣本有明顯的特征：解析PE結(jié)構(gòu)，所以當我們遇到這種樣本的時候，可以考慮為反射式DLL注入。
??用IDA逆向程序時，解析PE結(jié)構(gòu)的過程，編程中會出現(xiàn)很多+0xnumber 這里number代表十六進制數(shù)字。
??在磁盤發(fā)現(xiàn)某dll很可疑，如果該dll被注入到進程中已經(jīng)在運行，刪除或移動dll時會彈窗正在某某程序中使用，可以看到它是不是注入的dll。
??另外注入到進程的惡意Dll程序執(zhí)行錯誤時崩潰并不會導致被注入程序?qū)嶋H的崩潰。

參考

來源https://bbs.pediy.com/thread-224241.htm

總結(jié)

以上是生活随笔為你收集整理的反射式dll注入的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。