Process Virtual Address Space
│
├── Executable Image
├── Loaded DLLs
├── Heap Allocations
├── Thread Stacks
├── Memory-Mapped Files
└── Other Memory Regions

Each of these sections has a different purpose

Consider this:

If a memory region does not appear in the list of loaded modules, should we conclude that it is necessarily malicious or unrelated to any executable file?
To reach a conclusion, we must examine the memory structure, the origin of the region, and the process's behavior in conjunction with one another.

What evidence does an analyst examine?

When investigating an unusual memory region, the following types of information can be useful:

None of these factors, taken in isolation, constitute definitive proof; the real value lies in how they are correlated with one another.

Relevance to EDR and Memory Forensics

From a defensive perspective, a key question arises:

Is it possible to identify all behaviors associated with code execution solely by examining the list of loaded modules? No.

The module list provides only a limited view of the process's state. A more thorough investigation may require data such as:

Process
|
├── Module Inventory
├── Virtual Memory Map
├── Memory Protection
├── Thread Information
├── Call Stack
└── Event Timeline
|
v
Behavioral Analysis

This facilitates a better distinction between the application's normal behavior and anomalous activity.

An important caveat:
Not all EDR (Endpoint Detection and Response) solutions have equal access to this information, nor do they all analyze it in the same way; the outcome depends on the quality of the product and the available telemetry.

Conceptual Exercise:

Compare the following two scenarios:

Scenario 1:

Region Type: Image
Module: Known DLL
Protection: RX (Read/Execute)

Scenario 2:

Region Type: Private
Module: No clear association
Protection: RX (Read/Execute)

Based solely on this information, one cannot definitively label the second scenario as malicious; however, it may warrant further data collection.

For both scenarios, ask the following question:

Is the memory structure consistent with the region type? Do the threads and the call stack provide relevant information?

Are there events occurring before and after the creation of a memory region?

Keep these three concepts distinct:

Standard Image Loading:
Loading via the conventional Windows path and managing the associated steps.

Manual Mapping:
Preparing an image in memory using loading logic that differs from the standard path.

Memory Forensics:
Examining the structure and state of memory to understand the events that took place within a process.

While related, these three concepts are not the same.

@reverseengine

Free and Open Source Reverse Engineering Framework

https://rizin.re

@reverseengine

Cutter is a free and open-source reverse engineering

https://github.com/rizinorg/cutter

@reverseengine

Writing a Hyper-V Bridge for Fuzzing

https://www.alex-ionescu.com/writing-a-hyper-v-bridge-for-fuzzing-part-1-wdf

@reverseengine

angr’s documentation

https://docs.angr.io/en/latest/search.html?q=Document&check_keywords=yes&area=default

@reverseengine

QuarkslaB Dynamic binary Instrumentation

https://qbdi.quarkslab.com/introduction

@reverseengine

REA Is Impressive. But Reverse Engineering Was Never the New Part

https://crizantlai.medium.com/rea-is-impressive-but-reverse-engineering-was-never-the-new-part-ae5b26b958a1

How Dangerous Is REA (Reverse Engineer Anything) for Your App?

https://21zerixpm.medium.com/how-dangerous-is-rea-reverse-engineer-anything-for-your-app-2fce588968f1

@reverseengine

Someone Used AI to Reverse-Engineer PS5 Security in Weeks: What Is REA?

https://pub.towardsai.net/someone-used-ai-to-reverse-engineer-ps5-security-in-weeks-what-is-rea-11aed6dd106e

Reverse Engineer Anything v6.5.0

A tool for reverse engineering that allows AI agents to analyze applications and binary files without access to the source code

https://github.com/morluto/rea

@reverseengine