View previous topic :: View next topic |
Author |
Message |
dnsi0 I post too much
Reputation: 0
Joined: 04 Jan 2007 Posts: 2674
|
Posted: Sun Mar 17, 2013 4:24 am Post subject: Detecting Kernel Mode Memory Access To Usermode? |
|
|
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.
|
|
Back to top |
|
 |
Dark Byte Site Admin
Reputation: 470
Joined: 09 May 2003 Posts: 25796 Location: The netherlands
|
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)
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
Back to top |
|
 |
dnsi0 I post too much
Reputation: 0
Joined: 04 Jan 2007 Posts: 2674
|
Posted: Sun Mar 17, 2013 8:09 am Post subject: |
|
|
Dark Byte wrote: | 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) |
Well I don't really care about stepping through kernel mode. I just need to know what piece of memory from kernel mode is accessing the process memory. So all I have to do is go recompile driver and I'm fine right?
Edit: Oh... I'm on a rMBP running windows through BootCamp... I don't suppose DBVM supports that BIOS :\
|
|
Back to top |
|
 |
SteveAndrew Master Cheater
Reputation: 30
Joined: 02 Sep 2012 Posts: 323
|
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:)
Code: |
RtlCopyMemory(&CRCBuffer, (void*)CRCCheckRegion, CRCRegionSize);
// or even
for(__int64 i = 0; i < CRCRegionSize; i++)
{
CRCBuffer[i] = CRCCheckRegion[i];
}
//etc..
BYTE *pCRCBuffer = &CRCBuffer;
for (BYTE *pCRCMemory = CRCCheckRegion; pCRCMemory != CRCRegionEnd, pCRCMemory++)
{
*pCRCBuffer++ = *pCRCMemory;
}
|
I feel you on the not being able to support DBVM, last time I tried it I didn't have much luck either! But I haven't completely given up on it for my computer, I still have hope that it could work if I do something a certain way!
There is a way to do it, and I think you can pull it off! Even if you've got to learn a bit of 64-bit assembler, at least just to a small degree, it isn't too too different than x86. Well except for passing parameters in registers that may be one thing that's really different
_________________
|
|
Back to top |
|
 |
dnsi0 I post too much
Reputation: 0
Joined: 04 Jan 2007 Posts: 2674
|
Posted: Mon Mar 18, 2013 12:58 am Post subject: |
|
|
SteveAndrew wrote: | 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:)
Code: |
RtlCopyMemory(&CRCBuffer, (void*)CRCCheckRegion, CRCRegionSize);
// or even
for(__int64 i = 0; i < CRCRegionSize; i++)
{
CRCBuffer[i] = CRCCheckRegion[i];
}
//etc..
BYTE *pCRCBuffer = &CRCBuffer;
for (BYTE *pCRCMemory = CRCCheckRegion; pCRCMemory != CRCRegionEnd, pCRCMemory++)
{
*pCRCBuffer++ = *pCRCMemory;
}
|
I feel you on the not being able to support DBVM, last time I tried it I didn't have much luck either! But I haven't completely given up on it for my computer, I still have hope that it could work if I do something a certain way!
There is a way to do it, and I think you can pull it off! Even if you've got to learn a bit of 64-bit assembler, at least just to a small degree, it isn't too too different than x86. Well except for passing parameters in registers that may be one thing that's really different  |
Well... I managed to find the location in EagleX64.sys that uses KeAttachProcess. However I'm not sure if that's the CRC function or that it's just a hacktool scanning function. Oh god the x64 assembler is so different... They pass the first and second parameters through rcx and rdx and I can't even make heads or tails out of where the rest of code goes...
Anyways, I was wondering if WinDbg could do something like this or some other debugger that doesn't need DBVM.'
Edit: I managed to get DBVM to run but why does it crash the kernel if you put breakpoints in kernel space even with the step through kernel enabled?
|
|
Back to top |
|
 |
Dark Byte Site Admin
Reputation: 470
Joined: 09 May 2003 Posts: 25796 Location: The netherlands
|
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)
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
Back to top |
|
 |
dnsi0 I post too much
Reputation: 0
Joined: 04 Jan 2007 Posts: 2674
|
Posted: Mon Mar 18, 2013 3:47 am Post subject: |
|
|
Dark Byte wrote: | 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) |
Alright. Well it doesn't seem I can get this working properly. (I'll try again once I get DDK on my computer, the internet here is far too slow to download it atm).
Last question, is there a reason why I can't modify kernel code from CE? Whenever I try it crashes me out and says attempt to modify read only memory and I can't make the page writable. I know you can't modify windows essentials due to patch guard but I should be able to modify memory of EagleX64.sys that isn't a part of windows right?
|
|
Back to top |
|
 |
Dark Byte Site Admin
Reputation: 470
Joined: 09 May 2003 Posts: 25796 Location: The netherlands
|
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)
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
Back to top |
|
 |
dnsi0 I post too much
Reputation: 0
Joined: 04 Jan 2007 Posts: 2674
|
Posted: Mon Mar 18, 2013 5:14 am Post subject: |
|
|
Dark Byte wrote: | 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) |
Here's what I did from booting my computer:
1. Boot my mac and select Windows.
2. Hold down F8 and disable signed driver enforcement (even your signed driver is being detected as unsigned for some reason)
3. Open CE
4. Click about and click the dbvm button that's green and it says my system is now running dbvm.
5. Enable kernel mode op/rvm/query and kernel debugger (global debug and step through kernel code)
6. Load game and wait till hackshield initializes.
7. Attach to game and go to code I want to replace (in EagleX64.sys)
8. Try to make it writable and doesn't work. But if I try to just write anyways, it BSoD with the write to read only memory error.
And thanks, I'll try that the next time my computer reboots, I didn't disable enforcement this boot so I can't try it atm.
Edit: ok so the read change worked thanks.
Quote: | edit dbkkernel and remove the check that if the access is from a different process to ignore it |
Edit: nvm... I found it but it appears to be commented out by default :O
|
|
Back to top |
|
 |
SteveAndrew Master Cheater
Reputation: 30
Joined: 02 Sep 2012 Posts: 323
|
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
Code: |
//DbgPrint("DebuggerState.isDebugging\n");
//check if this should break
if (CurrentProcessID==(HANDLE)(UINT_PTR)DebuggerState.debuggedProcessID)
{
UINT_PTR originaldebugregs[6];
UINT64 oldDR7=getDR7();
if (CurrentProcessID==(HANDLE)(UINT_PTR)DebuggerState.debuggedProcessID)
{
|
it isn't commented out... (at least not in the online google code page: https://code.google.com/p/cheat-engine/source/browse/trunk/DBKKernel/debugger.c)
You might want to rebuild the driver anyway with it commented out just to be sure!
On a side note I got DBVM working on windows 8 64-bit using the offloading method with the cheatengine-i386 executable (After I read this post by DannyFl: http://forum.cheatengine.org/viewtopic.php?p=5461472&sid=9dffa5c2177c7cd2a64c855a4f88d262)
That's the first time I've ever seen that instead of a blue screen with CLOCK_WATCHDOG_TIMEOUT stop code...
Then the first thing I did was try the Ulti-map and then got a blue screen for IRQL_NOT_LESS_THAN_OR_EQUAL (dbk64.sys) but at least I think dbvm works for the most part... (I had all kernel mode options set though maybe I shouldn't of had all of them set (global debug, ability to step through kernel code, kernel query/read/write +open process routines) Is there any I shouldn't have chosen for using Ulti-map?) Or what can I do to prove dbvm is really working?
EDIT: It seems unless I have both 'global debug' and 'step through kernel' checked it gives me the blue screen or just a freeze when trying to offload with 32bit CE... Also I tested the kernel mode debugger to see if it would work as one way to test if dbvm was actually doing anything... finding what accessed a certain address it did in fact work and display the address which accessed it! (However it then froze the system lol... I wonder if I would've hit stop if it still would have... Anyway I suppose your right its buggy on Win8, I will have to test it on Win7 at least now I know I can get it to load dbvm without getting a blue screen!!!!)
I'm just happy to for it to at least tell me dbvm is running though! lol
_________________
|
|
Back to top |
|
 |
|