Hydra Absolute Position in FPS

[MSat]

No, I wasn't thinking of saving and restoring an entire game state, but rather keeping a consistent state the game is initialized in. So it's the "computer state" that's shared.

Besides memory management by the OS affecting the actual location of variables in memory, what would cause a program to change variable addresses each time it's run? It sounds like this is done deliberately by the developers presumably to deter cheating. Since we know the computers aren't inherently random, the developers are using some aspect of the computer's state to "randomize" variable addresses upon initialization (and perhaps run-time, but lets ignore that possibility for now). The idea is to maintain the state of a VM, so that when a game is initialized, whatever state data it's using to randomize these addresses is consistent. As an example (I know this is a bad one, as it could cause major problems if it was used, but it's the simplest way to explain my point) lets say upon startup of a game, the game requests the current date and time as a seed for its randomizing algorithm - if the VM always returned the same date and time, then the results of the randomizer would always be the same, therefore variable addresses would be consistent, and their locations only need to be determined once. It would be this machine state that users would need, and not the game state.

As for the VM, I don't think it would need to be a full-blown one - "just" one that initializes the memory space and partially intercepts OS calls - the latter possibly only during game startup. While I know this won't necessarily help with games that encrypt their variables, or games that change their values at the start of new missions (they way it sounds like Comanche4 does), it might still be viable option for plenty of other games.

[StreetRat]

I dont think such a thing is possible.
Most games fall into 2 categories, the older style with static memory addresses, or most if not all the new ones with dynamic memory addresses.

The variables usually change depending on what is loaded and what has to be loaded next.

Say you have just loaded up a game and your memory location is x (contains your view, rotation, location etc for simplicity), the game then proceeds to load up parts of the map new textures etc, and new npcs as you get in range. You then die.
Some games will use the same memory location x and just reload everything from that, others will reload everything new, but now you have new textures or npcs to load so everything changes a bit and you get memory location z

Most newer games ive played around with dont really treat you as anything different to the other npcs.
Just like you, they have an orientation and direction. So all npcs are put into one big list which it just cycles though when it has to load stuff. And that list changes when new npcs are added or removed

However, since the game still needs to know you from them to display the output on your monitor, it does keep track of which person you are.
Its just a matter of finding out who you are and which way you are facing.

On games that keep the same locations throughout a vm might work, but on games like that it would be just as easy to finding the base location the game uses. Most games reset everything on a reload or new level though.

[Fredz]

Wouldn't it be possible to detect the correct memory addresses by trial and error first, then find every occurences of these adresses in memory ? I guess that some functions use these adresses, so it may only be a matter of identifying these functions by a know signature to always get the correct memory addresses.

[WiredEarp]

Thats quite an innovative idea MSat, but I agree with StreetRat in that I dont think it will be possible, easily. The memory locations change due to other things being loaded first etc, so you'd have to contrl all of that. I don't think its just that the game itself is randomizing the memory positions (although, this might happen with some games...).

However, the part about intercepting OS calls is a possibility, in that for difficult games, you could find the code being called for a particular function that you knew was associated with the player view in memory, and then watch what variables that code looks at to find the correct memory locations. Is this what you were talking about Fredz? If so, I think that can/will work. I dont see any way to identify the addresses without tracing them to a function, as there are craploads of variables with identical numeric ranges.

[Fredz]

Is this what you were talking about Fredz? If so, I think that can/will work. I dont see any way to identify the addresses without tracing them to a function, as there are craploads of variables with identical numeric ranges.

Yes that's what I had in mind.

Actually I programmed a memory hack a long time ago (in the MS-Dos days) to have unlimited lives in games using a similar technique. Basically I typed the value of my current life count, let the app find all the corresponding values in memory, die in game (so life - 1), let the app find the new value in the list of addresses, then memorized the address if it was unique. If it was not I would repeat until it was the case. Then I was able to type a specific value that my interrupt code would always put at this address.

It would be harder to do for values you don't know beforehand like orientation from the mouse, but
I would basically do something like that :

Find the orientation values :
- cut the memory in manageable parts ;
- for each part :
- save it ;
- move the mouse ;
- find the list of addresses whose content changed ;
- repeat until you know which part of memory is concerned.

Some heuristics could be added to only look for known representations of this kind of data, like consecutives bytes in memory (12 or 24 for 3 euler angles, 16 or 32 for quaternions), matrices orders (3x3 or 4x4), an arbitrary max number of bytes (128) or even something based on the differences in values if mouse movements are kept small. I would then use the typing method to verify that the orientation is correctly modified using the new values.

When the memory addresses are known, I would then try to find the addresses (not the values) in memory using exactly the same method, but maybe with different heuristics based on the common methods for calculating orientation matrices or angles. With the same typing method I would be able to identify part of the code where these values are calculated, and I would log all the values in a wide range around these addresses. After playing a little bit, I would get the values that don't change over time, that would be the signature of the function.

Then, whenever I would launch the game, I only would have to find this signature and feed the corresponding memory addresses with the values from my tracker.

[MSat]

Ah, ok.. Thanks for the clarification, guys. I'm really not familiar with this topic at all.

For a trial and error method, would it be practical to automatically generate a sort of test pattern, and scan variables in memory that appear to correspond with the changes?

So for instance, run a couple of cycles using something like a mouse/joystick emulator to detect the X axis:

MouseDeltaX(10)
MouseDeltaX(-10)
repeat

Assuming most data variables in the game wouldn't oscillate like this, it should be easy enough to isolate the corresponding values in memory. Does that sound plausible?

[WiredEarp]

@ Fredz: Thats a very smart idea that I never considered. I think I understand, but correctme if i'm wrong - basically, you are eliminating the need for a base pointer, by refinding the hack addresses, using an automated version of the Cheat Engine type method that we are using to discover the memory addresses manually. I see no reason why that would not work fine, and while it would take a few cycles to gather the data, since it was automated it would most likely achieve a match very quickly. However, I think this would require significantly more work than existing methods like using base pointers (since you have to hack the game first, find the addresses manually etc, before you can generate an automated way of doing so) but in those difficult cases this could be one of the best solutions.

Your function signature idea I think is similar to pattern matching (just more sophisticated) - simply memory matching on some common variable. For example, in Comanche 4 I found out that the yaw was always 216 bytes after the username (which is easily retrieved from a data file). There were several places the username showed up, but since I always knew that the yaw variable was in a certain memory range, I could just search that range for the username and add the offset to quickly get the address. I experimented with manually finding variables that didn't change to make that into a signature type thing like I think you are referring, but didn't have much luck - an automated method however could work very well.

[StreetRat]

@ Fredz:
Thats what some of the trainers you find around the net do, they modify the code of the program, either in the exe or in memory, rather than just the memory itself.
When you start doing that you can come into laws against reverse engineering or modifying the game, where as, as far as i know, the memory values are created separate and theres no law against changing them.
So i was trying to stay away from that approach.

On top of that you will still run into a problem of different versions of the same game requiring different memory hacks, but really anything you do will have the same problem.
Another problem is some games have anti debug code so if you attach a debugger to search for locations, the whole game crashes. Thats the problem im having with Crysis.
There are some ways to get around it but i havent been bothered looking in to them.

This whole thing was just meant to be a basic app to map hydra orientation to ingame orientation in a 1:1 setting.
I guess the more people interested the more extravagant the solution can be.

@ WiredEarp:
The intercepting OS calls is what i was thinking about at first, since there are some standard directx calls that are related to view only, and they might work in different games, so its definitely worth a further look even if it wont do all games, they should do a few.
The biggest problem is games that write there own versions of these functions, but there usually only in the bigger engines, and once you have the location for that it shouldnt be too hard to get it for any game that works on that engine.

@ Fredz:
Thats kind of what were doing now, but programs like Cheat Engine have options to search for Unknown values, increased or decreased values, values that have or have not changed, so its easy enough to find most values that you want. The problem comes when you have 200 values almost identical and trying to find the one that you need, then finding the base address for that value.
Im not sure getting the computer to do the complete search would be any better or quicker, as after a while you start to get a feel for what looks right within the values.
Although searching for more complex data within ranges might make things a little quicker.
IE, at the moment to find a matrix you have to look for each value separately, which is a nightmare, but if you were to use your approach and look for a matrix at once, knowing what a 'base' matrix in that range looks like, then it might be easier to compare and find.

A completely automated system wouldent work, but semi automated might work.

[MSat]

How much do the desired addresses tend to vary each time the game starts or is reloaded? Wouldn't it be possible to (semi-)manually find these addresses a number of times, and then build a profile for a run-time based automated system that looks for expected values within a certain memory range?


Though now that I think of it, this problem sort of reminds me of a suggestion I made for FreePie - that is, emulate a joystick, and enable lookspring in the game. Vertical movements of the motion tracker (IMU, Hydra) are mapped to the virtual joystick's vertical output (and therefore should be able to be mapped 1:1 along this axis). The horizontal axis is a little bit trickier, as you have to convert velocity from the device to an appropriate joystick "amplitude". Some of the downsides with this method is that while you can set the absolute position along the vertical axis, it's not possible along the horizontal. Though this might not be a huge deal in games where you use an analog stick anyways to supplement those movements (which is sort of what John Carmack did with Doom3). This might not be ideal for non-FPS games, or perhaps even impossible for FPS games if they don't have a lookspring option, but those that do, it would be a fairly simple approach with no game hacks required. Of course, this doesn't help will roll - but perhaps that can be fudged with some sort of post-process shader if necessary?

[Fredz]

However, I think this would require significantly more work than existing methods like using base pointers (since you have to hack the game first, find the addresses manually etc, before you can generate an automated way of doing so) but in those difficult cases this could be one of the best solutions.

Yeah it's not going to be easy to implement, I'll have a go at it to see if it's workable.

I experimented with manually finding variables that didn't change to make that into a signature type thing like I think you are referring, but didn't have much luck - an automated method however could work very well.

I'll need to experiment as well to see what works best, my heuristic ideas were just off the top of my head, by going deeper into it I may find more effective ones. I may have a try with some games for which the source code is available - like Doom 3 and others - to have a better idea of how functions related to the orientation matrix are converted to binary code, both in OpenGL and Direct3D.

Thats what some of the trainers you find around the net do, they modify the code of the program, either in the exe or in memory, rather than just the memory itself.

Yeah I know that, I've implemented this long before any of these programs were available in the market (published in a comp. review in 1995). Basically it worked with a "terminate and stay resident call" that was then called by an Interrupt Service Routine which intercepted keystrokes and scanned the memory.

When you start doing that you can come into laws against reverse engineering or modifying the game, where as, as far as i know, the memory values are created separate and theres no law against changing them. So i was trying to stay away from that approach.

There are no such laws in my country (France) and neither in Europe, there is even a law that protects us from such abuses (Art L122-6-1 of the CPI, right to decompile in order to achieve interoperability, among other things). That's also the case in many other countries, including the USA. I'd be curious to know in which country you live in where it's not the case.

On top of that you will still run into a problem of different versions of the same game requiring different memory hacks, but really anything you do will have the same problem.

There are certainly different memory mappings for different versions of a game, but I'm really not sure there would be much differences in the function used to calculate the orientation matrix. If this function stays the same through the different versions of the game, then the signature would be identical and the method would work for all of them without having to rescan memory.

Another problem is some games have anti debug code so if you attach a debugger to search for locations, the whole game crashes. Thats the problem im having with Crysis.
There are some ways to get around it but i havent been bothered looking in to them.

Nice to know, I guess this should really be a problem. I'm currently using Linux so I may try fiddling with Wine to test that since I'll have more access to the underlying system.

This whole thing was just meant to be a basic app to map hydra orientation to ingame orientation in a 1:1 setting.

Yeah, nice that you started this thread, I didn't think about it but it would be a great way to feed my stereo 3D Linux driver with my head tracking readings.

[StreetRat]

@ MSat
Ive had some games that recycle addresses every 2 - 3 reloads, others that never use the same address after 10 - 15 or so reloads.
So it depends entirely on the game


@ Fredz
About the laws, i admit i had not really looked into it, only what id seen in the EULAs and such, and they usually say its not allowed. But upon a quick look, we have a similar law that does allow decompiling it for interoperability.
The question i guess is, do thoes laws allow for modification?
As far as i know, if you change the programs files on the hard drive, thats not allowed, if you change the program flow in memory then thats fine. Again, i havent looked too far into it so i could be wrong.

If the game uses directx calls say, and your modifying them then they should remain in the same spot since the dll is loaded separate, so you get the location of the dll and everything you need will be the right offset from that.
Something like OllyDbg can get the offsets of loaded dlls within the game so its possible, i just have no idea how they do it as of yet.

Anything within the exe iself or any dll that has been changed will change the location of the function within but if you have found what you need once, then finding it again for the new version shouldent be hard, the modification will probably be the same just a slight initial offset.
Both OllyDbg and Cheat Engine have a way of listing function calls within the code and searching for them so if you know what function it should be easy to find.

[Fredz]

About the laws, i admit i had not really looked into it, only what id seen in the EULAs and such, and they usually say its not allowed.

Most of the time EULAs are abusive, and in the end only the local laws count, what's in the EULAs has no legal basis.

The question i guess is, do thoes laws allow for modification?

Go to END for the executive summary.

As long as you legally obtained the software and you keep the modifications private there isn't any problem. That's just like modifying an electronic device you own, nobody can't prevent you to do anything you want with it. Except in some rare cases where it's considered dangerous. In France it was illegal to modify a Minitel for this reason for example, but I'm not sure it really would have stood up in a court.

If you publish your modifications, it depends on the type of modification you did. If it's solely used to circumvent a digital protection scheme without a need for interoperability, then most of the time it's illegal in most countries.

If the goal is interoperability, and even if it's a digital protection circumvention, then it's legal at least in the USA (DMCA 17 USC § 1201). Such circumventions are also allowed by European directive 2009/24/EC, but nothing is said about if the information can be made available. The previous law of 1991 didn't allow that, but there are no such limitations in the current law, so it should be allowed.

Still, you can't publish modified copyrighted software, you need to publish information that can help doing the interoperability modification or provide a software for which you own the rights able to do this.

== END ==
Basically that's what has been done for iPhone jailbreaking, and it's legal in the USA and considered legal in most countries in Europe. In our case there is no digital protection circumvention, so it should be legal in USA and in Europe.

[cybereality]

Woah! You use 'GOTO's!?!?! I thought they were evil!!!

[Fredz]

Yeah, couldn't resist, one of the first instructions I learned when I started programming.

[StreetRat]

Excellent, good to know we can have some fun.

I think ive also maybe cracked Crysis, they do it a rather weird way, but i think im almost there.
Also had a look at freepie and trying to get the two to work together.