Cheat Engine

BleachFan · How do I cheat? Reputation: 0 Joined: 01 Dec 2010 Posts: 8

I'm trying to find the location of two static variables in an .exe or .dll file. Eventually, I want to create a binary patch that lots of people can use.

The values are:

var 1 = 1280 (0x0500) -or- 1456 (0x05B0)
var 2 = 1024 (0x0400)

Before you ask, text/hex searches in various combinations of the above bytes (words, dwords, byte order, etc.) have turned up either massive numbers of false positives or nothing at all. Searching the binaries is a dead end.

So I downloaded CheatEngine and did the following:

1. Narrowed the variables' (most obvious) usage to one specific dll.
2. Found the function that initialized a private copy for that dll.
3. Rewrote these bytes (in memory) and had some of the desired effect.

This means that I'm on the right track.

However, (a) these memory addresses change every time the game is restarted, and (b) only part of the desired effect was achieved.

So I must find where the exe obtains these values.

I figured out how to set a breakpoint and used the call stack to get CheatEngine to display the disassembly for the function caller, which conveniently is a large function within the exe. Success!

Sadly, each time I do this, the disassembly view lost all its convenient C++ function labels. I end up in the middle of a massive, confusingly written function deep in the game's .exe file. I have no idea what code I am looking at. I can't read the assembly code well enough to tell where it's pulling its constants from.

I'm stuck for the moment. Any ideas? What part of CheatEngine should I try next?

Thank you!

Dark Byte · Posted: Wed Dec 01, 2010 7:22 pm Post subject:

one tip for when cheat engine decides to throw away all symbols:
In memory view click file->set symbol searchpath and just click ok
That should reinitialize the symbol engine

Geri · Moderator Reputation: 111 Joined: 05 Feb 2010 Posts: 5636

Maybe a trace in CE6 would help, because You can save the logs and You can try to check if the value is passed around in a register or not. Maybe it will not help at all, but there is a chance that You will find the code which is reading the value from the memory. I mean like this:

blablablabla
blablablabla
blablablabla
blablablabla
blablablabla
mov eax,[your value]
blablablabla
blablablabla
blablablabla
blablablabla

Then You would see it in the logs that eax has the value that You are looking for so that code is reading it from the memory.
Of course it can work in other ways too, but it doesn't hurt to give it a try.

BleachFan · How do I cheat? Reputation: 0 Joined: 01 Dec 2010 Posts: 8

Thank you both!

I traced the values back further. In the caller (see attached image), they find their way into something called an ST(0) register (as floats: 1456.0000 and 1024.0000) and from there it's a FSTP dword ptr [EBP-58] (and EBP-54 respectively).

EBP is 0x19xxxxxx and memory values at that address change constantly during normal execution so I assume it's a heap or stack. The address is between some unrelated DLLs. Is this normal?

What is ST(0) and how do these two floats find their way into it?

I got a copy of the Intel x86 reference and will be reading up on this.

Geri · Moderator Reputation: 111 Joined: 05 Feb 2010 Posts: 5636

BleachFan · How do I cheat? Reputation: 0 Joined: 01 Dec 2010 Posts: 8

Most likely it's my fault. Embarassed

EIP -- instruction pointer? -- is referring to a DLL (0x01Dxxxxx) whose code usually falls somewhere around (0x020xxxxx). I set the breakpoint there and went back to previous caller in exe (0x005xxxxx) (i.e. double-clicking previous caller in call stack window). I should have been more clear about this.

BTW, it is a 64-bit system, 32-bit app, and app and its DLLs have largeaddressaware flag set.

I will read the other things later (after lunch). Just wanted to clear that up.

Geri · Moderator Reputation: 111 Joined: 05 Feb 2010 Posts: 5636

Yes, that has cleared it up, thanks. Smile

So You need to check the stack to see where is the value coming from.

CE6 has a feature to log the stack with the "Break and trace" option, it would probably help. Or just debug it manually and check where is the value added to the stack.

BleachFan · How do I cheat? Reputation: 0 Joined: 01 Dec 2010 Posts: 8

Quick question:

When I find where the values (i.e. static data section of exe/dll) are mapped in memory, what will the memory sections window show for that area?

I encounter address 0x0CA3D000 consistently in calling function and 0x0CA3D000+D0 -> 05B0. See attached image for properties of this region.

The section is marked read/write though. I would've expected it to be read-only.

Geri · Moderator Reputation: 111 Joined: 05 Feb 2010 Posts: 5636

When You search for values, usually it is enough to scan the writable area, while when You are searching for codes, You need to check the read-only regions too.

BleachFan · How do I cheat? Reputation: 0 Joined: 01 Dec 2010 Posts: 8

I tracked persistent storage for these variables to an offset (D0) into a 4758-byte heap alloc (currently at 0x0C63AF98).

This memory is allocated once (at startup), is not reallocated when the engine reinitializes itself, and its base pointer is passed around practically every DLL, several times per frame. It's probably a global data structure of some sort.

Now the ideal thing to do would be to set a watch for that address and start the program to see what code writes var1 and var2 into the global data structure. But there are two problems:

(a) It is allocated on the heap, so the address probably varies. How do I watch for writes to an address that I don't know until after it has been written to? I bet if I could watch for a 4758-byte heap alloc it would lead me straight to the code (or data file?) I'm looking for.

(b) CE cannot start the program; it crashes with a securom error, probably related to elevated permissions or bad path. By the time I start the program, switch to CE, connect the debugger, and pause it, the memory is probably already allocated.[/b]

UPDATE:

No, those variables get overwritten even in the "global data structure."

I'll have to trace back further.

Geri · Moderator Reputation: 111 Joined: 05 Feb 2010 Posts: 5636

Maybe You should try to use another debugger and trace the whole process from the startup. Either manually or using a trace option. Or try using another version of CE or another debugger option in CE.

BleachFan · How do I cheat? Reputation: 0 Joined: 01 Dec 2010 Posts: 8

I found a huge function that initializes most of the app, but it actually pulls the values I'm looking for off the stack. Immediately before this there's a loop with a losd instruction inside, plus a few call instructions that lead to more losd instructions. Intel reference says losd/insd read and write strings to I/O ports. Any idea what they do? File I/O? Some optimization generated by the compiler?

Geri · Moderator Reputation: 111 Joined: 05 Feb 2010 Posts: 5636

Probably it is putting some string into the stack, You should be able to see what is it if You check the stack before and after the operation.

I kinda lost track of Your progress. What are those values that You are trying to track?

I don't know if You have tried that, but from the image that You have posted, these values are positioned right after each other in the stack. So what would be if You would search for both of them as an array? Maybe they are after each other before they are copied too. Or at least close to each other. You can also use wildcards when You search for an array. If they are not too far from each other, You should be able to find them.

For example lets say You have two values (I just guess two random values):

12345678
87654321

Then You could do an array of bytes scan like this:
1234567887654321

or like this

8765432112345678

or using some wild cards

12345678 * * * * 87654321

BleachFan · How do I cheat? Reputation: 0 Joined: 01 Dec 2010 Posts: 8

I don't know what I'm doing anymore with this hacking.

The two values I'm looking for are part of a GUI drawing resolution: width and height.

(No, it's not a DirectX resolution or a Win32 window size, this is part of the game's logic that draws its GUI into only a portion of its window.)

For some reason the game's code always initializes its GUI's virtual resolution to 1280x1024, in which every one of its controls is defined, and then the whole coordinate system is downscaled (< 1280x1024 physical resolution) or upscaled (> 1280x1024 physical resolution) to fit into the game's window. This is not necessarily a bad approach.

The upscaler works well. It's actually smart enough to draw text at higher point sizes, for example, instead of just upscaling the pixels. But the downscaler is absolutely horrible: It chops off whole rows of pixels from text, controls, etc. stretches or squashes all the elements in a seemingly haphazard method so the whole thing ends up as a distorted mess.

I've already rewritten the XML files that define the GUI to use a 1024x720 coordinate space, which is the smallest horizontal (1024x768) and vertical (1280x720) resolution the game supports. It works OK and is usable. However, the game's code assumes the files are still 1280x1024 and so my 1024x720 GUI is still downscaled to fit into a small portion of the 1024x720, when it should be rendering 1:1.

What I need to do is modify the game's code (or wherever the 1280x1024 value is located) to assume 1024x720. This IS possible and I've hacked it before, but (a) the values always move around in memory, and (b) only the drawing code was affected (not the input!) so I must look for the source of this data (i.e. either code in exe/dll or one of their data sections).

Many times over, I've checked every text and binary data file in the game's folders. They do not contain this information. It's got to be in the exe/dll files somewhere.

The exe is securom encrypted. Blasted encryption. The game's code in memory (0x00400000 to 0x006xxxxx) does not match the exe's image on disk. I searched for some opcode bytes in the .exe as shown in CE's memory view and couldn't find them anywhere in the exe image on disk. It's completely scrambled.

The DLLs appear clean though. Luckily, I found both the GUI drawing code and the global variable initialization code in the same DLL. I've been tracing the code. The variables appear in lots of places. They are stored, in static uint32's called cUIRenderWrapper::ourRenderWidth and cUIRenderWrapper::ourRenderHeight, twice (?) when the game is initialized and then every time certain graphic settings (e.g. resolution, AA, HDR) are changed.

Changing the two variables directly affects how the game renders its GUI. When I set them to 1200x720 -- I have no idea why the game must see the width as 176 higher than the actual value, but that's how it works -- the game renders my 1024x720 GUI 1:1 (or upscaled). Hurray! But IIRC the output is off-center, as if the game is still using its old x and y offsets assuming it must downscale from 1280x1024.

So I have been looking for where these 1280 and 1024 values are to be found, earlier in the game's initialization code. No luck so far.

I found cRenderGlobals::init, which is a huge function (thousands of bytes of opcodes) that is called at startup (and whenever graphic settings change). This function appears to uses string operations around init+3Cxx and finally the values I'm looking for are found at init+3CF4, followed by some loops that enumerate all possible resolutions -- why it does this, I don't know.

Most of this stuff is done using xmmN registers and FP(n) stack, neither of which CE keeps in its trace. I can't step through the code. Doing any debugging operation other than the automated Break and Trace causes the game to quit with a 0xC0000005 access violation. It probably doesn't like losing its DX resources (due to CE taking focus as I manually execute debugging operations) while its graphics init functions are paused.

Securom won't let the game start from any debugger. It tells me that it's incompatible with loader programs and quits. I tried CE and Windbg: same result.

I configured CE to auto-connect to this game and then setup a hotkey to pause the game so that I could very quickly setup a break and trace before the game's first called to cRenderGlobals::init, but sadly the variables only pass through the xmmN and fp(N) registers, which as I said CE doesn't store in the trace. So I got nothing.

The string/stack thing sounds interesting. I will check that out.

Oddly the exe's data section has many instances of 1456, 1280, and 1024 as strings; however, changing them had no effect. Most likely they are related to stats or constants. The game uses LUA scripting for many of its events and variables, so there's a bunch of that in the data section.

Searching for binary values of 0x05B0, 0x0500, and 0x0400 in code, data, or memory is like looking for a particular straw of hay in a bale. They're everywhere. The variables I'm looking for are sometimes stored next to each other. They are sometimes floats, they are sometimes integers, they are sometimes in width,height order and sometimes in height,width order. Sometimes they are far apart (e.g. 50+ bytes) and sometimes they are only a few bytes apart.

Yes, it would've been nice if the developers had defined them like so:

struct WH { int width, height; };

...and then just declared instances of struct WH all over the place, i.e. on the stack, the heap, in class definitions, in constants, etc. But they didn't. Apparently they just threw the width and height variables in at random places in class/function/struct definitions, with no consistent relationship between them. Very annoying.

UPDATE:

Until now I've been intent on finding and changing the original variables containing 1280 and 1024. If I change them to 1024 and 720, everything else dependent on them should "just work."

But there's another approach, one that's quick and dirty, requiring 2-3 codes.

1. Rewrite the cUIRenderWrapper::setScreenDimension (uint32, uint32), which invariably is called with parameters (1280, 1024), code to store my constants (1024, 720) into the globals cUIRenderWrapper::ourRenderWidth and cUIRenderWrapper::ourRenderHeight.

The above gets the game drawing the UI 1:1. But it is still offset partially, such that the top-left corner of the UI is not in the top-left corner of the game window and the bottom-right corner of the UI is outside the bottom-right dimensions of the window. So now I must find the offset and adjust those, too.

2. We find the offsets. (to do)

The above should get the UI drawing 1:1 and properly aligned within the window. But the mouse-input-to-UI mapping may be off. Testing is required.

3. (to do)

Geri · Moderator Reputation: 111 Joined: 05 Feb 2010 Posts: 5636

I see You have analyzed the program in details, btw. You can see the XMM registers too in the logs.

And about the debugger crash, it would probably take some time to experiment with it to get it to work.

It is hard to say any more about it, but if You know where are those values used, You can really change the code itself to use Your values instead of the original ones.