ノート

WindowsALPCの簡単な調査



Windows Alpc Simple Research



0x00

この記事はALPCの簡単な研究です。限られた時間のため、まだはっきりしない詳細がたくさんあり、多くの省略があります。翡翠を刺激する役割を果たすことができればと思います。また、話し合い、学ぶ専門家を見つけることができます。
ALPC（Advanced / Asynchronous Local Procedure Call）は、ネイティブRPCのLPCを置き換えるためにMicrosoftによって開発されたC / Sモデルテクノロジです。ただし、ユーザーの場合、RPCの概念のみが表示され、ALPCはほとんど表示されません。
典型的なALPC同期呼び出しスタックを見てみましょう。
画像
名前から、RPCRT4.dllがrpcのランタイムライブラリであることがわかります。個人的には、C側でRPCを使いたい場合は、主にこのライブラリを扱っていると感じています。
スタックの関数呼び出しからわかるように、RPCは最初にLRPCに入り、次にALPCに入ります。 Windowsでは、RPCはLRPC（ネイティブリモートプロシージャコール）とマルチマシンRPCに分けられます。
基本的に、2種類のRPCをよく理解しています。このマシンの場合、IPCにはさまざまな通信方法があり、全体的な環境は単純です。さまざまな端末のIPCは、主にtcp / ipプロトコルを使用します。ネットワーク環境の例外処理はより複雑です。
LRPCはALPCを介して実装されます。
最新のWindows環境では、ALPCの使用はほとんどの人が考えるよりもはるかに頻繁に発生する可能性があります。おなじみのAPIは、他のアプリケーション（主にsvchost）用にALPCによって内部的に実装されています。 syscan2014でのAlexIonescuのスピーチによると、最も単純なWindowsプログラムでもALPC接続があります。
procexp.exeを開いて、各プロセスのALPCポートの名前を確認できます。

0x01

ALPCの全体的なアーキテクチャは次のようになります。
画像
http://www.zer0mem.sk/?p=542
図からわかるように、クライアントポートはサーバーポートに接続され、alpc接続を形成しています。クライアントはメッセージをメッセージキューに配信します。メッセージによって運ばれるデータは比較的大きいと推測されるため、特定のデータがセクションを通過して、データのコピーが削減され、パフォーマンスが向上します。
ALPCを使用する簡単なプロセスは次のとおりです。
サーバー側はNtAlpcCreatePortを呼び出してサーバーポートを作成し、次にNtAlpcAcceptConnectPortを呼び出してクライアント接続を待機します。クライアント側はNtAlpcConnectPortを呼び出して接続を試みます。サーバー側がアクセス許可、SID、およびその他の情報を確認してから接続を許可すると、ポート接続が確立されます。
クライアントとサーバーがNtAlpcSendWaitReceivePortを呼び出して、相互にメッセージを送受信できるようになったら。



ALPCのアプリケーション層インターフェースを表示できます。 https://processhacker.sourceforge.io/doc/ntlpcapi_8h.html
ALPCの具体的な実装については、時間の関係により、IDAを反転させただけで、特別な発見はなく、醜いものを提供することはありません。

0x02

次に、_ALPC_PORTと_KALPC_MESSAGEのデータ構造を見てみましょう。
画像
画像
ALPC_PORTのより重要なフィールド：
1、PortListEntry、このフィールドを介して、システム内のすべてのALPCポートをトラバースできる必要があります
2、CommunicationInfo、このフィールドを介して、もう一方の端にあるポート情報を見つけることができます
3、さまざまな種類のキュー情報
4、OwnerProcess、どのプロセスがこのポートを作成したプロセスを示します
5、さまざまなキューの未処理のメッセージの長さ。たとえば、分析したダンプのPendingQueueLength
は0x3cdであるため、後続のALPCは常にブロックされ、APP全体がスタックします。
画像
画像
1.OwnerPort現在のメッセージはどのポートに関連付けられています。
2、WaitingThread、このメッセージが完了するのを現在待機しているスレッド、通常はNtAlpcSendWaitReceivePortへの呼び出しを開始したスレッド
3、ServerThreadこのALPCMSGの処理を担当するスレッド。以下は推測の内容です。批判してください：ALPCポートにはダイレクトキューと保留中のキューがあります。ダイレクトキューは特定のワーカースレッドによって処理される可能性があります保留中のキューはスレッドプール内のランダムスレッド、つまりに関連付けられたスレッドプールによって処理される可能性がありますALPCのCompletionPortは、イベントを受信した後にデータ処理を行います。 C側がカーネルへの入力要求を開始する前に、C側はServerThreadが誰であるかを知ることができません。この分野は非常に重要です。 MESSAGEフィールドが空ではないが、ALPC呼び出しが返されていない場合は、ServerThreadスレッドスタックに直接移動して、スタックしている理由を確認できます。
4. MessageId、グローバルに一意のALPCメッセージID。



0x03

Windbgには、ALPC情報を表示するための特別な！alpcコマンドがあります。
通常、APPがNtAlpcSendWaitReceivePortを長時間呼び出すと、カーネルのライブ/ダンプデバッグ（！process proc_addr）は次の情報を表示します。
ALPCメッセージへの返信を待っています[KALPC_MESSAGEaddr]
このメッセージでは、Windbgがどのように配置されているかが重要です。 kdexts.dllを直接見ることができます。
スレッド情報を出力するときにメッセージが表示されるため、IDA、特にDumpThread関数（実際には_ETHREAD構造体のAlpcMessageIdフィールド）でスレッド関連の関数を検索できます。
IDAでalpcを検索すると、alpcコマンドの処理機能がわかります。

0x04

RPCのデバッグについては、Microsoftにも詳細なドキュメントがありますが、ライブデバッグである必要があります。見る：
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