Tips for analyzing game entity array

[poilkioi]

Hi,

I've been hacking a game using MHS to search for pointers and offsets (the color coded hex editor is a great), and a custom c++ program to read and write process memory. I've got to the point where I've found the static pointer to the start of the array of game entities. I also know the offsets for each entity. But when running the game the entries get bogus values (I assume because the game invalidates that element for future use). I have to find what offset determines the status of the entity and whether it is actually used (to determine if a readprocessmemory is useful at all). Also I would like to know the length of this array. At least I hope it is an array and not a linked list or other data structure. So far I've only done pointer searches. What is the best way to continue, what should I read about?

[L. Spiro]

Finding what dtermines if an entry is valid or not could be done in any number of ways. There is no generic answer to suit all cases.

It it usually via a NULL pointer, but if there is not one, then there may be an ID near the start of the entity that dictates what type of entity it is. If it is not a player entity but you display it as one, you will get junk.
This ID can be a simple number or a bit mask; a bitmask would include all base classes to which the object can be cast.
To know if it uses one or the other you have to find out on your own. The value, however, must be part of the lowest base class in the chain, and so the value must be near the base address of the entity.


The normal ways to find the length of the array:
#1: Fixed arrays show up as a long set of purple values in the Hex Editor. You can select the whole range and divide by 4. It is usually 1024 or 4096 or some power-of-2 number such as these.
#2: The array may end with a NULL pointer. Look for it.
#3: There is a number indicating the length of the array just before or after the pointer to the start of the array. Count the size of the array manually and look for that value near the base pointer.


The Expression Searches in the next release will help you a lot with this.


L. Spiro

[poilkioi]

Thanks for the quick reply (convenient time zone difference, I'm from the Netherlands), this will help a lot.

- Dan

[poilkioi]

I guess I was getting a bit tired of looking at hex code last time I tried, the array simply consists of pointers which are set to NULL when an entity is no longer in range. I still have the issue of finding out what I'm looking at, whether it is the player (there is also a static pointer to the player directly somewhere else but maybe it is visible in the class itself), a friendly player, an enemy monster, an enemy player.

Here are some of dumps of the first part of each type of class, I have some questions which I hope you may be able to answer:

The start of the class is indicated by the value 0x972988, is this a pointer to something?

At offset 0x30 the height information is stored (float value 0xc44336cf in the first image), and it is repeated at offset 8c, does this copy have anything to do with base class and subclass?

At offset 0x24 there is a pointer to its own address, is this just a placeholder or a boundary of some sorts?

This game is probably compiled with VS2003, I'm searching for documentation on the compilation process, especially inheritance translation.

player


player (another dump of the player from different session)


teammate


teammate 2 (different teammate,which is also a pet)


enemy player 1


enemy player 2 (different enemy)


monster 1


monster 2 (different monster)

[L. Spiro]

#1: 0x972988 is a pointer to a function-pointer table. Follow this pointer, and then you will see a list of more pointers. Each pointer points to the start of a function related to that class.

#2: Position data often has multiple copies. Proper modular design dictates that the physics engine should be interchangeable and the game may even work without it at all. In which case the player class has its own position, but when attached to a physics engine it inherits from a base class which contains all the information the physics engine needs, including position, and instead uses that to determine its real position. In order for the other game parts to work properly it synchronizes its own position value with the one in the physics-related base class. The physics one is the real one. If you modify the upper one, you may end up with a player standing in one location but the camera in another. Or other random junk.

#3: This is common. Although they can have any reason they want for doing this, it usually means their class has a member which is an object, and that object requires a pointer to its parent, which of course means the player class. Then the object can manipulate the player class using its copy of the player-class pointer. It has no other significance.


L. Spiro

[poilkioi]

Thanks for the quick responses to my questions (also the one about timers).

#1 Is there any way to get readable names of those function pointers, that could help with more focused searches. When I made an error related to multiple threads working with a non-thread safe data structure in my dll injected code I got a nice popup from the game notifiyng that I've performed an unsafe operation (was a while ago, not sure what the exact error was, but it helped me fix my injected dll ), could this mean that the game is compiled in debug mode?

#2 When modifying the first height value, my character is positioned nicely in the air, the game does this pretty well, only when I start moving I get snapped back to the ground by the server (no real use, just for making funny screenshots).

#3 So this means the object member is embedded in the player class structure?

[L. Spiro]

#1: No. The game was not built in debug mode. You can not get function names. Any help an error message gave you was probably coincidence, but debug strings may be left in some functions and those are your only clues to function names.

#3: Yes.


L. Spiro