0x00

本文是对ALPC的简单研究，由于时间有限，还有很多细节没有搞清楚，还有很多疏漏。希望能起到抛砖引玉的作用，能找到高手讨论学习。
ALPC（Advanced/Asynchronous Local Procedure Call），是微软发展出来替代LPC，用于本机RPC的一种C/S模型技术。但是对用户来说，能看到只有RPC概念，很少能看到ALPC。
我们看一个典型的ALPC同步调用堆栈：

从名字上就能看出RPCRT4.dll是rpc的runtime库，我个人感觉在C端如果要使用RPC的话主要是和这个库打交道。
从堆栈的函数调用可以看出来，RPC先进入LRPC再进入ALPC。Windows中将RPC分为LRPC（本机远程过程调用）与多机RPC。
实质上分为两种RPC其实也是很好理解，对本机来说，IPC的通讯方法多样，整体环境简单；而不同终端的IPC主要使用的tcp/ip协议，网络环境的异常处理比较复杂。
LRPC是通过ALPC实现的。
在现代的Windows环境中，ALPC的使用的频繁程度可能远远超过大部分人的想象。可能很熟悉的API内部都是通过ALPC委托为其他的应用程序（主要是各类svchost）实现的。按照 Alex Ionescu在 syscan2014上的发言，即使最简单的windows程序都会有ALPC连接。
可以打开 procexp.exe查看每个进程的ALPC Port的名字。

0x01

ALPC的总体架构应该如下：

http://www.zer0mem.sk/?p=542
从图中我们可以看到，client port与server port相连形成alpc connection。Client将message deliver 到 message queue。猜测message携带的数据比较大，那么具体数据通过section来传递，减少数据拷贝，提升性能。
ALPC使用简单流程如下：
Server端调用NtAlpcCreatePort创建server port，然后调用NtAlpcAcceptConnectPort等待client连接。Client端调用NtAlpcConnectPort尝试连接，如果server端检查权限、SID等信息之后，允许连接的话，那么一个port connection就建立起来了。
之后client与server就能调用NtAlpcSendWaitReceivePort相互收发消息了。

ALPC的应用层接口可以查看：https://processhacker.sourceforge.io/doc/ntlpcapi_8h.html
关于ALPC的具体实现，由于时间关系，只是简单翻了下IDA，没有什么特殊的发现，就不拿出来献丑了。

0x02

接下来看看 _ALPC_PORT 与 _KALPC_MESSAGE的数据结构：


ALPC_PORT中比较重要的字段：
1、 PortListEntry，通过这个字段应该可以遍历系统中所有的ALPC port
2、 CommunicationInfo，通过这个字段我们能找到另一端的Port信息
3、 各类队列信息
4、 OwnerProcess，表明哪个进程创建这个port
5、 各类队列的未处理Message长度，例如在我分析的dump中，PendingQueueLength
是 0x3cd，导致了后续的ALPC一直block，从而整个APP卡死。


1、 OwnerPort 当前Message 是跟哪个Port相关联的
2、 WaitingThread，当前哪个线程正在等待这个消息完成，一般都是发起NtAlpcSendWaitReceivePort调用的线程
3、 ServerThread 哪个线程负责处理这个ALPC MSG。以下是猜测内容，请大家批判：ALPC Port中有Direct队列与Pending队列，Direct队列可能是由某个具体工作线程的处理的；Pending队列可能是由线程池中随机线程处理的，即一个线程池和ALPC的 CompletionPort相关联，收到事件后取数据处理。在C端发起请求到进入内核之前，C端是无法得知ServerThread到底是谁的。这个字段非常关键，如果MESSAGE的字段不为空，但是ALPC调用一直没有返回，那么可以直接去查看ServerThread的线程栈看看到底是为什么卡住
4、 MessageId，全局唯一的ALPC消息ID。

0x03

Windbg中有专门的!alpc命令可以查看ALPC的信息。
一般如果APP调用 NtAlpcSendWaitReceivePort长时间不返回，那么内核live/dump调试(!process proc_addr)会显示如下信息:
Waiting for reply to ALPC Message [KALPC_MESSAGE addr]
对这个消息，我们关心Windbg到底是如何定位的。我们可以直接看 kdexts.dll。
因为消息是在打印线程信息的时候出现的，那么可以在IDA中搜索thread相关的函数，具体是在DumpThread函数中，实际上就是_ETHREAD结构的 AlpcMessageId字段。
在IDA中搜索 alpc，我们能看到alpc命令的处理函数。

0x04

对于RPC的调试，微软也有比较详细的文档，但是必须得是live debug才行，具体见：
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/overview-of-rpc-debugging
另外还有关于ALPC与RPC消息查看的工具：
http://blogs.microsoft.co.il/pavely/2017/02/12/monitoring-alpc-messages/
https://github.com/silverf0x/RpcView