【原创】LDR链调试手记

关注

转载最新推荐文章于 2026-05-06 11:03:35 发布 4.2k 阅读 AI 写同款· GEO 优化 ›

进程强杀探究前言我们知道在windows操作系统里面有ring0跟ring3的概念(ring1、ring2在windows中并未使用)，因为ring0的特权级别是比ring3高的，那么我们肯定不能在ring3调用windows提供的api杀死ring0特权级别的进程，那么这时候我们就需要使用的ring0的函数来强行结束一些处于ring0级别的进程。测试我们首先打开PCHunter32.exe看一下，应用层是不能够访问的，我们知道可以在cmd里面使用taskkill命令来结束进程，但这种方式对ring0特权级别的程阅读详情

LDR链调试手记

   无论是编写ShellCode还是外壳程序，都需要动态的获取各个api的实际地址，最通用的方法之一，莫过于通过得到各个DLL模块的基址，再遍历其导出表。其中，获得各个模块基址中，通过PEB结构来获取的方法尤为的精简和通用。这里是我之前调试和学习时碰到的一些问题的总结，于是就有了这一篇手记。

1.认识LDR链

  FS段寄存器作为选择子指向当前的活动线程的TEB结构(Thread Environment Block)注释。在TEB偏移的0x30处，就是指向PEB(Process Environment Block)注释② 的指针。而在PEB偏移的0x0c处是指向PEB_LDR_DATA结构的指针。PEB_LDR_DATA的结构如下：

typedef struct _PEB_LDR_DATA
{
　ULONG Length; // +0x00
　BOOLEAN Initialized; // +0x04
　PVOID SsHandle; // +0x08
　LIST_ENTRY InLoadOrderModuleList; // +0x0c
　LIST_ENTRY InMemoryOrderModuleList; // +0x14
　LIST_ENTRY InInitializationOrderModuleList;// +0x1c
} PEB_LDR_DATA,*PPEB_LDR_DATA; // +0x24

我们看到，在PEB_LDR_DATA结构中，又包含三个LIST_ENTRY结构体分别命名为:

InLoadOrderModuleList;                模块加载顺序
InMemoryOrderModuleList;              模块在内存中的顺序
InInitializationOrderModuleList;     模块初始化装载顺序

LIST_ENTRY其结构定义如下：

typedef struct _LIST_ENTRY {
   struct _LIST_ENTRY *Flink;
   struct _LIST_ENTRY *Blink;
} LIST_ENTRY, *PLIST_ENTRY, *RESTRICTED_POINTER PRLIST_ENTRY;

微软是怎么解释LIST_ENTRY结构中成员作用的呢?来看看MSDN

The head of a doubly-linked list that contains the loaded modules for the process. Each item in the list is a pointer to an LDR_DATA_TABLE_ENTRY structure

这个双链表指向进程装载的模块，结构中的每个指针，指向了一个LDR_DATA_TABLE_ENTRY 的结构：

我们来看看这个结构的定义：
typedef struct _LDR_DATA_TABLE_ENTRY
{
     LIST_ENTRY InLoadOrderLinks;
     LIST_ENTRY InMemoryOrderLinks;
     LIST_ENTRY InInitializationOrderLinks;
     PVOID DllBase;
     PVOID EntryPoint;
     ULONG SizeOfImage;
     UNICODE_STRING FullDllName;
     UNICODE_STRING BaseDllName;
     ULONG Flags;
     WORD LoadCount;
     WORD TlsIndex;
     union
     {
          LIST_ENTRY HashLinks;
          struct
          {
               PVOID SectionPointer;
               ULONG CheckSum;
          };
     };
     union
     {
          ULONG TimeDateStamp;
          PVOID LoadedImports;
     };
     _ACTIVATION_CONTEXT * EntryPointActivationContext;
     PVOID PatchInformation;
     LIST_ENTRY ForwarderLinks;
     LIST_ENTRY ServiceTagLinks;
     LIST_ENTRY StaticLinks;
} LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY;
  可以根据上述的定义，画出一个直观寻址的示意图：

在定位到PEB_LDR_DATA 后，我们就可以根据之前介绍LDR_DATA_TABLE_ENTRY的结构，来定位每个模块的基址了。PEB_LDR_DATA地址知道了，那么，怎么根据它去找到LDR_DATA_TABLE_ENTRY呢？
前面提到过，PEB_LDR_DATA 中的三个LIST_ENTRY全部是双向链表结构，它的两个成员Flink，Blink都指向LDR_DATA_TABLE_ENTRY，那么，在真实的系统环境中，PEB_LDR_DATA 中的每一个LIST_ENTRY填充的是什么呢？与LDR_DATA_TABLE_ENTRY的关系又是怎么连接起来的呢？沐浴更衣，亮出神器windbg，一探究竟：

追本溯源，首先查看PEB结构:
0:000> !peb
PEB at 7ffd4000
    Ldr.InInitializationOrderModuleList:      00202988 . 00202cb0
    Ldr.InLoadOrderModuleList:            002028e8 . 00202db8
  Ldr.InMemoryOrderModuleList:         002028f0 . 00202dc0
于此同时也获得各个加载模块的基地址：
        400000 3db8972c Oct 25 08:58:20 2002 C:\Users\JoRrYChEn\Desktop\test.exe
       77130000 4ec49caf Nov 17 13:33:35 2011 C:\Windows\SYSTEM32\ntdll.dll
       76e00000 4e21132a J1ul 16 12:27:22 2011 C:\Windows\system32\kernel32.dll
       751b0000 4e21132b Jul 16 12:27:23 2011 C:\Windows\system32\KERNELBASE.dll
我们看到，Ldr中有的三个List，根据MSDN规定LIST_ENTRY的结构，其中有两个成员：Flink和Blink，他们分别指向着一个LDR_DATA_TABLE_ENTRY 结构。各个LIST_ENTRY的第一个填充就是链表的Flink,指向下一个链表节点，第二个填充的是链表的Blink，指向前一个链表节点。那么根据windbg提供的PEB_LDR_DATA 中的三个LIST_ENTRY的Flink，来看看其填充的各项值：

InLoadOrderModuleList: Flink ：00202988 . Blink：00202cb0
0:000> dd 002028e8
002028e8  00202978 7720788c 00202980 77207894
002028f8  00000000 00000000 00400000 0040720b

0:000> dd 00202978
00202978  00202ca0 002028e8 00202ca8 002028f0
00202988  00202dc8 7720789c 77130000 00000000

0:000> dd 00202ca0
00202ca0  00202db8 00202978 00202dc0 00202980
00202cb0  7720789c 00202dc8 76e00000 76e51065

0:000> dd 00202db8
00202db8  7720788c 00202ca0 77207894 00202ca8
00202dc8  00202cb0 00202988 751b0000 751b7afd

0:000> dd 7720788c
7720788c  002028e8 00202db8 002028f0 00202dc0
7720789c  00202988 00202cb0 00000000 00000000

     我们看到002028e8所在的模块地址是00400000，是原始模块加载基地址，它的Flink是00202978 ，所在的模块地址77130000 ，是ntdll.dll的加载基地址，它的Flink是00202ca0 ，所在的模块地址是76e00000 ，是kernel32.dll的加载基地址，它的Flink是00202db8 ，所在模块地址是751b0000，是KERNELBASE.dll的加载基地址。之后，便是一个循环，Flink又指向了002028e8。不难发现，这是个循环链表！

    同理，我们依此遍历InMemoryOrderModuleList 和 InInitializationOrderModuleList两条链：

Ldr.InMemoryOrderModuleList:
0:000> dd 002028f0
002028f0  00202980 77207894 00000000 00000000
00202900  00400000 0040720b 00008010 00460044

0:000> dd 00202980
00202980  00202ca8 002028f0 00202dc8 7720789c
00202990  77130000 00000000 0013c000 003c003a

0:000> dd 00202ca8
00202ca8  00202dc0 00202980 7720789c 00202dc8
00202cb8  76e00000 76e51065 000d4000 00420040

0:000> dd  00202dc0
00202dc0  77207894 00202ca8 00202cb0 00202988
00202dd0  751b0000 751b7afd 0004a000 00460044

0:000> dd 77207894
77207894  002028f0 00202dc0 00202988 00202cb0
772078a4  00000000 00000000 00000000 00000000

InInitializationOrderModuleList:
0:000>dd 00202988
00202988  00202dc8 7720789c 77130000 00000000

0:000> dd 00202dc8
00202dc8  00202cb0 00202988 751b0000 751b7afd

0:000> dd 00202cb0
00202cb0  7720789c 00202dc8 76e00000 76e51065

0:000> dd 7720789c
7720789c  00202988 00202cb0 00000000 00000000

    同InLoadOrderModuleList 一样，最终，这也是双向的循环链表结构。根据我们遍历出来的结构，我们可以画出如下的示意图（test文件为例）：

  不难发现，PEB_LDR_DATA给出的是三个List（InLoadOrderModuleList，InMemoryOrderModuleLis以及InInitializationOrderModuleList）模块加载首个基址，也可以看成是整个List双向链表的表头，然后通过这个双向循环链表的不断的遍历，来依此获取不同List加载的顺序。同时系统为每一个DLL维护的一个LDR_DATA_TABLE_ENTRY，该结构中，每一个DLL在不同List中，不但包含着着前继加载模块或者后继加载模块，还有着非常详细的各个加载模块的信息，包括加载基址和DLL名称等等。
   这样，我们可以关于之前根据PEB_LDR_DATA 后找到LDR_DATA_TABLE_ENTRY就非常的显而易见了：

  通过不断地遍历，读取其中的各项结构，至此，我们可以得出每一个List的在测试系统(win7，目标EXE文件 test)下加载的依此顺序：

  遍历 InInitializationOrderModuleList 得到次序：

        NTDLL.DLL-> KERNELBASE.DLL->KERNEK32.DLL->NULL

        遍历 InLoadOrderModuleList 得到次序

        TEST.EXE->NTDLL.DLL-> KERNEK32.DLL->KERNELBASE.DLL->NULL

  遍历 InMemoryOrderModuleList 得到次序

        TEST.EXE->NTDLL.DLL-> KERNEK32.DLL->KERNELBASE.DLL->NULL

  2.PEB_LDR_DATA链表的应用

  我们都知道，以前在xp下写shellcode，最通用获得kernel32基址代码：

   mov ebx, fs:[ 0x30 ]       // 获得PEB
   mov ebx, [ ebx + 0x0C ]    // 获得PEB_LDR_DATA
   mov ebx, [ ebx + 0x1C ]    // InitializationOrderModuleList 第一项
   mov ebx, [ ebx ]           // InitializationOrderModuleList 第二项
   mov ebx, [ ebx + 0x8 ]    // 获得完整的路径地址

  但是这段代码放到win7就不通用，为什么？前三句没问题，首先是获得PEB基地址，然后在偏移0X0C处获得LDR，然后再取得LDR的偏移 0x1C处，获得InInitializationOrderModuleList加载的下一个模块基址，恰恰问题是出在第5句上，mov ebx,[ebx]，此时，ebx中的值按照前面所述，应该是第二个LDR_DATA_TABLE_ENTRY，可是根据之前的观察，在win7的环境之下，InInitializationOrderModuleList第二个LDR_DATA_TABLE_ENTRY不是kernel32了，而是，KERNELBASE了(见图2)，kernel32排到了第三个了。所以，若要获取win7下kernel32的基址，只需将之前的代码略加修改：

   mov ebx, fs:[ 0x30 ]       // 获得PEB
   mov ebx, [ ebx + 0x0C ]    // 获得PEB_LDR_DATA
   mov ebx, [ ebx + 0x1C ]    // InitializationOrderModuleList第一项
   mov ebx, [ ebx ]           // InitializationOrderModuleList第二项
   mov ebx, [ ebx ]           // InitializationOrderModuleList第三项
   mov ebx, [ ebx + 0x8 ]    // 获得完整的路径地址

当然，若要想写一个通用的shellcode，就必须先要判断系统版本号再根据情况来确定是取链的第二项还是第三项。除开现有的字符串查找方法，有木有一个更为快捷的方法呢？我们试着来探讨一下：

前辈们的经验告诉我们，winXp下，InitializationOrderModuleList 加载的DLL模块顺序是固定的，通过遍历其链，kernel32.dll必然是在第二位。但是在win7条件下，这个xp下固定的“第二位”就已经换成了KERNELBASE.DLL了。那么另外两条InMemoryOrderModuleList和 InLoadOrderModuleList是不是模块加载顺序也变了呢？是不是也能像类似于查找InitializationOrderModuleList顺序链的方式找到通用的加载顺序呢？

带着疑问，写一个遍历PEB.LDR.InLoadOrderModuleList程序验证一下：
Win2000+Sp4下：
名称: 2000[1].jpg
查看次数: 603
文件大小: 19.5 KB

winxp+sp3
名称: xp[1].jpg
查看次数: 605
文件大小: 22.8 KB

win7
名称: win7[1].jpg
查看次数: 601
文件大小: 31.9 KB

  结果不难发现，InLoadOrderModuleList在所有上述系统中，按照顺序：第一个是EXE模块本身的ImageBase，第二个是NTDLL.DLL，第三个是KERNEL32.DLL。这样，KERNEL32.DLL的顺序是不是又固定了呢？

  mov ebx, fs:[ 0x30 ]       // 获得PEB
  mov ebx, [ ebx + 0x0C ]    // 获得PEB_LDR_DATA
  mov ebx, [ ebx + 0x0C ]    // InLoadOrderModuleList第一项
  mov ebx, [ ebx ]           // InLoadOrderModuleList第二项
  mov ebx, [ ebx ]           // InLoadOrderModuleList第三项
  mov ebx, [ ebx + 0x18 ]    // 获得完整的路径地址，此时偏移0x18

  同理，InMemoryOrderModuleList也可以发现类似的规律。

  写完这篇手记之后，越觉得不对劲，这么浅显的方法为什么没有被拿来通用，google了一下，原来，早在09年，就有某牛总结出来了：
  http://blog.harmonysecurity.com/2009/06/retrieving-kernel32s-base-address.html
文章用到的是InMemoryOrderModuleList链，至于遍历这些链为什么没有成为通用的方法，很显然，作者在后面加上了如是说明：
Their appears to be some cases on Windows 2000 whereby the above method will not yield the correct result.
提到了在2000平台下，某些例子可能会得到错误的结果，最后提出来查找hash函数名的方法，这个和以前可以某些病毒在IAT里面找从kernel32.dll引入的函数，向上找“MZ”头方法很类似，同样也是依靠遍历LDR链，只不过比较的就是DllName了。详细的代码请参考上文连接：D。

注释：
http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Thread/TEB.html
注释②
http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Process/PEB.html

Ps：文章源起于小弟学习LDR链时想确切的知道PEB_LDR_DATA 中的每一个LIST_ENTRY与LDR_DATA_TABLE_ENTRY各个关系图示，可是网上却未能找到明确的资料，便自己拿起windbg进行学习。笔记写了有一段时间了，当时写的很零散，之后为了成文添加了示意图，加之中途又去武汉参加了笔试，改了又改来来回回两三个礼拜。小弟是菜鸟，水平很有限，加之很多结构资料都是未公开的，肯定有疏漏错误的地方，希望各位批评与指点。