[Question] Is possible read value in the memory without readprocessmemory C++

Is possible read value in the memory without readprocessmemory(); like in dll injection;

Ex:

In dll injection:

Code:

int SomeValue = *(int*)0x0011; // address of sample.

instread in an extern process without injection is posible do something like the above without readprocessmemory?

Thx to all.

http://undocumented.ntinternals.net/...ualMemory.html

Originally Posted by niko1921

instread in an extern process without injection is posible do something like the above without readprocessmemory?

Can you explain why can't you use it?

If you don't want to use readprocessmemory() you can use native functions, like Hitokiri~ said.
But it would be much easier to inject a dll to read its own process memory.
Can you tell us what you want to achieve?

ReadProcessMemory calls NtReadVirtualMemory.
You cannot access the memory of another process without being part of the process other than through the Windows API.

@WasserEsser not only. Just to say, when you call ReadProcessMemory the ZwReadVirtualMemory function gets called too, that's the actual function which should read the process memory and write everything in a buffer.

Originally Posted by javalover

@WasserEsser not only. Just to say, when you call ReadProcessMemory the ZwReadVirtualMemory function gets called too, that's the actual function which should read the process memory and write everything in a buffer.

ReadProcessMemory calls NtReadVirtualMemory. ZwReadVirtualMemory is used by kernel drivers. ZwReadVirtualMemory doesn't validate the parameters and trusts the person calling the function, which you can't do for a function which is exposed to user mode applications. NtReadVirtualMemory will then call ZwReadVirtualMemory, yes. But NtReadVirtualMemory will get called first as the API is exposed to user mode and called from user mode.

A kernel-mode driver calls the Zw version of a native system services routine to inform the routine that the parameters come from a trusted, kernel-mode source. In this case, the routine assumes that it can safely use the parameters without first validating them. However, if the parameters might be from either a user-mode source or a kernel-mode source, the driver instead calls the Nt version of the routine, which determines, based on the history of the calling thread, whether the parameters originated in user mode or kernel mode.

Native system services routines make additional assumptions about the parameters that they receive. If a routine receives a pointer to a buffer that was allocated by a kernel-mode driver, the routine assumes that the buffer was allocated in system memory, not in user-mode memory. If the routine receives a handle that was opened by a user-mode application, the routine looks for the handle in the user-mode handle table, not in the kernel-mode handle table.

As i said above, you cannot access the memory of another process without being part of the process other than through the Windows API.

ReadProcessMemory / NtReadVirtualMemory / ZwReadVirtualMemory combined form a function from the Windows API. ReadProcessMemory is just a wrapper of a wrapper ( NtReadVirtualMemory ) of ZwReadVirtualMemory. You're still going through the Windows API, no matter which function you use though.

@WasserEsser how are you interpreting this:

Just to say, when you call ReadProcessMemory the ZwReadVirtualMemory function gets called too

? Did I say NtReadVirtualMemory doesn't get called firstly, or just that ZwReadVirtualMemory gets called too after you call ReadProcessMemory?

Yes, I know NtReadVirtualMemory gets called firstly.

NtReadVirtualMemory will then call ZwReadVirtualMemory, yes.

No. ZwReadVirtualMemory gets called just from the Ntoskrnl.exeⓘ core to access kernel mode or be aware it didn't access kernel mode, and not from NtReadVirtualMemory, that is called from ReadProcessMemory in ntdll.dll which contains just kernel NT functions.

Zw. Nt or Zw are system calls declared in ntdll.dll and ntoskrnl.exe. When called from ntdll.dll in user mode, these groups are almost exactly the same; they trap into kernel mode and call the equivalent function in ntoskrnl.exe via the SSDT. When calling the functions directly in ntoskrnl.exe (only possible in kernel mode), the Zw variants ensure kernel mode, whereas the Nt variants do not. The Zw prefix does not stand for anything.

As i said above, you cannot access the memory of another process without being part of the process other than through the Windows API.

ReadProcessMemory / NtReadVirtualMemory / ZwReadVirtualMemory combined form a function from the Windows API. ReadProcessMemory is just a wrapper of a wrapper ( NtReadVirtualMemory ) of ZwReadVirtualMemory. You're still going through the Windows API, no matter which function you use though.

I'm not sure you know I'm not the one who suggested to use NtReadVirtualMemory.

Originally Posted by javalover

@WasserEsser how are you interpreting this:

Originally Posted by javalover

Just to say, when you call ReadProcessMemory the ZwReadVirtualMemory function gets called too.

?

I'm not sure you know I'm not the one who suggested to use NtReadVirtualMemory.

I thought you were trying to say that ZwReadVirtualMemory is not part of ReadProcessMemory / Windows API and can be used as an alternative, as i said you can't access the memory of another process other than being part of the process or using the windows api. The response "not only, ZwReadVirtualMemory gets called too, thats the actual function" lead me into thinking that you meant that ZwReadVirtualMemory is not part of the Windows API. I was incorrectly interpreting your sentence and read it too quickly.

Originally Posted by WasserEsser

NtReadVirtualMemory will then call ZwReadVirtualMemory, yes.

Originally Posted by javalover

No. ZwReadVirtualMemory gets called just from the Ntoskrnl.exe core to access kernel mode or be aware it didn't access kernel mode, and not from NtReadVirtualMemory, that is called from ReadProcessMemory in ntdll.dll which contains just kernel NT functions.

When called from ntdll.dll in user mode, these groups are almost exactly the same; they trap into kernel mode and call the equivalent function in ntoskrnl.exe via the SSDT.

1.) ReadProcessMemory Calls NtReadVirtualMemory in NTDLL.DLL
2.) NtReadVirtualMemory passes through the SYSENTER/2Eh callgate and KeServiceDescriptorTable handler.
3.) ntoskrnl.exe calls ZwReadVirtualMemory for your application.
4.) ZwReadVirtualMemory reads the process memory and writes it into the buffer you supplied.

If you call a function directly or through a wrapper / descriptor table, you essentially made the function get called. You're right, NtReadVirtualMemory doesn't call ZwReadVirtualMemory directly, it gets called by ntoskrnl.exe, but you essentially got ZwReadVirtualMemory to get called, if you call it directly, call a wrapper or call it through the descriptor table, you ( NtReadVirtualMemory ) still got the function ( ZwReadVirtualMemory ) to get called. My wording is incorrect, yes.

Originally Posted by WasserEsser

1.) ReadProcessMemory Calls NtReadVirtualMemory in NTDLL.DLL
2.) NtReadVirtualMemory passes through the SYSENTER/2Eh callgate and KeServiceDescriptorTable handler.
3.) ntoskrnl.exe calls ZwReadVirtualMemory for your application.
4.) ZwReadVirtualMemory reads the process memory and writes it into the buffer you supplied.

Yes, but save your effort from copy/pasting this from a wiki page. I know how these functions do work, also if their documentation is horrible.

Originally Posted by javalover

Yes, but save your effort from copy/pasting this from a wiki page.

It's from a forum.

[Question] Is possible read value in the memory without readprocessmemory C++

Post a Reply

Similar Threads

Tags for this Thread