Формат ALPC-сообщений системных серверов

По отладке, юзер отладчик не покажет в списке на аттач csrss, так как сфейлит NtOpenProcess. Но есть лекарство.

 

нужно прицепиться отладчиком к клиенту
(например, svchost.exe), поставить брейкпоинт на
NtAlpcSendWaitReceivePort и посмотреть, как
клиент формирует ApiNumber и упаковывает
аргументы в CaptureBuffer ПЕРЕД отправкой
Посылать нужно валидную структуру API_MSG,
подменяя только данные, на которые она ссылается,
а не саму структуру (иначе сообщение не пройдет
базовую валидацию ALPC-цикла)

 

Код (Text):

1. [SIZE=5][B]Полная Спецификация Формата ALPC (Advanced Local Procedure Call)[/B][/SIZE]
2.   Сообщение ALPC в памяти ядра состоят из [B]четырёх независимых блоков[/B]:
3.   [CODE]+-----------------------------------------------------------------------+
4.   | 1. Заголовок Сообщения Ядра (_KALPC_MESSAGE)             [0x00..0x0F0]|
5.   +-----------------------------------------------------------------------+
6.   | 2. Пользовательский Заголовок (_PORT_MESSAGE)            [0x0F0..0x118]|
7.   +-----------------------------------------------------------------------+
8.   | 3. Атрибуты Сообщения (_KALPC_MESSAGE_ATTRIBUTES)        [Опционально]|
9.   +-----------------------------------------------------------------------+
10.   | 4. Полезная Нагрузка / Shared View (Payload / Section)   [0x118..N]   |
11.   +-----------------------------------------------------------------------+

1. Механизм Атрибутов Сообщений (ALPC Message Attributes)
К любому ALPC-сообщению через ядро можно прикрепить атрибуты. За них отвечает структура
nt!_KALPC_MESSAGE_ATTRIBUTES:

Код (Text):

1. dt nt!_KALPC_MESSAGE_ATTRIBUTES
2.   +0x000 ClientContext     : Ptr64 Void                     // Пользовательский контекст клиента
3.   +0x008 ServerContext     : Ptr64 Void                     // Пользовательский контекст сервера
4.   +0x010 PortContext       : Ptr64 Void                     // Контекст порта при подключении
5.   +0x018 CancelPortContext : Ptr64 Void                     // Контекст при отмене
6.   +0x020 SecurityData      : Ptr64 _KALPC_SECURITY_DATA     // Токен безопасности отправителя
7.   +0x028 View              : Ptr64 _KALPC_VIEW              // Ссылка на секцию разделяемой памяти
8.   +0x030 HandleData        : Ptr64 _KALPC_HANDLE_DATA       // Передаваемые хэндлы процессов
9.   +0x040 WorkOnBehalfData  : _KALPC_WORK_ON_BEHALF_DATA     // Билет имперсонации (Thread Impersonation)

Флаги доступных атрибутов (ValidAttributes):

• 
  []0x80000000 (ALPC_MESSAGE_SECURITY_ATTRIBUTE): Ядро автоматически прикрепляет токен безопасности
  клиента (_SECURITY_CLIENT_CONTEXT). Сервер может вызвать [FONT=Courier
  New]NtAlpcImpersonateClientOfPort[/FONT] и исполнить код с правами клиента!
  []0x40000000 (ALPC_MESSAGE_VIEW_ATTRIBUTE): Ядро передаёт отображение секции памяти
  (_KALPC_VIEW).
  
• 0x20000000 (ALPC_MESSAGE_HANDLE_ATTRIBUTE): Передача хэндла между процессами. Ядро сама делает
  DuplicateHandle из процесса-клиента в процесс-сервер!
  

2. Передача Больших Данных (> 64 КБ) через _KALPC_VIEW
Если клиенту нужно передать большой массив (например, картинку кадра в DWM или файл в CSRSS), он не шлёт
байты через _PORT_MESSAGE. Используется структура отображения памяти nt!_KALPC_VIEW:

Код (Text):

1. dt nt!_KALPC_VIEW
2.   +0x010 Region            : Ptr64 _KALPC_REGION
3.   +0x018 OwnerPort         : Ptr64 _ALPC_PORT
4.   +0x020 OwnerProcess      : Ptr64 _EPROCESS            // Процесс-владелец памяти
5.   +0x028 Address          : Ptr64 Void                 // Виртуальный адрес в юзермоде (VA)
6.   +0x030 Size             : Uint8B                     // Размер отображения в байтах
7.   +0x040 WriteAccessHandle : Ptr64 Void                 // Права записи

Как это работает:
1. Клиент создаёт секцию через NtAlpcCreateSection.
2. Клиент отображает её в ALPC-порт через NtAlpcCreateResourceSectionView.
3. Ядро монтирует эти же физические страницы в адресное пространство сервера без единого копирования байт.

3. Полная Таблица Типов Сообщений ALPC (MessageType)
В поле MessageType (смещение +0x0F4 в _KALPC_MESSAGE) указывается тип
транзакции:

Код (Text):

1. Код   Имя Типа                  Описание
2.   ──────┼─────────────────────────┼─────────────────────────────────────────────────────
3.   0x01 │ LPC_REQUEST             │ Обычный синхронный/асинхронный запрос
4.   0x02 │ LPC_REPLY               │ Ответ сервера на запрос
5.   0x03 │ LPC_DATAGRAM            │ Одностороннее сообщение без ожидания ответа (UDP-style)
6.   0x04 │ LPC_LOST_REPLY          │ Ошибка доставки ответа
7.   0x05 │ LPC_PORT_CLOSED         │ Уведомление о закрытии порта
8.   0x06 │ LPC_CLIENT_DIED         │ Уведомление ядра о гибели процесса-клиента
9.   0x07 │ LPC_EXCEPTION           │ Ошибка исключения в потоке сервера
10.   0x08 │ LPC_DEBUG_EVENT         │ Событие отладчика (устаревший LPC)
11.   0x0A │ LPC_CONNECTION_REQUEST  │ Запрос на новое подключение к серверу (NtAlpcConnectPort)

4. Асинхронные Кольцевые Очереди (ALPC Completion List)
Для высоконагруженных сервисов (например, сетевые службы в svchost.exe) Windows поддерживает режим
Completion List.
Ядро выделяет кольцевой буфер памяти (_ALPC_COMPLETION_LIST_HEADER), доступный одновременно ядру и
серверу в юзермоде.
• Сервер читает поступающие сообщения, просто опрашивая индексы атомарно (Lock-free ring buffer), не совершая
системных вызовов syscall / NtAlpcSendWaitReceivePort.

Полный чек-лист для исследования любого ALPC-сообщения
При анализе в отладчике WinDbg:
1. Заголовок сообщения: dt nt!_PORT_MESSAGE +0x0f0
2. Проверка атрибутов: dt nt!_KALPC_MESSAGE_ATTRIBUTES +0x068
3. Проверка передаваемых хэндлов: dt nt!_KALPC_HANDLE_DATA +0x030
4. Проверка передаваемой памяти (View): dt nt!_KALPC_VIEW +0x028

[/CODE]*