国庆回来，打开电脑，Windows Update更新了OGA通知（KB949810）的一个新版本。

更新完后重启电脑，登录进入桌面时OGAEXEC.exe进程出现错误提示，0x7c94cede处访问的0x00000000内存不能为Read。

网上搜索一下，发现这个问题八月底就有人在微软论坛反映了：
http://social.microsoft.com/Forums/en-US/genuineoffice/thread/3448c562-7799-45ec-ac41-a3fd4c36c45b
用户向微软反馈后，微软提供的方法是要求用户取消任务计划中的OGALogon.job，相当于取消这个验证功能来避免这个提示。这说明确实是OGA程序自己的问题。

为了看到问题在哪里，我再次重启电脑，当错误提示出现时点“取消”，激活了作为JIT调试器的WINDBG：

(bc0.7f0): Access violation - code c0000005 (!!! second chance !!!)
eax=0006fe58 ebx=0000ffff ecx=0006fe64 edx=0006fe80 esi=00000000 edi=80070000
eip=7c94cede esp=0006fe18 ebp=0006fe1c iopl=0         nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00000202
ntdll!RtlQueryInformationAcl+0x9:
7c94cede 8a06            mov     al,byte ptr [esi]          ds:0023:00000000=??

0:000> u ntdll!RtlQueryInformationAcl
ntdll!RtlQueryInformationAcl:
7c94ced5 8bff            mov     edi,edi
7c94ced7 55              push    ebp
7c94ced8 8bec            mov     ebp,esp
7c94ceda 56              push    esi
7c94cedb 8b7508          mov     esi,dword ptr [ebp+8]
7c94cede 8a06            mov     al,byte ptr [esi]
7c94cee0 3c02            cmp     al,2
7c94cee2 7256            jb      ntdll!RtlQueryInformationAcl+0x7d (7c94cf3a)

这个Access Violation是在ntdll!RtlQueryInformationAcl中触发的，原因是这时传入的pAcl参数为NULL。

0:000> kb
ChildEBP RetAddr Args to Child             
0006fe1c 77dc7e8f 00000000 0006fe58 0000000c ntdll!RtlQueryInformationAcl+0x9
*** ERROR: Module load completed but symbols could not be loaded for C:\WINDOWS\system32\OGAEXEC.exe
WARNING: Stack unwind information not available. Following frames may be wrong.
0006fe34 01004b5a 00000000 0006fe58 0000000c ADVAPI32!GetAclInformation+0x17
0006fe88 01006b12 00096d28 00000000 0006fec4 OGAEXEC+0x4b5a
0006febc 010090d6 00724e08 0006fed0 00000000 OGAEXEC+0x6b12
0006fed8 0100a183 01034320 00cc0004 00000000 OGAEXEC+0x90d6
0006ff10 0100a49e 00000001 00000000 00020b3e OGAEXEC+0xa183
0006ffa8 0101f9fb 019df984 019df9a4 7ffdb000 OGAEXEC+0xa49e
0006ffc0 7c817077 019df984 019df9a4 7ffdb000 OGAEXEC+0x1f9fb
0006fff0 00000000 0101f984 00000000 78746341 kernel32!BaseProcessStart+0x23

调用是从ADVAPI32!GetAclInformation进来的，ADVAPI32!GetAclInformation只是直接把参数push一遍然后传给了ntdll!RtlQueryInformationAcl，从上面信息看到传入ADVAPI32!GetAclInformation的pAcl参数就是NULL，根据MSDN，这必然会引发Access Violation：

The GetAclInformation function retrieves information about an access control list (ACL).

BOOL GetAclInformation(
PACL pAcl,
LPVOID pAclInformation,
DWORD nAclInformationLength,
ACL_INFORMATION_CLASS dwAclInformationClass
);

Parameters
pAcl
[in] A pointer to an ACL. The function retrieves information about this ACL. If a null value is passed, the function causes an access violation.

显然，这说明OGAEXEC.exe不应该在pAcl为NULL的情况下调用ADVAPI32!GetAclInformation（或者如果知道pAcl在调用时有可能为NULL的话，就应该搞个异常处理）。

进一步对OGAEXEC.exe的分析表明，OGAEXEC.exe调用该函数是为了获得文件odataext.dat的DACL信息。

具体地来说，OGAEXEC.exe调用GetFileSecurityW获取文件C:\Documents and Settings\All Users\Application Data\Office Genuine Advantage\data\odataext.dat的SecurityDescriptor：

.text:01006AD0
.text:01006AD0 loc_1006AD0:                            ; CODE XREF: sub_1006A24+A0 j
.text:01006AD0                 lea     eax, [ebp+nLengthNeeded]
.text:01006AD3                 push    eax             ; lpnLengthNeeded
.text:01006AD4                 push    [ebp+nLengthNeeded] ; nLength
.text:01006AD7                 mov     [ebp+var_4], edi
.text:01006ADA                 push    edi             ; pSecurityDescriptor
.text:01006ADB                 push    DACL_SECURITY_INFORMATION ; RequestedInformation
.text:01006ADD                 push    [ebp+lpFileName] ; lpFileName
.text:01006AE0                 call    esi ; GetFileSecurityW

然后对得到的SecurityDescriptor，调用GetSecurityDescriptorDacl获得其中的DACL：

.text:01004AF5
.text:01004AF5 loc_1004AF5:                            ; CODE XREF: sub_1004AC0+27 j
.text:01004AF5                 push    ebx
.text:01004AF6                 push    edi
.text:01004AF7                 lea     eax, [ebp+bDaclDefaulted]
.text:01004AFA                 push    eax             ; lpbDaclDefaulted
.text:01004AFB                 lea     eax, [ebp+pAcl]
.text:01004AFE                 push    eax             ; pDacl
.text:01004AFF                 lea     eax, [ebp+bDaclPresent]
.text:01004B02                 push    eax             ; lpbDaclPresent
.text:01004B03                 push    [ebp+SecurityDescriptor] ; pSecurityDescriptor
.text:01004B06                 call    ds:GetSecurityDescriptorDacl
.text:01004B0C                 test    eax, eax
.text:01004B0E                 mov     ebx, 0FFFFh
.text:01004B13                 mov     edi, 80070000h
.text:01004B18                 jnz     short loc_1004B33
.text:01004B18

对GetSecurityDescriptorDacl调用成功后的输出，OGAEXEC.exe做了这样的判断

.text:01004B33
.text:01004B33 loc_1004B33:                            ; CODE XREF: sub_1004AC0+58 j
.text:01004B33                 cmp     [ebp+bDaclPresent], esi ; esi is NULL
.text:01004B36                 jnz     short loc_1004B49 ; if bDaclPresent is TRUE, pAcl can also be NULL
.text:01004B36
.text:01004B38                 cmp     [ebp+pAcl], esi
.text:01004B3B                 jnz     short loc_1004B49
.text:01004B3B
.text:01004B3D                 mov     [ebp+var_4], 8000FFFFh
.text:01004B44                 jmp     loc_1004C6E
.text:01004B44

OGAEXEC.exe的以上判断逻辑认为，只要返回的bDaclPresent为TRUE，那么返回的pAcl值就一定非NULL，只有bDaclPresent为FALSE才需要对pAcl是否为NULL进行判断，这样在bDaclPresent为TRUE的情况下，直接就对该pAcl值调用了GetAclInformation：

.text:01004B49 ; ---------------------------------------------------------------------------
.text:01004B49
.text:01004B49 loc_1004B49:                            ; CODE XREF: sub_1004AC0+76 j
.text:01004B49                                         ; sub_1004AC0+7B j
.text:01004B49                 push    2               ; dwAclInformationClass
.text:01004B4B                 push    0Ch             ; nAclInformationLength
.text:01004B4D                 lea     eax, [ebp+pAclInformation]
.text:01004B50                 push    eax             ; pAclInformation
.text:01004B51                 push    [ebp+pAcl]      ; pAcl
.text:01004B54                 call    ds:GetAclInformation ; cause access violation
.text:01004B5A                 test    eax, eax
.text:01004B5C                 jnz     short loc_1004B77

然而，根据MSDN中对GetSecurityDescriptorDacl函数的解释：

A value of TRUE for lpbDaclPresent does not mean that pDacl is not NULL. That is, lpbDaclPresent can be TRUE while pDacl is NULL, meaning that a NULL DACL is in effect. A NULL DACL implicitly allows all access to an object and is not the same as an empty DACL. An empty DACL permits no access to an object. For information about creating a proper DACL, see Creating a DACL.

也就是说，在此处当bDaclPresent为TRUE时，pAcl可能为NULL，这时的NULL DACL表示对该对象允许所有权限。而OGAEXEC.exe没有对这种情况进行判断，导致在bDaclPresent为TRUE的情况下直接把一个为NULL的pAcl指针传给了ADVAPI32!GetAclInformation，导致后者在ntdll!RtlQueryInformationAcl访问这个NULL指针，从而触发了Access Violation异常。

源起http://bbs.pediy.com/showthread.php?p=686228
如果该帖楼主的问题是这样表述的：

“Intel或AMD的CPU情况下，系统内核文件应分别为ntoskrnl.exe和ntkrnlpa.exe，为什么我通过PsLoadedModuleList读取到的永远是ntoskrnl.exe？”

那么我可能很快就理解，然而楼主错误地把问题指向单核与双核的区别，说出了“内核文件名字ntkrnlmp.exe或者 ntoskrnl.exe”的话，结果我也就停留在告诉他“双核下内核文件名也不会叫ntkrnlmp.exe，虽然其源文件名是这个”。

之后自己动手试了一下才了解他问的问题的现象不是把双核内核文件显示成单核，而是系统把ntkrnlpa.exe的相应表项的BaseDllName也给显示成了ntoskrnl.exe。

lkd> dd PsLoadedModuleList
8055e720 855fc3b0 844dd2e0 00000000 00000000
8055e730 00000000 00000000 00000000 00000000
8055e740 80565bc0 80562de0 00000000 00000000
8055e750 00000000 00000000 00000000 00000000
8055e760 00000000 00000000 00000000 00000000
8055e770 00000000 00000000 8054b800 8054b000
8055e780 8054a200 80549000 8054d400 8054c000
8055e790 00000000 0000000c 0000000c 84e1db50
lkd> dt 855fc3b0 _LDR_DATA_TABLE_ENTRY
nt!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x855fc348 - 0x8055e720 ]
   +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
   +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
   +0x018 DllBase          : 0x804d8000
   +0x01c EntryPoint       : 0x806a2c08
   +0x020 SizeOfImage      : 0x20d000
   +0x024 FullDllName      : _UNICODE_STRING "\WINDOWS\system32\ntkrnlpa.exe"
   +0x02c BaseDllName      : _UNICODE_STRING "ntoskrnl.exe"
   +0x034 Flags            : 0xc004000
   +0x038 LoadCount        : 1
   +0x03a TlsIndex         : 0
   +0x03c HashLinks        : _LIST_ENTRY [ 0x0 - 0x1f3a86 ]
   +0x03c SectionPointer   : (null)
   +0x040 CheckSum         : 0x1f3a86
   +0x044 TimeDateStamp    : 0
   +0x044 LoadedImports    : (null)
   +0x048 EntryPointActivationContext : (null)
   +0x04c PatchInformation : 0x0074006e

事实俱在，用FullDllName就可以了。ZwQuerySystemInformation(SystemModuleInformation)也是用FullDllName的。

问题是这样解决了，然而我不死心，想知道为什么。于是只能一头扎进系统初始化的过程。

ntoskrnl.exe或ntkrnlpa.exe是在NTLDR!osloader.exe里加载的，相应LDR_DATA_TABLE_ENTRY也是在那里创建的，之后Windows内核初始化时再把BlLoaderBlock中的相应列表复制到PsLoadedModuleList中。

为了找到为什么相应LDR_DATA_TABLE_ENTRY中的BaseDllName永远是ntoskrnl.exe，我不得不去看看NTLDR!osloader.exe里是怎么创建它的。

NTLDR!osloader.exe里是在BlOsLoader函数中加载内核映像文件的。
BlOsLoader函数调用Blx86CheckForPaeKernel函数来判断应该加载哪个内核文件：

Blx86CheckForPaeKernel函数部分内容：
.text:00423B27                 mov     esi, offset s_Ntoskrnl_exe ; "ntoskrnl.exe"
.text:00423B2C                 mov     ebx, offset s_Ntkrnlpa_exe ; "ntkrnlpa.exe"
.text:00423B31                 jnz     short loc_423B3D
.text:00423B31
.text:00423B33                 cmp     byte ptr [ebp+PAEEnabled], 0
.text:00423B37                 mov     edi, ebx
.text:00423B39                 jnz     short loc_423B3D
.text:00423B39
.text:00423B3B                 mov     edi, esi
.text:00423B3B

调用BlLoadImageEx加载相应的内核文件。在此之后又加载了hal.dll和kdcom.dll

加载完这三个映像文件之后，就调用BlAllocateDataTableEntry函数为这三个文件创建LDR_DATA_TABLE_ENTRY表项。

对Windows内核文件创建LDR_DATA_TABLE_ENTRY表项的代码是这样的：

.text:004228E2                 lea     eax, [ebp+PNewDataEntry]
.text:004228E8                 push    eax             ; PNewDataEntry
.text:004228E9                 push    [ebp+DllBase]   ; DllBase
.text:004228EF                 lea     eax, [ebp+FullKernelName]
.text:004228F5                 push    eax             ; FullDllName
.text:004228F6                 push    offset s_Ntoskrnl_exe ; "ntoskrnl.exe"
.text:004228FB                 mov     _BlUsableLimit, 20000h
.text:00422905                 call    BlAllocateDataTableEntry(x,x,x,x)

该函数原型为

int __stdcall BlAllocateDataTableEntry(
        IN      char *BaseDllName,
        IN      char *FullDllName,
        IN      PVOID DllBase,
        OUT     PLDR_DATA_TABLE_ENTRY *PNewDataEntry)

其中第一参数指定的是填入LDR_DATA_TABLE_ENTRY 表项的BaseDllName.Buffer的字符串。

可以看到这里直接指定了BaseDllName为"ntoskrnl.exe"，这就是导致这里永远是ntoskrnl.exe的原因。

BlAllocateDataTableEntry的反汇编分析结果如下，可以很清楚地看出它是怎么填充结构内容的。

.text:00415927
.text:00415927 ; int __stdcall BlAllocateDataTableEntry(char *BaseDllName,char *FullDllName,PVOID DllBase,int PNewDataEntry)
.text:00415927 __stdcall BlAllocateDataTableEntry(x, x, x, x) proc near
.text:00415927                                         ; CODE XREF: AEInitializeIo(x)+8Bp
.text:00415927                                         ; BlScanImportDescriptorTable(x,x,x)+1A0p
.text:00415927                                         ; BlLoadDeviceDriver(x,x,x,x,x)+176p
.text:00415927                                         ; BlOsLoader(x,x,x)+E1Fp
.text:00415927                                         ; BlOsLoader(x,x,x)+E52p
.text:00415927                                         ; BlOsLoader(x,x,x)+E8Ep
.text:00415927
.text:00415927 BaseDllName     = dword ptr 8
.text:00415927 FullDllName     = dword ptr 0Ch
.text:00415927 DllBase         = dword ptr 10h
.text:00415927 PNewDataEntry   = dword ptr 14h
.text:00415927
.text:00415927                 mov     edi, edi
.text:00415929                 push    ebp
.text:0041592A                 mov     ebp, esp
.text:0041592C                 push    esi
.text:0041592D                 push    4Ch
.text:0041592F                 call    BlAllocateHeap(x) ; Allocate buffer for LDR_DATA_TABLE_ENTRY structure
.text:0041592F
.text:00415934                 mov     esi, eax
.text:00415936                 test    esi, esi
.text:00415938                 jnz     short loc_415942
.text:00415938
.text:0041593A                 push    10h
.text:0041593C                 pop     eax
.text:0041593D                 jmp     loc_415A12
.text:0041593D
.text:00415942 ; ---------------------------------------------------------------------------
.text:00415942
.text:00415942 loc_415942:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+11j
.text:00415942                 push    ebx
.text:00415943                 push    edi
.text:00415944                 mov     edi, [ebp+DllBase]
.text:00415947                 push    edi             ; ImageBase
.text:00415948                 call    RtlImageNtHeader(x)
.text:00415948
.text:0041594D                 mov     ebx, [ebp+BaseDllName]
.text:00415950                 mov     [esi+LDR_DATA_TABLE_ENTRY.DllBase], edi
.text:00415953                 mov     ecx, [eax+IMAGE_NT_HEADERS.OptionalHeader.SizeOfImage]
.text:00415956                 mov     [esi+LDR_DATA_TABLE_ENTRY.SizeOfImage], ecx
.text:00415959                 mov     ecx, [eax+IMAGE_NT_HEADERS.OptionalHeader.AddressOfEntryPoint]
.text:0041595C                 add     ecx, edi        ; DllBase+EntryPoint
.text:0041595E                 and     [esi+LDR_DATA_TABLE_ENTRY.HashLinks.Flink], 0
.text:00415962                 mov     [esi+LDR_DATA_TABLE_ENTRY.EntryPoint], ecx
.text:00415965                 mov     eax, [eax+IMAGE_NT_HEADERS.OptionalHeader.CheckSum]
.text:00415968                 mov     [esi+IMAGE_OPTIONAL_HEADER32.CheckSum], eax
.text:0041596B                 mov     eax, ebx        ; BaseDllName
.text:0041596D                 lea     edi, [eax+1]
.text:0041596D
.text:00415970
.text:00415970 loc_415970:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+4Ej
.text:00415970                 mov     cl, [eax]
.text:00415972                 inc     eax
.text:00415973                 test    cl, cl
.text:00415975                 jnz     short loc_415970
.text:00415975
.text:00415977                 sub     eax, edi        ; the length of the BaseDllName
.text:00415979                 lea     edi, [eax+eax]
.text:0041597C                 movzx   eax, di
.text:0041597F                 push    eax
.text:00415980                 call    BlAllocateHeap(x) ; AllocateBuffer for BaseDllName UNICODE_STRING
.text:00415980
.text:00415985                 test    eax, eax
.text:00415987                 jz      short loc_4159C7
.text:00415987
.text:00415989                 mov     [esi+LDR_DATA_TABLE_ENTRY.BaseDllName.Length], di
.text:0041598D                 mov     [esi+LDR_DATA_TABLE_ENTRY.BaseDllName.MaximumLength], di
.text:00415991                 mov     [esi+LDR_DATA_TABLE_ENTRY.BaseDllName.Buffer], eax
.text:00415994                 jmp     short loc_4159A0
.text:00415994
.text:00415996 ; ---------------------------------------------------------------------------
.text:00415996
.text:00415996 loc_415996:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+7Dj
.text:00415996                 movsx   cx, cl
.text:0041599A                 mov     [eax], cx       ; Copy BaseDllName into Buffer
.text:0041599D                 inc     eax
.text:0041599E                 inc     eax
.text:0041599F                 inc     ebx
.text:0041599F
.text:004159A0
.text:004159A0 loc_4159A0:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+6Dj
.text:004159A0                 mov     cl, [ebx]
.text:004159A2                 test    cl, cl
.text:004159A4                 jnz     short loc_415996
.text:004159A4
.text:004159A6                 mov     ebx, [ebp+FullDllName]
.text:004159A9                 mov     eax, ebx
.text:004159AB                 lea     edx, [eax+1]
.text:004159AB
.text:004159AE
.text:004159AE loc_4159AE:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+8Cj
.text:004159AE                 mov     cl, [eax]
.text:004159B0                 inc     eax
.text:004159B1                 test    cl, cl
.text:004159B3                 jnz     short loc_4159AE
.text:004159B3
.text:004159B5                 sub     eax, edx        ; get the length of FullDllName
.text:004159B7                 lea     edi, [eax+eax]
.text:004159BA                 movzx   eax, di
.text:004159BD                 push    eax
.text:004159BE                 call    BlAllocateHeap(x) ; Allocate Buffer for FullDllName UNICODE_STRING
.text:004159BE
.text:004159C3                 test    eax, eax
.text:004159C5                 jnz     short loc_4159CC
.text:004159C5
.text:004159C7
.text:004159C7 loc_4159C7:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+60j
.text:004159C7                 push    10h
.text:004159C9                 pop     eax
.text:004159CA                 jmp     short loc_415A10
.text:004159CA
.text:004159CC ; ---------------------------------------------------------------------------
.text:004159CC
.text:004159CC loc_4159CC:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+9Ej
.text:004159CC                 mov     [esi+LDR_DATA_TABLE_ENTRY.FullDllName.Length], di
.text:004159D0                 mov     [esi+LDR_DATA_TABLE_ENTRY.FullDllName.MaximumLength], di
.text:004159D4                 mov     [esi+LDR_DATA_TABLE_ENTRY.FullDllName.Buffer], eax
.text:004159D7                 jmp     short loc_4159E3
.text:004159D7
.text:004159D9 ; ---------------------------------------------------------------------------
.text:004159D9
.text:004159D9 loc_4159D9:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+C0j
.text:004159D9                 movsx   cx, cl
.text:004159DD                 mov     [eax], cx       ; Copy FullDllName into buffer
.text:004159E0                 inc     eax
.text:004159E1                 inc     eax
.text:004159E2                 inc     ebx
.text:004159E2
.text:004159E3
.text:004159E3 loc_4159E3:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+B0j
.text:004159E3                 mov     cl, [ebx]
.text:004159E5                 test    cl, cl
.text:004159E7                 jnz     short loc_4159D9
.text:004159E7
.text:004159E9                 mov     [esi+LDR_DATA_TABLE_ENTRY.Flags], 4000h
.text:004159F0                 mov     [esi+LDR_DATA_TABLE_ENTRY.LoadCount], 1
.text:004159F6                 mov     eax, _BlLoaderBlock
.text:004159FB                 lea     ecx, [eax+LOADER_PARAMETER_BLOCK.LoadOrderListHead.Blink]
.text:004159FE                 mov     edx, [ecx]
.text:00415A00                 mov     [esi+LDR_DATA_TABLE_ENTRY.InLoadOrderLinks.Flink], eax
.text:00415A02                 mov     eax, [ebp+PNewDataEntry]
.text:00415A05                 mov     [esi+LDR_DATA_TABLE_ENTRY.InLoadOrderLinks.Blink], edx
.text:00415A08                 mov     [edx+LDR_DATA_TABLE_ENTRY.InLoadOrderLinks.Flink], esi
.text:00415A0A                 mov     [ecx], esi
.text:00415A0C                 mov     [eax], esi
.text:00415A0E                 xor     eax, eax
.text:00415A0E
.text:00415A10
.text:00415A10 loc_415A10:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+A3j
.text:00415A10                 pop     edi
.text:00415A11                 pop     ebx
.text:00415A11
.text:00415A12
.text:00415A12 loc_415A12:                             ; CODE XREF: BlAllocateDataTableEntry(x,x,x,x)+16j
.text:00415A12                 pop     esi
.text:00415A13                 pop     ebp
.text:00415A14                 retn    10h
.text:00415A14
.text:00415A14 __stdcall BlAllocateDataTableEntry(x, x, x, x) endp

加载Boot驱动时BlLoadBootDriver->BlLoadDeviceDriver同样有调用BlAllocateDataTableEntry添加项目，但是这时的BaseDllName来自于对驱动注册表项的ImagePath键值取其中的文件名，因此与FullDllName中的内容会保持一致。

于是阳光找我讨论这是为什么。我相信大家在用OD的过程中也早已发现，如果不使用CREATE_SUSPENDED，初始化线程在跑到入口点后，其ebx同样指向PEB结构。

显然，我们必须进入Win32系统新进程创建的过程来找这个真相。由于我们知道初始化线程被创建后（尚未Resume）ebx就已经指向PEB了，所以要不然就是在NtCreateThread过程中，要不然就是在它前面。同时也应该在NtCreatePeb之后。因此我就在这个范围内找寻。

应该说这里我犯了个错误，就是没有详细看CreateProcess的流程，而是使劲往NtCreateThread的内核代码看去，N多函数调用关系看得我眼花，虽然这些内核函数对线程的Context有诸多操作，但是均并不涉及其Ebx。

最后终于回过头来看CreateProcessInternalW在NtCreateThread之前的过程。《Windows Internals 4th》在这里一句话带过了：

Before the thread can be created, it needs a stack and a context in which to run, so these are set up now.

原来是恰恰在NtCreateThread之前，在用户态初始化了新线程的Context，再结合网上其他的文章，终于找到关键函数：kernel32!BaseInitializeContext。

BaseInitializeContext(PCONTEXT Context, // 0x200 bytes
PPEB Peb,
PVOID EntryPoint,
DWORD StackTop,
int Type // union (Process, Thread, Fiber)
);

IDA中看一下这个函数：

.text:7C810443
.text:7C810443 __stdcall BaseInitializeContext(x, x, x, x, x) proc near
.text:7C810443                                         ; CODE XREF: CreateRemoteThread(x,x,x,x,x,x,x)+84 p
.text:7C810443                                         ; CreateProcessInternalW(x,x,x,x,x,x,x,x,x,x,x,x)+690 p
.text:7C810443                                         ; CreateFiberEx(x,x,x,x,x)+82 p
.text:7C810443
.text:7C810443 Context         = dword ptr 8
.text:7C810443 PPeb            = dword ptr 0Ch
.text:7C810443 EntryPoint      = dword ptr 10h
.text:7C810443 StackTop        = dword ptr 14h
.text:7C810443 Type            = dword ptr 18h
.text:7C810443
.text:7C810443 ; FUNCTION CHUNK AT .text:7C81508E SIZE 00000019 BYTES
.text:7C810443 ; FUNCTION CHUNK AT .text:7C82FF86 SIZE 0000000F BYTES
.text:7C810443
.text:7C810443                 mov     edi, edi
.text:7C810445                 push    ebp
.text:7C810446                 mov     ebp, esp
.text:7C810448                 mov     eax, [ebp+Context]
.text:7C81044B                 mov     ecx, [ebp+EntryPoint]
.text:7C81044E                 and     [eax+CONTEXT.SegGs], 0
.text:7C810455                 cmp     [ebp+Type], 1
.text:7C810459                 mov     [eax+CONTEXT.Eax], ecx
.text:7C81045F                 mov     ecx, [ebp+PPeb]
.text:7C810462                 mov     [eax+CONTEXT.Ebx], ecx
.text:7C810468                 push    20h
.text:7C81046A                 pop     ecx
.text:7C81046B                 mov     [eax+CONTEXT.SegEs], ecx
.text:7C810471                 mov     [eax+CONTEXT.SegDs], ecx
.text:7C810477                 mov     [eax+CONTEXT.SegSs], ecx
.text:7C81047D                 mov     ecx, [ebp+StackTop]
.text:7C810480                 mov     [eax+CONTEXT.SegFs], 38h
.text:7C81048A                 mov     [eax+CONTEXT.SegCs], 18h
.text:7C810494                 mov     [eax+CONTEXT.EFlags], 3000h
.text:7C81049E                 mov     [eax+CONTEXT.Esp], ecx
.text:7C8104A4                 jnz     loc_7C81508E
.text:7C8104A4
.text:7C8104AA                 mov     dword ptr [eax+CONTEXT.Eip], offset BaseThreadStartThunk(x,x)
.text:7C8104AA
.text:7C8104B4
.text:7C8104B4 loc_7C8104B4:                           ; CODE XREF: BaseInitializeContext(x,x,x,x,x)+4C5F j
.text:7C8104B4                                         ; BaseInitializeContext(x,x,x,x,x)+1FB4D j
.text:7C8104B4                 add     ecx, 0FFFFFFFCh
.text:7C8104B7                 mov     [eax+CONTEXT.ContextFlags], 10007h
.text:7C8104BD                 mov     [eax+CONTEXT.Esp], ecx
.text:7C8104C3                 pop     ebp
.text:7C8104C4                 retn    14h
.text:7C8104C4
.text:7C8104C4 __stdcall BaseInitializeContext(x, x, x, x, x) endp
.text:7C8104C4

.text:7C81508E
.text:7C81508E loc_7C81508E:                           ; CODE XREF: BaseInitializeContext(x,x,x,x,x)+61 j
.text:7C81508E                 cmp     [ebp+Type], 2
.text:7C815092                 jz      loc_7C82FF86
.text:7C815092
.text:7C815098                 mov     dword ptr [eax+CONTEXT.Eip], offset BaseProcessStartThunk(x,x)
.text:7C8150A2                 jmp     loc_7C8104B4
.text:7C8150A2

.text:7C82FF86
.text:7C82FF86 loc_7C82FF86:                           ; CODE XREF: BaseInitializeContext(x,x,x,x,x)+4C4F j
.text:7C82FF86                 mov     dword ptr [eax+CONTEXT.Eip], offset BaseFiberStart()
.text:7C82FF90                 jmp     loc_7C8104B4
.text:7C82FF90

这个函数就是新线程的线程上下文初始化的关键。下面这两行代码：

.text:7C81045F                 mov     ecx, [ebp+PPeb]
.text:7C810462                 mov     [eax+CONTEXT.Ebx], ecx

将其Ebx指向了PEB。同时这个函数也对几个段选择子进行了初始化，因此诸如为什么Ring3进线程初始化时这几个段选择子总是那样的值的问题，也一并解决了。

因为BaseInitializeContext在CreateRemoteThread中也被调用（CreateThread则又调用了CreateRemoteThread），所以Ring3下用这些常规方式创建的进线程，初始化时都经过这个函数，其线程上下文的相关内容便也保持一致的特点。

Update：

之前的说法还是有点不足之处，BaseInitializeContext的第二个参数，准确地来说应该是PPebOrPParameter。当被CreateProcessInternalW调用时，此处传入的是新进程的PEB指针（由父进程对新进程调用NtQueryInformationProcess得到）；当被CreateRemoteThread调用时，这里传入的是CreateRemoteThread的第五个输入参数，也就是lpParameter，也就是为新线程指定的传入参数。

BaseInitializeContext函数将相应CONTEXT结构中的Eip字段指定为BaseProcessStartThunk（新进程创建时CreateProcessInternalW调用的时候）或BaseThreadStartThunk（创建非主线程时，由CreateRemoteThread调用的时候），将Eax字段内容指定为线程入口点，将Ebx字段内容指定为新进程的PEB指针（新进程创建时CreateProcessInternalW调用的时候）或创建远程线程时传给新线程的参数（创建非主线程时，由CreateRemoteThread调用的时候）。

新进程的主线程进入BaseProcessStartThunk后：
xor ebp, ebp
push eax; 线程入口点
push 0
jmp BaseProcessStart

BaseProcessStart之后使用这个push eax时压入栈的线程入口点值来调用入口点函数，当入口点函数返回时，使用其返回值调用ExitThread退出线程：
call     dword ptr [ebp+8] ; 之前压入栈的线程入口点
push     eax              ; 进入主线程入口点时，[esp]的值就是这行指令的地址
call     ExitThread

远程线程进入BaseThreadStartThunk后的行为有点类似，但push的参数中多了一个ebx，即传入参数：
xor ebp, ebp
push ebx; 传入参数
push eax; 线程入口点
push 0
jmp BaseThreadStart

BaseThreadStart之后使用前面压入栈的线程入口点值和传入参数来调用入口点函数，当入口点函数返回时，使用其返回值调用ExitThread退出线程：
push     dword ptr [ebp+0Ch] ; 之前压入栈的传入参数
call     dword ptr [ebp+8] ; 之前压入栈的线程入口点
push     eax              ; 进入远程线程入口点时，[esp]的值就是这行指令的地址
call     ExitThread

另外除了进程和线程这两种类型之外，BaseInitializeContext还会被CreateFiberEx调用，相应的对象称为纤程，我还不知道这个纤程具体是怎么回事。

虽然该注册机可以照常使用，计算出来的注册码也是正确的，但是即使不算病毒，至少也算有AD行为，搜索过程中看到网友们慨叹“找到的注册机都是病毒”，实在有点不爽。

于是我逆向了该注册机程序，了解了它的注册码算法，发现算法并不复杂：

注册码以手机IMEI号为基础，程序中保存一段长10字节的密钥，先将表示IMEI号的字符串与此密钥逐个字节进行循环的XOR，将得到的新字符串作MD5，然后将得到的MD5结果的每个字节值使用10进制显示并连起来，最后得到的字符串的前10个字符，就是注册码。

于是我自己重写了一个注册机。我的注册机使用Win32汇编编写，MD5计算使用网上公开的静态库，程序界面的资源是使用VS2005生成的（所以图标我也没改了，看起来像MFC程序）。

我重写的注册机的好处，就是很干净，除了计算注册码的算法和GUI的窗口响应函数之外，没有任何多余的代码，因此体积小巧（程序未加壳，只有26K，压缩之后只有12K，而原来那个注册机加壳压缩完都要218K），无毒无害。我觉得这样简约实用的风格才是真正的cracker应该写出来的作品（虽然我专长不是做crack的……）。

注册机的使用方法也很简单，在IMEI栏里填入手机IMEI号，按"Generate"按钮，注册码即显示在下面的Reg栏里。

注册机下载网盘链接：
http://www.rayfile.com/files/41aa210a-98bb-11de-a8e0-0014221b798a/

不爽的是我的注册机，放上virustotal扫描照样有杀软报毒：

CAT-QuickHeal 10.00 2009.09.02 Win32.TrojanDownloader.Small.FC.4
Sophos 4.45.0 2009.09.03 Sus/Keygen-A

Sophos报疑似注册机报得很对（因为我用的GetDlgItemText和SetDlgItemText这些函数对于注册机来说太“标准”了，我不知道如果我把调用的API处理一下还会不会报），另一家报的就太荒谬了吧……

PS：本来想发到IT168诺基亚手机论坛的（原来的注册机就是在那里下的），发现我是新手没有上传rar附件权限，所以只能放网盘（我不喜欢rayfile，因为我用raysource下载从来没有成功过，但是急切又找不到其他方便别人下载的网盘，幸好文件够小可以直接下载），再加上本来我要解决的就是其病毒问题，偏偏我写出来的还有杀软误报……不发出来又不甘心，干脆放自己blog了，至少经常来我blog的人，应该还是能区分什么是误报的。

因此这次变成我第一次在blog上发注册机（不过我绕了个弯，因为我没有也不会逆向手机平台上的Opera Mobile，我只是逆向了在PC平台上Windows系统下运行的别人的注册机而已），很可能也是唯一一次，下不为例。

弄清楚了原因，漏洞补丁就很简单了，正如pshpan的blog中提到的方法：

.text:59F0D748                  lea      ecx, [ebp+8]

改为

.text:59F0D748                  mov      ecx, [ebp+8]

即可修复该漏洞。

微软的程序员也会出这样的错误，从这里也可以看出在编程序的过程中细心是多么的重要。

blog里字数限制太烦人，等以后有空再全文搬上来，先给个看雪帖子链接：

http://bbs.pediy.com/showthread.php?t=92912

我在看雪的主题帖只有四篇，不知道算不算贵精不贵多呢……

dump加载后windbg产生的信息摘要：

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ff116000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f907347f, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: ff116000

CURRENT_IRQL: 2

FAULTING_IP:
WinMTBus+1647f
f907347f f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: WinMount.exe

LAST_CONTROL_TRANSFER: from f907a8cc to f907347f

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f0cf2ba4 f907a8cc ff115fb0 03300000 fee97d48 WinMTBus+0x1647f
f0cf2bd8 f90647d7 03300000 feea9950 81d85c40 WinMTBus+0x1d8cc
f0cf2c18 f905d759 00ea9950 f905d64c 81d85c40 WinMTBus+0x77d7
f0cf2c58 8057ba9f 81d85b88 feea9950 ff0fa398 WinMTBus+0x759
f0cf2d00 8058ffe3 0000011c 00000000 00000000 nt!IopXxxControlFile+0x611
f0cf2d34 804df7ec 0000011c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f0cf2d34 7c92e514 0000011c 00000000 00000000 nt!KiFastCallEntry+0xf8
023eff38 00000000 00000000 00000000 00000000 0x7c92e514

STACK_COMMAND: kb

FOLLOWUP_IP:
WinMTBus+1647f
f907347f f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: WinMTBus+1647f

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: WinMTBus

IMAGE_NAME: WinMTBus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d27c40

FAILURE_BUCKET_ID: 0xD1_WinMTBus+1647f

BUCKET_ID: 0xD1_WinMTBus+1647f

Followup: MachineOwner
---------

从以上内容可以看到系统在IRQL==DISPATCH_LEVEL的时候读取了一个分页地址或无效地址，从而触发了BSOD。

kd> !process
GetPointerFromAddress: unable to read from 80560bd4
PROCESS feeb2da0 SessionId: none Cid: 0f54    Peb: 7ffda000 ParentCid: 0938
    DirBase: 07530000 ObjectTable: e11c1fb8 HandleCount: <Data Not Accessible>
    Image: WinMount.exe
    VadRoot ff5f7a60 Vads 186 Clone 0 Private 3086. Modified 1951. Locked 256.
（以下省略一些信息）

kd> r edi, esi, ecx
edi=03300060 esi=ff116000 ecx=00000004
kd> dd esi
ff116000 ???????? ???????? ???????? ????????
ff116010 ???????? ???????? ???????? ????????
ff116020 ???????? ???????? ???????? ????????
ff116030 ???????? ???????? ???????? ????????
ff116040 ???????? ???????? ???????? ????????
ff116050 ???????? ???????? ???????? ????????
ff116060 ???????? ???????? ???????? ????????
ff116070 ???????? ???????? ???????? ????????

发生BSOD的进程是WinMount.exe，位置在驱动 WinMTBus+1647f处，为一条rep movsd指令，这条指令在读取esi的地址所指向的内存时由于此内存地址无效而引发了BSOD。从ecx=4可以看出这里本来还要有0x10字节以供拷贝的。

从栈回溯信息可以看出这个操作来源是WinMount.exe在用户层的一次NtDeviceIoControlFile与驱动交互的调用，从进入NtDeviceIoControlFile时的堆栈：
kd> dd f0cf2d38
f0cf2d38 804df7ec 0000011c 00000000 00000000
f0cf2d48 00000000 023eff14 0022200a 00000000
f0cf2d58 00000000 03300000 00100000 023eff38
对照NtDeviceIoControlFile的函数原型可以看出，驱动符号链接句柄是0x11c（或许因为dump文件信息太少，查不出这个句柄对应的对象信息），IOCTL为0x0022200a，用于从驱动输出缓冲区信息到用户层，OutputBuffer为0x03300000，OutputBufferLength为0x100000。
可以看到edi=03300060正是在输出缓冲区中，可以判断此时正是驱动向里面拷数据。

kd> r eax
eax=03300000

可以看到eax正是指向缓冲区开头。

kd> dd eax
03300000 00000002 00000000 00000000 00000000
03300010 000b0050 00000000 00000000 00000000
03300020 00000000 00000000 00000012 ff0f1b58
03300030 00000000 00000000 00000000 00000000
03300040 ff115fb0 00000040 00000000 00000000
03300050 e244fd50 00000000 010000aa 00000000
03300060 00000000 00000000 00000000 00000000
03300070 00000000 00000000 00000000 00000000
kd> dd esi-60
ff115fa0 00000000 00000001 0a0b0007 53414d55
ff115fb0 000b0050 00000000 00000000 00000000
ff115fc0 00000000 00000000 00000012 ff0f1b58
ff115fd0 00000000 00000000 00000000 00000000
ff115fe0 ff115fb0 00000040 00000000 00000000
ff115ff0 e244fd50 00000000 010000aa 00000000
ff116000 ???????? ???????? ???????? ????????
ff116010 ???????? ???????? ???????? ????????

以上两部分内存对比，看出rep movsd指令已经把一部分数据拷过去了，可以猜测这条指令执行前ecx大概为0x18。

WinMount作者最令人佩服的是他的扭曲变换，可以说把代码混淆发挥到极致了，驱动被扭曲之后反汇编结果看起来也令人十分痛苦，故而我也没进一步分析这个的想法了，发此文章纯属记录。

因为我用的是WinMount 2.x最后一个稳定版本，不知道3.x怎么样，beta版的又怕怕，暂时不鼓捣它了。不过就其功能而言，WinMount的确是个比较强大的东东。

睡觉去了……

在铁军blog上看到这一系列金山客服内部考试题，其中这一题，我认为大家比较容易犯错。

以下哪个修改过的userinit键值的数据会导致用户开机反复注销
A.%systemroot%\system32\userinit.exe
B.userinit.exe
C.c:\windows\system32\userinit.exe,virus.exe
D.c:\windows\system32\userinit.exe

答案是A。这是一个极具迷惑性的题目。迷惑项目主要是C。因为一般的答题者通常会认为，由于病毒跟随userinit.exe启动，才导致了反复注销。其实这种理解是错误的。
出现开机反复注销的根源是系统找不到userinit.exe文件，而不是在启动userinit.exe的同时启动了病毒。
那么，A项选择为什么会导致系统找不到userinit.exe文件呢？
原因是A项的字符串中使用了环境变量%systemroot%
对于环境变量，这又是一个答题者容易忽略的注册表常识：在注册表中并不是所有字符串类型的键值，都支持环境变量的替换。
注册表键值中两种主要的字符串形式的键类型，一个是REG_SZ，一个是REG_EXPAND_SZ，两者的一个显著区别就是只有REG_EXPAND_SZ类型的键支持在键值中使用%systemroot%这样的环境变量。

具体到本题，相关注册表键位于
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
大家可以打开注册表，睁大眼睛看看这个键，你会发现在默认情况下它的类型是REG_SZ！

因此，这个键值不支持A选项这种包含环境变量的设置方法。当系统启动过程中读取这个键值时，没有办法将其中的%systemroot%当成环境变量并转化为WINDOWS文件夹的路径，于是导致系统找不到userinit.exe文件，不能启动userinit.exe，因此用户会遭遇登录后立即注销的问题。

REG_SZ与REG_EXPAND_SZ类型的某些区别是经常被我们忽略的问题，比如SREng的启动项添加和编辑功能，默认只是创建REG_SZ类型的，因此不支持环境变量。

然而事情是不是如此简单？未必。因为在注册表键值中使用环境变量，不单单要考虑键类型的问题，在某些条件下还要考虑这个环境变量是否已经被初始化的问题。

环境变量一般分为系统环境变量和用户环境变量。从系统启动到成功创建用户会话，到用户终于可以看到桌面的过程中，系统环境变量和用户环境变量的初始化是在不同的阶段进行的。

系统环境变量的初始化，是由会话管理器smss.exe完成的。smss.exe完成初始化后，创建csrss.exe和winlogon.exe进程，winlogon.exe进程再创建其他用户态进程。

userinit.exe进程是由winlogon.exe创建的，执行用户环境的初始化工作，完成如环境变量初始化、运行登陆脚本和应用安全策略等任务后运行缺省的Shell，即explorer.exe

从以上的两段中，你看出了什么？对了，在userinit.exe被启动之前，用户环境变量未被初始化，已被初始化的只有系统环境变量。

因此，即使Userinit键的类型是REG_EXPAND_SZ，也不代表它能使用所有的环境变量。这说明，在我们对系统的修改涉及到系统启动过程的时候，我们的考虑应该更加细致。

用IDA加载mshtml.dll，找到mshtml!CFunctionPointer::PrivateAddRef函数：
.text:42AF7811 public: virtual unsigned long __stdcall CFunctionPointer::PrivateAddRef(void) proc near
.text:42AF7811                                         ; DATA XREF: .text:42A3B3C4 o
.text:42AF7811

从函数头部的交叉参考进入，可以看到它被一个常量所引用：
.text:42A3B3C0 const CFunctionPointer::`vftable' dd offset CFunctionPointer::PrivateQueryInterface(_GUID const &,void * *)
.text:42A3B3C0                                         ; DATA XREF: CFunctionPointer::CFunctionPointer(CBase *,long)+15 o
.text:42A3B3C0                                         ; CElement::get_nodeType(long *)+1660 o
.text:42A3B3C4                 dd offset CFunctionPointer::PrivateAddRef(void)
.text:42A3B3C8                 dd offset CFunctionPointer::PrivateRelease(void)

这里可以说是一个messages dispatcher的表了，这个位置又被CFunctionPointer::CFunctionPointer所引用。CFunctionPointer::CFunctionPointer是一个类的构造函数：

.text:42AF79D9 public: __thiscall CFunctionPointer::CFunctionPointer(class CBase *, long) proc near
.text:42AF79D9                                         ; CODE XREF: CBase::ContextInvokeEx(long,ulong,ushort,tagDISPPARAMS *,tagVARIANT *,tagEXCEPINFO *,IServiceProvider *,IUnknown *)+AF361 p
.text:42AF79D9
.text:42AF79D9 arg_0           = dword ptr 8
.text:42AF79D9 arg_4           = dword ptr 0Ch
.text:42AF79D9
.text:42AF79D9 ; FUNCTION CHUNK AT .text:42B3F2C0 SIZE 00000020 BYTES
.text:42AF79D9
.text:42AF79D9                 mov     edi, edi
.text:42AF79DB                 push    ebp
.text:42AF79DC                 mov     ebp, esp
.text:42AF79DE                 push    esi
.text:42AF79DF                 mov     esi, ecx
.text:42AF79E1                 call    CBase::CBase(void)
.text:42AF79E1
.text:42AF79E6                 mov     ecx, [ebp+arg_0]
.text:42AF79E9                 test    ecx, ecx
.text:42AF79EB                 mov     eax, [ebp+arg_4]
.text:42AF79EE                 mov     dword ptr [esi], offset const CFunctionPointer::`vftable'
.text:42AF79F4                 mov     [esi+10h], ecx
.text:42AF79F7                 mov     [esi+14h], eax
.text:42AF79FA                 jz      short loc_42AF7A19
.text:42AF79FA
.text:42AF79FC                 mov     eax, [ecx]
.text:42AF79FE                 call    dword ptr [eax+34h]
.text:42AF7A01                 test    eax, eax
.text:42AF7A03                 mov     [esi+18h], eax
.text:42AF7A06                 jz      loc_42B3F2C0
.text:42AF7A06
.text:42AF7A0C
.text:42AF7A0C loc_42AF7A0C:                           ; CODE XREF: CFunctionPointer::CFunctionPointer(CBase *,long)+47902 j
.text:42AF7A0C                 mov     eax, [esi+18h]
.text:42AF7A0F                 test    eax, eax
.text:42AF7A11                 jz      short loc_42AF7A19
.text:42AF7A11
.text:42AF7A13                 mov     ecx, [eax]
.text:42AF7A15                 push    eax
.text:42AF7A16                 call    dword ptr [ecx+4]
.text:42AF7A16
.text:42AF7A19
.text:42AF7A19 loc_42AF7A19:                           ; CODE XREF: CFunctionPointer::CFunctionPointer(CBase *,long)+21 j
.text:42AF7A19                                         ; CFunctionPointer::CFunctionPointer(CBase *,long)+38 j
.text:42AF7A19                 mov     eax, esi
.text:42AF7A1B                 pop     esi
.text:42AF7A1C                 pop     ebp
.text:42AF7A1D                 retn    8

那么微软怎么把这个漏洞改掉的呢？打上KB961260补丁，我们返回来看刚刚那个表：

.text:42A39708 const CFunctionPointer::`vftable' dd offset CFunctionPointer::PrivateQueryInterface(_GUID const &,void * *)
.text:42A39708                                         ; DATA XREF: CFunctionPointer::CFunctionPointer(CBase *,long)+15 o
.text:42A39708                                         ; CElement::get_nodeType(long *)+1658 o
.text:42A3970C                 dd offset CIVersionVectorThunk::AddRef(void)
.text:42A39710                 dd offset CBase::PrivateRelease(void)

把CFunctionPointer::PrivateAddRef从表上换掉了，换成了CIVersionVectorThunk::AddRef(void)，这个函数的动作：

.text:42A4156D public: virtual unsigned long __stdcall CIVersionVectorThunk::AddRef(void) proc near
.text:42A4156D                                         ; DATA XREF: .text:42A0355C o
.text:42A4156D                                         ; .text:42A38434 o
.text:42A4156D                                         ; .text:42A384B4 o
.text:42A4156D                                         ; .text:42A38534 o
.text:42A4156D                                         ; .text:42A385BC o
.text:42A4156D                                         ; .text:42A38644 o ...
.text:42A4156D
.text:42A4156D arg_0           = dword ptr 8
.text:42A4156D
.text:42A4156D                 mov     edi, edi
.text:42A4156F                 push    ebp
.text:42A41570                 mov     ebp, esp
.text:42A41572                 mov     eax, [ebp+arg_0]
.text:42A41575                 inc     dword ptr [eax+4]
.text:42A41578                 xor     eax, eax
.text:42A4157A                 pop     ebp
.text:42A4157B                 retn    4
.text:42A4157B
.text:42A4157B public: virtual unsigned long __stdcall CIVersionVectorThunk::AddRef(void) endp

与之前的CFunctionPointer::PrivateAddRef对比可以发现，现在的CIVersionVectorThunk::AddRef只是设置一个引用计数（inc     dword ptr [eax+4]），没有其他调用了。

同时修改的还有CFunctionPointer::PrivateRelease，在表中它的位置直接被替换成了基类的方法CBase::PrivateRelease。

看看修改前的CFunctionPointer::PrivateRelease函数：

.text:42B1E30D public: virtual unsigned long __stdcall CFunctionPointer::PrivateRelease(void) proc near
.text:42B1E30D                                         ; DATA XREF: .text:42A3B3C8 o
.text:42B1E30D
.text:42B1E30D arg_0           = dword ptr 8
.text:42B1E30D
.text:42B1E30D                 mov     edi, edi
.text:42B1E30F                 push    ebp
.text:42B1E310                 mov     ebp, esp
.text:42B1E312                 push    esi
.text:42B1E313                 mov     esi, [ebp+arg_0]
.text:42B1E316                 cmp     dword ptr [esi+10h], 0
.text:42B1E31A                 jz      loc_42B22250
.text:42B1E31A
.text:42B1E320                 cmp     dword ptr [esi+4], 1
.text:42B1E324                 jbe     loc_42B22250
.text:42B1E324
.text:42B1E32A                 add     dword ptr [esi+8], 8
.text:42B1E32E                 push    edi
.text:42B1E32F                 push    esi
.text:42B1E330                 call    CBase::PrivateRelease(void)
.text:42B1E330
.text:42B1E335                 mov     edi, eax
.text:42B1E337                 mov     eax, [esi+10h]
.text:42B1E33A                 mov     ecx, [eax]
.text:42B1E33C                 push    eax
.text:42B1E33D                 call    dword ptr [ecx+8]
.text:42B1E340                 mov     ecx, esi
.text:42B1E342                 call    CBase::SubRelease(void)
.text:42B1E342
.text:42B1E347                 mov     eax, edi
.text:42B1E349                 pop     edi
.text:42B1E349
.text:42B1E34A
.text:42B1E34A loc_42B1E34A:                           ; CODE XREF: CElement::get_nodeType(long *)+1627 j
.text:42B1E34A                 pop     esi
.text:42B1E34B                 pop     ebp
.text:42B1E34C                 retn    4
.text:42B1E34C
.text:42B1E34C public: virtual unsigned long __stdcall CFunctionPointer::PrivateRelease(void) endp

显然也存在与CFunctionPointer::PrivateAddRef相类似的问题，可能call进shellcode中。现在换成了CBase::PrivateRelease，同样也就是直接把对象的引用计数标志减1而已。