I am pretty sure about this, but I just wanted confirmation.

Is it true that in any win32 program that even though the locations of values get changed at runtime, the distance between those given values will always remain the same?

I stress the word always.

So let's say your game has an address for Lives and another one for Ammo.

The locations of these values will change once the process has been restarted, but their delta will remain the same?


Another question:

Why is it much easier to find a pointer to a 1byte value than a pointer to a 32bit float? It seems that the base pointer for 32bit floats are buried under many dynamic pointers. But if you search for the base pointer to a 1byte value it is always found instantly.

Thanks.

really depends on the way the game was coded....



again, depends on the game, compiler used, language it was coded in etc etc

If the two variables ("values" in question are stored as global variables in data section(s) of the executable image, their distance should always remain the same if the program in question is not having any funny business going on. But for stack variables, objects (OO) and other dynamically allocated types of variables, you can never trust them to have the same distance (even if they might very well have it at many times in these situations too). The distance can also be different between executions if the variables are stored as global variables in data sections of different modules.

About the pointers you mention, I'm not completely sure what you mean, but it is most likely dependent on the design of the program in question, and/or the compiler used.

Is there anything a program needs to always be at the same mem location? Other than a pointer's value?

All the sections in the main executable module (i.e. the exe-file) are practically always at the same memory addresses (main executables are practically never relocated, and most of them don't even have relocation info included in the executable). This means that all data in all code sections, data sections (which means that all static global variables in these always have the same addresses) and other type of sections in the main executable are always on the same addresses. Why do you want to know about this?

I'm not talking about the program's ASM code, I am talking about the live memory.

I basically want a way to resolve dynamic values.

I guess calculating the distance from a given pointer is the only way.

What a lucky coincidence then, because that's what I'm talking about too... All sections of an executable file are mapped into "live memory" at runtime you know...

Yes I know. Sorry.

Anyway, If you wanted to resolve a dynamic value each time the program starts, how would you do it?

That depends very much on what kind of memory value it is, and even more on exactly which point you resolve it at? Do you have any kind of breakpoint in the program and then resolve it, or is it more arbitrary, like you attach to the program "a second or two after it starts" and then try to find it?

Please tell us more details and we will most likely be able to help.

Say for example in an RTS type game, you have a value for amount of gold. Every time that you reload the game you want to be able to read the value for gold into an edit box of your trainer.

But the value for gold is dynamic.


I already know how to do this with pointers, but just wanted to know if there was another way? Sometimes finding the pointer is the difficult part because often the base pointer is burried under many dynamic (fake) pointers.

In this case it is very dependent on the implementation of the target, and without analyzing the code used to access the value in the program itself it could be very hard (especially if it's designed to make the values non-easily found). The only generic approach I can think of is to emulate the search algorithm you used to originally find the value, in your "trainer", but this can be very hard too, since that original search might have involved program interaction and/or trial & error, but it might work.

even if the location of the code changes each time, it still has to use some form of a 'base pointer' and an index type to access it, so your best bet is analysing the code it uses for the index..

say for example

mov eax,[403000] ; load the base pointer
mov ebx,[403004] ; load the index
mov edx,[eax+(ebx*4)] ; load a value from the index..

in this example you would want to read the 2 dwords at 403000h and 403004 hinto your program, then multiply the value you read from 403004h by 4 (because thats how the program does the accessing) then add the value you read from 400300h, thus giving you the 'dynamic' address where the gold, lives, whatever is stored, again the example above will probably vary from game to game etc.. but i hope you get the idea

If you were just swimming through the code, and you saw the line:

mov eax,[403000].

Would you automatically know that it meant: 'load the base pointer'.

The location of where "Gold" may be stored at different locations from run-to-run IF it was in a dynamicly allocated structure (most games actually store such information in globals that don't change location, but that's off topic).

So you want a run-to-run independant way to get at "Gold"....

Obviously, the PROGRAM knows how to get it, right? And one of the pieces of code that gets "Gold" is ALWAYS going to be at the same location, regardless of run-to-run, correct (assuming the code doesn't get relocated)? So why not just call (or duplicate) one of their routines?

If you have Olly, run your program, set a hardware access breakpoint on "Gold", and when it pops up, make note of the function that's using it.

I mean, God, if you can fight protections this way, it should work for "Gold" too, no?

Anyway, an alternative would be just to make everything "Free" so you don't need any "Gold"...

Would those globals be useful in my situation?

Globals are always at the same position in memory. In effect, they are "hard coded" into the program. Variables which only have one instance are commonly implemented as Globals. Even though good programmers loath them, it's still common practice because lazy programmers are responsible for a majority of the bloatware that exists today.

The code HAS to be able to get the data, or else it would be useless. By placing a hardware access break on it, you can back trace when the break fires and figure out how it was referencing the memory.

NOTE: If you see it break on something like this:

mov eax, [ebp-42]

Then you HAVEN'T got the right address, and you will need to search again. The reason is that your search was just a temp variable on the stack. (not actually a bad thing, because if you can repeat, then you can find out what eventually happened to it, or at least where it originated from).

Seriously, I would try breaking some simple shareware apps. You'll learn quite a bit very fast. Most of the Pop games are trivial, and UltraEdit would be a good second step (it has a nifty suprise should you just make the keycheck always return GoodGuy, but finding the memory wiper is quite easy and won't frustrate you at all). A simple hint on these programs is NOT to go after the registration window, but instead to go after where they load in the registration from the registry. So few people attack from there, most programmers don't obfuscate at all.

Anyway, back to "Gold". Assuming you don't want to modify the code, you can write a program that attatches to the game as a debugger, and use WriteProcessMemory to modify your gold values at will. Alternatively, just find out where the "Load Saved Game" is, and modify it here.

Ok, thanks.

I have a lot to think about.

nope, thats where debugging the game comes into play, some code is easily identifiable tho and can usually be backtraced from a string xref such as the text 'Gold' or whatever you're searching for, of course, this can change per application, you just gotta do the hard work of debugging the application/game and analysing what it does.. the answers dont come magically u gotta work for them

Hmm, I thought Aquatic made it quite clear earlier in the thread that he "knew how to do this with pointers" (which require analysis of the code of the specific program, contrary to just use some memory scanner and noting down the address), but was just looking for an easier way, but now it doesn't seem like that at all anymore, hmm...

Anyway, many "big title games" today go to relatively far lengths trying to make it hard to cheat by patching their memory, e.g. by using encrypted memory values, fake/dummy values that will instead be found by the memory scanners, dynamic allocation with many levels, based only in differently placed stack variables and so on, so it might not be as easy as it seems anyway. But of course, with enough tracing and patience it will work just as much as breaking any protection, it's just that it might be quite hard to find a good initial breakpoint in a DirectX game like that, especially when values are encrypted in memory so that memory scanners can't help you to a good start.

Ok guys. The reason I ask all this is because a friend is making an application called Game Trainer Studio.

It needs the user to provide a base pointer, then if you want to freeze a value you just need to enter its distance from the pointer's value to resolve it.

Here is the trainer maker: http://www.gamehacking.com/ipb/?showtopic=7536 (early)


It would be nice if there was a way for the Maker to inspect the game, and then find some kind of base or reference that can always resolve values in memory for the user. That way the user only has to provide an address from their mem-sercher, and the program would automatically calculate the distance from the reference or pointer value.

The idea is to make the program as n00b friendly as possible.

My best idea for full automation would be like follows (which is still pretty unreliable and prone to error, but might work in many cases too):

1.
Find the correct value in memory by comparative search/analysis, like with most of these tools.

2.
Search the program's entire memory space (including stack, PE data sections and all dynamically allocated memory) for the pointer pointing to the closest memory location previous to the value (pointing right at it is of course the best, but not always likely if structs or objects are used).

3.
Repeat step 2 until the pointer you find is located either in a PE data section or on the stack (PE data section is best). Save this memory address, and save all the offsets between the pointer targets and the real values in each step of the chain.

4.
Restart the target program and traverse the same chain of pointers, from the "root address" you just found (the value on the stack or data section), by using the offsets you earlier saved.

5.
Modify the value at the end of the chain. If it affects the wanted property in the game, you are probably right, otherwise you are most likely not.


Like I said, this method can very easily go wrong or be thwarted due to several reasons, but it might also very well work under the right conditions. And if you want a fully automated method it's the best I can think of anyway.

Yep, that's what it does currently.

For example



http://www.222clan.com/up-down/GTM_pointers.zip