摘要:          本人进2年来主要在做windbg调试相关的工作, 有一些心得和体会. 我会逐片写在我blog中,希望对大家有用.  windbg调试最重要的是要对系统的方方面面有比较深入的了解. 只有了解了系统工作原理才能够顺藤摸瓜.  一步步展开线索.   windbg基础篇...  阅读全文

寄存器没有地址

也就是寄存器存放着存储器的地址．

ＣＰＵ通过寄存器中存放的存储器地址来访问存储器中的数据

X86系列的处理器中的寄存器较少,所以
没有给cpu中的寄存器进行编址,而是直接对这些寄存器进行了命名.在访问寄存器的时候只要直接使用寄存器名就可以了.


lea指令举例：
lea 取得地址（第二个参数）后放入到前面的寄存器。
如：lea edi, ebp  ,就是将ebp里存储的地址放入edi, 让edi也只想这个地址。
其实就是edi 指向ebp指向的存储器地址

又如: lea edi, [ebp+0cch],   []中代表存储器地址, 即ebp指向的存储器地址+0cch偏移。


再举一个例子：
mov ecx,30h
mov eax,0CCCCCCCCh
rep   stos dword ptr es:[edi]
stos是串存储指令，他的功能是将eax中的数据存入edi寄存器所指向的存储器地址中。同时，edi会增加4（字节数）
rep是指令重复执行ecx中填写的次数

从FS寄存器获取当前线程ID
int GetThreadId()
{
 int ithread = 0;
 _asm{
    xor esi , esi
    mov eax, fs:[esi+18h]     
       mov ecx, [eax+ 20h]
       mov eax, [eax+ 24h]
    mov dword ptr[ithread], eax
 }
 return ithread;
}
从FS寄存器获取当前进程ID
int GetProcessId()
{
 int iProcess = 0;
 _asm{
    xor esi , esi
    mov eax, fs:[esi+18h]
       mov ecx, [eax+ 20h]
       mov eax, [eax+ 24h]
    mov dword ptr[iProcess ], ecx
 }
 return iProcess ;
}

原理：
1.fs:18h 地址指向线程环境块_TEB
打开windbg可以证明：
0:028> dd fs:18h L1
0053:00000018  7eeb8000
0:028> !teb
TEB at 7eeb8000
    ExceptionList:        1f8ff15c
    StackBase:            1f900000
    StackLimit:           1f8fc000
    SubSystemTib:         00000000
    FiberData:            00001e00
    ArbitraryUserPointer: 00000000
    Self:                 7eeb8000
    EnvironmentPointer:   00000000
    ClientId:             00001a30 . 00001408
    RpcHandle:            00000000
    Tls Storage:          133d2718
    PEB Address:          7efde000
    LastErrorValue:       0
    LastStatusValue:      c0000302
    Count Owned Locks:    0
    HardErrorMode:        0

2. 在_TEB中找到线程ID和进程ID
0:028> dt ntdll!_TEB
   +0x000 NtTib            : _NT_TIB
   +0x01c EnvironmentPointer : Ptr32 Void
   +0x020 ClientId         : _CLIENT_ID

0:028> dt ntdll!_CLIENT_ID
   +0x000 UniqueProcess    : Ptr32 Void  >进程ID
   +0x004 UniqueThread     : Ptr32 Void  >线程ID

当然从TEB又可以找到_PEB的地址，从_PEB里面可以获取到更多的信息。暂且搁笔~~

      在驱动中分配内存，通常你的驱动会向NT VMM请求内存，这是你必须决定你的内存是可分页的或者非可分页的。
      分配原则：尽量使用可分页内存，但是必须注意高等级IRQL执行不允许page fault。所以不允许采用可分页内存。可以使用PAGED_CODE();宏来检查。
      非分页内存在系统中是一个有限的资源，取决于操作系统和物理内存大小. (NT VMM使用一个私有算法来计算非分页大小，这个算法使用物理内存总是作为计算因子来计算。)
     NT提供如下例程来分配内存：
       ExAllocatePool();
       ExAllocatePoolWithQuota();
       ExAllocatePoolWithTag();
        ExAllocatePoolWithQuotaTag
       调用以上例程分配内存是必须制定内存的类型：
       NonPagedPool
       PagedPool
       NonPagedPoolMustSuccessed.
       ......................

    关于非分页内存碎片问题：
     本来初始化的时候地址都是相邻的非分页池会变成碎片。而且VMM在托大的时候也不保证地址相邻。
    如果请求的分配或者释放小块内存（小于一个PAGE_SIZE）,可能导致物理内存碎片化。这回给系统带来各种各样的问题，包括降低系统性能和分配内存失败的情况。
    解决办法使用旁视列表，旁视列表是一个NT4.0开始提供的一个内存分配方式；具体请参考WDK docment.
     顺便提一下内核栈：
     每个在NT平台的线程有一个用户栈在用户模式执行的时候使用，一个内核栈在内核模式执行的时候使用。当线程请求系统服务而切换到内核模式的时候，陷阱机制会切换栈。用分配和线程的内核空间栈来覆盖用户空间栈。
在NT3.51之前，内核栈限制在两页的内存中。NT4.0开始增加到12KB.必须要谨慎的在栈上使用变量以节省占空间，防止超过限制而是系统停止。

首先是参数说明宏。参数说明宏一般都是空宏，最常见的是IN和OUT。其实定义很简单，如下所示：
#define IN
#define OUT
        这样一来，IN和OUT就被定义成了空。无论出现在代码中的任何地方，对代码都不会有什么实质的影响。在WDK的代码中，用来作为函数的说明。IN表示这个参数用于输入；OUT表示这个参数用来返回结果。比如下面的例子：
NTSTATUS
  ZwQueryInformationFile(
    IN HANDLE  FileHandle,
    OUT PIO_STATUS_BLOCK  IoStatusBlock,
    OUT PVOID  FileInformation,
    IN ULONG  Length,
    IN FILE_INFORMATION_CLASS  FileInformationClass
    );
        IN和OUT是比较传统的参数说明宏。在WDK中到处可见更复杂的参数说明宏，比如下面的例子：
VOID
NdisProtStatus(
    IN NDIS_HANDLE                          ProtocolBindingContext,
    IN NDIS_STATUS                          GeneralStatus,
    __in_bcount(StatusBufferSize) IN PVOID  StatusBuffer,
    IN UINT                                 StatusBufferSize
    )

        其中的__in_bcount不但说明参数StatusBuffer是一个输入参数，而且说明了StatusBuffer作为一个缓冲区，它的字节长度被另一个参数StatusBufferSize所指定。读者再见到类似的说明宏，就以字面意思理解即可。

        然后是指定函数位置的预编译指令。比如下面的例子：
NTSTATUS
ZwQueryInformationFile(
    IN HANDLE  FileHandle,
    OUT PIO_STATUS_BLOCK  IoStatusBlock,
    OUT PVOID  FileInformation,
    IN ULONG  Length,
    IN FILE_INFORMATION_CLASS  FileInformationClass
    );
        IN和OUT是比较传统的参数说明宏。在WDK中到处可见更复杂的参数说明宏，比如下面的例子：
VOID
NdisProtStatus(
    IN NDIS_HANDLE                          ProtocolBindingContext,
    IN NDIS_STATUS                          GeneralStatus,
    __in_bcount(StatusBufferSize) IN PVOID  StatusBuffer,
    IN UINT                                 StatusBufferSize
    )
         其中的__in_bcount不但说明参数StatusBuffer是一个输入参数，而且说明了StatusBuffer作为一个缓冲区，它的字节长度被另一个参数StatusBufferSize所指定。读者再见到类似的说明宏，就以字面意思理解即可。

        然后是指定函数位置的预编译指令。比如下面的例子：
#pragma alloc_text(INIT, DriverEntry)
#pragma alloc_text(PAGE, NdisProtUnload)
#pragma alloc_text(PAGE, NdisProtOpen)
#pragma alloc_text(PAGE, NdisProtClose)
#pragma alloc_text

        这个宏仅仅用来指定某个函数的可执行代码在编译出来后在sys文件中的位置。内核模块编译出来之后是一个PE格式的sys文件，这个文件的代码段（text段）中有不同的节（Section），不同的节被加载到内存中之后处理情况不同。读者需要关心的主要是3种节：INIT节的特点是在初始化完毕之后就被释放。也就是说，就不再占用内存空间了。PAGE节的特点是位于可以进行分页交换的内存空间,这些空间在内存紧张时可以被交换到硬盘上以节省内存。如果未用上述的预编译指令处理，则代码默认位于PAGELK节，加载后位于不可分页交换的内存空间中。

        函数DriverEntry显然只需要在初始化阶段执行一次，因此这个函数一般都用#pragma alloc_text(INIT, DriverEntry)使之位于初始化后立刻释放的空间内。为了节约内存，可以把很多函数放在PAGE节中。但是要注意：放在PAGE节中的函数不可以在Dispatch级调用，因为这种函数的调用可能诱发缺页中断。但是缺页中断处理不能在Dispatch级完成。为此，一般都用一个宏PAGED_CODE()进行测试。如果发现当前中断级为Dispatch级，则程序直接报异常，让程序员及早发现。示例如下：
#pragma alloc_text(PAGE, SfAttachToMountedDevice)
……
NTSTATUS
SfAttachToMountedDevice (
    IN PDEVICE_OBJECT DeviceObject,
    IN PDEVICE_OBJECT SFilterDeviceObject
    )
{       
    PSFILTER_DEVICE_EXTENSION newDevExt =
   SFilterDeviceObject->DeviceExtension;
    NTSTATUS status;
    ULONG i;

    PAGED_CODE();
 …

本文摘自《寒江独钓：Windows内核安全编程》

User32.dll,kernel32.dll,shell32.dll,gdi32.dll,rpcrt4.dll,comctl32.dll,advapi32.dll,version.dll等dll代表了Win32 API的基本提供者；
Win32 API中的所有调用最终都转向了ntdll.dll，再由它转发至ntoskrnl.exe。ntdll.dll是本机 API用户模式的终端。真正的接口在ntoskrnl.exe里完成。事实上，内核模式的驱动大部分时间调用这个模块，如果它们请求系统服务。Ntdll.dll的主要作用就是让内核函数的特定子集可以被用户模式下运行的程序调用。Ntdll.dll通过软件中断int 2Eh进入ntoskrnl.exe，就是通过中断门切换CPU特权级。
Ntdll.dll 上面的相关API函数原型和参数都没有文档化(Undocumented ):  http://undocumented.ntinternals.net/ 这里提供了Ntdll.dll部分未公开函数的原型.

理解window API及函数原型对我们的调试将是非常重要的: 因为你时常需要去察看一些函数的参数,或者根据参数找到某些输入指针.

例如:
  17  Id: a84.cc4 Suspend: 1 Teb: 7ff3a000 Unfrozen
ChildEBP RetAddr  Args to Child             
187ffdb8 77845e6c 7782fc72 00001938 00000000 ntdll!KiFastSystemCallRet
187ffdbc 7782fc72 00001938 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
187ffe20 7782fb56 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0x13e
187ffe48 01b05d13 0x77c8ba60 81fa55ed 028766c8 ntdll!RtlEnterCriticalSection+0x150

从堆栈可以看出线程17 正在进入某一个临界区.  0x77c8ba60 就是传入的临界值 参数.

17> !cs 0x77c8ba60             --> !cs 是用来查看临界区信息的命令
DebugInfo          = 0x77fbde20
Critical section   = 0x77c8ba60 (GDI32!semColorSpaceCache+0x0)
LOCKED
LockCount          = 0x0
OwningThread       = 0x00000dd8
RecursionCount     = 0x1
LockSemaphore      = 0x0
SpinCount          = 0x00000000

可以看到 LOCKED 代表临界区是锁定状态. 即被占用.
OwningThread   即是占用线程.

临界区信息结构定义在ntdll, 可以使用如下指令进行察看.
> dt  ntdll!_RTL_CRITICAL_SECTION
   +0x000 DebugInfo        : Ptr32 _RTL_CRITICAL_SECTION_DEBUG
   +0x004 LockCount        : Int4B
   +0x008 RecursionCount   : Int4B
   +0x00c OwningThread     : Ptr32 Void
   +0x010 LockSemaphore    : Ptr32 Void
   +0x014 SpinCount        : Uint4B

察看某个动态库函数表的指令:
x ntdll!*
x kernal!*

察看结构体定义:
dt ntdll!*

任何动态库包括window 32的用户态dll 和用户自定义动态库都是生长在进程内存空间上的.
DLL 没有自己的"私有"地址空间. 它们总是被影射到应用程序的虚拟地址空间,在需要时才会被读取到物理内存中.
在本系列的其它章节我会谈到虚拟地址空间的内容.

通过指令可以看到ntdll 被映射到77800000 ~ 7793c000的内存空间中.
> x *!
77800000 7793c000   ntdll      (pdb symbols)          c:\mylocalsymbols\ntdll.pdb\F0164DA71FAF4765B8F3DB4F2D7650EA2\ntdll.pdb

当你的代码(线程)栈中出现地址范围在 77800000 ~7793c000 之间的函数调用都表示在call NTDLL.dll
比如:
   7  Id: a84.c34 Suspend: 1 Teb: 7ff3f000 Unfrozen
ChildEBP RetAddr  Args to Child             
089bfe8c 77845e6c 75a0179c 00000d98 00000000 ntdll!KiFastSystemCallRet
089bfe90 75a0179c 00000d98 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
089bfefc 75c9f003 00000d98 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x98
089bff14 75c9efb2 00000d98 ffffffff 00000000 kernel32!WaitForSingleObjectExImplementation+0x75
089bff28 69434fea 00000d98 ffffffff 0780c178 kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
此线程中WARNING: Stack unwind information not available. Following frames may be wrong.表示windbg无法翻译或者找到对应symbols来显示code stack. 这种错误往往是保存dump file时出现的某种异常信息.window也没有给出合理的解释.
以下是MSDN的原话:
In some cases, the stack trace function will fail in the debugger. This can be caused by a call to an invalid address that caused the debugger to lose the location of the return address; or you may have come across a stack pointer for which you cannot directly get a stack trace; or there could be some other debugger problem. In any case, being able to manually walk a stack is often valuable.

这时候你需要手动的进行恢复栈调用. 如果你了解每个动态库的映射地址你就很容易进行分析了.

察看动态库中每个函数映射的地址可以采用如下指令 :
x ntdll!


手动恢复栈的大致原理如下:
1. 列出线程环境信息
 0:000> !teb

TEB at 7fffe000

    ExceptionList:        0012ff88

    StackBase:            00130000

    StackLimit:           00126000

    ……….

2. 打开整个线程栈.
0:000> dds 00126000 00130000

3. 察看内存中所有可能是函数返回值.  
>ln address

     摘要:          本人进2年来主要在做windbg调试相关的工作, 有一些心得和体会. 我会逐片写在我blog中,希望对大家有用.  windbg调试最重要的是要对系统的方方面面有比较深入的了解. 只有了解了系统工作原理才能够顺藤摸瓜.  一步步展开线索.   windbg基础篇...  阅读全文

本程序只关注对Gif纹理的实现。不对GIF加解密进行详细的说明。
GIF文档解析采用gif89a.h, gif89a.cpp实现。

gif89a 代码下载

详细纹理生成代码：

如有任何疑问请留言。交流~~