Determining Process Memory Area

Quote:

Original post by Zmurf So, would each memory address be a single byte of data? Also I'm not to sure what the last argument of VirtualQueryEx is and how I use it.

#include <windows.h>#include <stdio.h>int main(void){    MEMORY_BASIC_INFORMATION membasic;    printf(" address | BaseAddress, AllocationBase, AllocationProtect, RegionSize, State, Protect\n");    for (DWORD address = 0; address < 0x80000000; address += 0x10000UL)    {        VirtualQuery((DWORD*)address, &membasic, sizeof(membasic));        if ( MEM_COMMIT == membasic.State ) {            // scan me further            printf("%08X | %08X, %08X, %08X, %08d, %08X, %08X, %08X\n",            address, membasic.BaseAddress, membasic.AllocationBase,            membasic.AllocationProtect, membasic.RegionSize, membasic.State, membasic.Protect,            membasic.Type);        }    }    return 0;}

Quote:

Original post by Anonymous Poster I'm not exactly sure what you mean by your declaration... You can just include the required header and you're set to use VirtualQueryEx().

public uint GetMemoryState(IntPtr MemoryAddress)        {            ProcessMemoryReaderApi.MEMORY_BASIC_INFORMATION memInfo;            ProcessMemoryReaderApi.VirtualQueryEx(m_hProcess, MemoryAddress, &memInfo, sizeof(memInfo));            return memInfo.State;        }

Quote:

Error 1 Pointers and fixed size buffers may only be used in an unsafe context Error 2 The type or namespace name 'memInfo' could not be found (are you missing a using directive or an assembly reference?) Error 3 The best overloaded method match for 'MemoryEdit.ProcessMemoryReaderApi.VirtualQueryEx(System.IntPtr, System.IntPtr, MemoryEdit.ProcessMemoryReaderApi.MEMORY_BASIC_INFORMATION, long)' has some invalid arguments Error 4 Argument '3': cannot convert from 'MemoryEdit.ProcessMemoryReaderApi.MEMORY_BASIC_INFORMATION*' to 'MemoryEdit.ProcessMemoryReaderApi.MEMORY_BASIC_INFORMATION'

Quote:

In most cases process memory above 0x7FFFFFFF belongs to the kernel, so you don't have to scan the entire 4gb - you won't be able to scan the kernel portion anyway, at least not without some complicated hacks

Quote:

Original post by LessBread In most cases process memory above 0x7FFFFFFF belongs to the kernel...

Quote:

Original post by DaBookshah The messages are there to tell you that this sort of hackery is best done in a lower level language than C#. as for the error messages, use google. Quote: In most cases process memory above 0x7FFFFFFF belongs to the kernel, so you don't have to scan the entire 4gb - you won't be able to scan the kernel portion anyway, at least not without some complicated hacks I don't see how hacks are required, it's just read-only virtual memory. You can even write to it after you call VirtualProtect I believe(though not a good idea).

Quote:

Original post by LessBread My understanding is that attempts to touch addresses above 0x80000000 will produce an access violation exception. Most of the mapping above that address is the same across every process so I'm at a loss as to why it would be so easy to write to that range in another process and not within the current process.

Quote:

Then Ollydbg likely uses a device driver to read those addresses or it's a 16 bit app that runs at an extremely low level similar to SoftIce. K32 and NTDLL don't read data in kernel land from user land. They pass addresses from user space to kernel space through interrupt 2E. The eventual handler locks those addresses into ram so they don't page fault (page faults in kernel mode cause bsods), then if there is kernel data to be transfered back to user land, it's copied to the locked user land address, the userland memory is unlocked, the interupt handler returns passing execution back over to userland. That's the short of it at least.

Quote:

K32 and NTDLL don't read data in kernel land from user land

Quote:

Original post by DaBookshah Olly is not a 16-bit app....It's a ring 3 debugger, and I don't think it has any ring-0 components. And I am talking about under XP. In any case, that you can run olly and view this memory while NOT running as administrator rules out use of a device-driver(you need to be Administrator), I think. Bah, I'll just check when I get home.

Quote:

Original post by DaBookshah Quote: Then Ollydbg likely uses a device driver to read those addresses or it's a 16 bit app that runs at an extremely low level similar to SoftIce. K32 and NTDLL don't read data in kernel land from user land. They pass addresses from user space to kernel space through interrupt 2E. The eventual handler locks those addresses into ram so they don't page fault (page faults in kernel mode cause bsods), then if there is kernel data to be transfered back to user land, it's copied to the locked user land address, the userland memory is unlocked, the interupt handler returns passing execution back over to userland. That's the short of it at least. wow, I actually understood all of that!

Quote:

Original post by DaBookshah Quote: K32 and NTDLL don't read data in kernel land from user land Seems theres some confusion, I don't think that happens either. EDIT: Admiral is the expert, but I would read his post as saying that kernel32/ntdll are loaded above 0x80000000.

public uint GetMemoryState(IntPtr MemoryAddress)        {            ProcessMemoryReaderApi.MEMORY_BASIC_INFORMATION memInfo                = new ProcessMemoryReaderApi.MEMORY_BASIC_INFORMATION();            ProcessMemoryReaderApi.VirtualQueryEx(                m_hProcess,                 MemoryAddress,                 memInfo,                 System.Runtime.InteropServices.Marshal.SizeOf((memInfo))                );            return memInfo.State;        }

Quote:

PInvokeStackImbalance was detected Message: A call to PInvoke function 'MemoryEdit!MemoryEdit.ProcessMemoryReaderApi::VirtualQueryEx' has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature. Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature.