Cheat Engine

SBAOM · Newbie cheater Reputation: 0 Joined: 10 Feb 2010 Posts: 19

Hi again. I fixed the 0 thing, for those who doesn't know, I'm developing a cheat for a specific game in C++, in which I need to modify a single byte (B7) to 00, which is GetLastError thing (CreateMutexA), my problem is when I try to use WriteProcessMemory I get error 299. I'm using windows vista x64 (although this doesn't work under windows 7 x86 either). Before the WriteProcessMemory call I call the following to, in order:

Dark Byte · Posted: Fri Mar 05, 2010 1:19 pm Post subject:

Error 299 means partial copy, but knowing from experience, that partial copy can be 0 bytes long, but does mean the processhandle is valid and you have proper rights

The error for VirtualQueryEx is because you havn't opened the process with PROCESS_QUERY_INFORMATION

OldProtection changing no idea, perhaps you've not set the original protection back so the next time you can it you get the value you set it to (with or without an os modified flag)

As for writeprocessmemory not working no idea.
The readProcessMemory call does work? And you're giving the proper address ?

SBAOM · Newbie cheater Reputation: 0 Joined: 10 Feb 2010 Posts: 19

This computer is really very crazy... DAMN! I did what you said. Worked. Not only that, when I did that i got error 487 in VirtualProtect and WriteProcessMemory. I modified a very tiny thing (which by the way I got it like before) and now ReadProcessMemory is giving me error 299 (WPM and VP are still giving me error 487 -Attempt to access invalid address-.

EDIT: The answer is this: OpenProcess is hooked. Somehow microsoft "hooked" (nice time to learn something) this function, which is now protected, so I can't access some privilleges like PROCESS_VM_WRITE or PROCESS_VM_OPERATION (main problematic stuff here, ReadProcessMemory, WriteProcessMemory and VirtualProtect). Until I un-hook it or hook it back or something, I don't know what that is so I suggest you tell me, I won't be able to continue with my program

EDIT 2: There is a second option, though, which is injecting it as a DLL, making of it a much simpler thing. I wouldn't like that much though, it's the easy way out. Still waiting for help.

Dark Byte · Posted: Sat Mar 06, 2010 9:44 am Post subject:

Cheat Engine also makes use of OpenProcess and ReadProcessMemory (Unless Kernelmode versions are used, but they are only used when explicitly enabled)
The only special thing is that it must be run in admin mode (It has a manifest embedded that tells windows it needs to run as admin)

I take it you already tried running it as admin? (that requires that you also run the debugger as admin)

If you're not running explicitly as administrator, then check your user account, and see if it's allowed to be granted the vm access rights

as for the hook:
On a normal windows system(64-bit), OpenProcess is:

SBAOM · Newbie cheater Reputation: 0 Joined: 10 Feb 2010 Posts: 19

I actually NEED to run the program as admin, because I use CreateProcess, which needs elevation (if I don't run it as admin, I get error 740, anyway, I'm actually used to run every program as admin).

Dark Byte · Posted: Sat Mar 06, 2010 7:29 pm Post subject:

A hook is defined as relocating the address of some api's, or rewriting the first few instructions so they jump to another location before jumping back to the rest of the routine

The openprocess api looks like a hook, but it doesn't jump to an extra routine that blocks you. It's the usual OpenProcess access rights check and open process stuff that always happens.

And if it's a blocking hook, then how can CE work ? I'm pretty sure I don't have any special dealings with Microsoft that they allow me to call those functions without a problem

With running as admin I mean rightclick the process and choose run as administrator, even turning off UAC isn't always enough

As for declaring the functions yourself I meant the WriteProcessMemory and ReadProcessMemory instead of using those provided in windows.h
For example, you might be running your app in 64-bit, and have declared the function to take the read address and buffer pointer as a DWORD instead of a pointer
That will cause it to randomly return wrong results, since bits 32 to 63 of the actual pointer will then contain random data, sometimes being 0 and succeed, other times having a bit set making it read an invalid address
I really doubt you did that though.

Also, it could be it's not the address you're trying to accessi s invalid, but your read/write buffers are. Have they been allocated? Are they big enough? And is the size parameter you give within the size of that buffer?

SBAOM · Newbie cheater Reputation: 0 Joined: 10 Feb 2010 Posts: 19

May I insert the whole code here? It's not that long.

NOTE: Comments, debugging stuff and output are in spanish, just don't pay attention to them.

Main.cpp

Dark Byte · Posted: Sun Mar 07, 2010 9:29 am Post subject:

Your call to ReadProcessMemory and WriteProcessMemory is wrong

you have set bufferIn to the address you want to read

SBAOM · Newbie cheater Reputation: 0 Joined: 10 Feb 2010 Posts: 19

Yeah, I know that, but the thing is the opposite. It gives the same value for each address, each time I restart the application a different address. That's what I meant. I'm gonna try what you said and edit after. Thank you Smile

.

Okay. There are still some problems, though WriteProcessMemory isn't retrieving any official errors, it's having some problems. First of all, there is ReadProcessMemory. Every address it reads, it reads it as 0, unless I call WriteProcessMemory, which variates each time I restart the executable. VirtualProtect is returning error 487 and another error I don't remember right now, and sometimes no error, even though when I call VirtualQueryEx the protect thing doesn't change. This is really messed up, I'd love to know what's going on, quite a mistery. The good thing is after I solve this problem, I'll have it no more Smile

Dark Byte · Posted: Mon Mar 08, 2010 5:29 pm Post subject:

Moved to general programming.

Anyhow,

SBAOM · Newbie cheater Reputation: 0 Joined: 10 Feb 2010 Posts: 19

Oh my god. Whats going on here? Good thing is VirtualProtectEx doesn't return any errors and works perfectly. The thing is I have a completly different problem here, or at least it is the same one but I found out more about it. When I call ReadProcessMemory BEFORE calling WriteProcessMemory, the output is set to 0. I tried writing 50 into that address, and when I called ReadProcessMemory AFTER calling WriteProcessMemory, the output is set to.. guess what? 50. The WEIRDEST though, is that after I execute my program calling WPM writing 50 into an address, and I execute it again WITHOUT the WPM, the address is still 50. It seems that when I write to an address (which isn't really the address I want to access), and I'm trying to read that memory piece again, i get the same value I wrote last time I executed the program... Here's the thing: When I open the exact same process with Cheat Engine, that space in memory (which is in this case 0x762B286B) is STILL 0xB7, it hasn't been affected by my program. There are two possibilities I thought about:

First possibility is that my program is not accessing the correct address because of an unknown problem

Second possibility is that my program is accessing an address that is not from the program's kernel32 module but an unexistent address, out of range.

If I'm right about the second possibility then I must ask: How can I access a process' module? Is it the same way of accessing a process executable address?

There's something else:

Since I was able to use WriteProcessMemory, my game (even when I open it without my executable) crashes after it isn't used for a while.

Dark Byte · Posted: Mon Mar 08, 2010 9:59 pm Post subject:

Are you sure the offset from the base address of kernel32.dll is 0x8D858 ?

modules are usually loaded on an address base thatends with 4 0's, (e.g 789a0000)
that means the offset should end with 286B , not D858

SBAOM · Newbie cheater Reputation: 0 Joined: 10 Feb 2010 Posts: 19

I found that out using Olly DBG. I actually think that address is correct, because, using my function GetKernelAddress I get the base address of kernel32 (which changes every time I restart my computer, by the way, that's why I have to use that function. The total size of kernel32.dll in my computer is of 0x128F5C bytes, so 0x8D86B (that's actually my offset) would be correct. Anyway, after I run the program I output the complete memory address (kernel32 base address + offset) and I look for it on Cheat Engine. It's actually the value I'm looking for. By the way, why this value (286B)?

The question here is: Why would I change an address PERMANENTLY by using WriteProcessMemory? Why is that memory address different in cheat engine and my executable?

What I know is this: The problem here is with ReadProcessMemory and WriteProcessMemory. They are not reading the correct address, which means they are missenterpreting the input value of the address buffer. Good thing is that they are missinterpreting it the same way, so this shouldn't be hard to solve. Thank you once again,
Cheers

SBAOM

Dark Byte · Posted: Tue Mar 09, 2010 9:21 am Post subject:

SBAOM · Newbie cheater Reputation: 0 Joined: 10 Feb 2010 Posts: 19

Okay. I'll start by saying that the address did not actually end at 286B, I mistakenly wrote that 2 instead of my B, sometimes I do that, as the 9 for the d or the 5 for the f lol. I don't know why that happens to me quite often. So the correct offset IS 0x8D86B. I tried it with cheat engine doing what you said, kernel32.dll+8d86b and I got B7.

I don't underestand this phrase, shall you explain?