Windows Remote Procedure Calls (RPC): How Programs Communicate
Modern Windows systems are made up of many different processes and components.
These components often need to communicate with one another.
But how can one process request another process to perform an operation?
One important answer is Remote Procedure Call, or RPC.
What Is RPC?
Remote Procedure Call (RPC) is a communication mechanism that allows a program to request a function or operation from another process or system.
The important idea is:
A program can request an operation from another program without directly managing how that operation is performed.
The other program receives the request, performs the operation, and returns a result.
A simplified model is:
Client
↓
RPC Request
↓
RPC System
↓
Server
↓
Operation
↓
Response
↓
Client
Why Is RPC Useful?
Programs are often separated into different processes for security, reliability, or architectural reasons.
RPC provides a structured way for these components to communicate.
It can be used for:
Windows system services
Enterprise applications
Distributed applications
Network services
Administrative operations
Communication between Windows components
Local RPC vs Remote RPC
Despite its name, RPC does not necessarily mean communication across the Internet.
RPC can happen between processes on the same computer.
It can also happen between different computers over a network.
Local RPC:
Process A
↓
Process B
or:
Remote RPC:
Computer A
Process A
↓
Network
↓
Computer B
Process B
Client and Server
RPC communication usually involves two sides.
Client
The client requests an operation.
Server
The server receives the request and performs the operation.
For example:
Client Process
│
│ Request
↓
Server Process
│
│ Result
↓
Client Process
The terms "client" and "server" describe their roles in the communication rather than necessarily referring to separate physical computers.
RPC Stubs
RPC frameworks commonly use stubs to help translate between normal function calls and messages sent between processes.
A simplified model is:
Client Application
↓
Client Stub
↓
RPC Runtime
↓
Network / IPC
↓
RPC Runtime
↓
Server Stub
↓
Server Application
The stubs help package the function arguments and interpret the returned data.
Marshalling and Unmarshalling
When information needs to cross a process or machine boundary, it needs to be represented in a form that can be transferred.
This process is commonly called marshalling.
The receiving side performs the reverse process, often called unmarshalling.
Conceptually:
Function Arguments
↓
Marshalling
↓
Communication
↓
Unmarshalling
↓
Server Function
This allows structured data to travel between the client and server.
RPC Runtime
The RPC runtime provides infrastructure that helps manage RPC communication.
It can handle tasks such as:
Communication
Data transfer
Endpoint handling
Serialization-related work
Request and response processing
Applications generally interact with RPC through APIs and generated interfaces rather than implementing all of this infrastructure themselves.
Microsoft RPC
Windows provides an implementation commonly known as Microsoft RPC (MSRPC).
It is widely used by Windows components and applications.
Windows RPC can operate through different communication mechanisms depending on the situation.
RPC and Windows Services
RPC is closely connected to many Windows services.
A service may expose functionality that other processes can request through RPC.
For example:
Application
↓
RPC Request
↓
Windows Service
↓
Operation
↓
Response
This architecture allows applications to interact with system services without directly accessing their internal implementation.
RPC Endpoints
An RPC server needs a way for clients to locate and communicate with it.
This involves an endpoint.
An endpoint identifies where RPC communication can be delivered.
Conceptually:
RPC Server
↓
Endpoint
↓
Client Connection
Depending on the RPC configuration, endpoints can involve mechanisms such as named pipes or network ports.
RPC Endpoint Mapper
Windows includes an RPC Endpoint Mapper that helps clients discover endpoints for RPC interfaces.
The general idea is:
Client
↓
Endpoint Mapper
↓
"Where is this RPC interface?"
↓
RPC Server Endpoint
↓
Communication
This becomes particularly important in distributed Windows environments.
RPC and Security
RPC communication needs to be protected.
Windows can use security mechanisms to control:
Who can connect
Which operations are allowed
How identities are authenticated
How communication is protected
A service should not assume that every client is trusted.
Security checks are therefore an important part of RPC-based architectures.
RPC and Authentication
Windows RPC can integrate with Windows authentication mechanisms.
The identity of the client can be available to the server, allowing the server to make authorization decisions.
A simplified flow is:
Client
↓
Authentication
↓
RPC Server
↓
Authorization
↓
Allow / Deny
This connects RPC with concepts such as access tokens, users, groups, and privileges.
RPC and Windows Internals
RPC connects several Windows concepts we've already studied:
User / Process
↓
Windows API
↓
RPC
↓
Service / Server Process
↓
Kernel / System Resources
Understanding RPC therefore helps explain how Windows components communicate without directly sharing their internal memory or implementation.
RPC in Malware Analysis
RPC is important during malware analysis because malicious programs may communicate with Windows services or other processes using legitimate Windows communication mechanisms.
An analyst may investigate:
Which RPC interfaces a process interacts with
Which services receive requests
Which endpoints are contacted
What security context is involved
Whether unusual RPC activity occurs
However, RPC usage by itself is not evidence of malware.
Windows relies heavily on RPC for legitimate system functionality.
RPC and Lateral Movement
RPC can also appear in network-based attacks because Windows systems commonly use RPC-related services for remote administration and management.
Security analysts therefore monitor unusual RPC activity across systems.
For example:
Computer A
↓
RPC Communication
↓
Computer B
Unexpected communication between systems can become an important investigation clue.
RPC vs Shared Memory
RPC and shared memory are both forms of inter-process communication, but they work differently.
| Feature | RPC | Shared Memory |
|---|---|---|
| Basic idea | Request an operation | Share a memory region |
| Communication | Messages / requests | Common memory |
| Same computer | Yes | Yes |
| Network communication | Yes | Generally local |
| Synchronization | Often handled through communication model | Usually requires synchronization |
| Common use | Services and distributed systems | High-speed local data sharing |
RPC vs Direct Function Calls
A normal function call might look like:
Function
↓
Same Process
RPC is different:
Client Process
↓
RPC
↓
Other Process
The function being requested belongs to another execution context.
A Simple Analogy
Imagine ordering food at a restaurant.
You don't enter the kitchen and prepare the food yourself.
Instead:
Customer
↓
Order
↓
Waiter
↓
Kitchen
↓
Food
↓
Customer
The customer is the client.
The kitchen is the server.
The order is the RPC request.
The completed food is the response.
Final Thoughts
Remote Procedure Calls provide a structured way for processes and systems to request operations from other processes or systems.
Remember:
Client → RPC Request → Server → Operation → Response
Important concepts include:
Client and server
RPC runtime
Stubs
Marshalling
Endpoints
Endpoint Mapper
Authentication
Authorization
RPC is deeply integrated into Windows and is an important part of understanding how Windows components communicate.
In the next article, we'll explore Windows APIs and System Calls and see how applications move from high-level programming interfaces toward the operating system itself.
