我吃你家米了 - 外文翻译

WindowsInternal--APC

2025-10-29T00:00:00+01:00

reference:

http://www.opening-windows.com/download/apcinternals/2009-05/windows_vista_apc_internals.pdf

本文附带的测试驱动文件

APC基本概念

APC可以使得一个线程从原先的执行流转而去执行我们指定的另一块代码

APC最重要的东西是他是针对一个特定的线程的

APC的文档很少，内核APC对他们的使用并不是公开的，而且他们内部的工作原理也只有很少一部分被外界知悉

APC之所以令我们感兴趣是因为他和windows的线程分发是密切相关的，通过分析他们我们可以更好地了解这个Windows核心特性

Widows Internal相关的书籍总是提及说APC是通过各种软件中断来被调度的

这就引起我们的一个疑问，系统是如何保证这个中断是发生在特定的线程上下文中的

这个其实就是APC的终极目标，软件中断可以中断到当前线程上下文中，而当前线程到底是哪一个是随机的

通过APC执行的代码，根据APC类型的不同，可以运行在特定的IRQL等级中，这个等级就叫做APC level

那么说了半天，APC到底是干啥的：

IO管理器使用APC来在发起该IO操作的线程上下文中完成IO操作
special APC将会在一个进程必须要terminate的时候进入到其执行流中
内核APC的实现隐藏在诸如QueueUserAPC和ReadFileEx/WriteFileEx这种Windows API函数中

APC进程上下文

通常情况下，Windows线程执行在创建了自己的那个进程的上下文中，尽管如此，线程也有一个将自己附着在另一个进程中，也就是说在另一个进程的上下文中执行（什么情况下会这样，我怎么没听说过）

Windows在管理APC的时候考虑到了这种情况，APC可能会被调度到拥有该线程的进程上下文中，也有可能被调度到当前线程所附着到的进程的上下文中

Windows通过_KAPC_STATE结构体来维护所有等待执行的APC的状态：

kd>  dt nt!_kapc_state
   +0x000 ApcListHead      : [2] _LIST_ENTRY
   +0x010 Process          : Ptr32 _KPROCESS
   +0x014 KernelApcInProgress : UChar
   +0x015 KernelApcPending : UChar
   +0x016 UserApcPending   : UChar

_KTHREAD结构体中有两个类型为_KAPC_STATE的字段，一个是ApcState，另一个是SavedApcState，他们被称作APC环境

ApcState是当前线程中的APC环境，不管这个线程是在自己的进程还是别的进程上下文中，这个字段中保存着可以被交付的APC

SavedApcState字段存储的是当前上下文暂时不可用，必须等待的APC

举例来说，如果线程附着到别的进程中，此时有针对当前线程的APC，那么这些APC就会被保存到SavedApcState中，他们会等待当前线程从其他进程上下文中剥离出来

根据上面的解释，我们可以理解当一个线程attach自己到另外一个进程的时候，ApcState会被拷贝到SavedApcState中，并被重新初始化

当线程脱离的时候，ApcState将会从SavedApcState字段中恢复，SavedApcState会被清空

同时，我们可以看到负责分发APC的内核模块总是查看ApcState来搜索可以传递的APC

_KTHREAD结构体中有一个数组，这个数组只有两个元素，其实就是两个指针，一个指向当前_KTHREAD的ApcState字段，另一个指向SavedApcState字段，其中[0]号指针总是指向线程所属的进程环境，[1]号指针总是指向当前线程附着到的进程环境

举例来说，如果当前线程没有附着在其他进程，当前线程所属的进程的环境处于活跃状态，那么这个环境信息会被保存到ApcState字段，然后ApcStatePointer[0]保存ApcState的地址

如果当前线程附着到了其他的进程，那么当前线程所属的进程环境会被保存到SavedApcState中，ApcStatePointer[0]指向SavedApcState地址

最后，_KTHREAD.ApcStateIndex存储着AcpStatePinter数组的index，这个index永远指向当前线程所处的进程的环境，也就是说在上面的例子中，第一种情况下，ApcStateIndex=0，第二种情况下，ApcStateIndex=1

当我们schedule一个APC的时候，我们可以指定将其添加到线程所属进程的环境中（ApcStatePointer[ApcStateIndex]）还是当前处于活跃状态的环境中（ApcState）

APC类型

APC有三种类型

SpecialKernelModeApc，简称SKApc，这种APC运行在APC IRQL下，他是正儿八经的异步事件，他会将线程从原本的执行流改到内核模式的代码中去执行，这段代码叫做KernelRoutine

如果SKAPC被插入到线程队列中，如果该线程进入了等待状态，线程可以通过以下4个APC调用进入等待状态

KeWaitForSingleObject
KeWaitForMultipleObjects
KeWaitForMutexObject
KeDelayExecutionThread

此时线程就会被唤醒，然后执行KernelRoutine，之后重新进入等待状态

通常情况下，SKAPC会在目标线程IRQL降低至APC level（IRQL=1）时被尽快传递给目标线程，尽管如此，APC传递可以被线程禁用

当_KTHREAD的SpecilaApcDisable成员被设置为非0值时，APC的传递将会被彻底禁用

第二种APC类型是普通内核APC，regular kernel APC

简称RKAPC，这种APC运行在PASSIVE IRQL（IRQL=0），和SKAPC一样，他们会打破线程原有的执行流，将线程从等待状态唤醒从而执行APC中的代码，尽管如此，RKAPC的执行拥有更多的限制条件，后面我们会再讨论到这个东西

第三种是用户模式APC，简称UMAPC，这种APC的运行存在更多的限制

只在线程进入alertable状态时被分发，在线程调用以下四个API的时候会进入到alertable状态：

KeWaitForSingleObject
KeWaitForMultipleObjects
KeWaitForMutexObject
KeDelayExecutionThread

调用这四个API的时候需要指定Alertable参数为true，指定WaitMode参数为User

因此，正常情况下，UMAPC不会异步地进入到线程的执行流中，他们更像是一个可以被队列的workitem，他们可以在任意时间被插入到一个线程中，由线程代码决定什么时候来处理他们

APC初始化

APC由_KAPC结构体代表

kd> dt nt!_KAPC
   +0x000 Type             : UChar
   +0x001 SpareByte0       : UChar
   +0x002 Size             : UChar
   +0x003 SpareByte1       : UChar
   +0x004 SpareLong0       : Uint4B
   +0x008 Thread           : Ptr32 _KTHREAD
   +0x00c ApcListEntry     : _LIST_ENTRY
   +0x014 KernelRoutine    : Ptr32     void 
   +0x018 RundownRoutine   : Ptr32     void 
   +0x01c NormalRoutine    : Ptr32     void 
   +0x020 NormalContext    : Ptr32 Void
   +0x024 SystemArgument1  : Ptr32 Void
   +0x028 SystemArgument2  : Ptr32 Void
   +0x02c ApcStateIndex    : Char
   +0x02d ApcMode          : Char
   +0x02e Inserted         : UChar

_KAPC结构体由KeInitializeApc函数初始化，函数签名如下（undocumented）

NTKERNELAPI VOID KeInitializeApc (
IN PRKAPC Apc,
IN PKTHREAD Thread,
IN KAPC_ENVIRONMENT Environment,
IN PKKERNEL_ROUTINE KernelRoutine,
IN PKRUNDOWN_ROUTINE RundownRoutine OPTIONAL,
IN PKNORMAL_ROUTINE NormalRoutine OPTIONAL,
IN KPROCESSOR_MODE ApcMode,
IN PVOID NormalContext
);

KeInitializeApc并不会schedule APC，而只是填充_KAPC结构体的一部分字段，要想真正的schedule一个APC，还有更多的步骤要做

KeInitilizeApc会将_KAPC的Type字段设置为一个常量0x12，将当前结构体标识为一个APC对象，并设置Size字段

线程字段Thread会被设置为该函数的第二个参数的值，即_KTHREAD指针

KeInitializeApc函数并不会设置ApcListEntry字段，它会在APC真正被调度的时候被用到，它用于把当前APC链接到目标线程所有的处于等待状态的APC中

KernelRoutine字段，由函数中的KernelRoutine参数来进行设置，这个函数是APC真正会执行的代码，每一个APC都有一个KernelRoutine，根据APC的类型，还可能会有一个NornalRoutine

由KernelRoutine字段指向的函数将会在APC IRQL下被调用

NormalRoutine和ApcMode参数决定了APC的类型

如果NormalRoutine为0，那么这就是一个SKAPC

对于这种类型的APC，KeInitializeApc将会设置_KAPC.ApcMode为0，表示内核模式，并将_KAPC.NormalContext设置为0，对应的函数参数将会被忽略，也就是说如果你调用KeInitializeApc函数的时候，将NormalRoutine参数设为0，那么即使你提供了一个NormalContext也会被该函数忽略掉

如果NormalRoutine不为0且ApcMode为0，那么这就是一个RKAPC，_KAPC.ApcMode和_KAPC.NormalContext将根据函数参数进行设置

RKAPC也是执行内核代码的，因为ApcMode=0表示内核模式，但是他的特权比SKAPC要低，也就意味着他必须要在某些限制下被执行，后面会讲

NormalRoutine将会被存储到_KAPC对应的字段中，他将会在APC被传达的时候被执行

RKAPC被传达的时候，首先执行的就是KernelRoutine，在APC IRQL（IRQL=1），随后NormalRoutine会在PASSIVE IRQL（IRQL=0）下被执行，这两个Routine都是在内核模式下执行的

正如我们随后将会看到的那样，KernelRoutine有机会在NormalRoutine真正执行之前阻止NormalRoutine的执行，并且可以把NormalRoutine的地址修改掉

如果NormalRoutine不为0且ApcMode为1，那么这就是一个UMAPC，那么NormalRoutine就会在用户模式下执行

对于用户模式的APC，KeInitializeApc会将_KAPC.ApcMode和_KAPC.NormalContext设置为函数参数指定的值

NormalContext参数会被同时传送给KernelRoutine和NnormalRoutine

SystemArgument1和2不会由KeInitializeApc来设置，而是在APC被调度时他们会被传递给回调routine，我们后面将会看到更多相关的细节

Environment参数，_KAPC.ApcStateIndex决定了APC的环境，会在后面作为ApcStatePointer数组的index来选定用于存储APC状态的_KAPC_STATE的地址，如果这个字段的值为2，那么它将会被设置为KeInitializeApc函数的第二个参数，即KTHREAD的ApcStateIndex的值，由于KTHREAD的ApcStateIndex字段总是指向ApcStatePointer数组中保存当前进程环境的指针的index，也就意味着这个APC会在任意环境下被调度

最后Inserted字段被设置为0以表示当前APC还未被插入到线程中，KeInsertQueueApc负责调度APC，该函数会将该字段设置为1

初始APC调度

所有类型的APC都是由KeInsertQueueApc来插入到队列中的，对于所有的APC来说，该函数的操作都是一样的

这个函数接收4个参数

指向_KAPC的指针
两个用户自定义的参数，SystemArgument1和2
一个优先级增量

KeInsertQueueApc首先会请求一个自旋锁，这个锁存储在_KTHREAD中，然后将IRQL提升至0x1B，这样一来，他的后续操作就只能被时钟和IPI（IPI (Inter-Processor Interrupt) is a special interrupt used in multiprocessor (SMP) systems）打断

然后他会查看_THREAD的0xB8偏移，这个位置是一个1字节的flag位，他会检查第六个bit（从0开始数就是position 5）是否设置，即ApcQueueable是否被set，否则他将会立即终止并返回0

   +0x0b8 AutoAlignment    : Pos 0, 1 Bit
   +0x0b8 DisableBoost     : Pos 1, 1 Bit
   +0x0b8 EtwStackTraceApc1Inserted : Pos 2, 1 Bit
   +0x0b8 EtwStackTraceApc2Inserted : Pos 3, 1 Bit
   +0x0b8 CalloutActive    : Pos 4, 1 Bit
   +0x0b8 ApcQueueable     : Pos 5, 1 Bit
   +0x0b8 EnableStackSwap  : Pos 6, 1 Bit
   +0x0b8 GuiThread        : Pos 7, 1 Bit
   +0x0b8 UmsPerformingSyscall : Pos 8, 1 Bit
   +0x0b8 VdmSafe          : Pos 9, 1 Bit
   +0x0b8 UmsDispatched    : Pos 10, 1 Bit
   +0x0b8 ReservedFlags    : Pos 11, 21 Bits
   +0x0b8 ThreadFlags      : Int4B

然后KeInsertQueueApc会检查输入的_KAPC的Inserted字段是否被设置为1，如果为1，则返回FALSE（已经被插入了）

如果上面这两个检查都通过了的话，那么APC就会被按照如下步骤被调度

该函数首先会拷贝输入的SystemArgument1和2到_KAPC结构体的对应字段中，这些值将会被传递到APC回调Routine从而提供了一种给APC提供了上下文信息的通道，和NormalContext所不同的是他们的赋值时机，NormalContext是在APC初始化阶段就被赋值了的

之后，该函数会将_KAPC.Insereted设为1并调用nt!KiInsertQueueApc函数，其第二个参数将会被设置为优先级增量，第一个参数被设置为_KAP

nt!KiInsertQueueApc负责了APC调度的实际工作，这个函数后面会被我们再次提及

SKAPC和RKAPC

调度

由KiInsertQueueApc负责的调度可以被分为两大步骤：

将_KAPC连接到等待中的APC
更新目标线程的控制变量，从而使得线程可以转而去处理等待中的APC

链接`_KAPC`到链表

KiInsertQueueApc首先检查_KAPC.ApcStateIndex，到这里我们知道当KeInitializeApc被调用的时候，这个字段已经通过Environment参数设置过了，值2是一个pseudo-value，它的效果是设置环境为当前可用环境，不管是线程所属进程环境还是所处进程环境

KiInsertQueueApc允许另一个pseudo-value 3，这个值拥有和2类似的效果，如果ApcStateIndex值为3，那么它将会被替换为_KTHREAD.ApcStateIndex的值

因此2意味着KeInitializeApc被调用时的环境，3意味着KiInsertQueueApc被调用时所处的环境

_KAPC.ApcStateIndex的最终值被用于选择_KAPC将会被链接到的环境

KiInsertQueueApc访问目标线程的_KTHREAD的0x168偏移，即ApcStatePointer数组，由ApcStateIndex决定选择0号_KAPC_STATE还是1号，之后_KAPC将会被链接到上面选择的_KAPC_STATE中

kd> dt nt!_KAPC_STATE
   +0x000 ApcListHead      : [2] _LIST_ENTRY
   +0x010 Process          : Ptr32 _KPROCESS
   +0x014 KernelApcInProgress : UChar
   +0x015 KernelApcPending : UChar
   +0x016 UserApcPending   : UChar

ApcListHead数组包含了两个链表的Head，一个是kernelmode另一个是usermode，KiInsertQueueApc使用_KAPC.ApcMode作为该数组的index，也就是说ApcListHead[0]表示内核APC，[1]表示用户APC

内核模式的APC链表被SKAPC和RKAPC共用，SKAPC会被链接到RKAPC前面，如果里面已经有了SKAPC，那么新的SKAPC会连接到他后面（仍然位于RKAPC前面）

命令线程去执行APC

本节我们将会讲解目标线程是如何从原来的执行流转而执行APC代码的，此时就会用到APC软件中断，正如我们即将看到的，这个中断只会用在特殊的场景下，控制变量也会被用到

处理过程的第一步就是检查由_KAPC.ApcStateIndex所指示的APC环境是否和当前环境一致

如果不一致，那么这个函数会直接返回，这个动作看起来非常有趣，一方面，他很合理，只要目标线程还附着在其他的进程环境中，他就无法处理APC，另一方面，这也意味着负责将线程切换到其他进程环境中的代码需要检查链表中的APC并尝试让线程去执行他们

这是众多APC interrupt不会被使用的场景之一

这个逻辑意味着内核模式的APC，即使是SKAPC，会一直处于等待状态，直到当前进程环境和_KAPC所指定的保持一致

如果环境一致，KiInsertQueueApc会继续检查APC是否是针对当前正在执行的线程的

当前线程的内核APC

在这种情况下，KiInsertQueueApc将目标_KTHREAD的ApcState的KernelApcPending字段设为1

ApcState字段存储了APC环境信息，由于我们已经决定了我们的APC是活动环境，我们直接从ApcState访问控制变量而不是从KTHREAD的ApcStatePointer来访问

KernelApcPending是一个非常重要的Flag，他在进入线程执行流的过程中扮演着非常重要的角色

SepcialApcDisable标志

如果这个标志位处于set状态，KiInsertQueueApc会检查_KTHREAD.SpecialApcDisable

+0x086 SpecialApcDisable : Int2B

如果他不为0，那么KiInsertQueueApc会直接返回

这就意味着SpecialApcDisable可以禁用所有类型的内核APC，包括SKAPC

APC是什么时候被分发的呢？一部分答案可以从nt!SwapContext函数中找到

这个函数用于加载一个线程的上下文，在他被选择运行和检查KernelApcPending标志位的时候，如果他是set状态，且SpecialApcDisable为0，那么他就会触发APC的分发

我们后面将会看到更多细节，现在我们暂且先记住一件事，那就是KernelApcPending的set状态会确保APC在线程下次被调度以运行的时候被分发（且此时SpecialApcDisable为0）

KiCheckForKernelApcDelivery会触发当前线程的内核APC的delivery，如果IRQL是PASSIVE，这个函数会将其升高至APC level并调用KiDeliverApc函数，这个函数负责deliver APC

否则他将会设置_KTHREAD.ApcState.KernelApcPending为1然后请求一个APC interrupt，这个中断将会在IRQL降低至APC level以下的时候调用KiDeliverApc，后面我们会讲到这个中断的细节

APC中断

回到KiInsertQueueApc函数中，我们已经分析了如果_KTHREAD.SpecialApcDisable非0时会发生什么，如果他是0，该函数会通过调用hal!HalRequestSoftwareInterrupt函数来请求一个APC软件中断，然后退出

在探索这个中断的效果之前，我们先记下来一件事情，那就是KiInsertQueueApc函数对APC所进行的操作是针对当前线程的

因此对于RKAPC的限制，也就是只有在特殊条件下才会被分发，也实现到了KiDeliverApc函数中，我们后面将会看到

APC中断不能在现在立刻处理，因为在KiInsertQueueApc内部，IRQL已经被升高到了0x1b，但是最终在IRQL被降低的时候会被处理，此时KiDeliverApc会被调用

这就让我们引出一个问题，在中断请求和中断处理中间这段时间，时钟仍然会继续中断处理器，由于时钟的IRQL是0x1c，比当前的0x1b要高

该中断的处理程序可以检测当前线程的时间片（quantum）已到期，并请求触发一个 DPC（延迟过程调用）软件中断，以调用线程调度器。

在这种情况下，当IRQL被降低至PASSIVE等级的时候，还有两个软件中断，一个是DPC，一个是APC，前者的IRQL等级更高，因此会先执行

所以线程调度器被执行，他可能会选择一个别的线程来运行，最终IRQL会降低到PASSIVE，APC中断会被处理，但是在错误的线程上下文中，尽管如此，还有两个处理APC的步骤可以挽救这个错误

第一个是APC分发器，KiDeliverApc函数，最终会被APC中断所调用，并允许其发现当前没有APC在列表中，如果是这种情况，他会直接返回，因此在错误的线程中执行并不会引发任何问题

尽管如此，我们可能会想我们存在失去正确线程的APC的风险，因为中断已经处理完了，但是事实并不是这样的，由于KerneApcPending标志位仍然处于set状态，并且SwapContext会查看原始线程并给予他再次运行的机会，重新触发KiDeliverApc函数

APC中断真的会break into到错误的线程中吗

测试代码

我专门为这篇文章写了一个测试驱动，确认了上面讲到的情况确实是有可能发生的，这个测试的测试函数是ApcSpuriousIntTest

这个函数在SwapContext函数的KiDeliverApc函数安装了一个hook，来追踪这两个函数什么时候被调用，以及调用时的一些数据，然后他会升高IRQL到DISPATCH level(IRQL=2，比APC level高一级)，调度APC并浪费时间来等待DISPATCH中断被请求，之后将IRQL降低到PASSIVE，此时APC和DPC都可以被处理，这个驱动会向调试器控制台打印trace信息

下面是我捕捉的一个trace信息

ffffd0823e0a5080是我们降低IRQL之前的线程，我们在将irql降低至passive之后，执行流就会被swapcontext抢占，因为此时存在dpc中断，swapcontext会进行线程调度，从trace中可以看到即使是kernelapcpending为1，如果不是将要切换到ffffd0823e0a5080线程，kideliverapc也不会deliver apc，直到new thread是ffffd0823e0a5080的时候，kideliverapc才会真正的deliver apc，证据就是在kideliverapc trace后面就是我们一开始插入的kernelapc的ApcKernelRoutineSIT的trace打印

另外我们还可以注意到的一点就是，我们在降低irql之后，此时是同时存在dpc和apc中断的，你可以看到swapcontext trace之后就是kideliverapc trace，因为dpc中断处理完了，就是处理apc中断，但是此时新线程并不是ffffd0823e0a5080，即非目标线程，所以他是不会deliver apc的

针对其他线程的kernel apc

在这种情况下，kiinsertqueueapc函数需要另外一个用于保护KPRCB的自旋锁

该函数会检查目标线程的状态，_kthread的state字段存储了线程状态信息，一共有以下几种状态

ready 1
running 2
wait 5
deferredready 7
gatewait 另一种等待状态

运行状态的thread

如果线程状态是running，那么他肯定是运行在另一个处理器上的，因为我们已经确定他是另一个线程了，而当前处理器正在运行当前线程（kiinsertqueueapc），如果另一个线程还处于running状态，那么只有一种可能，那就是他运行在另一个处理器中

那么就会产生一个IPI中断（interprocessor interrupt）（处理器间中断），这个中断会被发送到目标线程所在的处理器，从而触发针对目标线程的APC中断

线程处于等待状态

在某些特定条件下，kiinsertqueueapc会唤醒目标线程并执行apc

kthread的waitirql字段保存了他处于运行状态时的irql

如果kiinsertqueueapc发现目标线程的waitirql不为0，就会退出，（为甚么会退出，这两者有什么逻辑关系吗？）

这就让我们对这个字段开始感兴趣了，当一个线程进入到一个等待状态，这个字段记录运行时的irql，即转换到wait状态前的irql等级

这个观点可以由对kewaitforsingleobject函数的分析来确认，该函数会将当前irql存储到这个字段中

因此，kiinsertqueueapc背后的逻辑很简单，如果线程没有运行在passive等级，那么apc中断就无法触发，因为apc中断等级是1，如果线程不是运行在passive等级，即irql=0的等级，那至少就是运行在irql=1等级，apc中断也是1，那么就无法抢占目标线程的执行流，这也是为什么前面kiinsertqueueapc在发现waitirql不为0就会退出的原因

另外还有一点需要注意的是，处于等待状态的线程的waitirql其实只可能是两个值，要么0要么1，因为高于apc的线程是无法被调度的，dpc等级也就只有2而已

和往常一样，kernelapcpending字段被设置，来保证当时机合适时，apc将会最终被delivered

如果线程确实是在passive等级下等待，那么kiinsertqueueapc会检查specialapcdisable字段，如果该字段不为0，他会直接退出，不会尝试唤醒线程

如果apc是启用状态，且是一个SKAPC，那么kiinsertqueueapc函数会唤醒目标线程，该线程会由swapcontext直接唤醒并派遣apc

如果这是一个RKAPC（regular kernel apc），那么将会进行两个额外的检查

首先，如果kernelapcdisable不为0，kiinsertqueueapc会直接退出，不会唤醒目标线程，因此kernelapcdisable和specialapcdisable字段的作用类似，只不过他是针对RKAPC的

第二个检查是针对apcstate字段的kernelapcinprogress字段的，如果该字段不为0，那么kiinsertqueueapc就会退出

nt!_KAPC_STATE
   +0x000 ApcListHead      : [2] _LIST_ENTRY
   +0x020 Process          : Ptr64 _KPROCESS
   +0x028 InProgressFlags  : UChar
   +0x028 KernelApcInProgress : Pos 0, 1 Bit
   +0x028 SpecialApcInProgress : Pos 1, 1 Bit
   +0x029 KernelApcPending : UChar
   +0x02a UserApcPendingAll : UChar
   +0x02a SpecialUserApcPending : Pos 0, 1 Bit
   +0x02a UserApcPending   : Pos 1, 1 Bit

我们将会看到在kideliverapc函数中，他会设置kernelapcinprogress标志位，在调用RKAPC的normal routine之前

这个检测意味着如果线程进入等待状态，在处理RKAPC的过程中进入等待状态，那么我们可以保证它不会被其他的RKAPC所劫持，换句话说，RKAPC不会套娃（nested）

我们在前面已经看到过，当APC是针对当前线程的时候，kideliverapc会被调用，不管是什么类型的APC，不管是RKAPC还是SKAPC

线程唤醒和kiunwaitthread

其实在我的最新版本上的win11上面已经不存在这个函数了，win11上的是kitryunwaitthread

如果kiinsertqueueapc决定唤醒线程，他会通过调用kiunwaitthread函数来完成，这个向我们展示了一个有趣的信息

DDK文档表明当一个等待线程被派遣，来处理一个内核APC的时候，处理完成后他会重新进入等待状态，也就是说这个线程不会在处理完apc之后从kewaitfor...函数中返回，从另一方面来讲，ddk也说明了一个等待线程被派遣用于处理一个用户模式的apc的时候将会从wait函数中返回，返回值是status_user_apc

这个在微软文档中确实可以看到

status_kernel_apc定义为0x100

kiunwaitthread的edx决定了目标线程在处理完apc之后是否应该从wait函数中返回，如果是status_user_apc，那么等待函数就会返回，如果是status_kernel_apc，那么在处理完apc之后会重新恢复为等待状态，即调用者永远都不会看到这个返回值，这也是为什么status_kernel_apc并未被documented

kiunwaitthread的另一个传入参数是优先级增量，这个参数来自于kiinsertqueueapc的caller给他传进来的，有趣的是，如果kiinsertqueueapc必须要自旋来等待同步锁的时候，这个值会会在每次迭代的时候增加1，意味着优先级会一直上升，来补偿在自旋中损失的时间

唤醒目标线程之后，kiinsertqueueapc会释放自旋锁并退出

针对gatewait状态下的thread

gatewait状态的值是8，是另一种类型的等待状态

对于这种线程，kiinsertqueueapc首先会同步threadlock字段

nt!_KTHREAD
   +0x040 ThreadLock : Uint8B

这个锁的用法跟自旋锁很像，只不过不会真的调用正常的自旋锁函数，处理器会在一个循环中自旋直到成功修改他的值

在拥有锁之后，kiinsertqueueapc会检查线程状态是否仍然为gatewait，如果改变了，就释放所有锁并退出，这是正常的，因为对于kiinsertqueueapc来说，除了running、wait和gatewait状态，kiinsertqueueapc什么都不会做，只会设置一个kernelapcpending标志

这意味着threadlock保护了线程状态，函数改变状态，只会在获取到锁之后

之后，kiinsertqueueapc会进行常规检查，和waiting状态的函数一样，waitirql必须是pasive（0），specialapcdisable必须为0，以及kernelapcdisable和kerneapcinprogress

如果这些检查都通过了，kiinsertqueueapc会执行unwait线程的操作

然后将这个线程从一个链表中解脱出来，这个链表被连接在waitblock[0]字段中，然后将其状态修改改为deferredready状态，就像kiunwaitthread对等待线程所作的那样

0: kd> dt _kthread waitblock
nt!_KTHREAD
   +0x140 WaitBlock : [4] _KWAIT_BLOCK
0: kd> dt _KWAIT_BLOCK
nt!_KWAIT_BLOCK
   +0x000 WaitListEntry    : _LIST_ENTRY
   +0x010 WaitType         : UChar
   +0x011 BlockState       : UChar
   +0x012 WaitKey          : Uint2B
   +0x014 SpareLong        : Int4B
   +0x018 Thread           : Ptr64 _KTHREAD
   +0x018 NotificationQueue : Ptr64 _KQUEUE
   +0x018 Dpc              : Ptr64 _KDPC
   +0x020 Object           : Ptr64 Void
   +0x028 SparePtr         : Ptr64 Void

kiinsertqueueapc也会这是watistatus字段为0x100，

kiinsertqueueapc会将线程链接到一个由deferredreadylisthead指向的链表中，这个东西在kprcb结构体中

nt!_KPRCB
   +0x2d08 DeferredReadyListHead : _SINGLE_LIST_ENTRY

针对kireadythread和kideferredreadythread函数的分析证明了deferredready是一个状态，这个状态的含义是，一个线程准备运行了，在选择在哪个处理器上运行本线程之前，线程将会从deferredready状态切换到ready状态，如果选择的那个处理器正忙于运行其他的线程，或者会切换到standby状态，如果目标处理器可以立刻开始执行本线程

因此kiunwaitthread和kiinsertqueueapc会开启相同的转换，这个转换会导致线程成为running状态并开始处理他的apc

wait VS gatewait

有趣的是比较kiunwaitthread的步骤在wait状态中的线程

和kiinsertqueueapc在gatewait线程中的步骤相比

线程等待队列

对于一个wait线程，kiunwaitthread将其从该线程正在等待的对象中解脱出来，线程被连接到他们通过一个由waitblocklist字段指向的链接，kiunwaitthread遍历这个链表并将其解脱出来

这些waitblocks，在azure cto Mark Russinovich的书《Inside Microsoft Windows 2000; Third Edition;》中有详细的介绍，在第230页Data Structures一节：

kthread中有两个重要的数据结构跟踪了是谁在等待什么
dispatcher headers和wait block
0: kd> dt _kthread
nt!_KTHREAD
   +0x000 Header           : _DISPATCHER_HEADER

0: kd> dt _kthread waitblock
nt!_KTHREAD
   +0x140 WaitBlock : [4] _KWAIT_BLOCK

0: kd> dt _DISPATCHER_HEADER
nt!_DISPATCHER_HEADER
   +0x000 Lock             : Int4B
   +0x000 LockNV           : Int4B
   +0x000 Type             : UChar
   +0x001 Signalling       : UChar
   +0x002 Size             : UChar
   +0x003 Reserved1        : UChar
   +0x000 TimerType        : UChar
   +0x001 TimerControlFlags : UChar
   +0x001 Absolute         : Pos 0, 1 Bit
   +0x001 Wake             : Pos 1, 1 Bit
   +0x001 EncodedTolerableDelay : Pos 2, 6 Bits
   +0x002 Hand             : UChar
   +0x003 TimerMiscFlags   : UChar
   +0x003 Index            : Pos 0, 6 Bits
   +0x003 Inserted         : Pos 6, 1 Bit
   +0x003 Expired          : Pos 7, 1 Bit
   +0x000 Timer2Type       : UChar
   +0x001 Timer2Flags      : UChar
   +0x001 Timer2Inserted   : Pos 0, 1 Bit
   +0x001 Timer2Expiring   : Pos 1, 1 Bit
   +0x001 Timer2CancelPending : Pos 2, 1 Bit
   +0x001 Timer2SetPending : Pos 3, 1 Bit
   +0x001 Timer2Running    : Pos 4, 1 Bit
   +0x001 Timer2Disabled   : Pos 5, 1 Bit
   +0x001 Timer2ReservedFlags : Pos 6, 2 Bits
   +0x002 Timer2ComponentId : UChar
   +0x003 Timer2RelativeId : UChar
   +0x000 QueueType        : UChar
   +0x001 QueueControlFlags : UChar
   +0x001 Abandoned        : Pos 0, 1 Bit
   +0x001 DisableIncrement : Pos 1, 1 Bit
   +0x001 QueueReservedControlFlags : Pos 2, 6 Bits
   +0x002 QueueSize        : UChar
   +0x003 QueueReserved    : UChar
   +0x000 ThreadType       : UChar
   +0x001 ThreadReserved   : UChar
   +0x002 ThreadControlFlags : UChar
   +0x002 CycleProfiling   : Pos 0, 1 Bit
   +0x002 CounterProfiling : Pos 1, 1 Bit
   +0x002 GroupScheduling  : Pos 2, 1 Bit
   +0x002 AffinitySet      : Pos 3, 1 Bit
   +0x002 Tagged           : Pos 4, 1 Bit
   +0x002 EnergyProfiling  : Pos 5, 1 Bit
   +0x002 SchedulerAssist  : Pos 6, 1 Bit
   +0x002 ThreadReservedControlFlags : Pos 7, 1 Bit
   +0x003 DebugActive      : UChar
   +0x003 ActiveDR7        : Pos 0, 1 Bit
   +0x003 Instrumented     : Pos 1, 1 Bit
   +0x003 Minimal          : Pos 2, 1 Bit
   +0x003 Reserved4        : Pos 3, 2 Bits
   +0x003 AltSyscall       : Pos 5, 1 Bit
   +0x003 Emulation        : Pos 6, 1 Bit
   +0x003 Reserved5        : Pos 7, 1 Bit
   +0x000 MutantType       : UChar
   +0x001 MutantSize       : UChar
   +0x002 DpcActive        : UChar
   +0x003 MutantReserved   : UChar
   +0x004 SignalState      : Int4B
   +0x008 WaitListHead     : _LIST_ENTRY

0: kd> dt _KWAIT_BLOCK
nt!_KWAIT_BLOCK
   +0x000 WaitListEntry    : _LIST_ENTRY
   +0x010 WaitType         : UChar
   +0x011 BlockState       : UChar
   +0x012 WaitKey          : Uint2B
   +0x014 SpareLong        : Int4B
   +0x018 Thread           : Ptr64 _KTHREAD
   +0x018 NotificationQueue : Ptr64 _KQUEUE
   +0x018 Dpc              : Ptr64 _KDPC
   +0x020 Object           : Ptr64 Void
   +0x028 SparePtr         : Ptr64 Void

dispatch header包含了对象类型，即0x0偏移处的type字段

对象类型dump代码

我当前测试用的win11的dump结果

他这个dispatcher header中的type跟我的有点对不上啊，我等待的明明是一个event啊，可是实际调试器中查看type的值是6

他这个object type跟我理解的object type好像不是一个东西

他是KOBJECTS那个枚举

我也不知道他这个准不准，根据他这个上面的定义，6代表的是THREAD，thread等待thread是什么玩意儿

我先来翻译一下azure cto的书里面的内容

dispatch header包含对象类型、signaled state，和一个线程等待的对象的列表

wait block代表了一个线程正在正待的一个对象

每一个线程处于等待状态的，都拥有一个wait block列表，用于表示线程正在等待的对象

每一个dispatcher对象都有一个列表，这个列表是wait blocks列表，代表线程正在等待的对象

这个列表被保存，因此当一个派遣对象被signaled的时候，内核可以快速决定谁正在等待这个对象

这个wait block有一个指针，指向正在等待的对象，还有一个指向正在等待这个对象的线程的指针，还有一个指向下一个wait block的指针（如果这个线程正在等待多个对象的话）

他同时也记录了等待的类型，以及位置of这个entry在这个handle数组由线程通过waitformultipleobjects函数传入的数组（如果线程只等待一个对象的话，那就是0）

下图展示了dispatch对象和wait blocks和线程之间的关系

从我实际调试的结果来看，无法反映上图中所展示的关系，我的kthread结构体中有一个waitblock数组，长度为4，其中前两个有值，后两个没值

我当前调试显示只有0和1号element的object字段不为0，这个对象一个是event一个是transaction manager Enlistment

0: kd> !object 0xffff9b06178cb660
Object: ffff9b06178cb660  Type: (ffff9b060781de20) Event
    ObjectHeader: ffff9b06178cb630 (new version)
    HandleCount: 1  PointerCount: 32769
0: kd> !object 0xffffc10bc3644a88
Object: ffffc10bc3644a88  Type: (ffff9b06077fa230) TmEn
    ObjectHeader: ffffc10bc3644a58 (new version)
    HandleCount: 18446633048981155296  PointerCount: 18446633049058614408

我们现在只需要关注event对象即可，也就是0号元素，WaitListEntry 字段确实不是空的，使用windbg的!list命令查看可以看到两个节点，根据cto的书的说明，这个listentry可以索引到dispatch object中的wait list head指向的链表

哦我好像误会了他的意思，他说的是dispatch对象，并不是kthread中的disatch header

所有的dispatcher对象都拥有一个dispatch header，所以我们应该去查看event对象

0: kd> dt _kevent ffff9b06178cb660
nt!_KEVENT
   +0x000 Header           : _DISPATCHER_HEADER
0: kd> dt _DISPATCHER_HEADER ffff9b06178cb660 WaitListHead  
nt!_DISPATCHER_HEADER
   +0x008 WaitListHead : _LIST_ENTRY [ 0xffff9b06`102e71c0 - 0xffff9b06`102e71c0 ]
0: kd> dt _kthread waitblock
nt!_KTHREAD
   +0x140 WaitBlock : [4] _KWAIT_BLOCK
0: kd> dqs ffff9b06102e7080+140 ; ffff9b06102e7080我们的测试kthread
ffff9b06`102e71c0  ffff9b06`178cb668
ffff9b06`102e71c8  ffff9b06`178cb668

可以看到kevent对象的waitlisthead确实指向了kthread的waitblocks数组的0号元素的listentry所在的链表

好了，关于等待对象我们就看到这里就够了，吼吼吼

回到apc那本书，waitblocks用来连接一个线程到dispatcher对象中（evetn、mutexes等），它允许一个事实，那就是一个线程可以等待多个对象，且每一个对象都可以由多个线程在等待

为了实现这个，关系，每一个线程都有一个waitblocks数组，这里每一个节点代表一个对象这个线程正在等待的

这个结论和我前面看cto的书得到的结论是一致的，每一个节点都是一个_kwait_block结构体

nt!_KWAIT_BLOCK
   +0x000 WaitListEntry    : _LIST_ENTRY
   +0x010 WaitType         : UChar
   +0x011 BlockState       : UChar
   +0x012 WaitKey          : Uint2B
   +0x014 SpareLong        : Int4B
   +0x018 Thread           : Ptr64 _KTHREAD
   +0x018 NotificationQueue : Ptr64 _KQUEUE
   +0x018 Dpc              : Ptr64 _KDPC
   +0x020 Object           : Ptr64 Void
   +0x028 SparePtr         : Ptr64 Void

以前的vista的这个结构体中有一个next字段用于指向当前线程等待的下一个对象，但是我这个win11没有了，那么我想知道，如果当前线程等待了多个对象的时候，你怎么跟踪这个状态呢，让我来写个代码测试一下

桥豆麻袋，不会是这个notificationqueue字段在负责这个吧

我先看一下我等待一个event的时候这个字段是什么状态

可以看到现在这个队列是空的，里面都是无意义的数值

0: kd> Dt _KQUEUE 0xffff9b06`102e7080
nt!_KQUEUE
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 EntryListHead    : _LIST_ENTRY [ 0x00000000`00000000 - 0x00000000`08229211 ]
   +0x028 CurrentCount     : 0xc3645c70
   +0x02c MaximumCount     : 0xffffc10b
   +0x030 ThreadListHead   : _LIST_ENTRY [ 0xffffc10b`c3640000 - 0xffffc10b`c3646000 ]

ok，我去网上搜了一下，弄明白了

关键就是WaitBlockList字段，这个字段是一个指针，里面存了一个数组的地址，这个数组的元素是_KWAIT_BLOCK，至于他具体有几个元素，是在哪里指定的我没弄清楚，但是每隔0x30字节就是一个_KWAIT_BLOCK结构体，和!process kthread 2的输出是完全吻合的

用于等待多个event来进行测试的代码

kiunwaitthread会遍历这个数组来将entry从event对象链表中解脱出来

而kiinsertqueueapc做的事情对于gatewait状态的线程有点不一样

他会使用kthread的gateobject字段，该字段指向kgate结构体，kgate只有一个字段，就是dispatchheader

靠，我的win11根本就没有他说的这个字段，算了妈的先打会儿游戏再说

从一个C语言项目到汇编再到shellcode

2022-10-09T00:00:00+02:00

原文链接

概述

恶意软件作者以及exp开发者经常将一段独立的、位置无关的代码叫做shellcodes

这种类型的代码可以被很简单的注入到任何合适的内存中并立即执行，不需要任何外部的加载器

尽管shellcode为研究人员和恶意软件作者提供了很大的便利，但是构造shellcode非常麻烦

shellcodes必须要遵循一套与编译器输出的格式具有很大差异的准则

这也是为什么大家都直接用汇编语言来写shellcode，就是为了完全控制输出的格式

毋庸置疑的是，使用汇编语言来构造shellcode是最精确的方法，但是与此同时，也很容易出错并且很麻烦

因此就有很多研究者想尽办法来简化这一过程，最大程度的利用C语言编译器而不是手动使用汇编语言来构建

在这份文档中，我将会分享我的相关经验以及我所使用的方法

此文档适用于初学者，在文中我详细介绍了一些围绕shellcode创建的常见技术，在第一部分中，我将会展示一些shellcode需要遵守的基本准则，以及相关方法的原理，然后我会逐步讲解shellcode的创建过程

使用这些方法，我们可以避免手动编写全部的汇编代码，而只需要对生成的汇编代码做一些手动修改即可，我们并没有抛弃手动编写shellcode的优势，只是跳过了繁冗复杂的部分

以前的技术和我攥写本文档的动力

使用C代码来创建shellcode的想法并不新鲜

在Bill Blunden于2012年出版的《The Rootkit Arsenal - Second Edition》一书中，他讲解了自己通过C代码创建shellcode的方法（第十章：使用C语言创建shellcode）

在Matt Graeber (@Mattifestation)的文章Writing Optimized Windows Shellcode in C中也介绍了相似的技术

在上面提到的这两种方法中，shellcode都是直接从C代码创建出来的，整个的理念都是围绕着修改编译器配置来创建出来一个PE文件使得我们能够从该文件中提取出来一段能够独立运行的代码

但是在这些方法中都完全忽略了使用纯汇编代码来创建shellcode的优势，之前的这些方法只能让我们获取到最终生成好的代码，而无法直接控制汇编代码，并且根本没有提供和这些汇编代码交互或者修改的机会

我所探寻的是一种能够将两者结合起来的方法：略过复杂且易出错的汇编代码编写部分，与此同时生成能够让我自由修改的汇编代码，最终用于生成shellcode

Shellcode的通用准则

对于PE格式的文件，我们并不需要关心他是怎么被加载的，Windows Loader会帮你做这些事，但是对于shellcode就不一样了，我们不能依赖Windows Loader和PE格式提供的便利：

没有section
没有Data Directory （导入表、重定位表等等）

下面是PE文件和shellcode的差异对比表格：

特性	PE	Shellcode
加载	通过Windows Loader；运行EXE会触发进程的创建	自定义，简化过的；必须寄生在已经存在的进程中（比如通过代码注入+进程注入）或者附加到已经存在的PE文件中（比如病毒）
构成	分为不同的section，拥有特定的访问权限，搭载不同的元素（code、data、resources等）	全部都在一片内存区域中（读、写、执行）
根据load base重定位	在重定位表中定义，被Windows Loader所使用	自定义；位置无关的代码
对系统API的访问	在导入表中定义，被Windows Loader所使用	自定义；通过PEB查找来获取导入；没有导入表或者简化过的

位置无关的代码

对于PE文件，根据其在内存中加载的基地址，Windows Loader可以通过重定位表将所有的地址进行偏移，这一过程是在运行时自动完成的

而对shellcodes而言，我们无法利用这个特性，因此只能编写出不需要进行重定位的代码，遵循此准则的代码被称作Position Independent Code (PIC)

通过使用相对地址可以创建出PIC，我们可以使用short jumps、long jumps、调用本地方法，因为这些操作都使用相对地址

不通过导入表调用API

对于PE文件，所有在我们的代码中被调用的API都会被收集到导入表中，导入表是由链接器创建的，然后在运行时对导入表进行解析

对于shellcodes，我们无法访问导入表，因此我们需要自己来处理API的解析

为了获取到在代码中被调用的API，我们需要利用PEB （Process Environment Block ---- 在进程运行时创建出来的系统结构）

一旦我们的shellcode注入到进程中，我们就需要获取到目标的PEB，然后用它来搜索加载到该进程运行地址空间中的DLL

我们需要获取到ntdll.dll或者kernel32.dll来解析剩下的API，每一个进程都会加载ntdll.dll，kernel32.dll会在进程初始化完成后被加载，这两者中的任意一个被我们获取到之后，就能用来加载所有我们需要的DLL文件

获取shellcode的导入API：

获取PEB地址
通过PEB->Ldr->InMemoryOrderModuleList查找到：
kernel32.dll
或者ntdll.dll
遍历kernel32（或者ntdll）的导出表，查找到下面函数的地址：
kernel32.LoadLibraryA (该函数最终会调用ntdll.LdrLoadDll)
kernel32.GetProcAddress (该函数最终会调用ntdll.LdrGetProcedureAddress)
使用LoadLibraryA（或者LdrLoadDll）来加载我们需要的DLL
使用GetProcAddress（或者LdrGetProcedureAddress）来获取我们需要的函数

获取PEB

PEB可以很方便的通过纯汇编代码来获取，指向PEB的指针是另一个结构体TEB（Thread Environment Block）的一个成员

32位进程使用FS段寄存器指向TEB，64位进程使用GS段寄存器指向TEB

进程位数	32bit	64bit
指向TEB的指针	FS段寄存器	GS段寄存器
PEB在TEB结构体中的偏移量	0x30	0x60

C语言实现如下：

    PPEB pen = NULL;
#if defined(_WIN64)
    peb = (PPEB)__readgsqword(0x60)
#else
    peb = (PPEB)__readfsdword(0x30)
#endif

基于PEB的DLL查找

PEB的其中一个成员是一个LinkedList，包含了该进程加载到内存中的所有DLL：

通过遍历该LinkedList，就能搜索到我们需要的DLL

下面的C代码演示了查找DLL的过程

#include <Windows.h>

#ifndef __NTDLL_H__

#ifndef TO_LOWERCASE
#define TO_LOWERCASE(out, c1) (out = (c1 <= 'Z' && c1 >= 'A') ? c1 = (c1 - 'A') + 'a': c1)
#endif

typedef struct _UNICODE_STRING
{
    USHORT  Length;
    USHORT  MaximumLength;
    PWSTR   Buffer;
} UNICODE_STRING, * PUNICODE_STRING;

typedef struct _PEB_LDR_DATA
{
    ULONG       Length;
    BOOLEAN     Initialized;
    HANDLE      SsHandle;
    LIST_ENTRY  InLoadOrderModuleList;
    LIST_ENTRY  InMemoryOrderModuleList;
    LIST_ENTRY  InInitializationOrderModuleList;
    PVOID       EntryInProgress;
} PEB_LDR_DATA, * PPEB_LDR_DATA;

// 这里我们不想使用任何由外部模块导入的函数

typedef struct _LDR_DATA_TABLE_ENTRY {
    LIST_ENTRY      InLoadOrderModuleList;
    LIST_ENTRY      InMemoryOrderModuleList;
    LIST_ENTRY      InInitializationOrderModuleList;
    void*           BaseAddress;
    void*           EntryPoint;
    UNICODE_STRING  FullDllName;
    UNICODE_STRING  BaseDllName;
    ULONG           Flags;
    SHORT           LoadCount;
    SHORT           TlsIndex;
    HANDLE          SectionHandle;
    ULONG           CheckSum;
    ULONG           TimeDateStamp;
} LDR_DATA_TABLE_ENTRY, * PLDR_DAT_TABLE_ENTRY


typedef struct _PEB_LDR_DATA{
    BOOLEAN InheritedAddressSpace;
    BOOLEAN ReadImageFileExecOptions;
    BOOLEAN BeingDebugged;
    BOOLEAN SpareBool;
    HANDLE Mutant;

    PVOID IMAGEBaseAddress;
    PPEB_LDR_DATA Ldr;
} PEB, * PPEB;

#endif

inline LPVOID get_module_by_name(WCHAR* module_name)
{
    PPEB peb = NULL;
    #if defined(_WIN64)
    peb == (PPEB)___readgsqword(0x60);
    #else
        peb = (PPEB)__readfsdword(0x30);
    #endif
    PPEB_LDR_DATA ldr = peb->Ldr;
    LIST_ENTRY list = ldr->InLoadOrderModuleList;

    PLDR_DATA_TABLE_ENTRY Flink = *((PLDR_DATA_TABLE_ENTRY*)(&list));
    PLDR_DATA_TABLE_ENTRY curr_module = Flink;

    while(curr_module != NULL && curr_module->BaseAddress != NULL)
    {
        if(curr_module->BaseDllName.Buffer==NULL)continue;
        WCHAR* curr_name = curr_module->BaseDllName.Buffer;

        size_t i=0;
        for(i=0;module_name[i] !=0&&curr_name[i]!=0;i++){
            WCHAR c1,c2;
            TO_LOWERCASE(c1,module_name[i]);
            TO_LOWERCASE(c2,curr)name[i]);
            if(c1!=c2) break;
        }
        if(module_name[i]==0&&curr_name[i]==0) {
            return curr_module->BaseAddress;
        }
        curr_module = (PLDR_DATA_TABLE_ENTRY)curr_module->InLoadOrderModuleList.Flink;
    }
    return NULL;
}

导出函数查询

获取到kernel32.dll的基地址之后，我们还需要获取一些函数的地址：LoadLibraryA和GetProcAddress，这个工作可以通过查询该DLL的导出表来完成

首先，我们需要从这个DLL的Data Directory中获取到导出表，然后遍历导出表中所有的函数名称直到找到我们想要的函数，然后拿到该函数的RVA，加到DLL的基地址上面获取到完整的函数地址

下面是导出表搜索函数的代码：

inline LPVOID get_func_by_name(LPVOID module, char* func_name)
{
    IMAGE_DOS_HEADER* idh = (IMAGE_DOS_HEADER*)module;
    if(idh->e_magic!=IMAGE_DOS_SIGNATURE){
        return NULL;
    }
    IMAGE_NT_HEADERS* nt_headers = (IMAGE_NT_HEADERS*)((BYTE*)module+idh->e_lfanew);
    IMAGE_DATA_DIRECTORY* exportsDir=&(nt_headers->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]);
    if(exportsDir->VirtualAddress==NULL)return NULL;
    DWORD expAddr = exportsDir->VirtualAddress;
    IMAGE_EXPORT_DIRECTORY* exp=(IMAGE_EXPORT_DIRECTORY*)(expAddr+(ULONG_PTR)module);
    SIZE_T namesCount=exp->NumberOfNames;

    DWORD funcsListRva=exp->AddressOfFunctions;
    DWORD funcNamesListRVA=exp->AddressOfNames;
    DWORD namesOrdsListRVA=exp->AddressOfNameOrdinals;

    for(SIZE_T i=0;i<namesCount;i++){
        DWORD* nameRVA=(DWORD*)(funcNamesListRVA+(BYTE*)module +i*sizeof(DWORD);
        DWORD* nameIndex=(WORD*)(funcNamesListRVA+(BYTE*)module +i*sizeof(WORD);
        DOWRD* funcRVA = (DOWRD*)(funcsListRva+(BYTE*)module+(*nameIndex)*sizeof(DWORD));

        LPSTR curr_name = (LPSTR)(*nameRva+(BYTE*)module);
        size_t k=0;
        for(k=0;func_name[k]!=0&&curr_name[k]!=0;k++){
            if(func_name[k]!=curr_name[k] break;        
        }
        if(func_name[k]==0&&curr_name[k]==0){
            return (BYTE*)module+(*funcRVA);
        }
    }
    return NULL;
}

把上面的代码封装到一个头文件peb_lookup.h

#pragma once
#include <Windows.h>

#ifndef __NTDLL_H__

#ifndef TO_LOWERCASE
#define TO_LOWERCASE(out, c1) (out = (c1 <= 'Z' && c1 >= 'A') ? c1 = (c1 - 'A') + 'a': c1)
#endif


typedef struct _UNICODE_STRING
{
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;

} UNICODE_STRING, * PUNICODE_STRING;

typedef struct _PEB_LDR_DATA
{
    ULONG Length;
    BOOLEAN Initialized;
    HANDLE SsHandle;
    LIST_ENTRY InLoadOrderModuleList;
    LIST_ENTRY InMemoryOrderModuleList;
    LIST_ENTRY InInitializationOrderModuleList;
    PVOID      EntryInProgress;

} PEB_LDR_DATA, * PPEB_LDR_DATA;

//here we don't want to use any functions imported form extenal modules

typedef struct _LDR_DATA_TABLE_ENTRY {
    LIST_ENTRY  InLoadOrderModuleList;
    LIST_ENTRY  InMemoryOrderModuleList;
    LIST_ENTRY  InInitializationOrderModuleList;
    void* BaseAddress;
    void* EntryPoint;
    ULONG   SizeOfImage;
    UNICODE_STRING FullDllName;
    UNICODE_STRING BaseDllName;
    ULONG   Flags;
    SHORT   LoadCount;
    SHORT   TlsIndex;
    HANDLE  SectionHandle;
    ULONG   CheckSum;
    ULONG   TimeDateStamp;
} LDR_DATA_TABLE_ENTRY, * PLDR_DATA_TABLE_ENTRY;


typedef struct _PEB
{
    BOOLEAN InheritedAddressSpace;
    BOOLEAN ReadImageFileExecOptions;
    BOOLEAN BeingDebugged;
    BOOLEAN SpareBool;
    HANDLE Mutant;

    PVOID ImageBaseAddress;
    PPEB_LDR_DATA Ldr;

    // [...] this is a fragment, more elements follow here

} PEB, * PPEB;

#endif //__NTDLL_H__

inline LPVOID get_module_by_name(WCHAR* module_name)
{
    PPEB peb = NULL;
#if defined(_WIN64)
    peb = (PPEB)__readgsqword(0x60);
#else
    peb = (PPEB)__readfsdword(0x30);
#endif
    PPEB_LDR_DATA ldr = peb->Ldr;
    LIST_ENTRY list = ldr->InLoadOrderModuleList;

    PLDR_DATA_TABLE_ENTRY Flink = *((PLDR_DATA_TABLE_ENTRY*)(&list));
    PLDR_DATA_TABLE_ENTRY curr_module = Flink;

    while (curr_module != NULL && curr_module->BaseAddress != NULL) {
        if (curr_module->BaseDllName.Buffer == NULL) continue;
        WCHAR* curr_name = curr_module->BaseDllName.Buffer;

        size_t i = 0;
        for (i = 0; module_name[i] != 0 && curr_name[i] != 0; i++) {
            WCHAR c1, c2;
            TO_LOWERCASE(c1, module_name[i]);
            TO_LOWERCASE(c2, curr_name[i]);
            if (c1 != c2) break;
        }
        if (module_name[i] == 0 && curr_name[i] == 0) {
            //found
            return curr_module->BaseAddress;
        }
        // not found, try next:
        curr_module = (PLDR_DATA_TABLE_ENTRY)curr_module->InLoadOrderModuleList.Flink;
    }
    return NULL;
}

inline LPVOID get_func_by_name(LPVOID module, char* func_name)
{
    IMAGE_DOS_HEADER* idh = (IMAGE_DOS_HEADER*)module;
    if (idh->e_magic != IMAGE_DOS_SIGNATURE) {
        return NULL;
    }
    IMAGE_NT_HEADERS* nt_headers = (IMAGE_NT_HEADERS*)((BYTE*)module + idh->e_lfanew);
    IMAGE_DATA_DIRECTORY* exportsDir = &(nt_headers->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]);
    if (exportsDir->VirtualAddress == NULL) {
        return NULL;
    }

    DWORD expAddr = exportsDir->VirtualAddress;
    IMAGE_EXPORT_DIRECTORY* exp = (IMAGE_EXPORT_DIRECTORY*)(expAddr + (ULONG_PTR)module);
    SIZE_T namesCount = exp->NumberOfNames;

    DWORD funcsListRVA = exp->AddressOfFunctions;
    DWORD funcNamesListRVA = exp->AddressOfNames;
    DWORD namesOrdsListRVA = exp->AddressOfNameOrdinals;

    //go through names:
    for (SIZE_T i = 0; i < namesCount; i++) {
        DWORD* nameRVA = (DWORD*)(funcNamesListRVA + (BYTE*)module + i * sizeof(DWORD));
        WORD* nameIndex = (WORD*)(namesOrdsListRVA + (BYTE*)module + i * sizeof(WORD));
        DWORD* funcRVA = (DWORD*)(funcsListRVA + (BYTE*)module + (*nameIndex) * sizeof(DWORD));

        LPSTR curr_name = (LPSTR)(*nameRVA + (BYTE*)module);
        size_t k = 0;
        for (k = 0; func_name[k] != 0 && curr_name[k] != 0; k++) {
            if (func_name[k] != curr_name[k]) break;
        }
        if (func_name[k] == 0 && curr_name[k] == 0) {
            //found
            return (BYTE*)module + (*funcRVA);
        }
    }
    return NULL;
}

编写并编译汇编代码

正如前面提到的，编写shellcodes的经典方法就是汇编代码

首先我们需要选择用于编译代码的汇编器，这会对我们编写汇编代码时使用的语法有些许影响

对于Windows而言，最常用的汇编器是MASM，同时也是VS的一部分，有两个版本，一个32位的（ml.exe）一个64位的（ml64.exe)，MASM生成的object文件可以被链接为PE格式的可执行文件，下面是一段演示代码：

.386
.model flat

extern _MessageBoxA@16:near
extern _ExitProcess@4:near

.data
msg_title db "Demo!", 0
msg_content db "Hello World!", 0

.code
main proc
    push 0
    push 0
    push offset msg_title
    push offset msg_content
    push 0
    call _MessageBoxA@16
    push 0
    call _ExitProcess@4
main endp
end

使用VS自带的ml.exe和link.exe进行编译和链接，首先要使用vcvars32.bat初始化环境变量

编译：

ml.exe /c demo.asm

链接：

link.exe demo.obj /subsystem:console /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:main /out:demo32_masm.exe

MASM是Windows默认的汇编器，但是YASM（NASM的继任者）才是最好的选择，它是一个免费、独立的多平台汇编器，它可以被用来像MASM一样创建PE文件，YASM的语法稍有不同，请看下面的演示代码：

bits 32
extern _MessageBoxA@16:proc
extern _ExitProcess@4:proc

.data
msg_title db "Demo!", 0
msg_content db "Hello World!", 0

global main

main:
    push 0
    push 0
    push msg_title
    push msg_content
    push 0
    call _MessageBoxA@16
    push 0
    call _ExitProcess@4

编译

yasm-1.3.0-win32.exe -f win32 demo.asm -o demo32.obj

链接方法和上面的一样

上面这两段汇编代码都是不能直接生成shellcode的，因为他们都使用了外部依赖（extern），并没有遵循shellcode准则，不过我们可以通过移除这些依赖来生成shellcode

后面我们将使用MASM，因为如果我们想要使用VS来编译C代码，那么编译生成的汇编代码就是MASM语法，然后我们要做的就是从最终生成的PE文件中把代码挖出来

逐步编译C项目

现在大家都直接使用IDE来编译自己的代码了，这样一来，整个的编译过程对我们来说就是透明的了，默认情况下，输出就是一个PE文件：Windows专用的本地可执行文件格式

但是，有些时候将这个过程分成数个步骤还是有用的，这样我们可以拥有更大的控制权

让我们先来复习一下C/C++代码的编译过程

和汇编代码进行比较

相比于汇编代码，我们可以先使用C语言来编写代码，然后让编译器帮我们生成对应的汇编代码，之后再根据shellcode的准则来对生成的汇编代码进行适当的修改，相关内容将会在后面的章节中更详细地进行介绍

以下是一段样例代码

#include <Windows.h>

int main()
{
    const char msg_title[] = "Demo!";
    const char msg_content[] = "Hello World!";

    MessageBoxA(0, msg_title, msg_content, MB_OK);
    ExitProcess(0);
}

下面我们通过命令行的方式来生成exe，进行之前需要先运行vcvars32.bat，如果你想要生成64位的exe文件，那么就要先运行vcvars64.bat

编译链接：

cl /c demo.cpp                                         

link demo.obj /defaultlib:user32.lib /out:demo_cpp.exe

其中链接时我们可以使用第三方的链接器，比如crinkler，可以用来进行混淆等操作

如果在编译的时候加上一个/FA选项，那么编译器会在当前目录生成一个同名的asm文件（MASM语法），然后你可以再使用该asm文件编译出obj文件

这样我们就拥有了修改汇编代码的机会，而不是从0开始全部用汇编语言编写代码

从C语言项目到shellcode

核心理念

我们创建shellcodes的方法就是利用C编译器可以从C代码生成汇编代码的特性，它包含了如下几个基础步骤：

准备一个C项目
将该项目重构，所有的导入函数都通过PEB查找的方式进行（移除导入表中的依赖）
使用C编译器生成汇编代码：cl /c /FA /GS- <file_name>.cpp
重构汇编代码，以使得其遵循shellcode的准则（移除其他剩余的依赖，将字符串和变量等改为内联）
将汇编代码进行编译：cl /c file.asm
链接为PE文件，测试运行是否正常
获取.text中的代码，可以使用pe-parser，这个提取出来的代码就是shellcode

C编译器生成的汇编代码有时候并不是100%正确的，有时需要手动进行修改

准备C项目

当我们为shellcode准备C项目的时候，我们需要遵守以下几个规则：

不要直接使用导入表
总是通过PEB获取API地址
不要使用任何静态库
只是用局部变量，不要用全局变量和静态变量（否则它们会被存储到另外的section中从而破坏代码的位置无关性）
使用基于栈的字符串（或者在生成的汇编代码中内联）

基于栈的字符串转换

下面进行演示，我们的代码会弹个窗

#include <Windows.h>

int main()
{
    MessageBoxW(0, L"Hello World!", L"Demo!", MB_OK);
    ExitProcess(0);
}

准备导入函数

作为准备工作的第一步，我们需要将所有用到的导入函数进行动态加载，在演示代码中，有两个导入函数：MessageBoxW(user32.dll)和ExitProcess(kernel32.dll)

一般情况下，如果我们想要动态加载这些导入函数并避免使用导入表，我们需要对代码进行如下的重构

#include <Windows.h>

int main() 
{
    LPVOID u32_dll = LoadLibraryA("user32.dll");

    int (WINAPI* _MessageBoxW)(
        _In_opt_ HWND hWnd,
        _In_opt_ LPCWSTR lpText,
        _In_opt_ LPCWSTR lpCaption,
        _in_ UINT uType) = (int (WINAPI*)(
            _In_opt_ HWND,
            _In_opt_ LPCWSTR,
            _In_opt_ LPCWSTR,
            _In_    UINT)) GetProcAddress((HMODULE)u32_dll, "MessageBoxW");

    if(_MessageBoxW==NULL) return 4;
    _MessageBoxW(0, L"Hello World!", L"Demo!", MB_OK);

    return 0;
}

但是上面的代码中依然还有两个依赖：LoadLibraryA和GetProcAddress，这两个函数需要通过PEB查找来解析出来，这个工作可以通过之前的peb_lookup.h完成，下面是完整的popup.cpp：

#include <Windows.h>
#include "peb_lookup.h"

int main()
{
    LPVOID base = get_module_by_name((const LPWSTR)L"kernel32.dll");
    if (!base) {
        return 1;
    }

    LPVOID load_lib = get_func_by_name((HMODULE)base, (LPSTR)"LoadLibraryA");
    if (!load_lib) {
        return 2;
    }
    LPVOID get_proc = get_func_by_name((HMODULE)base, (LPSTR)"GetProcAddress");
    if (!get_proc) {
        return 3;
    }
    auto _LoadLibraryA = reinterpret_cast<decltype(&LoadLibraryA)>(load_lib);
    auto _GetProcAddress = reinterpret_cast<decltype(&GetProcAddress)>(get_proc);

    LPVOID u32_dll = _LoadLibraryA("user32.dll");

    auto _MessageBoxW = reinterpret_cast<decltype(&MessageBoxW)>(_GetProcAddress((HMODULE)u32_dll, "MessageBoxW"));
    if (!_MessageBoxW) return 4;

    _MessageBoxW(0, L"Hello World!", L"Demo!", MB_OK);

    return 0;
}

跳转表

如果我们在代码中使用了switch语句，那么在编译之后生成的汇编代码中可能会产生一个跳转表，这个是由编译器优化产生的，在一个普通的可执行文件中，跳转表很有用，但是对于shellcode，我们必须谨慎处理，因为它会破坏shellcode的位置无关性：跳转表需要重定位

汇编语言中的跳转表：

是否生成跳转表由编译器决定，低于4种情况的switch语句通常不会生成跳转表，因此我们必须重构C代码避免出现过长的switch语句，通常有两种处理方式，一种是拆分为多个函数，另一种是拆分为多个if-else语句

示例：

下面这段代码生成的汇编代码中将会包含跳转表

#include<stdio.h>

bool switch_state(char * buf, char * resp) {
  switch (resp[0]) {
  case 0:
    if (buf[0] != '9') break;
    resp[0] = 'Y';
    return true;
  case 'Y':
    if (buf[0] != '3') break;
    resp[0] = 'E';
    return true;
  case 'E':
    if (buf[0] != '5') break;
    resp[0] = 'S';
    return true;
  case 'S':
    if (buf[0] != '8') break;
    resp[0] = 'D';
    return true;
  case 'D':
    if (buf[0] != '4') break;
    resp[0] = 'O';
    return true;
  case 'O':
    if (buf[0] != '7') break;
    resp[0] = 'N';
    return true;
  case 'N':
    if (buf[0] != '!') break;
    resp[0] = 'E';
    return true;
  }
  return false;
}

int main() {
  char resp[] = "caaonima";
  char buf[] = "nimacao";
  printf("%d\n", switch_state(buf, resp));
  return 0;
}

生成汇编代码：

cl /c /FA /GS- demo.cpp

可以看到有跳转表被生成

如果我们将原来代码中的switch语句截成几个代码块，就可以解决这个问题

#include<stdio.h>

bool switch_state(char * buf, char * resp) {
    {
        switch (resp[0]) {
        case 0:
          if (buf[0] != '9') break;
          resp[0] = 'Y';
          return true;
        case 'Y':
          if (buf[0] != '3') break;
          resp[0] = 'E';
          return true;
        case 'E':
          if (buf[0] != '5') break;
          resp[0] = 'S';
          return true;
        }
    }  
    {
        switch (resp[0]) {
        case 'S':
          if (buf[0] != '8') break;
          resp[0] = 'D';
          return true;
        case 'D':
          if (buf[0] != '4') break;
          resp[0] = 'O';
          return true;
        case 'O':
          if (buf[0] != '7') break;
          resp[0] = 'N';
          return true;
        }
    }
    {
        switch (resp[0]) {
        case 'N':
          if (buf[0] != '!') break;
          resp[0] = 'E';
          return true;
        }
    }
    return false;
}

int main() {
    char resp[] = "caaonima";
    char buf[] = "nimacao";
    printf("%d\n", switch_state(buf, resp));
    return 0;
}

使用if-else太麻烦，不推荐使用

移除隐式依赖

struct sockaddr_in sock_config = { 0 };

乍一看这行代码并没有调用任何函数，但是实际上它隐式调用了memset函数来初始化这个结构体变量

我这边实际测试的时候并没有发现有memset函数的引入

不过为了避免出现这种情况，我们还是使用自定义的函数或者inline的函数来初始化这种结构体

struct sockaddr_in sock_config;
SecureZeroMemory(&sock_config, sizeof(sock_config));

SecureZeroMemory是inline函数

可以看到该函数的定义直接存在于生成的汇编代码中

处理字符串（可选）

我们还需要将所有用到的字符串转换为基于栈的，这个在这篇文章中有提到

char load_lib_name[] = {'L','o','a','d','L','i','b','r','a','r','y','A',0};
LPVOID load_lib = get_func_by_name((HMODULE)base, (LPSTR)load_lib_name);

这段代码生成的汇编代码如下：

生成汇编代码

现在我们已经准备好将C项目编译生成汇编代码了

cl /c /FA /GS- demo.cpp

注意将peb_lookup.h和demo.cpp放到同一目录，编译的时候会自动将其包含进去

/GS-选项用于关闭stack cookie checks，如果没有这个选项，那么我们生成的汇编代码将会变成这样：

这样的话就多了一个外部依赖，所以一定要加上这个编译选项来避免出现这种情况

重构汇编代码

32位和64位有一些细微的差别，重构步骤也会因此有一些差异，我们将分开介绍

32位

首先使用vcvars32.bat初始化环境变量，然后编译生成汇编代码

0.清理汇编代码

首先，我们直接编译上面生成的汇编代码来生成EXE

在汇编代码的最上面加上下面这一行来解决这个报错

这个时候应该能生成一个可以正常运行的exe

使用PE-bear可以看到，该exe中仍然包含导入表

这是因为一些标准库默认链接到了我们的exe中，下面我们移除这些外部依赖

1.移除剩余的外部依赖

把汇编代码中的这三行注释掉：

include listing.inc
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

在上面那一步中，我们生成的exe链接了静态库LibCMT，其中包含了入口函数_mainCRTStartup，现在我们把这个依赖移除之后，链接器就找不到入口函数了，因此我们需要在编译的时候显式指定入口函数：

ml /c demo.asm
link demo.obj /entry:main

这下彻底干净了

2.确保代码的位置无关性

如果之前在C代码中已经将所有的字符串重构为基于栈的，那么这一步就可以省略掉了

为了保证代码的位置无关性，我们不能在除了.text之外的任何其他sections中存储数据，所有的事情都必须要在.text中完成，如果我们的字符串被存储到了.data中，那么我们就需要重构汇编代码来inline掉这些字符串

这里不再赘述，推荐在写C代码的时候使用基于栈的方式

3.提取shellcode

这一步可以使用pe-parser完成

64位

首先使用vcvars64.bat初始化环境变量，然后编译生成汇编代码

栈对齐

如果你想用XMM指令，那么需要确保16字节的栈对齐，否则，你的exe会直接崩掉

相关细节在Matt Graeber (@Mattifestation)的文章Writing Optimized Windows Shellcode in C中的Ensuring Proper Stack Alignment in 64-bit Shellcode一节中有提到

这一部分暂且略过，并没有考虑编写64位的shellcode

THE END

演示视频

上面的演示视频中，shellcode提取之后使用加载器运行没有成功，正在解决这个问题

换了一个加载器就好了，原来的这个加载器可能有点问题