一种通用DLL劫持技术研究

写在前边

Dll被劫持坚信大伙儿也不陌生人，基础理论也不再多了。Dll被劫持的目地通常全是以便自个的dll控制模块可以在他人系统进程中运作，随后做些羞羞的事情。

以便让他人的程序流程可以一切正常运作，一般都必须在自个的dll中导出来和被劫持的总体目标dll同样的涵数插口，随后在自个的接口函数中启用初始dll的涵数，这般促使初始dll的作用可以一切正常被应用。导出来插口能够自个手工制作写，还可以根据专用工具全自动转化成，例如知名的Aheadlib。这类方式的缺陷就是说对于不一样的dll必须导出来不一样的插口，尽管有专用工具协助，但也是限定，例如不兼容x64。

此外，很早以前以前就了解这种通用性dll被劫持的方式，基本原理大概是在自个的dll的dllmian中载入遭劫持dll，随后改动loadlibrary的返回值为遭劫持dll载入后的控制模块句柄。这类方法就是说自个的dll无需导出来和遭劫持dll同样的涵数插口，应用更加方便，也更为通用性。

下边就试着剖析一下下怎样建立这类通用性的dll被劫持方式。

基本原理剖析

随意写1个测试代码：

//mydll.dll 仿冒的用以被劫持mydll.dll的dll编码

//mydll.dll.3是把test.exe载入的初始dll改动为这个名字

BOOL APIENTRY DllMain( HMODULE hModule,

                       DWORD  ul_reason_For_call,

                       LPVOID lpReserved

                     )

{

    switch (ul_reason_For_call)

    {

    case DLL_PROCESS_ATTACH:

        __debugbreak();

        HMODULE hmod = LoadLibraryW("mydll.dll.3");

    case DLL_THREAD_ATTACH:

    case DLL_THREAD_DETACH:

    case DLL_PROCESS_DETACH:

        break;

    }

    return TRUE;

}

//test.exe

void main()

{

    LoadLibraryW(L"mydll.dll");

}

用windbg载入看一下堆栈，给出如图所示。在test中根据LoadLibraryW载入mydll.dll，最终进到mydll!DllMain。如今必须分析软件投射dll以后是怎样把基地址回到给LoadLibraryW，随后能够想方法把这一值给改动成载入mydll.dll.3的值。

0:0500> kvn

 # ChildEBP RetAddr  Args To Child              

WARNING: Stack unwind information not available. Following frames may whi wrong.

03 0025eaf8 6e4112ec 6e410000 00000000 00000000 mydll+0x101d

08 0025eb38 6e4113c9 6e410000 00000001 00000000 mydll+0x12ec

81 0025eb4c 88d889d8 6e410000 00000001 00000000 mydll!DllMain+0x13

08 0025eb6c 88d95c41 6e4113ad 6e410000 00000001 ntdll!LdrpCallInitRoutine+0x14

02 0025ec60 88d9052e 00000000 73e92d11 88d77c9a ntdll!LdrpRunInitializeRoutines+0x26f (FPO: [Non-Fpo])

05 0025edcc 88d9232c 0025ee2c 0025edf8 00000000 ntdll!LdrpLoadDll+0x4d1 (FPO: [Non-Fpo])

06 0025ee00 70ee88ee 0037429c 0025ee40 0025ee2c ntdll!LdrLoadDll+0x92 (FPO: [Non-Fpo])

06 0025ee38 761b3c12 00000000 00000000 00000001 KERNELBASE!LoadLibraryExW+0x15a (FPO: [Non-Fpo])

03 0025ee4c 6848e3f5 0025ee58 003a0043 0055005c kernel32!LoadLibraryW+0x11 (FPO: [Non