Understanding Process Memory and Cross-Process Operations in Windows

Introduction

In the previous articles, we explored how Windows executables become processes, how threads execute instructions, and how applications create new processes using the CreateProcess() API.

At this point in the series, we understand:

• How PE files are structured
• How Windows creates processes
• Why threads are the real execution units
• How applications communicate with Windows through APIs

A natural next question follows:

How do applications interact with memory after a process has been created?

Every running process contains memory, threads, handles, and security information. Windows carefully manages these resources to ensure stability, security, and isolation between applications.

Understanding process memory and cross-process operations is a crucial step toward mastering Windows Internals, malware analysis, reverse engineering, debugging, and incident response.

In this article, we’ll explore how Windows manages process memory, how applications obtain access to other processes, and the APIs that enable controlled interaction between processes.

Every Process Owns Memory

When Windows launches an executable, it creates a process and assigns it a dedicated virtual memory space.

This memory stores:

• Executable code
• Program data
• Global variables
• Dynamic allocations
• Thread stacks
• Loaded DLLs

A process can be thought of as a container that holds all resources required for execution.

Why Windows Uses Process Isolation

Imagine if every application could freely modify the memory of every other application.

A simple bug in one program could crash another.

A malicious application could steal data from any running process.

To prevent this, Windows enforces process isolation.

Each process receives its own address space, and Windows controls how processes access each other’s resources.

This design improves:

• Stability
• Reliability
• Security

Accessing another process always requires explicit permission from the operating system.

Understanding Process Handles

Throughout this series, we’ve repeatedly encountered the concept of handles.

A handle is a reference provided by Windows that allows applications to interact with operating system resources.

Examples include:

• File Handles
• Registry Handles
• Process Handles
• Thread Handles
• Event Handles

Applications never directly manipulate operating system resources.

Instead, they request handles from Windows and use those handles to perform operations.

Opening Another Process

Before interacting with another process, an application must obtain a valid process handle.

Windows provides the following API:

OpenProcess()

This function retrieves a handle to a target process.

Once a handle is obtained, applications can:

• Read information
• Inspect memory
• Query process details
• Perform memory operations
• Monitor process activity

The amount of access granted depends on the permissions requested.

Common access rights include:

Access RightPurposePROCESS_VM_READRead memoryPROCESS_VM_WRITEWrite memoryPROCESS_VM_OPERATIONPerform memory operations

Windows validates these requests before granting access.

Code Example

OpenProcess() example from the “How to open a process using OpenProcess windows api function” section.

Why Applications Access Other Processes

Opening another process is not inherently suspicious.

Many legitimate applications perform cross-process operations every day.

Examples include:

Debuggers

Tools like WinDbg and Visual Studio inspect process memory during debugging.

Performance Monitoring Tools

Applications collect CPU, memory, and thread information.

Security Products

EDR and antivirus solutions monitor processes for suspicious activity.

Accessibility Software

Screen readers and accessibility tools often interact with other applications to provide enhanced functionality.

Understanding the context behind these operations is critical during investigations.

Understanding Virtual Memory Allocation

Applications constantly require additional memory during execution.

Examples include:

• Storing user input
• Creating data structures
• Processing files
• Loading resources

Windows provides:

VirtualAlloc()

This API allocates memory inside the current process.

The operating system reserves memory pages and makes them available to the application.

Applications use this memory for runtime operations and temporary storage.

VirtualAlloc() allows applications to dynamically allocate memory during execution.

Understanding Memory Permissions

Not all memory regions are equal.

Some memory stores executable instructions.

Some contains only data.

Others should never be modified.

Windows assigns permissions to memory pages.

Common examples include:

Permission Description: PAGE_READONLY Read only PAGE_READWRITE Read and write PAGE_EXECUTE_READ Execute and read PAGE_EXECUTE_READWRITE Execute, read and write

These permissions help Windows enforce security boundaries and improve system stability.

Allocating Memory Inside Another Process

Windows also provides APIs that operate on another process.

One important API is:

VirtualAllocEx()

Unlike VirtualAlloc(), which allocates memory within the current process, VirtualAllocEx() allocates memory inside a target process.

This capability is commonly used by:

• Debuggers
• Monitoring tools
• Security software
• Accessibility applications

The target process must first be opened using OpenProcess().

Code Example

Writing Data to Process Memory

Allocating memory alone is not sufficient.

Applications often need to place data into the allocated memory region.

Windows provides:

WriteProcessMemory()

This API allows applications to write data into a target process’s memory.

At a high level:

OpenProcess()
      ↓
VirtualAllocEx()
      ↓
WriteProcessMemory()

This workflow forms the foundation of many legitimate process interaction mechanisms.

Code Example

Understanding Remote Threads

Earlier in this series, we learned that:

Processes contain resources, but threads perform execution.

Windows provides another API called:

CreateRemoteThread()

This function creates a thread inside a target process.

Conceptually, the workflow becomes:

OpenProcess()
      ↓
VirtualAllocEx()
      ↓
WriteProcessMemory()
      ↓
CreateRemoteThread()

Each API performs a specific task: OpenProcess : Obtain process access VirtualAllocEx: Allocate memory WriteProcessMemory: Write data CreateRemoteThread: Create thread

Understanding how these APIs relate to one another provides valuable insight into Windows Internals and process interaction mechanisms.

Code Example

Workflow : OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread.

Why Security Analysts Care About These APIs

Security professionals frequently investigate:

• Process access requests
• Memory allocations
• Thread creation events
• Cross-process interactions
• Memory permissions

These activities often reveal how software behaves internally.

Tools such as:

• Process Hacker
• Process Explorer
• Sysmon
• EDR Platforms

provide visibility into these operations and help analysts understand process behavior.

Understanding these APIs significantly improves one’s ability to investigate suspicious activity on Windows systems.

Connecting the Pieces

At this stage of the series, we’ve covered:

PE Files

How executables are structured on disk.

Processes

How executables become running applications.

Threads

How code executes.

Handles

How resources are accessed.

CreateProcess()

How Windows launches applications.

Process Memory

How applications allocate and manage memory.

Together, these concepts form the foundation of Windows Internals and provide the building blocks required to understand more advanced topics.

Final Thoughts

Memory sits at the center of everything a process does.

Whether you’re developing software, performing reverse engineering, investigating incidents, or studying malware analysis, understanding process memory is a fundamental skill.

The APIs discussed in this article demonstrate how Windows manages memory, controls access to processes, and enables controlled interaction between applications.

In the next article, we’ll explore how software maintains execution across system reboots and examine common Windows persistence mechanisms.