利用远程线程直接注入

注入代码到其他进程地址空间的方法是使用WriteProcessMemory API。这次你不用编写一个独立的DLL而是直接复制你的代码到远程进程。

 让我们看一下CreateRemoteThread的声明和CreateThread相比，有以下不同：

●增加了hProcess参数。这是要在其中创建线程的进程的句柄。

●CreateRemoteThread的lpStartAddress参数必须指向远程进程的地址空间中的函数。这个函数必须存在于远程进程中，所以我们不能简单地传递一个本地ThreadFucn的地址，我们必须把代码复制到远程进程。

●同样，lpParameter参数指向的数据也必须存在于远程进程中，我们也必须复制它。

现在，我们总结一下使用该技术的步骤：

1． 得到远程进程的HANDLE（OpenProcess）。

2． 在远程进程中为要注入的数据分配内存（VirtualAllocEx）、

3． 把初始化后的INJDATA结构复制到分配的内存中（WriteProcessMemory）。

4． 在远程进程中为要注入的数据分配内存（VirtualAllocEx）。

5． 把ThreadFunc复制到分配的内存中（WriteProcessMemory）。

6． 用CreateRemoteThread启动远程的ThreadFunc。

7． 等待远程线程的结束（WaitForSingleObject）。

8． 从远程进程取回指执行结果（ReadProcessMemory 或 GetExitCodeThread）。

9． 释放第2、4步分配的内存（VirtualFreeEx）。

10． 关闭第6、1步打开打开的句柄。

另外，编写ThreadFunc时必须遵守以下规则：

1． ThreadFunc不能调用除kernel32.dll和user32.dll之外动态库中的API函数。只有kernel32.dll和user32.dll（如果被加载）可以保证在本地和目的进程中的加载地址是一样的。（注意：user32并不一定被所有的Win32进程加载！）参考附录A。如果你需要调用其他库中的函数，在注入的代码中使用LoadLibrary和GetProcessAddress强制加载。如果由于某种原因，你需要的动态库已经被映射进了目的进程，你也可以使用GetMoudleHandle代替LoadLibrary。同样，如果你想在ThreadFunc中调用你自己的函数，那么就分别复制这些函数到远程进程并通过INJDATA把地址提供给ThreadFunc。

2． 不要使用static字符串。把所有的字符串提供INJDATA传递。为什么？编译器会把所有的静态字符串放在可执行文件的“.data”段，而仅仅在代码中保留它们的引用（即指针）。这样，远程进程中的ThreadFunc就会执行不存在的内存数据（至少没有在它自己的内存空间中）。

3． 去掉编译器的/GZ编译选项。这个选项是默认的（看附录B）。

4． 要么把ThreadFunc和AfterThreadFunc声明为static，要么关闭编译器的“增量连接（incremental linking）”（看附录C）。

5． ThreadFunc中的局部变量总大小必须小于4k字节（看附录D）。注意，当degug编译时，这4k中大约有10个字节会被事先占用。

6． 如果有多于3个switch分支的case语句，必须像下面这样分割开，或用if-else if代替.

switch( expression ) {

  case constant1: statement1; goto END;

  case constant2: statement2; goto END;

  case constant3: statement2; goto END;

}

switch( expression ) {

  case constant4: statement4; goto END;

  case constant5: statement5; goto END;

  case constant6: statement6; goto END;

}

END:

如果你不按照这些游戏规则玩的话，你注定会使目的进程挂掉！记住，不要妄想远程进程中的任何数据会和你本地进程中的数据存放在相同内存地址！

所有取得远程edit中文本的工作都被封装进这个函数：GetWindowTextRemote(A/W)：

int GetWindowTextRemoteA( HANDLE hProcess, HWND hWnd, LPSTR lpString );

int GetWindowTextRemoteW( HANDLE hProcess, HWND hWnd, LPWSTR lpString );参数：

hProcess：  目的edit所在的进程句柄

hWnd：  目的edit的句柄

lpString： 接收字符串的缓冲

返回值：  成功复制的字符数。

让我们看以下它的部分代码，特别是注入的数据和代码。为了简单起见，没有包含支持Unicode的代码。

//INJDATA

typedef LRESULT   (WINAPI *SENDMESSAGE)(HWND,UINT,WPARAM,LPARAM);

typedef struct { 

  HWND hwnd;             // handle to edit control

  SENDMESSAGE fnSendMessage;   // pointer to user32!SendMessageA

  char psText[128];   // buffer that is to receive the password

} INJDATA;

INJDATA是要注入远程进程的数据。在把它的地址传递给SendMessageA之前，我们要先对它进行初始化。幸运的是unse32.dll在所有的进程中（如果被映射）总是被映射到相同的地址，所以SendMessageA的地址也总是相同的，这也保证了传递给远程进程的地址是有效的。

//ThreadFunc

static DWORD WINAPI ThreadFunc (INJDATA *pData)

{

  pData->fnSendMessage( pData->hwnd, WM_GETTEXT,   // 得到密码

                sizeof(pData->psText),

                (LPARAM)pData->psText );

  return 0;

}

// This function marks the memory address after ThreadFunc.

// int cbCodeSize = (PBYTE) AfterThreadFunc - (PBYTE) ThreadFunc.

static void AfterThreadFunc (void)

{

}

ThreadFunc是远程线程实际执行的代码。

●注意AfterThreadFunc是如何计算ThreadFunc的代码大小的。一般地，这不是最好的办法，因为编译器会改变你的函数中代码的顺序（比如它会把ThreadFunc放在AfterThreadFunc之后）。然而，你至少可以确定在同一个工程中，比如在我们的WinSpy工程中，你函数的顺序是固定的。如果有必要，你可以使用/ORDER连接选项，或者，用反汇编工具确定ThreadFunc的大小，这个也许会更好。

如何用该技术子类（subclass）一个远程控件

示例程序：InjectEx

让我们来讨论一个更复杂的问题：如何子类属于其他进程的一个控件？

首先，要完成这个任务，你必须复制两个函数到远程进程：

1． ThreadFunc，这个函数通过调用SetWindowLong API来子类远程进程中的控件，

2． NewProc， 那个控件的新窗口过程（Window Procedure）。

然而，最主要的问题是如何传递数据到远程的NewProc。因为NewProc是一个回调（callback）函数，它必须符合特定的要求（译者注：这里指的主要是参数个数和类型），我们不能再简单地传递一个INJDATA的指针作为它的参数。幸运的我已经找到解决这个问题的方法，而且是两个，但是都要借助于汇编语言。我一直都努力避免使用汇编，但是这一次，我们逃不掉了，没有汇编不行的。

解决方案1

不知道你是否注意到了，INJDATA紧挨着NewProc放在NewProc的前面？这样的话在编译期间NewProc就可以知道INJDATA的内存地址。更精确地说，它知道INJDATA相对于它自身地址的相对偏移，但是这并不是我们真正想要的。现在，NewProc看起来是这个样子：

static LRESULT CALLBACK NewProc(

HWND hwnd,     // handle to window

UINT uMsg,     // message identifier

WPARAM wParam,   // first message parameter

LPARAM lParam ) // second message parameter

{

  INJDATA* pData = (INJDATA*) NewProc; // pData 指向

                            // NewProc;

  pData--;         // 现在pData指向INJDATA;

                        //记住，INJDATA 在远程进程中刚好位于NewProc的紧前面;

  //-----------------------------

  // 子类代码

  // ........

  //-----------------------------

  //调用用来的的窗口过程;

  // fnOldProc (由SetWindowLong返回) 是被ThreadFunc（远程进程中的）初始化

  // 并且存储在远程进程中的INJDATA里的;

  return pData->fnCallWindowProc( pData->fnOldProc,

                        hwnd,uMsg,wParam,lParam );

}

然而，还有一个问题，看第一行：

INJDATA* pData = (INJDATA*) NewProc;

pData被硬编码为我们进程中NewProc的地址，但这是不对的。因为NewProc会被复制到远程进程，那样的话，这个地址就错了。

用C/C++没有办法解决这个问题，可以用内联的汇编来解决。看修改后的NewProc：

static LRESULT CALLBACK NewProc(

HWND hwnd,     // handle to window

UINT uMsg,     // message identifier

WPARAM wParam, // first message parameter

LPARAM lParam ) // second message parameter

{

  // 计算INJDATA 的地址;

  // 在远程进程中，INJDATA刚好在

  //NewProc的前面;

  INJDATA* pData;

  _asm {

    call   dummy

dummy:

    pop   ecx       // <- ECX 中存放当前的EIP

    sub   ecx, 9     // <- ECX 中存放NewProc的地址

    mov   pData, ecx

  }

  pData--;

  //-----------------------------

  // 子类代码

  // ........

  //-----------------------------

  // 调用原来的窗口过程

  return pData->fnCallWindowProc( pData->fnOldProc,

                        hwnd,uMsg,wParam,lParam );

}

这是什么意思？每个进程都有一个特殊的寄存器，这个寄存器指向下一条要执行的指令的内存地址，即32位Intel和AMD处理器上所谓的EIP寄存器。因为EIP是个特殊的寄存器，所以你不能像访问通用寄存器（EAX，EBX等）那样来访问它。换句话说，你找不到一个可以用来寻址EIP并且对它进行读写的操作码（OpCode）。然而，EIP同样可以被JMP，CALL，RET等指令隐含地改变（事实上它一直都在改变）。让我们举例说明32位的Intel和AMD处理器上CALL/RET是如何工作的吧：

当我们用CALL调用一个子程序时，这个子程序的地址被加载进EIP。同时，在EIP被改变之前，它以前的值会被自动压栈（在后来被用作返回指令指针[return instruction-pointer]）。在子程序的最后RET指令自动把这个值从栈中弹出到EIP。

现在我们知道了如何通过CALL和RET来修改EIP的值了，但是如何得到他的当前值？

还记得CALL把EIP的值压栈了吗？所以为了得到EIP的值我们调用了一个“假（dummy）函数”然后弹出栈顶值。看一下编译过的NewProc：

Address   OpCode/Params   Decoded instruction

--------------------------------------------------

:00401000 55     push ebp         ; entry point of

                              ; NewProc

:00401001 8BEC         mov ebp, esp

:00401003 51         push ecx

:00401004 E800000000     call 00401009     ; *a*   call dummy

:00401009 59         pop ecx         ; *b*

:0040100A 83E909       sub ecx, 00000009   ; *c*

:0040100D 894DFC       mov [ebp-04], ecx   ; mov pData, ECX

:00401010 8B45FC       mov eax, [ebp-04]

:00401013 83E814       sub eax, 00000014   ; pData--;

.....

.....

:0040102D 8BE5         mov esp, ebp

:0040102F 5D         pop ebp

:00401030 C21000       ret 0010

a． 一个假的函数调用；仅仅跳到下一条指令并且（译者注：更重要的是）把EIP压栈。

b． 弹出栈顶值到ECX。ECX就保存的EIP的值；这也就是那条“pop ECX”指令的地址。

c． 注意从NewProc的入口点到“pop ECX”指令的“距离”为9字节；因此把ECX减去9就得到的NewProc的地址了。

这样一来，不管被复制到什么地方，NewProc总能正确计算自身的地址了！然而，要注意从NewProc的入口点到“pop ECX”的距离可能会因为你的编译器/链接选项的不同而不同，而且在Release和Degub版本中也是不一样的。但是，不管怎样，你仍然可以在编译期知道这个距离的具体值。

1． 首先，编译你的函数。

2． 在反汇编器（disassembler）中查出正确的距离值。

3． 最后，使用正确的距离值重新编译你的程序。

这也是InjectEx中使用的解决方案。InjectEx和HookInjEx类似，交换开始按钮上的鼠标左右键点击事件。

解决方案2

在远程进程中把INJDATA放在NewProc的前面并不是唯一的解决方案。看一下下面的NewProc：

static LRESULT CALLBACK NewProc(

HWND hwnd,     // handle to window

UINT uMsg,     // message identifier

WPARAM wParam, // first message parameter

LPARAM lParam ) // second message parameter

{

  INJDATA* pData = 0xA0B0C0D0;   // 一个假设

  //-----------------------------

  // 子类代码

  // ........

  //-----------------------------

  // 调用以前的窗口过程

  return pData->fnCallWindowProc( pData->fnOldProc,

                        hwnd,uMsg,wParam,lParam );

}

这里，0XA0B0C0D0仅仅是INJDATA在远程进程中的地址的占位符（placeholder）。你无法在编译期得到这个值，然而你在调用VirtualAllocEx（为INJDATA分配内存时）后确实知道INJDATA的地址！（译者注：就是VirtualAllocEx的返回值）

我们的NewProc编译后大概是这个样子：

Address   OpCode/Params   Decoded instruction

--------------------------------------------------

:00401000 55           push ebp

:00401001 8BEC         mov ebp, esp

:00401003 C745FCD0C0B0A0   mov [ebp-04], A0B0C0D0

:0040100A ...

....

....

:0040102D 8BE5         mov esp, ebp

:0040102F 5D           pop ebp

:00401030 C21000         ret 0010

编译后的机器码应该为：558BECC745FCD0C0B0A0......8BE55DC21000。

现在，你这么做：

1． 把INJDATA，ThreadFunc和NewFunc复制到目的进程。

2． 改变NewPoc的机器码，让pData指向INJDATA的真实地址。

比如，假设INJDATA的的真实地址（VirtualAllocEx的返回值）为0x008a0000，你把NewProc的机器码改为：

558BECC745FCD0C0B0A0......8BE55DC21000

<- 修改前的 NewProc 1

558BECC745FC00008A00......8BE55DC21000

<- 修改后的 NewProc

  也就是说，你把假值 A0B0C0D0改为INJDATA的真实地址2

3． 开始指向远程的ThreadFunc，它子类了远程进程中的控件。

¹ 你可能会问，为什么A0B0C0D0和008a0000在编译后的机器码中为逆序的。这时因为Intel和AMD处理器使用littl-endian标记法（little-endian notation）来表示它们的（多字节）数据。换句话说：一个数的低字节（low-order byte）在内存中被存放在最低位，高字节（high-order byte）存放在最高位。

想像一下，存放在四个字节中的单词“UNIX”，在big-endia系统中被存储为“UNIX”，在little-endian系统中被存储为“XINU”。

² 一些蹩脚的破解者用类似的方法来修改可执行文件的机器码，但是一个程序一旦载入内存，就不能再更改自身的机器码（一个可执行文件的.text段是写保护的）。我们能修改远程进程中的NewProc是因为它所处的那块内存在分配时给予了PAGE_EXECUTE_READWRITE属性。

何时使用CreateRemoteThread和WriteProcessMemory技术

通过CreateRemoteThread和WriteProcessMemory来注入代码的技术，和其他两种方法相比，不需要一个额外的DLL文件，因此更灵活，但也更复杂更危险。一旦你的ThreadFunc中有错误，远程线程会立即崩溃（看附录F）。调试一个远程的ThreadFunc也是场恶梦，所以你应该在仅仅注入若干条指令时才使用这个方法。要注入大量的代码还是使用另外两种方法吧。

再说一次，你可以在文章的开头部分下载到WinSpy，InjectEx和它们的源代码。

最后，我们总结一些目前还没有提到的东西：

方法   适用的操作系统可操作的进程

I. Windows钩子Win9x 和WinNT连接了USER32.DLL的进程

II. CreateRemoteThread & LoadLibrary仅WinNT2所有进程3，包括系统服务4

III. CreateRemoteThread & WriteProcessMemory仅WinNT所有进程，包括系统服务

1． 很明显，你不能给一个没有消息队列的线程挂钩。同样SetWindowsHookEx也对系统服务不起作用（就算它们连接了USER32）。

2． 在Win9x下没有CreateRemoteThread和VirtualAllocEx（事实上可以在9x上模拟它们，但是到目前为止还只是个神话）

3． 所有进程 ＝ 所有的Win32进程 ＋ csrss.exe

本地程序（native application）比如smss.exe, os2ss.exe, autochk.exe，不使用Win32 APIs，也没有连接到kernel32.dll。唯一的例外是csrss.exe，win32子系统自身。它是一个本地程序，但是它的一些库（比如winsrv.dll）需要Win32 DLL包括kernel32.dll.

4.如果你向注入代码到系统服务或csrss.exe，在打开远程进程的句柄（OpenProcess）之前把你的进程的优先级调整为“SeDebugprovilege”(AdjustTokenPrivileges)。

你注入的代码（特别是存在错误时）很容易就会把目的进程拖垮。

远程线程指把当前进程部分代码注入到其他进程做为线程执行，虽然钩子程序能挂钩其他程序的消息，但钩子程序退出，注入的dll也就退出了，而远程线程不会随着本地进程退出而结束。而且可以处理更多的事情，而不局限于消息。由于98不支持所以只能在nt内核上运行。

 

附录

A)   为什么kernel32.dll和user32.dll中是被映射到相同的内存地址？

我的假定：以为微软的程序员认为这么做可以优化速度。让我们来解释一下这是为什么。

一般来说，一个可执行文件包含几个段，其中一个为“.reloc”段。

当链接器生成EXE或DLL时，它假定这个文件会被加载到一个特定的地址，也就是所谓的假定/首选加载/基地址（assumed/preferred load/base address）。内存映像（image）中的所有绝对地址都时基于该“链接器假定加载地址”的。如果由于某些原因，映像没有加载到这个地址，那么PE加载器（PE loader）就不得不修正该映像中的所有绝对地址。这就是“.reloc”段存在的原因：它包含了一个该映像中所有的“链接器假定地址”与真正加载到的地址之间的差异的列表（注意：编译器产生的大部分指令都使用一种相对寻址模式，所以，真正需要重定位[relocation]的地方并没有你想像的那么多）。如果，从另一方面说，加载器可以把映像加载到链接器首选地址，那么“.reloc”段就会被彻底忽略。

但是，因为每一个Win32程序都需要kernel32.dll，大部分需要user32.dll，所以如果总是把它们两个映射到其首选地址，那么加载器就不用修正kernel32.dll和user32.dll中的任何（绝对）地址，加载时间就可以缩短。

让我们用下面的例子来结束这个讨论：

把一个APP.exe的加载地址改为kernel32的（/base:"0x77e80000"）或user32的（/base:"0x77e10000"）首选地址。如果App.exe没有引入UESE32，就强制LoadLibrary。然后编译App.exe，并运行它。你会得到一个错误框（“非法的系统DLL重定位”），App.exe无法被加载。

为什么？当一个进程被创建时，Win2000和WinXP的加载器会检查kernel32.dll和user32.dll是否被映射到它们的首选地址（它们的名称是被硬编码进加载器的），如果没有，就会报错。在WinNT4 中ole32.dll也会被检查。在WinNT3.51或更低版本中，则不会有任何检查，kernel32.dll和user32.dll可以被加载到任何地方。唯一一个总是被加载到首选地址的模块是ntdll.dll，加载器并不检查它，但是如果它不在它的首选地址，进程根本无法创建。

总结一下：在WinNT4或更高版本的操作系统中：

●总被加载到它们的首选地址的DLL有：kernel32.dll，user32.dll和ntdll.dll。

●Win32程序（连同csrss.exe）中一定存在的DLL：kernel32.dll和ntdll.dll。

●所有进程中都存在的dll：ntdll.dll。

B)   /GZ编译开关

在Debug时，/GZ开关默认是打开的。它可以帮你捕捉一些错误（详细内容参考文档）。但是它对我们的可执行文件有什么影响呢？

当/GZ被使用时，编译器会在每个函数，包含函数调用中添加额外的代码（添加到每个函数的最后面）来检查ESP栈指针是否被我们的函数更改过。但是，等等，ThreadFunc中被添加了一个函数调用？这就是通往灾难的道路。因为，被复制到远程进程中的ThreadFunc将调用一个在远程进程中不存在的函数。

C)   static函数和增量连接（Incremental linking）

增量连接可以缩短连接的时间，在增量编译时，每个函数调用都是通过一个额外的JMP指令来实现的（一个例外就是被声明为static的函数！）这些JMP允许连接器移动函数在内存中的位置而不用更新调用该函数的CALL。但是就是这个JMP给我们带来了麻烦：现在ThreadFunc和AfterThreadFunc将指向JMP指令而不是它们的真实代码。所以，当计算ThreadFunc的大小时:

const int cbCodeSize = ((LPBYTE) AfterThreadFunc - (LPBYTE) ThreadFunc);

实际得到的将是指向ThreadFunc和AfterThreadFunc的JMP指令之间的“距离”。现在假设我们的ThreadFunc在004014C0，和其对应的JMP指令在00401020

:00401020   jmp 004014C0

...

:004014C0   push EBP       ; ThreadFunc的真实地址

:004014C1   mov EBP, ESP

...

然后，

WriteProcessMemory( .., &ThreadFunc, cbCodeSize, ..);

将把“JMP 004014C0”和其后的cbCodeSize范围内的代码而不是ThreadFunc复制到远程进程。远程线程首先会执行“JMP 004010C0”，然后一直执行到这个进程代码的最后一条指令（译者注：这当然不是我们想要的结果）。

然而，如果一个函数被声明为static，就算使用增量连接，也不会被替换为JMP指令。这就是为什么我在规则#4中说把ThreadFunc和AfterThreadFunc声明为static或禁止增量连接的原因了。（关于增量连接的其他方面请参看Matt Pietrek写的“Remove Fatty Deposits from Your Applications Using Our 32-bit Liposuction Tools”）

D)   为什么ThreadFunc只能有4K的局部变量？

    局部变量总是保存在栈上的。假设一个函数有256字节的局部变量，当进入该函数时（更确切地说是在functions prologue中），栈指针会被减去256。像下面的函数：

void Dummy(void) {  BYTE var[256];  var[0] = 0;  var[1] = 1;  var[255] = 255;}

会被编译为类似下面的指令：

:00401000   push ebp

:00401001   mov ebp, esp

:00401003   sub esp, 00000100       ; change ESP as storage for

                                    ; local variables is needed

:00401006   mov byte ptr [esp], 00     ; var[0] = 0;

:0040100A   mov byte ptr [esp+01], 01   ; var[1] = 1;

:0040100F   mov byte ptr [esp+FF], FF   ; var[255] = 255;

:00401017   mov esp, ebp           ; restore stack pointer

:00401019   pop ebp

:0040101A   ret

请注意在上面的例子中ESP（栈指针）是如何被改变的。但是如果一个函数有多于4K的局部变量该怎么办？这种情况下，栈指针不会被直接改变，而是通过一个函数调用来正确实现ESP的改变。但是就是这个“函数调用”导致了ThreadFunc的崩溃，因为它在远程进程中的拷贝将会调用一个不存在的函数。

让我们来看看文档关于栈探针（stack probes）和/Gs编译选项的说明：

“/Gssize选项是一个允许你控制栈探针的高级特性。栈探针是编译器插入到每个函数调用中的一系列代码。当被激活时，栈探针将温和地按照存储函数局部变量所需要的空间大小来移动。

如果一个函数需要大于size指定的局部变量空间，它的栈探针将被激活。默认的size为一个页的大小（在80x86上为4k）。这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互，在运行期间向程序栈增加已提交的内存总数。

我能确定你们对上面的叙述（“栈探针将温和地按照存储函数局部变量所需要的空间大小来移动”）感到奇怪。这些编译选项（他们的描述！）有时候真的让人很恼火，特别是当你想真的了解它们是怎么工作的时候。打个比方，如果一个函数需要12kb的空间来存放局部变量，栈上的内存是这样“分配”的

sub   esp, 0x1000   ; 先“分配”4 Kb

test [esp], eax     ; touches memory in order to commit a

              ; new page (if not already committed)

sub   esp, 0x1000   ; “分配”第二个 4 Kb

test [esp], eax     ; ...

sub   esp, 0x1000

test [esp], eax

注意栈指针是如何以4Kb为单位移动的，更重要的是每移动一步后使用test对栈底的处理（more importantly, how the bottom of the stack is "touched" after each step）。这可以确保了在“分配”下一个页之前，包含栈底的页已经被提交。

继续阅读文档的说明：

“每一个新的线程会拥有（receives）自己的栈空间，这包括已经提交的内存和保留的内存。默认情况下每个线程使用1MB的保留内存和一个页大小的以提交内存。如果有必要，系统将从保留内存中提交一个页。”（看MSDN中GreateThread > dwStackSize > “Thread Stack Size”）

..现在为什么文档中说“这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互”也很清楚了。

E)   为什么我要把多于3个case分支的swith分割开来呢？

同样，用例子来说明会简单些：

int Dummy( int arg1 )

{

  int ret =0;

  switch( arg1 ) {

  case 1: ret = 1; break;

  case 2: ret = 2; break;

  case 3: ret = 3; break;

  case 4: ret = 0xA0B0; break;

  }

  return ret;

}

将会被编译为类似下面的代码：

Address   OpCode/Params   Decoded instruction

--------------------------------------------------

                              ; arg1 -> ECX

:00401000 8B4C2404       mov ecx, dword ptr [esp+04]

:00401004 33C0         xor eax, eax   ; EAX = 0

:00401006 49           dec ecx       ; ECX --

:00401007 83F903       cmp ecx, 00000003

:0040100A 771E         ja 0040102A

; JMP to one of the addresses in table <B>***</B>

; note that ECX contains the offset

:0040100C FF248D2C104000   jmp dword ptr [4*ecx+0040102C]

:00401013 B801000000     mov eax, 00000001   ; case 1: eax = 1;

:00401018 C3           ret

:00401019 B802000000     mov eax, 00000002   ; case 2: eax = 2;

:0040101E C3           ret

:0040101F B803000000     mov eax, 00000003   ; case 3: eax = 3;

:00401024 C3           ret

:00401025 B8B0A00000     mov eax, 0000A0B0   ; case 4: eax = 0xA0B0;

:0040102A C3           ret

:0040102B 90           nop

; 地址表 ***

:0040102C 13104000       DWORD 00401013   ; jump to case 1

:00401030 19104000       DWORD 00401019   ; jump to case 2

:00401034 1F104000       DWORD 0040101F   ; jump to case 3

:00401038 25104000       DWORD 00401025   ; jump to case 4

看到switch-case是如何实现的了吗？

它没有去测试每个case分支，而是创建了一个地址表（address table）。我们简单地计算出在地址表中偏移就可以跳到正确的case分支。想想吧，这真是一个进步，假设你有一个50个分支的switch语句，假如没有这个技巧，你不的不执行50次CMP和JMP才能到达最后一个case，而使用地址表，你可以通过一次查表即跳到正确的case。使用算法的时间复杂度来衡量：我们把O（2n）的算法替换成了O(5)的算法，其中：

1．         O代表最坏情况下的时间复杂度。

2．         我们假设计算偏移（即查表）并跳到正确的地址需要5个指令。

现在，你可能认为上面的情况仅仅是因为case常量选择得比较好，（1，2，3，4，5）。幸运的是，现实生活中的大多数例子都可以应用这个方案，只是偏移的计算复杂了一点而已。但是，有两个例外：

●如果少于3个case分支，或

●如果case常量是完全相互无关的。（比如 1， 13， 50， 1000）。

最终的结果和你使用普通的if-else if是一样的。

有趣的地方：如果你曾经为case后面只能跟常量而迷惑的话，现在你应该知道为什么了吧。这个值必须在编译期间就确定下来，这样才能创建地址表。

回到我们的问题！

注意到0040100C处的JMP指令了吗？我们来看看Intel的文档对十六进制操作码FF的说明：

Opcode   Instruction   Description

FF /4   JMP r/m32     Jump near, absolute indirect,

                address given in r/m32

JMP使用了绝对地址！也就是说，它的其中一个操作数（在这里是0040102C）代表一个绝对地址。还用多说吗？现在远程的ThreadFunc会盲目第在地址表中004101C然后跳到这个错误的地方，马上使远程进程挂掉了。

F)   到底是什么原因使远程进程崩溃了？

如果你的远程进程崩溃了，原因可能为下列之一：

1．         你引用了ThreadFunc中一个不存在的字符串。

2．         ThreadFunc中一个或多个指令使用了绝对寻址（看附录E中的例子）

3．         ThreadFunc调用了一个不存在的函数（这个函数调用可能是编译器或连接器添加的）。这时候你需要在反汇编器中寻找类似下面的代码：

:004014C0   push EBP       ; entry point of ThreadFunc

:004014C1   mov EBP, ESP

...

:004014C5   call 0041550   ; 在这里崩溃了

                    ; remote process

...

:00401502   ret

如果这个有争议的CALL是编译器添加的（因为一些不该打开的编译开关比如/GZ打开了），它要么在ThreadFunc的开头要么在ThreadFunc接近结尾的地方

不管在什么情况下，你使用CreateRemoteThread & WriteProcessMemory技术时必须万分的小心，特别是编译器/连接器的设置，它们很可能会给你的ThreadFunc添加一些带来麻烦的东西。

 

下面是制作远程线程需要使用的api；

FindWindow函数返回与指定字符创相匹配的窗口类名或窗口名的最顶层窗口的窗口句柄。这个函数不会查找子窗口。

　　函数原型：

　　HWND FindWindow(LPCTSTR lpClassName,LPCTSTR lpWindowName );

　　参数表：

lpClassName：

指向一个以null结尾的、用来指定类名的字符串或一个可以确定类名字符串的原子。如果这个参数是一个原子，那么它必须是一个在调用此函数前已经通过

GlobalAddAtom函数创建好的全局原子。这个原子（一个16bit的值），必须被放置在lpClassName的低位字节中，lpClassName的高位字节置零。

lpWindowName：

指向一个以null结尾的、用来指定窗口名（即窗口标题）的字符串。如果此参数为NULL，则匹配所有窗口名。

返回值：

如果函数执行成功，则返回值是拥有指定窗口类名或窗口名的窗口的句柄。如果函数执行失败，则返回值为 NULL 。可以通过调用GetLastError函数获得更加详细的错误信息。

GetWindowThreadProcessId 函数:该函数用于获取创建指定窗口的线程标识和创建窗口的进程标识符，后一项是可选的。

函数原型

DWORD GetWindowThreadProcessId(HWND hWnd, LPDWORD lpdwProcessId);

参数

hWnd: 窗口的句柄。

lpdwProcessId 

接收进程标识的 32 位整型变量的指针(pid)。如果这个参数不为 NULL ，GetWindowThreadProcessId 函数将进程标识拷贝到指针对应的 32 位变量中，否则不拷贝。

返回值: 返回值为创建窗口的线程标识。

得到进程id 之后，可以使用 OpenProcess函数来获得进程句柄

HANDLE OpenProcess(DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD dwProcessId);

dwDesiredAccess参数: 对打开的进程的访问权限，可以是下列值的组合：

process_all_access-----------等于下面所有权限的组合

process_create_thread-------允许创建远程线程

process_dup_handle---------允许进程句柄被复制

process_query_information--允许使用getexitcodeprocess函数查询和getprorityclass 查询进程信息

process_set_information-----允许使用setpriorityclass函数设置进程的优先级

process_terminate-----------允许结束进程

process_vm_operation-------允许使用writeprocessmemory函数或者virtualprotectex来修改进程的地址空间

process_vm_read------------允许对读取进程地址空间

process_vm_write------------允许使用写入进程地址空间

bInheritHandl参数: 指定返回的进程句柄是否可以被当前进程的子进程继承

dwProcessId 参数: 指定目标进程的进程id

//还有一种方法是使用CreateToolhelp32Snapshot 函数(快照)函数来获得进程句柄，上面的方法进程必须要有窗口，而快照函数不需要进程拥有窗口.

下面是读写进程数据的两个api函数：

BOOL ReadProcessMemory(HANDLE hProcess, LPCVOID lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize, SIZE_T* lpNumberOfBytesRead);

handle hprocess, // 进程句柄

lpcvoid lpbaseaddress, // 要读取的目标进程起始内存

lpvoid lpbuffer, // 本地进程用来存放读取内容的数据缓冲区

size_t nsize, // 要从目标进程读取得数据长度

size_t * lpnumberofbytesread // 要读出的到本地的数量，为null则忽略这个参数

 

BOOL WriteProcessMemory(HANDLE hProcess, LPVOID lpBaseAddress, LPCVOID lpBuffer, SIZE_T nSize, SIZE_T* lpNumberOfBytesWritten);

handle hprocess, // 进程句柄

lpvoid lpbaseaddress, // base of memory area

lpvoid lpbuffer, // data buffer

size_t nsize, // count of bytes to write

size_t * lpnumberofbyteswritten // count of bytes written

要注入远程线程，必须要在目标进程中开辟一段空间，来存放远程线程代码。

LPVOID VirtualAllocEx(HANDLE hProcess, LPVOID lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect);

handle hprocess, // 要开辟内存的进程

lpvoid lpaddress, // 从进程那个地址开始分配，为null,则系统决定

size_t dwsize, // 要分配的空间大小

dword flallocationtype, // 分配的类型，一般用 mem_commit即可

dword flprotect // 这段内存访问的权限，page_execute_readwrite,远程线程所处空间必须可读可执行

 

下面是注入远程线程的需要使用的函数：

HANDLE CreateRemoteThread(

HANDLE hProcess, // 要写入远程线程进程句柄

LPSECURITY_ATTRIBUTES lpThreadAttributes, // 线程安全属性

SIZE_T dwStackSize,// 初始化堆栈大小

LPTHREAD_START_ROUTINE lpStartAddress,// 远程线程函数

LPVOID lpParameter,// 标志，可以创建挂起的线程等等

DWORD dwCreationFlags, // 标志，可以创建挂起的线程等等

LPDWORD lpThreadId  // 用来返回线程id的指针

);

 

代码重定位：

有了这些函数就可以把一段代码插入到目标进程，这段代码将作为目标进程中一个独立的线程运行。但是代码编译时，全局变量、api函数等等，将被编译为地址形，这些地址对于本地进程是可读可执行的，对于目标进程，读取这些地址是非法的，windows这样做，可以保证每个进程都拥有自己独立的4gb空间，而不互相干扰（处于ring3的进程互相访问是非法的）。对于所有的高级语言，包括c语言，根本不能解决重定位问题，程序只能先写一个dll文件，然后用 CreateRemoteThread把LoadLibrary 函数注入到目标进程中。LoadLibrary 函数调用DLL文件，执行自己想要的功能，不过这样用一些进程工具可以看到目标进程多了一个dll。

重定位是汇编语的拿手好戏:

call @f

@@:

pop ebx

sub ebx,offset @b

现在 ebx 即得到了代码的实际地址和汇编地址之间的偏差，所以在需要重定位的代码上加上这个偏移值即可。