Need to help to read the physical memory address of a Windows t process (Notepad -64bit process).
For example, I the Windows API , I can read the Heap memory of a process - Block Size, Block Address. It is Virtual address of heap.
Now, through inline assembly, how to translate this address to actual physical memory of the Intel i7 processor??
Objective: For a security project - If the processor Instruction Pointer (RIP) points to heap memory of the Windows process , program( Win32, C, Intel C++ compiler on Visual Studio community/ Windows 10)) should be detect and alert. Is the LEA instruction useful. Am I missing something ?!
Any suggestion, highly useful :)
All process on Windows, including the O/S run in a (its) Virtual Address space. As to if the Virtual Address and Physical Address are the same (e.g. device register) it is a matter of what the Page Tables are based at. A privileged level process (or system call) can obtain the base address for a page table entry descriptor.
>>Objective: For a security project - If the processor Instruction Pointer (RIP) points to heap memory of the Windows process , program( Win32, C, Intel C++ compiler on Visual Studio community/ Windows 10)) should be detect and alert.
Most of the Intel processors have a bit that can be set into the page table in 64-bit and PAE processes. As to if you want certain pages of a process execute disabled, this is up to the design of the application and/or driver. See:
Edit: This might be a better starting point:
And related pages.
Thanks Jim for reply. Appreciate of your efforts. yes, I got your points.
I aware of DEP policy and setting NX bit (through BCD /set nx Always On) on 32 bit Windows process policy. Believe, many of DEP related process attack (Malware) has been fixed since Windows 7 and later. On 64 bit Windows process -DEP is always ON. which is more secure.
At the moment, focusing on User mode anti malware application...not on Driver side though interesting to know - Execute pool types.
The main question, how to detect from application (inline Assembly and C) if Instruction Pointer (RIP/EIP) points to physical memory address process Heap ( currently running Windows 32bit /64bit process like Notepad ). Or Is it possible? I am new to anti malware techniques. Thanks again :)
>>physical memory address process Heap
There isn't such a thing. It is all Virtual. IOW the Page Table is either turned on or turned off. At boot time (generally) the Page Table is turned off. For a short period of time, generally the time necessary to initialize the Page Table then transition into Page Table enabled mode. Then the CPU stays in Page Table enabled mode (aka Protected Mode). Ring-0 code can manipulate Page Table entries.
When a process is started (Windows), a portion of the Virtual Memory space (usually half) is reserved for System space (a portion of which is actually mapped to system space which reside as Virtual Addresses which may or may not be the same as physical addresses). The other half (non-reserved for system portion) is used for application. A portion of which is mapped at program load time (code, uninitialized data, initialized data, data for initializing initialized data). The initial stack may have Virtual Addresses reserved for use, but do not get mapped until first used. The remainder of the virtual address space is available for heap and/or unassigned. The process heap(s) is(are) not mapped until actually touched. Touching an unmapped addresses causes a page fault to the O/S, when the address is within a designated space (reserved for stack or reserved for one or more heaps), a page is allocated from the Page File (when Page File is enabled, it generally is), then physical memory is assigned to the (to be retouched immediately on retry of instruction). As to if the NX bit is on or off for "normal" behavior of heap, I cannot say. You will have to consult the MSDN articles.
Note, an application can be constructed to select an appropriate Heap Manager (e.g. one that explicitly sets the NX bit). As for stack, you will have to research this (use Google: Your Search Terms Here site:msdn.microsoft.com).