Backtracking a Complex Pointer - When Do I Give Up?

[Zach]

I'm trying to write a small trainer for Mercenaries 2, so the first element I attempt to track down is the player's current ammo since, well, that's a good place to start since it can be easily altered in-game (i.e., fire your gun).

The problem is that the pointer de-referencing never ends!

This is where I'm at so far:

Code: Select all

[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[1E8E8D20h+C]+C]+C]+C]+C]+C]+C]+C]+C]+C] \
+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C] \
+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+28h]

(I added the line breaks in the above expression only so not to have this thread horizontally scroll to infinity. )


(The above has less addresses listed than implied in my Evaluation Expression because when I saw a consistent increment in the addresses, I just went to the Hex Editor and manually determined the addresses and offsets.)

I'm a programmer, but this is actually the first time I ever bothered hacking a game. Has any one here with actual experience hacking games ever seen anything like the above? I don't get it. No one can write code this poorly and inefficiently. Then again, Mercenaries 2 is a glitchy and buggy PC port, so maybe this is why.

So am I missing something?


P.S. I can't seem to debug the game which would be a lot easier way of finding the static base pointer no doubt, at least for me. I've tried both with MHS and even Visual Studio, but when I break on a breakpoint, the game screen freezes (obviously ) and Windows refuses to redraw anything on the desktop other than the taskbar. I end up having to kill both the debugger and game processes to regain control of my system.

Any thoughts on this would be appreciated as well.

[poilkioi]

Have you tried the debugger/disassembler? I've found it to be a lot more efficient pointer finder . Right-click the ammo address in the main window and select "find what writes this address". The disassembler window will open with a Helper window. Click the address in the Auto-Hack tab of the Helper window. If nothing shows up in the middle part of that window go in the game and change the ammo value. Now click on one of the lines in the middle window and look at the Disassembly line. If it shows a MOV instruction with [A_REGISTER+OFFSET] then the bottom part of the Helper window will contain your player's base pointer listed next to A_REGISTER, and the offset was shown already. Use this pointer to continue the search for the static pointer of the player.

-Dan

[Zach]

That's already how I am doing it.

As I explained, though, every subsequent pointer is just a pointer to another pointer. It's madness.

Ideally, I'd like to be able to put a breakpoint there and halt the execution entirely so I could step out of the function, but as I explained in my "P.S.," doing that freezes the current frame and Windows refuses to repaint the desktop when I alt-tab back out of the game. No clue why. I messed around hacking GTA-SA last year and I was able to halt the game and alt-tab back out to Visual Studio just fine.

[CoMPMStR]

In my experiences most single player games, and even some online games, have repeating pointers to confuse the hacker and make them go around in circles. It's very tedious work and time consuming to find the correct complex address. What I do is stop at the first static address I come to, the ones in green. Then I reload the last save, or restart the game, to make the address change and see if the pointer I chose works correctly. If it doesn't I just try another combination. It's mostly trial and error, just remember, it's not always the lowest offset in the list. That's another trick they use to confuse you. Also, the complex address doesn't necessarily have to begin with the offset you found in the disassembler. Just like rules for everything else, there are exceptions.

You could also use the expression evaluator to assist keeping track of the offsets you've chosen already. Then when you do subsequent pointer searches, you can see if any of the offsets you've chosen before are showing up again.

If you want to try setting a breakpoint at that location, try running the game in window mode. Then when it pauses the process, you can alt+tab and gain focus to the disassembler, then use the hotkeys F7/F8/F9 to step thru the commands. That doesn't necessarily mean that the game window will minimize and repaint the desktop, because the process is frozen, but it does allow you to move the window to the corner of the screen before the breakpoint is executed. If the game itself doesn't have an option to run in window mode you can always try using a program like D3DWindower that runs any game in window mode.

If you're having too much trouble finding the correct pointer, you could always write a code cave to make it do what you want. The bad part about this is that most of the time the effects work for the CPU as well. So if you write a code cave to give youself infinite health, the CPU will probably have infinite health as well.

When I get this game I'll see if I can produce any results.

[Zach]

You could also use the expression evaluator to assist keeping track of the offsets you've chosen already.

Yeah, check my screen shot. Actually, that is/was the most time consuming part as the expression had become so long and unwieldy it was a pain to edit it to enter the new location: lots of scrolling, etc.

..., try running the game in window mode. <...> D3DWindower

That idea finally popped into my head an hour ago (while I was watching American Gangster on HBO). The game doesn't directly support Windowed Mode, but I remembered a program cited over on the GTA-SA forums a couple of years ago (thread is probably archived and gone by now) about how to get GTA-SA to run windowed. I never had a problem hacking the game in fullscreen mode, so I never bothered with it since Alt-Tabbing was very quick and not that annoying for what I was doing. (I was just messing around with addresses and instruction streams other people were posting, not hunting down anything myself.)

Anyway, thanks for the reference ("D3DWindower"). I'll check it out.

------------------------------------------------------------------------
UPDATE: Found and tried D3dWindower, but it just crashes the game up startup:



I had my hopes up for a second as the game DID start up in 800x600 (what I set it to) windowed mode, but before the first logo screen, crash. (Maybe if I zero out the .bik files.... hmmmmm... ) Anyway, thanks for the suggestion, but I guess I need to go dig around the GTA-SA forums and find that other app I alluded to.
------------------------------------------------------------------------

When I get this game I'll see if I can produce any results.

I'm certain you will find the pointers in a matter of minutes. Actually, there already are a couple of trainers out, so I know this isn't impossible, but they incredibly lag the game, so to speak. The game stutters, be it whether I'm running on foot or driving in a vehicle, so literally every 3-5 seconds the game freezes for half a second. Very annoying, hence my quest to write my own trainer.

[CoMPMStR]

The other window mode app I heard of is called dxwnd. In my experiences with it, D3DWindower works where dxwnd hasn't worked. I still have a few hours before I have the game for myself so I can't actually test anything just yet. Tomorrow I'll be able to see what I can do with it.

I did notice the screenshot after I posted. I noticed from it you were picking pointer addresses that are very similar and close to one another. These addresses are mainly there to confuse you, the hacker. I might not find any working pointers, it's hard to tell without having the game in front of me. The next best thing, which might be what the other trainers do, is to make a code cave. I don't think many people take the time to find pointers, especially for single player games, even though they are much better than using code caves.

[L. Spiro]

The problem is that the pointer de-referencing never ends!

This is where I'm at so far:

Code: Select all

[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[1E8E8D20h+C]+C]+C]+C]+C]+C]+C]+C]+C]+C] \
+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C] \
+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+C]+28h]

It does end, but it may be after thousands of dereferences.
What you are seeing is a linked list of all the game objects (or all the game objects of a specific type).
Since there could be thousands of objects in the game this list could go on for a while.
Since you are a programmer you should be able to see how each object is pointing to the next object in the list, and of course the offsets are the same for each because they are pointing to an object of the same type.


Furthermore, since this is a linked list, your player object could be anywhere in the list. The order of the objects will never be certain.
The only way to make the address is with a Script Address which runs through the list to its end and for each object it checks a flag that determines if the current object is your player or not.
But sometimes the game stores a special pointer trail straight to your player. The alternative is to simply find and use that.


As for all the talk about game makers adding distracting pointers and useless data to prevent hacking, you give them too much credit.
90% of all game programmers do not even know how the data looks in RAM nor the popular methods for hacking it out. Remember, even if the game comes from a large company, most of its parts are outsourced to smaller companies. The core engine may be produced by a highly professional team, but the core needs to be friendly to use for all the basic programmers who will be working on games with it later. If the programmer added all the mess of distracting pointers and what-not, he or she would be fired. Furthermore, they simply would not have the time to do that. It is enough work just to make your own 3D animation format and run it in the game without bugs.


L. Spiro

[Zach]

Well, it's not a matter of me picking the addresses. There's always just one and only one to choose from.

Well, the initial search for the in-game ammo count always yields six (6) addresses, and the game is definitely maintaining six copies. And if I change the value (i.e., adjust the ammo count) of one of them, it nearly instantly changes back, so there is also some in-game sanity checks going on.

But anyway, after starting with any of the six, then it becomes very linear: ptr[n-m] --> ptr[n-3] --> ptr[n-2] --> ptr[n-1] --> ptr[n], etc. where ptr[n-m] would be the static address if I ever found it. (FYI, my original post above was based off the first of the six. I'm now working my way through the other five, and I have one more to go, but I'm still seeing the same pattern.)

I really need to step through the program to verify some assumptions I'm making, but then again, plugging my found addresses/offsets in the Evaluator yields the proper results, so it's definitely a puzzler (for me).


Oh, well, I'm probably just doing something boneheaded. But maybe not. That laggy trainer is probably doing what you are saying (using code caves) because he couldn't find the address either, hence why it's laggy.

[Zach]

Since you are a programmer you should be able to see how each object is pointing to the next object in the list, and of course the offsets are the same for each because they are pointing to an object of the same type.

Well, yeah, I already mentioned that, or alluded to it anyway, when I stated that I determined many of the addresses/offsets just by examining the raw memory in your Hex Editor. Sorry I wasn't clear.

But the notion of a scripted address search is promising. Looking at the memory dump, it seems to be a singly-linked list, though, so I still need to determine the static address for the pointer pointing to the first node. So different data, but same problem.

[CoMPMStR]

As for all the talk about game makers adding distracting pointers and useless data to prevent hacking, you give them too much credit.
90% of all game programmers do not even know how the data looks in RAM nor the popular methods for hacking it out. Remember, even if the game comes from a large company, most of its parts are outsourced to smaller companies. The core engine may be produced by a highly professional team, but the core needs to be friendly to use for all the basic programmers who will be working on games with it later. If the programmer added all the mess of distracting pointers and what-not, he or she would be fired. Furthermore, they simply would not have the time to do that. It is enough work just to make your own 3D animation format and run it in the game without bugs.

I wasn't saying the game developers are purposely adding distracting pointers. I was saying that's just how most games are made.

Everytime I do pointer searches on the newer games, there are at least 10-20 pointers that resemble the previous address I was searching for, and most of the time none of those addresses have anything to do with the correct complex address. Sometimes there are even multiple pointers with the same offset and if you choose the wrong one it will bring you around in circles too. That's why I say they have pointers there to confuse you. I don't actually know the specifics, I'm just going by what I've noticed when I search for pointers. Sorry if I caused any confusion.

[Zach]

Okay, now that I've gotten a good night's sleep, I'll try a new approach.

The structure I'm looking at after finding the ammo slot is definitely not any type "player" structure. I knew that from the get-go, actually, since next to the ammo was the clip count and next to that was the clip size, but no where in the struct is any type of health, armor, or location info.

So in retrospect, I've just been wasting my time for the last two days as there probably is no static pointer to find!

So now I guess I'll go track down the player's health, and undoubtedly from there it will be easy to track down the base pointer to the player structure. (And when I find it and then find the pointer to my ammo/weapon structure that I have been tracking, I'm going to laugh at myself. )

Oh, well, it's all a learning experience, and I'm having fun.