从内核模式启动进程
来源：互联网 发布：传智python就业班 编辑：程序博客网 时间：2024/05/22 12:07
从内核模式启动进程
我想很多人都会有这样的问题，能否从内核驱动中启动用户应用程序呢？在Win9x（win95, 98, ME）中有专门的导出函数ShellVxd_ShellExecute，此函数能够启动应用程序。而在NT系统中没有专门的导出函数。
单数不存在导出函数决不意味这种想法不可能实现。恰恰相反，这种想法是完全可能实现的。当然，您可能会觉得这有如恶梦一般，分析一大堆系统对象，仔细的研究它们的属性与方法等等。不用紧张，事实上要简单得多。来，让我们放松一下，并用几种非标准的观点看一下这个问题。
我们先推开现实不管。仔细的查看模块ntoskrnl.exe的导出函数，我们没有找到能直接赋予新进程生命的函数。DDK对此也保持沉默。但是我们知道，进程是由用户模块kernel32.dll的导出函数kernel32.dll:CreateProcessA, CreateProcessW, CreateProcessInternalA, CreateProcessInternalW创建的，对于这些函数的描述以及参数可以很容易的在PSDK的文档中找到。当然，绕过kernel32.dll，尝试自己模拟这些函数是可以成功的。对这种方法的讲解和相应的代码可以在Garry Nebetta的WinNT Native Api指南中找到。实际上这也没有什么不可思议的。进程仍然从用户模式启动，只不过是直接调用了ntdll.dll模块里的导出函数。但是我们的问题依然没有答案，内核中的哪些东东能实现同样的效果呢？
其实，我所给出的方法也没有显出什么太古怪的地方来。我们不会自己构造内核对象并靠自己的力量和智慧来模拟出相应的内核行为和机制。我们知道，没有人能比操作系统做得更好，而且内核恐怕也不会对我们的“自己动手”表示赞赏。但是，我们还是要在内核模式驱动中把应用程序启动起来，只是……是在用户模式下。下面我们就来开始吧。
--------------------------------------------------------------------------------
方法很简单。现在我对机制进行一点解释，然后继续对内核代码进行分析。主要的思想就是，要“抓住”某个进程的用户线程，并将其与我们自己的条件“捆绑”，也就是说修改执行的代码并让它转向到预先准备好的用户地址空间中的代码中，这段代码调用函数kernel32.dll:CreateProcessA。
怎样才能做到呢？首先需要找到线程从内核模式转向用户模式的地方。进程是如何从用户模式切换到内核模式再切换回来的呢？这是通过中断门/快速系统调用接口进行的。对于本例，经过思考，我们没有找到比INT 0x2E/SYSENTER更好的地方，而正是在这里线程改变了自己的优先级。
当然，如果有其它类似的服务，比如调试用的int 0x2d，或是timer int 0x2a。但是我们需要稳定的方法，对大多数进程能够使用的，可以频繁使用的方法。这样，在一番寻找之后，最好的候选方法就是系统调用门接口INT 0x2E/SYSENTER。我们如何才能使用这个后门呢？无疑需要知道，在中断调用时会发生向段寄存器重新加载事先保存在TSS中的选择子，主要是CS和SS。在通过门到达内核后，在堆栈中保存着中断的返回地址。使用指令sysenter（winXP+）的情况类似。这个地址是我们所需要的，而取得它完全不是问题。之后，我们必需拦截函数_KiSystemService，向其中插入我们处理程序的代码。问题又来了，我们如何找到_KiSystemService函数呢？
有一点是显然的，中断向量INT 0x2E指向这个函数。但是，在WinXP+中情况并非只此一种。由于最新处理器的新特性，新版本的系统都使用了快速系统调用指令SYSENTER/SYSEXIT。SYSENTER指令与INT指令类似，但有一点区别，就是它调用的代码的地址位于MSR寄存器中的某一个里。为什么这种情况下我们需要多余的查找呢？另外，我们还知道，MSR的内容是经常变化的。尽管如此，IDT表中的中断向量int 0x2e不管怎样都还是指向_KiSystemService的起始代码。尽管int 0x2e没有被使用，但找到它显然不是问题。
害怕失望——您错了。拦截掉INT 0x2E会怎样呢？例如，ntice就好干这个。在代码调试时我们没有可能“亲眼”见到这个函数。除此之外，在ntoskrnl.exe的导出中，此函数也没有被提及。但是，还不是太坏。我们来想一想，如何能找到它。扫描全部内存查找含有_KiSystemService函数的一组指令没有什么意义。我们这里的解决方案十分简单。我们知道，_KiSystemService是转向内核函数的入口，所以在函数的内部有直接调用内核服务的代码。我们来看下面的代码。
0008:804DA113 5A POP EDX
0008:804DA114 FF0538F6DFFF INC DWORD PTR [FFDFF638]
0008:804DA11A 8BF2 MOV ESI,EDX
0008:804DA11C 8B5F0C MOV EBX,[EDI+0C]
0008:804DA11F 33C9 XOR ECX,ECX
0008:804DA121 8A0C18 MOV CL,[EBX+EAX]
0008:804DA124 8B3F MOV EDI,[EDI]
0008:804DA126 8B1C87 MOV EBX,[EAX*4+EDI]
0008:804DA129 2BE1 SUB ESP,ECX
0008:804DA12B C1E902 SHR ECX,02
0008:804DA12E 8BFC MOV EDI,ESP
0008:804DA130 3B35D4C75480 CMP ESI,[ntoskrnl!MmUserProbeAddress]
0008:804DA136 0F83A1010000 JAE 804DA2DD
0008:804DA13C F3A5 REPZ MOVSD
0008:804DA13E FFD3 CALL EBX
0008:804DA140 8BE5 MOV ESP,EBP
我们看到了_KiSystemService的一段代码，指令CALL EBX调用了某个内核函数，这个函数是预先从服务表中选出的，然后在EBX寄存器中加载这个函数的地址（详细过程可以阅读我前一篇文章《跟踪Native Api函数调用》）。
函数_KiSystemService并没有在ntoskrnl.exe的导出表中，但是我们有指向表KeServiceDescriptorTable的指针，从这个表中可以取出所要的Native Api函数的地址，比如说，NtReadFile。接下来，函数将在发出CALL EBX指令的进程上下文中调用并返回至_KiSystemService的下一条指令。
前一篇文章中有个问题涉及到了拦截NativeApi函数，所用的方法是将自己的处理程序添加到服务表中替换原来的函数，然后依次调用这两个函数。这里使用的也是这种办法。比如，我们拦截了NtReadFile这个最常调用的函数，然后，在我们的处理程序内部的堆栈中有函数返回到_KiSystemService的地址。以下是演示代码：
DWORD FindKiSystemServiceOriginalEntryPoint()
{
KPRIORITY CurrentThreadPriority;
// 拦截 NtReadFile这个最常调用的函数
CurrentThreadPriority = KeQueryPriorityThread(KeGetCurrentThread());
// so that the system not degraded
KeSetPriorityThread(KeGetCurrentThread(),1);
if( *NtBuildNumber == 2195 ) OriginalNtReadFile = *KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2195];
if( *NtBuildNumber == 2600 ) OriginalNtReadFile = *KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2600];
disableinterruptions
clearwp
if( *NtBuildNumber == 2195 ) KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2195] = ArtificialNtReadFile;
if( *NtBuildNumber == 2600 ) KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2600] = ArtificialNtReadFile;
restorewp
enableinterruptions
while( !FindingForWhile );
// wait, NtReadFile will be called, надеюсь не вечно :)
// 相似的, 地址被找到, 取下ArtificialNtReadFile()处理程序
disableinterruptions
clearwp
if( *NtBuildNumber == 2195 )
KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2195] =
*OriginalNtReadFile;
if( *NtBuildNumber == 2600 )
KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2600] =
*OriginalNtReadFile;
restorewp
enableinterruptions
KeSetPriorityThread(KeGetCurrentThread(),CurrentThreadPriority);
// 恢复原先状态
// 现在计算KiSystemService原来的入口点
return NtReadFileReturnAddress - 0xC4;
// KiSystemService内部入口点与返回点的差
}
NtReadFile的处理程序:
__declspec(naked) ArtificialNtReadFile()
{ __asm
{
push dword ptr [esp] // !!!
pop NtReadFileReturnAddress
inc dword ptr FindingForWhile // 找到所需函数的地址
jmp dword ptr OriginalNtReadFile
}
}
这段代码的含义您可能已经猜到了。对不同版本Win NT的_KiSystemService函数的分析显示，除了WinXPSP2和2K3，在所有NT内核中这个函数都是相同的（为了保证兼容性，在驱动的代码中有某些不大的改动）。这些都可以利用起来。我想现在大家都会明白，如果我们找到了某个内部函数的地址，而函数又有确定的大小，就不难找到它的startup。call ebx后面一条指令的地址我们可在处理程序的堆栈中找到，而从这条指令到startup间的距离是0xC4字节（Win XP, 2K）。现在_KiSystemService的起始地址就不难计算了。
// такова разница м/д точкой входа и точкой возврата внутри KiSystemService
return NtReadFileReturnAddress - 0xC4;
由此我们就得到了_KiSystemService的原始入口点。
这样，第一步就走完了，我们继续向下进行。下面向实现目标迈出的这一大步就应该是找到放置调用kernel32:CreateProcessA的代码的位置。自然，我们可以将代码数据只放在用户地址空间中，而且是放在大多数进程都能访问到的地方。对此没什么太好的办法，我们所能做的就是利用修正后的kernel32.dll模块第一页中的空闲空间，这块空间紧挨着首部。在被加载到内存并进行修正后，从0x1000字节PE首部占据了某些地方的0x400字节，剩余的地方都由0填充。这些地方完全可以为我们所用。但是，这还是个次要的问题，主要的问题是要在内核模式下找到kernel32.dll的基地址。
这个问题也并不困难。实际上，我们所需要的一切都能在进程PEB指向的结构体中找到。有些结构体的描述可以在Свен Шрайбер的那本关于undocunmented win nt的书中找到。有个结构体指向了进程加载的模块的列表，但是我没有在此书中找到具体的对此结构体的描述，所以只好祭起调试器来小小的挖掘一下。看过PEB，我们立即被pPeb->ProcessModuleInfo->ModuleHeader.List3域所吸引。书中所提到的正是这个成员（List3）。经过试验我明白了，这个ListEntry类型的结构体大概是这个样子的（与MS的源码可能会有区别）：
typedef struct _KMODULEINFOLISTENTRY {
DWORD Flink;
DWORD Blink;
DWORD ModuleIBase;
DWORD DllEntryPoint;
DWORD Unknown2;
DWORD Unknown3;
PWCHAR ModuleName;
} KMODULEINFOLISTENTRY, *PKMODULEINFOLISTENTRY, **PPKMODULEINFOLISTENTRY;
某些域对于我来说还是个迷，实际上我们对这些域并不感兴趣，其余的我想也不需要解释了。这样，使用这个结构体，我们就可以用
DWORD kwsGetModule(PWCHAR ModuleNameW)函数找到kernel32.dll的基地址，此函数可参见驱动源代码。实际上，这个函数可以用来查找进程中的各个模块。
现在我们回到查找最适宜放置调用kernel32:CreateProcessA代码的位置这个问题上来。我们前边提到，代码将位于kernel32.dll模块首部后紧接着的第一页中。这样我们一箭双雕：一是嵌入这个位置中的代码能被所有的进程看到，二是我们有足够的空间来放置植入的CreateProcessA调用代码。别的倒也没什么，只是模块的PE的第一页在用户空间中是只读的，属性为readonly。为了详细的了解此问题，我们来打开PSDK文档并对CreateProcess函数作更细致的研究：
BOOL CreateProcess(
LPCTSTR lpApplicationName, // name of executable module
LPTSTR lpCommandLine, // command line string
LPSECURITY_ATTRIBUTES lpProcessAttributes, // SD
LPSECURITY_ATTRIBUTES lpThreadAttributes, // SD
BOOL bInheritHandles, // handle inheritance option
DWORD dwCreationFlags, // creation flags
LPVOID lpEnvironment, // new environment block
LPCTSTR lpCurrentDirectory, // current directory name
LPSTARTUPINFO lpStartupInfo, // startup information
LPPROCESS_INFORMATION lpProcessInformation // process information
);
typedef struct _STARTUPINFO {
DWORD cb;
LPTSTR lpReserved;
LPTSTR lpDesktop;
LPTSTR lpTitle;
DWORD dwX;
DWORD dwY;
DWORD dwXSize;
DWORD dwYSize;
DWORD dwXCountChars;
DWORD dwYCountChars;
DWORD dwFillAttribute;
DWORD dwFlags;
WORD wShowWindow;
WORD cbReserved2;
LPBYTE lpReserved2;
HANDLE hStdInput;
HANDLE hStdOutput;
HANDLE hStdError;
} STARTUPINFO, *LPSTARTUPINFO;
typedef struct _PROCESS_INFORMATION {
HANDLE hProcess;
HANDLE hThread;
DWORD dwProcessId;
DWORD dwThreadId;
} PROCESS_INFORMATION;
我们看到，函数在堆栈中接收10个双字，多数都是指针。其中某些并不是必需的，可以传递NULL，而例如lpStartupInfo，lpProcessInformation和ProgExeNameAddrinUser则是必需要确定的（关于调用权限和传递参数更详细的信息我这里就不给出了，对此可参阅MSDN）。相应的需要为这些参数分配空间。但这只是问题的一部分。
问题的另一部分在于，除了要为结构体提供空间之外，CreateProcess还应该向它们的域进行写入。我们这里不能出现这种情况，因为我们的页是只读的，并且任何向其中写入的尝试都会引起异常，这个异常会关掉当前进程。为了消除在用户模式下向此页写入的可能性，我们应该修改该页PTE的属性。对此有两种办法：一是在内核模式下调用NtProtectVirtualMemory，这时应考虑到这个函数没有导出，需要找到SST表的入口点；二是直接找到该页的descriptor（PTE）并修正这个恼人的“错误”。我们实际上调用了专门为此而写的函数PageAccessProp(…)，在堆栈中接收4个参数，这些参数我想就不必解释了。
除此之外，此函数还可以用在如下情况，比如必须在UserMode下操作系统内存页的时候。为此需要相应的翻转U位，但是如果内核使用的是4K字节的页，则在descriptor里还有一个G位。此位的意思是这一页是全局的，而且在任务切换或重置CR3时不应在TLB中更新或替换此PTE。也就是说，如果翻转U位，关掉G位，在用户模式下向高2G空间中写入，就会引起异常。一定要关掉CR4中的PGE位，然后进行类似的操作并向系统页进行写入。除此之外，不要忘了CR0中的WP位。从原理上讲会出现的问题到这里就讲完了。
接下来还有一个有趣的任务。我们必须找到导出函数kernel32:CreateProcessA。在我们的驱动中这项工作是由函数GetExportedFuncAddr(DWORD ModuleImageBase,PCHAR FuncName)来负责的，此函数的参数是模块在内存中的地址和所要找函数的名字。若找到，则返回其在内存中的基地址。代码我就不解释了，更详细的信息请参见PE的相关文档，同时还可以直接研究GetExportedFuncAddr。驱动中用到的所有结构体都位于struc.h中。一般来讲，在跟踪CreateImplant()函数时，前面讲到的各个部分会按顺序出现。
前面我们讨论了所有所需的辅助，相关的函数，并被引导到了神秘的目标面前。现在我们从大体上来依次研究驱动的算法。
驱动中最主要的函数就是ReplaceKiSystemServiceCode()。此函数首先用前面讲到的方法找到startup _KiSystemService，然后直接切入代码的核心来取得控制权。为此我们必须：第一，取得_KiSystemService返回时的返回点来分析地址并为后面替换此地址提供方便，而替换后的地址就指向我们植入kernel32.dll第一页中的代码；第二，处理程序将植入代码注入到用户模式内存中。总共会有两处拦截。
现在来更详细的看一下第一处拦截。我们来看代码：
0008:804DA07C 6A00 PUSH 00
0008:804DA07E 55 PUSH EBP
0008:804DA07F 53 PUSH EBX
0008:804DA080 56 PUSH ESI
0008:804DA081 57 PUSH EDI
0008:804DA082 0FA0 PUSH FS
0008:804DA084 BB30000000 MOV EBX,00000030
0008:804DA089 668EE3 MOV FS,BX
0008:804DA08C FF3500F0DFFF PUSH DWORD PTR [FFDFF000]
0008:804DA092 C70500F0DFFFFFFFFFFF MOV DWORD PTR [FFDFF000],FFFFFFFF
0008:804DA09C 8B3524F1DFFF MOV ESI,[FFDFF124]
0008:804DA0A2 FFB640010000 PUSH DWORD PTR [ESI+00000140]
0008:804DA0A8 83EC48 SUB ESP,48
原始的 startup _KiSystemService.
我们直接在代码起始处注入第一个处理程序，方法就是splicing，保存原始地址，之后将其恢复。这样就得到了下面的代码：
0008:804DA07C FF25008578FC JMP [ArtificialKiSystemService]
0008:804DA082 0FA0 PUSH FS
0008:804DA084 BB30000000 MOV EBX,00000030
0008:804DA089 668EE3 MOV FS,BX
0008:804DA08C FF3500F0DFFF PUSH DWORD PTR [FFDFF000]
0008:804DA092 C70500F0DFFFFFFFFFFF MOV DWORD PTR [FFDFF000],FFFFFFFF
0008:804DA09C 8B3524F1DFFF MOV ESI,[FFDFF124]
0008:804DA0A2 FFB640010000 PUSH DWORD PTR [ESI+00000140]
0008:804DA0A8 83EC48 SUB ESP,48
下面是处理程序KiSystemServiceHandler()，这个函数的地址就保存在ArtificialKiSystemService里。
__declspec(naked) KiSystemServiceHandler()
{
SaveKISSRetAddr // 保存由系统服务向用户模式返回的返回点
_asm{
OriginalKiSystemServiceInlineStartUpCode // 恢复原始代码
push dword ptr [OriginalKiSystemService]
add dword ptr [esp],OriginalKiSystemServiceStartUpCodeSize
ret
}
}
我希望您能明白，为什么拦截被实现在startup代码的起始处。正是在这里我们能从线程堆栈中取出所需的地址而不用多费力气。但是我不主张在KiSystemServiceHandler()处理程序内部进行更为复杂的操作。这段代码是在关中断的情况下执行的，也就是说IRQL处于最高级，且除此之外fs也不要动。处理程序中不当的行为必然会引起系统崩溃。现在来看第二处拦截，代码如下：
0008:804DA07C FF25008578FC JMP [ArtificialKiSystemService]
0008:804DA082 0FA0 PUSHFS
0008:804DA084 BB30000000 MOV EBX,00000030
0008:804DA089 668EE3 MOV FS,BX
0008:804DA08C FF3500F0DFFF PUSH DWORD PTR [FFDFF000]
0008:804DA092 C70500F0DFFFFFFFFFFF MOV DWORD PTR [FFDFF000],FFFFFFFF
0008:804DA09C 8B3524F1DFFF MOV ESI,[FFDFF124]
0008:804DA0A2 FFB640010000 PUSH DWORD PTR [ESI+00000140]
0008:804DA0A8 83EC48 SUB ESP,48
0008:804DA0AB 8B5C246C MOV EBX,[ESP+6C]
0008:804DA0AF 83E301 AND EBX,01
0008:804DA0B2 889E40010000 MOV [ESI+00000140],BL
0008:804DA0B8 8BEC MOV EBP,ESP
0008:804DA0BA 8B9E34010000 MOV EBX,[ESI+00000134]
0008:804DA0C0 895D3C MOV [EBP+3C],EBX
0008:804DA0C3 89AE34010000 MOV [ESI+00000134],EBP
0008:804DA0C9 FC CLD
0008:804DA0CA F6462CFF TEST BYTE PTR [ESI+2C],FF
0008:804DA0CE 0F85D6FEFFFF JNZ 804D9FAA
0008:804DA0D4 FB STI // 降IRQL
0008:804DA0D5 FF25F08478FC JMP [ArtificialKiSystemServiceSafedCode]
0008:804DA0DB CC INT 3
0008:804DA0DC CC INT 3
0008:804DA0DD 8BCF MOV ECX,EDI
现在我们来看处理程序KiSystemServiceHandler2()，其地址就在ArtificialKiSystemServiceSafedCode：
__declspec(naked)KiSystemServiceHandler2()
{
__asm mov CanUnload,FALSE // 设置不能卸载驱动的标志
saveregisters // 保护寄存器
if (!isP)
{
isP++; // 建立不可多次进入的标志
CreateImplant(); // 注入植入代码
}
restoreregisters // 恢复寄存器
__asm
{
OriginalKiSystemServiceInLineSafedCode
push dword ptr [KiSystemServiceSafedCode]
add dword ptr [esp],OriginalAfterStiCodeSize
mov CanUnload,TRUE // 现在可以放心的卸载驱动了:)
ret
}
}
在这个处理程序中我们可以做所有我们想到的事情。这里的IRQL是最低的，所以我们在这里调用CreateImplant()函数。这个函数完成前面讲过的操作，包括注入植入代码。在此之后，在_KiSystemService返回后将调用植入代码，在其处理程序之后线程重新返回到这个中断之前，更精确讲，就是返回到ntdll.dll内部。下面是CreateImplant()函数中创建植入代码部分的代码。
// 将从KiSystemService返回时的返回点
// 改为用户模式下植入代码的地址
mov eax,ImpStartAddr
mov ebx,[KISS_SP]
// 将参数由后向前塞入堆栈
mov [ebx],eax
// pushad
mov bl,0x60
mov [eax],bl
inc eax
mov bl, 0xb8
mov [eax], bl
inc eax
mov ebx,pUprocessInformation // PI
mov [eax],ebx // mov eax,PI
add eax,4
mov [eax],0x50 // push eax
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,pUstartUpInfo
mov [eax],ebx // mov eax,SI
add eax,4
mov [eax],0x50 // push eax
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
mov [eax],ebx // mov eax,0
add eax,4
mov [eax],0x50 // push eax
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
mov [eax],ebx // mov eax,0
add eax,4
mov [eax],0x50 // push eax
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0x04000000
// mov eax,0x04000000 = Create_default_error_mode
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
// mov eax,0
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
// mov eax,0
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
// mov eax,0
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,ProgExeNameAddrinUser
// mov eax,ProgExeNameAddrinUser
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
// mov eax,0
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
// 现在是过程调用本身
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,CreateProcessA_OEP
// mov eax,CreateProcessA_OEP
mov [eax],ebx
add eax,4
mov bx,0xD0FF
mov [eax], bx
// call eax
add eax,2
// popad
mov bl,0x61
mov [eax],bl
inc eax
mov bl,0xbb
mov [eax],bl
inc eax
mov ebx,KiSystemServiceReturnAddress
// mov ebx,KiSystemServiceReturnAddress
mov [eax],ebx
add eax,4
mov bx,0xE3FF
// jmp ebx ... 现在重新恢复
// KiSystemService的原始返回点
mov [eax], bx
我们看到，借助于数十行的汇编指令，我们在kernel32.dll的首部中建立起了植入代码，这段代码看上去如下：
图中所示为kernel32.dll模块的一段内存dump。红框内的是代码，而蓝框内的是结构体USTARTUPINFO、UPROCESS_INFORMATION和ProgExeName，对应于CreateProcessA中相应的结构体。红框中的代码的实际意义如下：
0010:77E6047A 60 PUSHAD
0010:77E6047B B84C04E677 MOV EAX,77E6044C - UPROCESS_INFORMATION
0010:77E60480 50 PUSH EAX
0010:77E60481 B80804E677 MOV EAX,77E60408 - USTARTUPINFO
0010:77E60486 50 PUSH EAX
0010:77E60487 B800000000 MOV EAX,00000000
0010:77E6048C 50 PUSH EAX
0010:77E6048D B800000000 MOV EAX,00000000
0010:77E60492 50 PUSH EAX
0010:77E60493 B800000004 MOV EAX,04000000 - Create_default_error_mode
0010:77E60498 50 PUSH EAX
0010:77E60499 B800000000 MOV EAX,00000000
0010:77E6049E 50 PUSH EAX
0010:77E6049F B800000000 MOV EAX,00000000
0010:77E604A4 50 PUSH EAX
0010:77E604A5 B800000000 MOV EAX,00000000
0010:77E604AA 50 PUSH EAX
0010:77E604AB B85C04E677 MOV EAX,77E6045C - ProgExeNameAddrinUser
0010:77E604B0 50 PUSH EAX
0010:77E604B1 B800000000 MOV EAX,00000000
0010:77E604B6 50 PUSH EAX
0010:77E604B7 B8BC1BE677 MOV EAX,KERNEL32!CreateProcessA
0010:77E604BC FFD0 CALL EAX
0010:77E604BE 61 POPAD
0010:77E604BF BB0403FE7F MOV EBX,7FFE0304 - 向ntdll.dll中返回的地址
0010:77E604C4 FFE3 JMP EBX
总的来说都比较简单。在线程用指令ret/sysexit离开_KiSystemService时，通过改换返回线程内核堆栈的地址，就去执行前面编写的汇编植入代码。这段代码在CreateProcessA中调用，之后JMP EBX指令重新返回到ntdll.dll。由此，如果一切顺利，就会调用创建进程的植入代码。
之后从类似于Mark Russinovich的Process Explorer这样的程序中就可以看到所创建的进程。如果，比如说，我们创建了一个GUI进程，则在某些情况下看不到应用程序窗口，尽管Process Explorer能正常显示其存在。不用担心，事实上，在某些我所不了解的情况下进程没有连接上WindowStation并获得比如说Desktop，这会发生在父进程成为Services进程时。
例如，我们看到，“产生”在WinAmp内部的CMD.EXE进程，取得了Desktop并在“表面”上可见。
这又是另一种情况了。
我想就不必多说了。
通过本文所讲，我想我们已经体会到，我们实现目的的方法是多么的简单。说起来，从内核模式启动用户进程不算是什么鬼把戏。现在在读过所有说明与补充之后，您可以着手研究驱动代码了。加载驱动可以用Four-F的KmdKit里的KmdManager。其实，要感谢他帮助解决了文末的一个问题，同时还要感谢lial先生对本文的热情帮助。
批评建议请发至troguar@yandex.ru。
我想很多人都会有这样的问题，能否从内核驱动中启动用户应用程序呢？在Win9x（win95, 98, ME）中有专门的导出函数ShellVxd_ShellExecute，此函数能够启动应用程序。而在NT系统中没有专门的导出函数。
单数不存在导出函数决不意味这种想法不可能实现。恰恰相反，这种想法是完全可能实现的。当然，您可能会觉得这有如恶梦一般，分析一大堆系统对象，仔细的研究它们的属性与方法等等。不用紧张，事实上要简单得多。来，让我们放松一下，并用几种非标准的观点看一下这个问题。
我们先推开现实不管。仔细的查看模块ntoskrnl.exe的导出函数，我们没有找到能直接赋予新进程生命的函数。DDK对此也保持沉默。但是我们知道，进程是由用户模块kernel32.dll的导出函数kernel32.dll:CreateProcessA, CreateProcessW, CreateProcessInternalA, CreateProcessInternalW创建的，对于这些函数的描述以及参数可以很容易的在PSDK的文档中找到。当然，绕过kernel32.dll，尝试自己模拟这些函数是可以成功的。对这种方法的讲解和相应的代码可以在Garry Nebetta的WinNT Native Api指南中找到。实际上这也没有什么不可思议的。进程仍然从用户模式启动，只不过是直接调用了ntdll.dll模块里的导出函数。但是我们的问题依然没有答案，内核中的哪些东东能实现同样的效果呢？
其实，我所给出的方法也没有显出什么太古怪的地方来。我们不会自己构造内核对象并靠自己的力量和智慧来模拟出相应的内核行为和机制。我们知道，没有人能比操作系统做得更好，而且内核恐怕也不会对我们的“自己动手”表示赞赏。但是，我们还是要在内核模式驱动中把应用程序启动起来，只是……是在用户模式下。下面我们就来开始吧。
--------------------------------------------------------------------------------
方法很简单。现在我对机制进行一点解释，然后继续对内核代码进行分析。主要的思想就是，要“抓住”某个进程的用户线程，并将其与我们自己的条件“捆绑”，也就是说修改执行的代码并让它转向到预先准备好的用户地址空间中的代码中，这段代码调用函数kernel32.dll:CreateProcessA。
怎样才能做到呢？首先需要找到线程从内核模式转向用户模式的地方。进程是如何从用户模式切换到内核模式再切换回来的呢？这是通过中断门/快速系统调用接口进行的。对于本例，经过思考，我们没有找到比INT 0x2E/SYSENTER更好的地方，而正是在这里线程改变了自己的优先级。
当然，如果有其它类似的服务，比如调试用的int 0x2d，或是timer int 0x2a。但是我们需要稳定的方法，对大多数进程能够使用的，可以频繁使用的方法。这样，在一番寻找之后，最好的候选方法就是系统调用门接口INT 0x2E/SYSENTER。我们如何才能使用这个后门呢？无疑需要知道，在中断调用时会发生向段寄存器重新加载事先保存在TSS中的选择子，主要是CS和SS。在通过门到达内核后，在堆栈中保存着中断的返回地址。使用指令sysenter（winXP+）的情况类似。这个地址是我们所需要的，而取得它完全不是问题。之后，我们必需拦截函数_KiSystemService，向其中插入我们处理程序的代码。问题又来了，我们如何找到_KiSystemService函数呢？
有一点是显然的，中断向量INT 0x2E指向这个函数。但是，在WinXP+中情况并非只此一种。由于最新处理器的新特性，新版本的系统都使用了快速系统调用指令SYSENTER/SYSEXIT。SYSENTER指令与INT指令类似，但有一点区别，就是它调用的代码的地址位于MSR寄存器中的某一个里。为什么这种情况下我们需要多余的查找呢？另外，我们还知道，MSR的内容是经常变化的。尽管如此，IDT表中的中断向量int 0x2e不管怎样都还是指向_KiSystemService的起始代码。尽管int 0x2e没有被使用，但找到它显然不是问题。
害怕失望——您错了。拦截掉INT 0x2E会怎样呢？例如，ntice就好干这个。在代码调试时我们没有可能“亲眼”见到这个函数。除此之外，在ntoskrnl.exe的导出中，此函数也没有被提及。但是，还不是太坏。我们来想一想，如何能找到它。扫描全部内存查找含有_KiSystemService函数的一组指令没有什么意义。我们这里的解决方案十分简单。我们知道，_KiSystemService是转向内核函数的入口，所以在函数的内部有直接调用内核服务的代码。我们来看下面的代码。
0008:804DA113 5A POP EDX
0008:804DA114 FF0538F6DFFF INC DWORD PTR [FFDFF638]
0008:804DA11A 8BF2 MOV ESI,EDX
0008:804DA11C 8B5F0C MOV EBX,[EDI+0C]
0008:804DA11F 33C9 XOR ECX,ECX
0008:804DA121 8A0C18 MOV CL,[EBX+EAX]
0008:804DA124 8B3F MOV EDI,[EDI]
0008:804DA126 8B1C87 MOV EBX,[EAX*4+EDI]
0008:804DA129 2BE1 SUB ESP,ECX
0008:804DA12B C1E902 SHR ECX,02
0008:804DA12E 8BFC MOV EDI,ESP
0008:804DA130 3B35D4C75480 CMP ESI,[ntoskrnl!MmUserProbeAddress]
0008:804DA136 0F83A1010000 JAE 804DA2DD
0008:804DA13C F3A5 REPZ MOVSD
0008:804DA13E FFD3 CALL EBX
0008:804DA140 8BE5 MOV ESP,EBP
我们看到了_KiSystemService的一段代码，指令CALL EBX调用了某个内核函数，这个函数是预先从服务表中选出的，然后在EBX寄存器中加载这个函数的地址（详细过程可以阅读我前一篇文章《跟踪Native Api函数调用》）。
函数_KiSystemService并没有在ntoskrnl.exe的导出表中，但是我们有指向表KeServiceDescriptorTable的指针，从这个表中可以取出所要的Native Api函数的地址，比如说，NtReadFile。接下来，函数将在发出CALL EBX指令的进程上下文中调用并返回至_KiSystemService的下一条指令。
前一篇文章中有个问题涉及到了拦截NativeApi函数，所用的方法是将自己的处理程序添加到服务表中替换原来的函数，然后依次调用这两个函数。这里使用的也是这种办法。比如，我们拦截了NtReadFile这个最常调用的函数，然后，在我们的处理程序内部的堆栈中有函数返回到_KiSystemService的地址。以下是演示代码：
DWORD FindKiSystemServiceOriginalEntryPoint()
{
KPRIORITY CurrentThreadPriority;
// 拦截 NtReadFile这个最常调用的函数
CurrentThreadPriority = KeQueryPriorityThread(KeGetCurrentThread());
// so that the system not degraded
KeSetPriorityThread(KeGetCurrentThread(),1);
if( *NtBuildNumber == 2195 ) OriginalNtReadFile = *KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2195];
if( *NtBuildNumber == 2600 ) OriginalNtReadFile = *KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2600];
disableinterruptions
clearwp
if( *NtBuildNumber == 2195 ) KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2195] = ArtificialNtReadFile;
if( *NtBuildNumber == 2600 ) KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2600] = ArtificialNtReadFile;
restorewp
enableinterruptions
while( !FindingForWhile );
// wait, NtReadFile will be called, надеюсь не вечно :)
// 相似的, 地址被找到, 取下ArtificialNtReadFile()处理程序
disableinterruptions
clearwp
if( *NtBuildNumber == 2195 )
KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2195] =
*OriginalNtReadFile;
if( *NtBuildNumber == 2600 )
KeServiceDescriptorTable->NtoskrnlTable.ServiceTable[_NtReadFile_2600] =
*OriginalNtReadFile;
restorewp
enableinterruptions
KeSetPriorityThread(KeGetCurrentThread(),CurrentThreadPriority);
// 恢复原先状态
// 现在计算KiSystemService原来的入口点
return NtReadFileReturnAddress - 0xC4;
// KiSystemService内部入口点与返回点的差
}
NtReadFile的处理程序:
__declspec(naked) ArtificialNtReadFile()
{ __asm
{
push dword ptr [esp] // !!!
pop NtReadFileReturnAddress
inc dword ptr FindingForWhile // 找到所需函数的地址
jmp dword ptr OriginalNtReadFile
}
}
这段代码的含义您可能已经猜到了。对不同版本Win NT的_KiSystemService函数的分析显示，除了WinXPSP2和2K3，在所有NT内核中这个函数都是相同的（为了保证兼容性，在驱动的代码中有某些不大的改动）。这些都可以利用起来。我想现在大家都会明白，如果我们找到了某个内部函数的地址，而函数又有确定的大小，就不难找到它的startup。call ebx后面一条指令的地址我们可在处理程序的堆栈中找到，而从这条指令到startup间的距离是0xC4字节（Win XP, 2K）。现在_KiSystemService的起始地址就不难计算了。
// такова разница м/д точкой входа и точкой возврата внутри KiSystemService
return NtReadFileReturnAddress - 0xC4;
由此我们就得到了_KiSystemService的原始入口点。
这样，第一步就走完了，我们继续向下进行。下面向实现目标迈出的这一大步就应该是找到放置调用kernel32:CreateProcessA的代码的位置。自然，我们可以将代码数据只放在用户地址空间中，而且是放在大多数进程都能访问到的地方。对此没什么太好的办法，我们所能做的就是利用修正后的kernel32.dll模块第一页中的空闲空间，这块空间紧挨着首部。在被加载到内存并进行修正后，从0x1000字节PE首部占据了某些地方的0x400字节，剩余的地方都由0填充。这些地方完全可以为我们所用。但是，这还是个次要的问题，主要的问题是要在内核模式下找到kernel32.dll的基地址。
这个问题也并不困难。实际上，我们所需要的一切都能在进程PEB指向的结构体中找到。有些结构体的描述可以在Свен Шрайбер的那本关于undocunmented win nt的书中找到。有个结构体指向了进程加载的模块的列表，但是我没有在此书中找到具体的对此结构体的描述，所以只好祭起调试器来小小的挖掘一下。看过PEB，我们立即被pPeb->ProcessModuleInfo->ModuleHeader.List3域所吸引。书中所提到的正是这个成员（List3）。经过试验我明白了，这个ListEntry类型的结构体大概是这个样子的（与MS的源码可能会有区别）：
typedef struct _KMODULEINFOLISTENTRY {
DWORD Flink;
DWORD Blink;
DWORD ModuleIBase;
DWORD DllEntryPoint;
DWORD Unknown2;
DWORD Unknown3;
PWCHAR ModuleName;
} KMODULEINFOLISTENTRY, *PKMODULEINFOLISTENTRY, **PPKMODULEINFOLISTENTRY;
某些域对于我来说还是个迷，实际上我们对这些域并不感兴趣，其余的我想也不需要解释了。这样，使用这个结构体，我们就可以用
DWORD kwsGetModule(PWCHAR ModuleNameW)函数找到kernel32.dll的基地址，此函数可参见驱动源代码。实际上，这个函数可以用来查找进程中的各个模块。
现在我们回到查找最适宜放置调用kernel32:CreateProcessA代码的位置这个问题上来。我们前边提到，代码将位于kernel32.dll模块首部后紧接着的第一页中。这样我们一箭双雕：一是嵌入这个位置中的代码能被所有的进程看到，二是我们有足够的空间来放置植入的CreateProcessA调用代码。别的倒也没什么，只是模块的PE的第一页在用户空间中是只读的，属性为readonly。为了详细的了解此问题，我们来打开PSDK文档并对CreateProcess函数作更细致的研究：
BOOL CreateProcess(
LPCTSTR lpApplicationName, // name of executable module
LPTSTR lpCommandLine, // command line string
LPSECURITY_ATTRIBUTES lpProcessAttributes, // SD
LPSECURITY_ATTRIBUTES lpThreadAttributes, // SD
BOOL bInheritHandles, // handle inheritance option
DWORD dwCreationFlags, // creation flags
LPVOID lpEnvironment, // new environment block
LPCTSTR lpCurrentDirectory, // current directory name
LPSTARTUPINFO lpStartupInfo, // startup information
LPPROCESS_INFORMATION lpProcessInformation // process information
);
typedef struct _STARTUPINFO {
DWORD cb;
LPTSTR lpReserved;
LPTSTR lpDesktop;
LPTSTR lpTitle;
DWORD dwX;
DWORD dwY;
DWORD dwXSize;
DWORD dwYSize;
DWORD dwXCountChars;
DWORD dwYCountChars;
DWORD dwFillAttribute;
DWORD dwFlags;
WORD wShowWindow;
WORD cbReserved2;
LPBYTE lpReserved2;
HANDLE hStdInput;
HANDLE hStdOutput;
HANDLE hStdError;
} STARTUPINFO, *LPSTARTUPINFO;
typedef struct _PROCESS_INFORMATION {
HANDLE hProcess;
HANDLE hThread;
DWORD dwProcessId;
DWORD dwThreadId;
} PROCESS_INFORMATION;
我们看到，函数在堆栈中接收10个双字，多数都是指针。其中某些并不是必需的，可以传递NULL，而例如lpStartupInfo，lpProcessInformation和ProgExeNameAddrinUser则是必需要确定的（关于调用权限和传递参数更详细的信息我这里就不给出了，对此可参阅MSDN）。相应的需要为这些参数分配空间。但这只是问题的一部分。
问题的另一部分在于，除了要为结构体提供空间之外，CreateProcess还应该向它们的域进行写入。我们这里不能出现这种情况，因为我们的页是只读的，并且任何向其中写入的尝试都会引起异常，这个异常会关掉当前进程。为了消除在用户模式下向此页写入的可能性，我们应该修改该页PTE的属性。对此有两种办法：一是在内核模式下调用NtProtectVirtualMemory，这时应考虑到这个函数没有导出，需要找到SST表的入口点；二是直接找到该页的descriptor（PTE）并修正这个恼人的“错误”。我们实际上调用了专门为此而写的函数PageAccessProp(…)，在堆栈中接收4个参数，这些参数我想就不必解释了。
除此之外，此函数还可以用在如下情况，比如必须在UserMode下操作系统内存页的时候。为此需要相应的翻转U位，但是如果内核使用的是4K字节的页，则在descriptor里还有一个G位。此位的意思是这一页是全局的，而且在任务切换或重置CR3时不应在TLB中更新或替换此PTE。也就是说，如果翻转U位，关掉G位，在用户模式下向高2G空间中写入，就会引起异常。一定要关掉CR4中的PGE位，然后进行类似的操作并向系统页进行写入。除此之外，不要忘了CR0中的WP位。从原理上讲会出现的问题到这里就讲完了。
接下来还有一个有趣的任务。我们必须找到导出函数kernel32:CreateProcessA。在我们的驱动中这项工作是由函数GetExportedFuncAddr(DWORD ModuleImageBase,PCHAR FuncName)来负责的，此函数的参数是模块在内存中的地址和所要找函数的名字。若找到，则返回其在内存中的基地址。代码我就不解释了，更详细的信息请参见PE的相关文档，同时还可以直接研究GetExportedFuncAddr。驱动中用到的所有结构体都位于struc.h中。一般来讲，在跟踪CreateImplant()函数时，前面讲到的各个部分会按顺序出现。
前面我们讨论了所有所需的辅助，相关的函数，并被引导到了神秘的目标面前。现在我们从大体上来依次研究驱动的算法。
驱动中最主要的函数就是ReplaceKiSystemServiceCode()。此函数首先用前面讲到的方法找到startup _KiSystemService，然后直接切入代码的核心来取得控制权。为此我们必须：第一，取得_KiSystemService返回时的返回点来分析地址并为后面替换此地址提供方便，而替换后的地址就指向我们植入kernel32.dll第一页中的代码；第二，处理程序将植入代码注入到用户模式内存中。总共会有两处拦截。
现在来更详细的看一下第一处拦截。我们来看代码：
0008:804DA07C 6A00 PUSH 00
0008:804DA07E 55 PUSH EBP
0008:804DA07F 53 PUSH EBX
0008:804DA080 56 PUSH ESI
0008:804DA081 57 PUSH EDI
0008:804DA082 0FA0 PUSH FS
0008:804DA084 BB30000000 MOV EBX,00000030
0008:804DA089 668EE3 MOV FS,BX
0008:804DA08C FF3500F0DFFF PUSH DWORD PTR [FFDFF000]
0008:804DA092 C70500F0DFFFFFFFFFFF MOV DWORD PTR [FFDFF000],FFFFFFFF
0008:804DA09C 8B3524F1DFFF MOV ESI,[FFDFF124]
0008:804DA0A2 FFB640010000 PUSH DWORD PTR [ESI+00000140]
0008:804DA0A8 83EC48 SUB ESP,48
原始的 startup _KiSystemService.
我们直接在代码起始处注入第一个处理程序，方法就是splicing，保存原始地址，之后将其恢复。这样就得到了下面的代码：
0008:804DA07C FF25008578FC JMP [ArtificialKiSystemService]
0008:804DA082 0FA0 PUSH FS
0008:804DA084 BB30000000 MOV EBX,00000030
0008:804DA089 668EE3 MOV FS,BX
0008:804DA08C FF3500F0DFFF PUSH DWORD PTR [FFDFF000]
0008:804DA092 C70500F0DFFFFFFFFFFF MOV DWORD PTR [FFDFF000],FFFFFFFF
0008:804DA09C 8B3524F1DFFF MOV ESI,[FFDFF124]
0008:804DA0A2 FFB640010000 PUSH DWORD PTR [ESI+00000140]
0008:804DA0A8 83EC48 SUB ESP,48
下面是处理程序KiSystemServiceHandler()，这个函数的地址就保存在ArtificialKiSystemService里。
__declspec(naked) KiSystemServiceHandler()
{
SaveKISSRetAddr // 保存由系统服务向用户模式返回的返回点
_asm{
OriginalKiSystemServiceInlineStartUpCode // 恢复原始代码
push dword ptr [OriginalKiSystemService]
add dword ptr [esp],OriginalKiSystemServiceStartUpCodeSize
ret
}
}
我希望您能明白，为什么拦截被实现在startup代码的起始处。正是在这里我们能从线程堆栈中取出所需的地址而不用多费力气。但是我不主张在KiSystemServiceHandler()处理程序内部进行更为复杂的操作。这段代码是在关中断的情况下执行的，也就是说IRQL处于最高级，且除此之外fs也不要动。处理程序中不当的行为必然会引起系统崩溃。现在来看第二处拦截，代码如下：
0008:804DA07C FF25008578FC JMP [ArtificialKiSystemService]
0008:804DA082 0FA0 PUSHFS
0008:804DA084 BB30000000 MOV EBX,00000030
0008:804DA089 668EE3 MOV FS,BX
0008:804DA08C FF3500F0DFFF PUSH DWORD PTR [FFDFF000]
0008:804DA092 C70500F0DFFFFFFFFFFF MOV DWORD PTR [FFDFF000],FFFFFFFF
0008:804DA09C 8B3524F1DFFF MOV ESI,[FFDFF124]
0008:804DA0A2 FFB640010000 PUSH DWORD PTR [ESI+00000140]
0008:804DA0A8 83EC48 SUB ESP,48
0008:804DA0AB 8B5C246C MOV EBX,[ESP+6C]
0008:804DA0AF 83E301 AND EBX,01
0008:804DA0B2 889E40010000 MOV [ESI+00000140],BL
0008:804DA0B8 8BEC MOV EBP,ESP
0008:804DA0BA 8B9E34010000 MOV EBX,[ESI+00000134]
0008:804DA0C0 895D3C MOV [EBP+3C],EBX
0008:804DA0C3 89AE34010000 MOV [ESI+00000134],EBP
0008:804DA0C9 FC CLD
0008:804DA0CA F6462CFF TEST BYTE PTR [ESI+2C],FF
0008:804DA0CE 0F85D6FEFFFF JNZ 804D9FAA
0008:804DA0D4 FB STI // 降IRQL
0008:804DA0D5 FF25F08478FC JMP [ArtificialKiSystemServiceSafedCode]
0008:804DA0DB CC INT 3
0008:804DA0DC CC INT 3
0008:804DA0DD 8BCF MOV ECX,EDI
现在我们来看处理程序KiSystemServiceHandler2()，其地址就在ArtificialKiSystemServiceSafedCode：
__declspec(naked)KiSystemServiceHandler2()
{
__asm mov CanUnload,FALSE // 设置不能卸载驱动的标志
saveregisters // 保护寄存器
if (!isP)
{
isP++; // 建立不可多次进入的标志
CreateImplant(); // 注入植入代码
}
restoreregisters // 恢复寄存器
__asm
{
OriginalKiSystemServiceInLineSafedCode
push dword ptr [KiSystemServiceSafedCode]
add dword ptr [esp],OriginalAfterStiCodeSize
mov CanUnload,TRUE // 现在可以放心的卸载驱动了:)
ret
}
}
在这个处理程序中我们可以做所有我们想到的事情。这里的IRQL是最低的，所以我们在这里调用CreateImplant()函数。这个函数完成前面讲过的操作，包括注入植入代码。在此之后，在_KiSystemService返回后将调用植入代码，在其处理程序之后线程重新返回到这个中断之前，更精确讲，就是返回到ntdll.dll内部。下面是CreateImplant()函数中创建植入代码部分的代码。
// 将从KiSystemService返回时的返回点
// 改为用户模式下植入代码的地址
mov eax,ImpStartAddr
mov ebx,[KISS_SP]
// 将参数由后向前塞入堆栈
mov [ebx],eax
// pushad
mov bl,0x60
mov [eax],bl
inc eax
mov bl, 0xb8
mov [eax], bl
inc eax
mov ebx,pUprocessInformation // PI
mov [eax],ebx // mov eax,PI
add eax,4
mov [eax],0x50 // push eax
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,pUstartUpInfo
mov [eax],ebx // mov eax,SI
add eax,4
mov [eax],0x50 // push eax
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
mov [eax],ebx // mov eax,0
add eax,4
mov [eax],0x50 // push eax
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
mov [eax],ebx // mov eax,0
add eax,4
mov [eax],0x50 // push eax
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0x04000000
// mov eax,0x04000000 = Create_default_error_mode
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
// mov eax,0
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
// mov eax,0
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
// mov eax,0
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,ProgExeNameAddrinUser
// mov eax,ProgExeNameAddrinUser
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,0
// mov eax,0
mov [eax],ebx
add eax,4
// push eax
mov [eax],0x50
inc eax
// 现在是过程调用本身
mov bl,0xb8
mov [eax],bl
inc eax
mov ebx,CreateProcessA_OEP
// mov eax,CreateProcessA_OEP
mov [eax],ebx
add eax,4
mov bx,0xD0FF
mov [eax], bx
// call eax
add eax,2
// popad
mov bl,0x61
mov [eax],bl
inc eax
mov bl,0xbb
mov [eax],bl
inc eax
mov ebx,KiSystemServiceReturnAddress
// mov ebx,KiSystemServiceReturnAddress
mov [eax],ebx
add eax,4
mov bx,0xE3FF
// jmp ebx ... 现在重新恢复
// KiSystemService的原始返回点
mov [eax], bx
我们看到，借助于数十行的汇编指令，我们在kernel32.dll的首部中建立起了植入代码，这段代码看上去如下：
图中所示为kernel32.dll模块的一段内存dump。红框内的是代码，而蓝框内的是结构体USTARTUPINFO、UPROCESS_INFORMATION和ProgExeName，对应于CreateProcessA中相应的结构体。红框中的代码的实际意义如下：
0010:77E6047A 60 PUSHAD
0010:77E6047B B84C04E677 MOV EAX,77E6044C - UPROCESS_INFORMATION
0010:77E60480 50 PUSH EAX
0010:77E60481 B80804E677 MOV EAX,77E60408 - USTARTUPINFO
0010:77E60486 50 PUSH EAX
0010:77E60487 B800000000 MOV EAX,00000000
0010:77E6048C 50 PUSH EAX
0010:77E6048D B800000000 MOV EAX,00000000
0010:77E60492 50 PUSH EAX
0010:77E60493 B800000004 MOV EAX,04000000 - Create_default_error_mode
0010:77E60498 50 PUSH EAX
0010:77E60499 B800000000 MOV EAX,00000000
0010:77E6049E 50 PUSH EAX
0010:77E6049F B800000000 MOV EAX,00000000
0010:77E604A4 50 PUSH EAX
0010:77E604A5 B800000000 MOV EAX,00000000
0010:77E604AA 50 PUSH EAX
0010:77E604AB B85C04E677 MOV EAX,77E6045C - ProgExeNameAddrinUser
0010:77E604B0 50 PUSH EAX
0010:77E604B1 B800000000 MOV EAX,00000000
0010:77E604B6 50 PUSH EAX
0010:77E604B7 B8BC1BE677 MOV EAX,KERNEL32!CreateProcessA
0010:77E604BC FFD0 CALL EAX
0010:77E604BE 61 POPAD
0010:77E604BF BB0403FE7F MOV EBX,7FFE0304 - 向ntdll.dll中返回的地址
0010:77E604C4 FFE3 JMP EBX
总的来说都比较简单。在线程用指令ret/sysexit离开_KiSystemService时，通过改换返回线程内核堆栈的地址，就去执行前面编写的汇编植入代码。这段代码在CreateProcessA中调用，之后JMP EBX指令重新返回到ntdll.dll。由此，如果一切顺利，就会调用创建进程的植入代码。
之后从类似于Mark Russinovich的Process Explorer这样的程序中就可以看到所创建的进程。如果，比如说，我们创建了一个GUI进程，则在某些情况下看不到应用程序窗口，尽管Process Explorer能正常显示其存在。不用担心，事实上，在某些我所不了解的情况下进程没有连接上WindowStation并获得比如说Desktop，这会发生在父进程成为Services进程时。
例如，我们看到，“产生”在WinAmp内部的CMD.EXE进程，取得了Desktop并在“表面”上可见。
这又是另一种情况了。
我想就不必多说了。
通过本文所讲，我想我们已经体会到，我们实现目的的方法是多么的简单。说起来，从内核模式启动用户进程不算是什么鬼把戏。现在在读过所有说明与补充之后，您可以着手研究驱动代码了。加载驱动可以用Four-F的KmdKit里的KmdManager。其实，要感谢他帮助解决了文末的一个问题，同时还要感谢lial先生对本文的热情帮助。
批评建议请发至troguar@yandex.ru。
- 从内核模式启动进程
- gdb跟踪调试内核从start_kernel到init进程启动
- 跟踪内核从start_kernel到init进程启动
- 从start_kernel到init进程启动 《Linux内核分析》笔记
- 从核心模式启动一个进程----怎样从内部的驱动程序启动一个Win32进程
- MOOC-Linux内核lab3 调试内核从start_kernel到init进程启动
- 从内存启动进程
- Linux内核启动进程流程
- 跟踪分析Linux内核的启动过程(从start_kernel到init进程)
- 使用gdb跟踪调试内核从start_kernel到init进程启动
- Linux内核分析之三——使用gdb跟踪调试内核从start_kernel到init进程启动
- 从django 启动守护进程
- UNIX内核概述-进程/内核模式
- linux内核如何启动第一个进程
- linux内核如何启动第一个进程
- linux内核启动的进程浅析
- 内核启动kernel_init（init）进程分析
- 从进程到内核---ring3到ring0
- vivi系统引导程序的网络功能扩展
- 万丈高楼平地起——写在开博时
- 【新手学习】Excel操作指南 之一
- apache服务器配置全攻略
- 踏入C++中的雷区——C++内存管理详解
- 从内核模式启动进程
- WEBSITE
- petshop4.0项目概述与架构分析
- CMM介绍一
- 一张浓缩大学生活的顶级报（转载）
- 杀毒引擎外一篇--讨论杀软卡机的原理
- 还原完整备份的语法如下：
- web 性能测试小结
- 跟踪Native API函数调用
