Target application crashes when using ReadProcessMemory

Question

I have an interesting application that seems to crash whenever a particular region of memory is read using ReadProcessMemory. I know it's not doing anything special with RPM because:

1. Injecting a DLL to read that region of memory directly also causes a crash.
2. Scanning regions with applications like CheatEngine also causes a crash.

It's also not a guard region or a region with special protection flags. It's just a private R+W region.

At first I thought they were installing hardware data breakpoints like those described here, but after checking the debug registers of all threads and seeing that they were all zero made me conclude that another technique is used.

I suspect that they are somehow raising an exception whenever that piece of memory is read. I'm looking to understand what they're doing and how to detect it, or at the very least, make RPM not crash the application.

P.S. I cannot attach a debugger to this application, and the executable is encrypted, but I do know that various TLS callbacks are used along with VEH exception handlers.

Answer 1

Alright, it would appear that we have an answer to this. And it's a lot simpler than I thought, and actually pretty cool.

Basically, they allocate some pages with no physical backing until the page is accessed. This means that any access whatsoever (even in kernel mode) will validate the page, thus allowing the application to see that the page has been validated and promptly crash the game.

To avoid this, you can use QueryWorkingSetEx or NtQueryVirtualMemory and if the "valid" property of the returned structure is zero, then you probably shouldn't be reading that page.

I can't say for certain that this is the correct answer, but it fits my analysis. If anybody has more information on this technique, specifically how to implement it with something like VirtualAlloc, I would love to learn more.

P.S. The application doesn't appear to have any kernel mode access whatsoever, it's just a regular user mode application.

EDIT: Sample C++ implementation can be found here.

Answer 2

Check if attaching windbg in non-invasive mode works. If yes, check the page permissions of the target address range.

Answer 3

Is there any kernel mode anti-debug? The ReadProcessMemory is using KeAttachProcess. Maybe there's an inline hook that stops you.

Using ARK tools like PCHunter can search hooks in your system easily.

And I don't think that the application can detect RPM in user mode. In fact, to detect RPM, either hooking NtReadVirtualMemory or hooking the system page fault handler is need. What's more, even if the page is protected with PAGE_NO_ACCESS, the application shouldn't crash.

So I suspect that there is kernel mode hooking.

Answer 4

VirtualProtect or WriteProcessMemory are affected by this

because windows checks up the Vad Table with with a internal function called "MiCheckForConflictingNode" windows reacts to 0x00200000 what is 2 = VVadImageMap = 2 to value 0x00400000 what is in VadTypeVadWriteWatch = 4 to value 0x0008000 this flag is "NoChange" yes (1) or no (0) either contains 0 or 1

KeAttachProcess also calls a trigger im uncertain if its a flag or a function that got set

the trigger from the target is made to delay executed it then read out that information that got left from KeAttachProcess

after this the target prints a error but its only a trigger

to avoid this do not use that functions or either emulate them so they dont call triggers or flags there other ways too

microsoft gives a .txt file what includes text that is pure scam and talks like 10 pages about that microsoft is protecting those companys

and saying something like "stack error" what is not the case its just scamming and trolling

also i figured out that this part got added to windows with over a so called "security update" what is rather about the take the users away the rights from his own computer

thats why i never liked windbg it has a tons of dependencies

as you can see this problem here