write loader with memory hooker

[Ayumi]

Originally Posted by mcr4ck

If you have a sample code, or if possible, give an example because I didn't fully understand
I can't do anything about this problem

the memory address is not in the memory space of the executable PE file
stack memory/private memory airspace

Because it is loaded in the address of the private memory and it cannot be found and the address changes every time

The PE file does not describe the entire memory space of an executable. It only contains the data required to execute a program, and the OS keeps the right to add additional regions without the user's awareness.
For example...Things such as the heap, the stack and other internal memory regions required for a process to function and operate are not the responsibility of a PE file (or any executable file for that matter).

A PE doesn't define a heap, it requests a heap to be allocated for it from the OS (AllocateHeap is a Windows API that does that). There's no need to actually eat up space for a heap "placeholder" in the PE file. The same goes for the stack, the PEB, and other memory objects a process has.

Additionally, a user(i.e. programmer) does not usually need to even call AllocateHeap for it's process to have a heap. OSes usually allocate a default heap for the process when loading it (either by the loader itself or by startup code the OS runs before control is given to the PE's Entry Point). Other times the compiler prefixes the code with code that allocates a heap.

So check all those other locations too.

[chants]

Originally Posted by Ayumi

The PE file does not describe the entire memory space of an executable. It only contains the data required to execute a program, and the OS keeps the right to add additional regions without the user's awareness.
For example...Things such as the heap, the stack and other internal memory regions required for a process to function and operate are not the responsibility of a PE file (or any executable file for that matter).

A PE doesn't define a heap, it requests a heap to be allocated for it from the OS (AllocateHeap is a Windows API that does that). There's no need to actually eat up space for a heap "placeholder" in the PE file. The same goes for the stack, the PEB, and other memory objects a process has.

Additionally, a user(i.e. programmer) does not usually need to even call AllocateHeap for it's process to have a heap. OSes usually allocate a default heap for the process when loading it (either by the loader itself or by startup code the OS runs before control is given to the PE's Entry Point). Other times the compiler prefixes the code with code that allocates a heap.

So check all those other locations too.

Wrong. Tyro detected. Microsoft literally since they made PE file format let's you control the size of both the stack and the "local heap" right in the PE optional header towards the start of the file.

https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#optional-header-standard-fields-image-only

72/72
4/8
SizeOfStackReserve
The size of the stack to reserve. Only SizeOfStackCommit is committed; the rest is made available one page at a time until the reserve size is reached.
76/80
4/8
SizeOfStackCommit
The size of the stack to commit.
80/88
4/8
SizeOfHeapReserve
The size of the local heap space to reserve. Only SizeOfHeapCommit is committed; the rest is made available one page at a time until the reserve size is reached.
84/96
4/8
SizeOfHeapCommit
The size of the local heap space to commit.

Certain aliases giving bad information doesn't surprise me

[tinomal]

Originally Posted by Ayumi

The PE file does not describe the entire memory space of an executable. It only contains the data required to execute a program, and the OS keeps the right to add additional regions without the user's awareness.
For example...Things such as the heap, the stack and other internal memory regions required for a process to function and operate are not the responsibility of a PE file (or any executable file for that matter).

A PE doesn't define a heap, it requests a heap to be allocated for it from the OS (AllocateHeap is a Windows API that does that). There's no need to actually eat up space for a heap "placeholder" in the PE file. The same goes for the stack, the PEB, and other memory objects a process has.

Additionally, a user(i.e. programmer) does not usually need to even call AllocateHeap for it's process to have a heap. OSes usually allocate a default heap for the process when loading it (either by the loader itself or by startup code the OS runs before control is given to the PE's Entry Point). Other times the compiler prefixes the code with code that allocates a heap.

So check all those other locations too.

@Ayumi's answer seems to be from here:

https://reverseengineering.stackexchange.com/a/14853

The answer is right but additional point to add:
The sizes are defined explicitly by the PE file. Only the location in memory is up to the OS.