摘要:          本人進(jìn)2年來主要在做windbg調(diào)試相關(guān)的工作, 有一些心得和體會. 我會逐片寫在我blog中,希望對大家有用.  windbg調(diào)試最重要的是要對系統(tǒng)的方方面面有比較深入的了解. 只有了解了系統(tǒng)工作原理才能夠順藤摸瓜.  一步步展開線索.   windbg基礎(chǔ)篇...  閱讀全文

寄存器沒有地址

也就是寄存器存放著存儲器的地址．

ＣＰＵ通過寄存器中存放的存儲器地址來訪問存儲器中的數(shù)據(jù)

X86系列的處理器中的寄存器較少,所以
沒有給cpu中的寄存器進(jìn)行編址,而是直接對這些寄存器進(jìn)行了命名.在訪問寄存器的時候只要直接使用寄存器名就可以了.


lea指令舉例：
lea 取得地址（第二個參數(shù)）后放入到前面的寄存器。
如：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中的數(shù)據(jù)存入edi寄存器所指向的存儲器地址中。同時，edi會增加4（字節(jié)數(shù)）
rep是指令重復(fù)執(zhí)行ecx中填寫的次數(shù)

從FS寄存器獲取當(dāng)前線程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寄存器獲取當(dāng)前進(jìn)程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 地址指向線程環(huán)境塊_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和進(jìn)程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  >進(jìn)程ID
   +0x004 UniqueThread     : Ptr32 Void  >線程ID

當(dāng)然從TEB又可以找到_PEB的地址，從_PEB里面可以獲取到更多的信息。暫且擱筆~~

      在驅(qū)動中分配內(nèi)存，通常你的驅(qū)動會向NT VMM請求內(nèi)存，這是你必須決定你的內(nèi)存是可分頁的或者非可分頁的。
      分配原則：盡量使用可分頁內(nèi)存，但是必須注意高等級IRQL執(zhí)行不允許page fault。所以不允許采用可分頁內(nèi)存。可以使用PAGED_CODE();宏來檢查。
      非分頁內(nèi)存在系統(tǒng)中是一個有限的資源，取決于操作系統(tǒng)和物理內(nèi)存大小. (NT VMM使用一個私有算法來計算非分頁大小，這個算法使用物理內(nèi)存總是作為計算因子來計算。)
     NT提供如下例程來分配內(nèi)存：
       ExAllocatePool();
       ExAllocatePoolWithQuota();
       ExAllocatePoolWithTag();
        ExAllocatePoolWithQuotaTag
       調(diào)用以上例程分配內(nèi)存是必須制定內(nèi)存的類型：
       NonPagedPool
       PagedPool
       NonPagedPoolMustSuccessed.
       ......................

    關(guān)于非分頁內(nèi)存碎片問題：
     本來初始化的時候地址都是相鄰的非分頁池會變成碎片。而且VMM在托大的時候也不保證地址相鄰。
    如果請求的分配或者釋放小塊內(nèi)存（小于一個PAGE_SIZE）,可能導(dǎo)致物理內(nèi)存碎片化。這回給系統(tǒng)帶來各種各樣的問題，包括降低系統(tǒng)性能和分配內(nèi)存失敗的情況。
    解決辦法使用旁視列表，旁視列表是一個NT4.0開始提供的一個內(nèi)存分配方式；具體請參考WDK docment.
     順便提一下內(nèi)核棧：
     每個在NT平臺的線程有一個用戶棧在用戶模式執(zhí)行的時候使用，一個內(nèi)核棧在內(nèi)核模式執(zhí)行的時候使用。當(dāng)線程請求系統(tǒng)服務(wù)而切換到內(nèi)核模式的時候，陷阱機(jī)制會切換棧。用分配和線程的內(nèi)核空間棧來覆蓋用戶空間棧。
在NT3.51之前，內(nèi)核棧限制在兩頁的內(nèi)存中。NT4.0開始增加到12KB.必須要謹(jǐn)慎的在棧上使用變量以節(jié)省占空間，防止超過限制而是系統(tǒng)停止。

首先是參數(shù)說明宏。參數(shù)說明宏一般都是空宏，最常見的是IN和OUT。其實定義很簡單，如下所示：
#define IN
#define OUT
        這樣一來，IN和OUT就被定義成了空。無論出現(xiàn)在代碼中的任何地方，對代碼都不會有什么實質(zhì)的影響。在WDK的代碼中，用來作為函數(shù)的說明。IN表示這個參數(shù)用于輸入；OUT表示這個參數(shù)用來返回結(jié)果。比如下面的例子：
NTSTATUS
  ZwQueryInformationFile(
    IN HANDLE  FileHandle,
    OUT PIO_STATUS_BLOCK  IoStatusBlock,
    OUT PVOID  FileInformation,
    IN ULONG  Length,
    IN FILE_INFORMATION_CLASS  FileInformationClass
    );
        IN和OUT是比較傳統(tǒng)的參數(shù)說明宏。在WDK中到處可見更復(fù)雜的參數(shù)說明宏，比如下面的例子：
VOID
NdisProtStatus(
    IN NDIS_HANDLE                          ProtocolBindingContext,
    IN NDIS_STATUS                          GeneralStatus,
    __in_bcount(StatusBufferSize) IN PVOID  StatusBuffer,
    IN UINT                                 StatusBufferSize
    )

        其中的__in_bcount不但說明參數(shù)StatusBuffer是一個輸入?yún)?shù)，而且說明了StatusBuffer作為一個緩沖區(qū)，它的字節(jié)長度被另一個參數(shù)StatusBufferSize所指定。讀者再見到類似的說明宏，就以字面意思理解即可。

        然后是指定函數(shù)位置的預(yù)編譯指令。比如下面的例子：
NTSTATUS
ZwQueryInformationFile(
    IN HANDLE  FileHandle,
    OUT PIO_STATUS_BLOCK  IoStatusBlock,
    OUT PVOID  FileInformation,
    IN ULONG  Length,
    IN FILE_INFORMATION_CLASS  FileInformationClass
    );
        IN和OUT是比較傳統(tǒng)的參數(shù)說明宏。在WDK中到處可見更復(fù)雜的參數(shù)說明宏，比如下面的例子：
VOID
NdisProtStatus(
    IN NDIS_HANDLE                          ProtocolBindingContext,
    IN NDIS_STATUS                          GeneralStatus,
    __in_bcount(StatusBufferSize) IN PVOID  StatusBuffer,
    IN UINT                                 StatusBufferSize
    )
         其中的__in_bcount不但說明參數(shù)StatusBuffer是一個輸入?yún)?shù)，而且說明了StatusBuffer作為一個緩沖區(qū)，它的字節(jié)長度被另一個參數(shù)StatusBufferSize所指定。讀者再見到類似的說明宏，就以字面意思理解即可。

        然后是指定函數(shù)位置的預(yù)編譯指令。比如下面的例子：
#pragma alloc_text(INIT, DriverEntry)
#pragma alloc_text(PAGE, NdisProtUnload)
#pragma alloc_text(PAGE, NdisProtOpen)
#pragma alloc_text(PAGE, NdisProtClose)
#pragma alloc_text

        這個宏僅僅用來指定某個函數(shù)的可執(zhí)行代碼在編譯出來后在sys文件中的位置。內(nèi)核模塊編譯出來之后是一個PE格式的sys文件，這個文件的代碼段（text段）中有不同的節(jié)（Section），不同的節(jié)被加載到內(nèi)存中之后處理情況不同。讀者需要關(guān)心的主要是3種節(jié)：INIT節(jié)的特點是在初始化完畢之后就被釋放。也就是說，就不再占用內(nèi)存空間了。PAGE節(jié)的特點是位于可以進(jìn)行分頁交換的內(nèi)存空間,這些空間在內(nèi)存緊張時可以被交換到硬盤上以節(jié)省內(nèi)存。如果未用上述的預(yù)編譯指令處理，則代碼默認(rèn)位于PAGELK節(jié)，加載后位于不可分頁交換的內(nèi)存空間中。

        函數(shù)DriverEntry顯然只需要在初始化階段執(zhí)行一次，因此這個函數(shù)一般都用#pragma alloc_text(INIT, DriverEntry)使之位于初始化后立刻釋放的空間內(nèi)。為了節(jié)約內(nèi)存，可以把很多函數(shù)放在PAGE節(jié)中。但是要注意：放在PAGE節(jié)中的函數(shù)不可以在Dispatch級調(diào)用，因為這種函數(shù)的調(diào)用可能誘發(fā)缺頁中斷。但是缺頁中斷處理不能在Dispatch級完成。為此，一般都用一個宏P(guān)AGED_CODE()進(jìn)行測試。如果發(fā)現(xiàn)當(dāng)前中斷級為Dispatch級，則程序直接報異常，讓程序員及早發(fā)現(xiàn)。示例如下：
#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內(nèi)核安全編程》

User32.dll,kernel32.dll,shell32.dll,gdi32.dll,rpcrt4.dll,comctl32.dll,advapi32.dll,version.dll等dll代表了Win32 API的基本提供者；
Win32 API中的所有調(diào)用最終都轉(zhuǎn)向了ntdll.dll，再由它轉(zhuǎn)發(fā)至ntoskrnl.exe。ntdll.dll是本機(jī) API用戶模式的終端。真正的接口在ntoskrnl.exe里完成。事實上，內(nèi)核模式的驅(qū)動大部分時間調(diào)用這個模塊，如果它們請求系統(tǒng)服務(wù)。Ntdll.dll的主要作用就是讓內(nèi)核函數(shù)的特定子集可以被用戶模式下運行的程序調(diào)用。Ntdll.dll通過軟件中斷int 2Eh進(jìn)入ntoskrnl.exe，就是通過中斷門切換CPU特權(quán)級。
Ntdll.dll 上面的相關(guān)API函數(shù)原型和參數(shù)都沒有文檔化(Undocumented ):  http://undocumented.ntinternals.net/ 這里提供了Ntdll.dll部分未公開函數(shù)的原型.

理解window API及函數(shù)原型對我們的調(diào)試將是非常重要的: 因為你時常需要去察看一些函數(shù)的參數(shù),或者根據(jù)參數(shù)找到某些輸入指針.

例如:
  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 正在進(jìn)入某一個臨界區(qū).  0x77c8ba60 就是傳入的臨界值 參數(shù).

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

可以看到 LOCKED 代表臨界區(qū)是鎖定狀態(tài). 即被占用.
OwningThread   即是占用線程.

臨界區(qū)信息結(jié)構(gòu)定義在ntdll, 可以使用如下指令進(jìn)行察看.
> 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

察看某個動態(tài)庫函數(shù)表的指令:
x ntdll!*
x kernal!*

察看結(jié)構(gòu)體定義:
dt ntdll!*

任何動態(tài)庫包括window 32的用戶態(tài)dll 和用戶自定義動態(tài)庫都是生長在進(jìn)程內(nèi)存空間上的.
DLL 沒有自己的"私有"地址空間. 它們總是被影射到應(yīng)用程序的虛擬地址空間,在需要時才會被讀取到物理內(nèi)存中.
在本系列的其它章節(jié)我會談到虛擬地址空間的內(nèi)容.

通過指令可以看到ntdll 被映射到77800000 ~ 7793c000的內(nèi)存空間中.
> x *!
77800000 7793c000   ntdll      (pdb symbols)          c:\mylocalsymbols\ntdll.pdb\F0164DA71FAF4765B8F3DB4F2D7650EA2\ntdll.pdb

當(dāng)你的代碼(線程)棧中出現(xiàn)地址范圍在 77800000 ~7793c000 之間的函數(shù)調(diào)用都表示在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無法翻譯或者找到對應(yīng)symbols來顯示code stack. 這種錯誤往往是保存dump file時出現(xiàn)的某種異常信息.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.

這時候你需要手動的進(jìn)行恢復(fù)棧調(diào)用. 如果你了解每個動態(tài)庫的映射地址你就很容易進(jìn)行分析了.

察看動態(tài)庫中每個函數(shù)映射的地址可以采用如下指令 :
x ntdll!


手動恢復(fù)棧的大致原理如下:
1. 列出線程環(huán)境信息
 0:000> !teb

TEB at 7fffe000

    ExceptionList:        0012ff88

    StackBase:            00130000

    StackLimit:           00126000

    ……….

2. 打開整個線程棧.
0:000> dds 00126000 00130000

3. 察看內(nèi)存中所有可能是函數(shù)返回值.  
>ln address

     摘要:          本人進(jìn)2年來主要在做windbg調(diào)試相關(guān)的工作, 有一些心得和體會. 我會逐片寫在我blog中,希望對大家有用.  windbg調(diào)試最重要的是要對系統(tǒng)的方方面面有比較深入的了解. 只有了解了系統(tǒng)工作原理才能夠順藤摸瓜.  一步步展開線索.   windbg基礎(chǔ)篇...  閱讀全文

本程序只關(guān)注對Gif紋理的實現(xiàn)。不對GIF加解密進(jìn)行詳細(xì)的說明。
GIF文檔解析采用gif89a.h, gif89a.cpp實現(xiàn)。

gif89a 代碼下載

詳細(xì)紋理生成代碼：

如有任何疑問請留言。交流~~