APC
Windows内核分析索引目录：https://www.cnblogs.com/onetrainee/p/11675224.html
APC
1. APC的本质
一个线程，其一直占用着CPU，对CPU拥有所有权，不可能从外部改变行为。
APC的本质就是：通过一个函数，让线程执行，从而可以从外部改变该线程的行为。
1）APC的挂入位置 _KAPC_STATE
_ETHREAD+0x034 ApcState，存在一个_KAPC_STATE结构体：
其存在两个双向链表，称为APC队列，一个挂内核APC队列，一个挂用户APC队列。
//0x18 bytes (sizeof) struct _KAPC_STATE {
struct _LIST_ENTRY ApcListHead[2]; //0x0 用户/内核 APC队列
struct _KPROCESS* Process; //0x10 所挂靠的进程
UCHAR KernelApcInProgress; //0x14 当前内核APC函数是否执行 0/1
UCHAR KernelApcPending; //0x15 是否存在内核APC 0/1
UCHAR UserApcPending; //0x16 是否存在用户APC 0/1
};
2）APC存储的单元 _KAPC
前面我们介绍过 _KAPC_STATE，其中一个Entry_List，里面一个个结构就是 _KAPC结构，如下：
//0x30 bytes (sizeof)
struct _KAPC {
SHORT Type; //0x0 类型
SHORT Size; //0x2 大小
ULONG Spare0; //0x4 未发现使用
struct _KTHREAD* Thread; //0x8 目标线程
struct _LIST_ENTRY ApcListEntry; //0xc APC队列挂的位置（双向链表）
VOID (*KernelRoutine)(struct _KAPC* arg1, VOID (**arg2)(VOID* arg1, VOID* arg2, VOID* arg3), VOID** arg3, VOID** arg4, VOID** arg5); //0x14 APC完成释放内存
VOID (*RundownRoutine)(struct _KAPC* arg1); //0x18
VOID (*NormalRoutine)(VOID* arg1, VOID* arg2, VOID* arg3); //0x1c APC函数所在的位置:如果是内核APC，其是函数地址；如果是用户APC，则是三环总入口
VOID* NormalContext; //0x20 VOID* SystemArgument1; //0x24 内核APC：略；用户APC：当前函数的总入口。
VOID* SystemArgument1; //0x24 APC函数的参数
VOID* SystemArgument2; //0x28 APC函数的参数
CHAR ApcStateIndex; //0x2c 挂哪个队列，有四个值 0,1,2,3
CHAR ApcMode; //0x2d UCHAR 用户APC 内核APC
Inserted; //0x2e 表示当前APC是否已经挂入
};
3）APC函数何时执行
关注一下KiServiceExit，从零环返回三环就通过这个函数，该函数是系统调用、异常和中断的必经之路。
APC处理函数通过 _KiDeliverApc 函数来执行，而 KiServiceExit 上来就先检查是否存在用户APC，如果有就调用该函数来执行。
该函数先判断是否存在内核APC，如果内核APC存在就先执行内核APC，然后再执行用户APC。
2. 备用APC队列
_Kthread+0x14c SavedApcState存在一个备用APC队列，其与 +0x034 ApcState位置结构体完全一样。
其和进程挂靠相关，如果不了解，可以去看《进程与线程》一节，该节后面介绍了进程挂靠相关细节。
1）线程APC中的函数都是与进程相关联的
线程APC中的函数要执行，执行的是当前CR3的内存地址，但是线程可以挂靠，当线程A挂靠到其他进程的CR3时，
如果此时线程A的APC函数要进行内存读写，其就会读写挂靠进程的内存地址，显然会发生错误。
2）SavedApc作用：
SavedApc函数就是为了避免当出现线程挂靠时内存读取错误，当线程挂靠时，其将该线程的APC存储到SavedApc中。
等到解除挂靠，再还原回来，这样就避免了内存执行错误。
3）SavedApc真实运行策略：
在挂靠环境下，也是可以向当前线程插入APC的，比如X进程中A线程挂靠T进程，此时也可以插入APC函数，只不过针对B进程的。
ApcState:B进程相关的APC函数。
SavedApcState:A进程相关的APC函数。
4）_KTHREAD+0x138 ApcStatePointer[2]:
Windows为了方便操作这两个_APC_STATE，设置了一组指针，在_KTHREAD+0x138处 ApcStatePointer[2]，其操作情况如下。
因此，如果找原线程的APC，直接ApcStatePointer[0]就好，找Saved就找ApcStatePointer[1]，很好理解。
5）_KTHREAD+0x165 ApcStateIndex 实现组合寻址
0 正常状态 / 1 挂靠状态
其经常会结合ApcStatePointer来进行寻址。
A进程的线程挂靠B进程，如果在非挂靠的情况下，此时插入的是A进程的APC，因此为ApcStatePointer[ApcState]；
如果此时在挂靠情况下，插入的进程就是关于B进程的APC，此时A进程的APC被备份到SavedApcState，B进程的也为ApcStatePointer[ApcState]。
6）_KTHREAD+0x166 ApcQueueAble
表示当前线程是否可以插入APC，比如线程退出时，不允许插入APC。
此时会将ApcQueueAble置为0，则进制APC挂入。
3. APC的插入
1）KeInitalizeApc函数分析
该函数声明如下，简单来说就是对应KAPC中的各个成员（可在文章开头查看）
2）KAPC.ApcStateIndex 作用
注意，其与KTHREAD.ApcStateIndex同名，但其值只有0/1，我们在之前的进程挂靠讲过，配合ApcStatePointer来指向有关地址。
0 原始环境 ；1 挂靠环境 ；2 当前环境 ；3 插入APC时的当前环境。
结合挂靠那一节，我们来分析下面的各种情况，以A进程的线程挂靠B进程为例（可能有点乱，一定结合上面挂靠来看）
0 原始环境：ApcStatePointer[0] 正常：ApcState；挂靠：SavedApcState，其都是写入A进程的ApcState。
1 挂靠环境：ApcStatePointer[1] 正常：SavedApcState；挂靠：ApcState，都是写入B进程的ApcState。
2 当前环境：其在初始化时修改为当前线程的Kthread.ApcStateIndex，Pointer[ApcStateIndex]，挂靠哪个插入哪个。
3 插入Apc时当前环境： 真正指向插入时（KiInserQueueApc），再做判断，插入当前进程的Apc中。（初始化到插入时，可能APC又被修改）
3）KiInsertQueueApc函数分析
该函数虽然长，但结构体比较单一，很好分析其对应的操作步骤。
4）Kthread+0x164 Alterable属性
Kthread+0x164 Alterable，其表示是否可以被用户APC唤醒。
我们在挂起线程调用SleepEx或WaitForSingleObjectEx，其最后一个参数就是修改这个值（注意，必须是Ex结尾的函数）。
当在KiInsertQueueApc插入用户KAPC之后，其会判断是否需要唤醒当前线程，如果此时值为1，则唤醒线程执行用户APC。
4. 内核APC执行过程
1）APC函数的执行与插入不是一个线程
A线程向B线程插入一个APC，插入的动作在A线程中完成的，但什么时候执行则由B线程决定！所以叫“异步过程调用”。
内核APC函数与用户APC函数的执行时间和执行方式也有区别。
2）内核APC的时机
①SwapContext
我们在线程切换时，会判断是否要有用户APC执行，注意，此时作为SwapContext的返回值返回，其一直返回到KiSwapThread中。
此时如果返回值为1，其会调用KiDeliverApc函数来处理当前线程的Apc。
②KiServiceExit
KiServiceExit中也会判断是否存在用户APC，调用KiDeliverApc函数来执行。
3）KiDeliverApc函数分析
内核APC如下（注意，其_LIST_ENTRY偏移在中间，故看起来很不美观），其直接从_KAPC中取出kernel
5. 用户APC执行过程
1） 用户APC函数的执行时机
当程序在零环执行完成返回三环时，其调用_KiServiceExit，此时其调用_KiDeliverApc来检查是否有派发的APC函数，然后执行。
2） 用户APC执行流程
当发现有用户APC要执行时，其处于零环，要执行必须返回三环。
执行流程为：零环->三环（执行用户APC）->零环->三环（正常退出）。
之前我们在系统调用这中提到过如何从三环进到零环，其三环现场保存在_KTRAP_FRAME（_ETHREAD+0x124）这个结构体中。
此时回去肯定不能从_KTRPA_FRAME中返回三环。
3）构建_CONTEXT结构体返回三环
返回三环时根据_KTRAP_FRAME.Eip来返回三环，因此我们想要处理用户APC，其必须修改KTrapFrame.EIP。
1> KiDiverApc函数中调用KiInitalUserApc来初始化用户APC环境
2> KiInitalUserApc函数中调用KiContextFromKframes将TrapFrame转换为CONTEXT结构体
这一步的目的是为了备份原来的TrapFrame，因为返回三环必然修改TrapFrame，因此将旧的转换为CONTEXT预先放到三环的堆栈。
3> KiInitalUserApc函数中将_APC_RECORD和_CONTEXT保存到三环的堆栈中
虽然此时处于零环，但是可以从TrapFrame.esp来获取三环的堆栈地址，然后将两者保存进去。
因为APC执行完之后还必须从三环进入零环，此时直接在堆栈进行操作进行复原即可。
1* 获取esp并计算提升堆栈大小
2* 将 _Context 写入三环地址
3* 将ApcRecord写入三环地址
4* 保存之后三环的堆栈空间
4> KiInitalUserApc函数中修改TrapFrame为返回三环做准备
其修改很多TrapFrame的值，但对于我们最重要的就是回到三环后的落脚点。
其回到KeUserApcDispatch来执行用户的APC函数，至于函数地址，ApcRecord.NormalContext存放的是真正的APC函数。
4）总结
理解上面过程，此时，我们就可以通过KiServiceExit函数利用KTrapFrame来返回用户层，其返回的就是KiInitalizeUserApc函数，然后执行用户APC。
当用户APC执行完成之后，返回零环，此时就是Context。我们直接在三环把Context再转换为KtrapFrame，这之后就很好理解了。
