Simple view:

Program.exe
|
v
Import Table
|
v
Required DLLs
|
v
Resolve Functions
|
v
Import Address Table (IAT)

The IAT table contains the addresses used to access imported functions

That is why the contents of some PE parts in Memory can differ from the corresponding initial values ​​in the file on disk

So why might the PE on disk and the memory be different?

There are several important reasons:

Relocation:
Some addresses are modified depending on the loading location

Import Resolution:
The address of imported functions is determined during the loading process

Memory Layout:
The structure of sections in memory is not necessarily the same as the raw layout of the file

Runtime Changes:
The program itself may change some memory data during execution

Zero Initialization:
Some sections may have allocated space in memory but have no corresponding data in the file and are initialized to zero

So if an analyst wants to compare a file on disk with Memory, he should not expect all the bytes to be exactly the same

How is this useful in Memory Forensics?

Suppose you are examining a Memory Dump
and you find a section whose content looks like the structure of a PE

A few questions to ask yourself:

Is the header valid?

Are the sections recognizable?

Are the addresses consistent with the Image structure?

Memory
Related to a known module?

Can the differences between file and memory be explained?

It is important to note that finding an MZ signature alone does not prove that a valid or executable PE exists in that area. A complete set of evidence must be examined for proper analysis. A PE may also not be easily recoverable due to the way it was uploaded, runtime changes, or even incomplete memory dump data.

How this relates to EDR. EDR can use information about memory modules and process behavior to investigate suspicious activity.

For example, we might put this information together:

Process Information

+ Loaded Modules + Memory Regions + Thread Activity
+ Call Stack + Execution Timeline

If the memory information is inconsistent with the expected state of a program, further investigation may be warranted.

However, it is important to note that: A difference in memory from a file on disk alone is not a definitive indication of malicious manipulation.

Some differences are a natural consequence of program upload and execution.

So far, we have been familiar with some important concepts. We are:

These concepts are very, very important to us in the discussion of memory analysis and program behavior analysis

@reverseengine