Archived. Extracted from private repos for reference. Written July 2020. No guarantee it compiles or runs on any current version of Windows.
ALPC-based kernel driver used as the communication layer in a private game modification utility. Part of a series of IPC experiments alongside the ksocket and shared-memory drivers.
ALPC (Advanced Local Procedure Call) is the underlying mechanism Windows uses for named pipes, RPC, and COM. Using it directly (via ZwAlpcCreatePort in the kernel and NtAlpcConnectPort in usermode) gives you an IPC endpoint with no device object and no symbolic link. The port name appears in the object namespace (\IPCS_Port), but there's no driver dispatch table to enumerate and no DeviceIoControl call visible in usermode.
One design choice worth noting: replies don't travel back through the ALPC message. Once the kernel handles a request, it writes the result directly into a usermode buffer via MmCopyVirtualMemory (the reply_address field in the request). Usermode spins on a sentinel value (responded == 1337) to know when the result is ready. This keeps the message path one-directional and avoids having to deal with ALPC reply semantics. Future work and reverse engineering is encouraged, though I made do with a cheap hack.
shared/
shared.hpp KERNEL_REQUEST, KERNEL_REPLY, request_index enum
kernel/
ipcs_km.hpp server loop, port creation, request dispatch, reply via MmCopyVirtualMemory
usermode/
ipcs.hpp ipcs_client class: Connect, Disconnect, SendRequest, ReadMemory<T>, WriteMemory<T>
ipcs_client client;
client.Connect();
uint32_t health = 0;
client.ReadMemory<uint32_t>(self_pid, game_pid, health_addr, health);
client.Disconnect();