Cheat Engine

dnsi0

I've been trying to hack this game but from what I can see, there are multiple usermode CRCs (which are easy to bypass) and a kernel mode CRC (from HS) that's reading memory and passing it back to usermode in an encrypted form. The good news is the driver isn't obfuscated in any manor so if I can locate where it accesses the memory, I can write my own driver and patch it.

The driver has a reference to KeAttachProcess so I'm assuming that's how it's managing to read memory but I'm not good enough to reverse engineer the function that does the reading (illiterate in x64 assembly... Q.Q).

So...
I'm wondering is there a way to put a breakpoint on usermode space that detects KERNEL memory reads as well. Like the "Find out what accesses this address" function in cheat engine but extends its detection to kernel access through KeAttachProcess as well?

Thanks.

Dark Byte · Posted: Sun Mar 17, 2013 5:39 am Post subject:

If your system is dbvm compatible (mainboard, bios, cpu, memory amount) edit dbkkernel and remove the check that if the access is from a different process to ignore it

Then enable global debugging in ce (kernelmode debugger interface) and try to find what accesses that address (Because you're compiling the driver yourself you'll need to boot with unsigned driver support or sign the driver with your own certificate)

hmm, the "Ability to step through kernelmode might be needed here, but there's a bug that makes it a one step only thing. (bsod after that) haven't looked into that one yet. And since cheat engine is most likely reading that memory as well big chance the first break will be ce's own read of that memory (so useless)

If all you care about is information about what accesses it you could just store all the accesses or just use DbgPrint to output all the data but skip the stepping part (where it pauses in kernelmode and asks ce on how to continue)

dnsi0 · Posted: Sun Mar 17, 2013 8:09 am Post subject:

SteveAndrew · Posted: Sun Mar 17, 2013 5:45 pm Post subject:

Ahh I see how that can be a tricky one! If they are using KeAttachProcess, then they are just directly accessing the memory after attaching to it... They aren't using an API (like ZwReadVirtualMemory for example) that you can just hook to figure it out / feed it the proper bytes...

(what I mean by directly accessing the memory is after KeAttachProcess, they could just do something like:)

dnsi0 · Posted: Mon Mar 18, 2013 12:58 am Post subject:

Dark Byte · Posted: Mon Mar 18, 2013 3:39 am Post subject:

Step through kernel is bugged. Perhaps something small or perhaps the whole idea i'm using is flawed. For now you can break only one time but never continue afterwards

If i get time i might look at it again, but there's no good lead to what causes the resume in kernel to bug out but resume in usermode works fine. (Perhaps i make a change that's only valid for usermode and forget to undo that)

dnsi0 · Posted: Mon Mar 18, 2013 3:47 am Post subject:

Dark Byte · Posted: Mon Mar 18, 2013 4:20 am Post subject:

Weird, this kind of exceptions should have been handled. Can you write to normal usermode memory ? Or write to manually allocated non-paged memory ? (kernel tools)

Did you normally load this driver? Or use a force loader to get this driver into memory without detection? (Undetected drivers can not make use of exception handlers)

Anyhow, there is a way to make it writable:
Go to :((Address & 0xffffffffffff) / 0x1000)*8 +fffff68000000000

There change the second bit (bit 1) to a 1 (e.g: 21 becomes 23)

(And while you're there you can set bit 2 to 1 so you can access that memory from usermode as well)

dnsi0 · Posted: Mon Mar 18, 2013 5:14 am Post subject:

SteveAndrew · Posted: Mon Mar 18, 2013 2:14 pm Post subject:

I suppose he means this code here: (in debugger.c) as part of the int1 handler