Cheat Engine

[ChildOfTux]

Hi,

I'm new to the forums but I've been using CE off and on for a few years. Nothing too heavy or complicated... until now!

I'm making a mod for a game that uses the Unreal 2 engine. The game is Brothers in Arms: Road to Hill 30 (and it's sequal Earned in Blood).

I need to find some memory addresses/stable pointer chains that track certain game states. I've found a rock-solid pointer chain for tracking menu state and one for a particular game mode (Situational Awareness View) but I'm having a ridiculous amount of trouble trying to pin down Aim Down Sights (ADS) state.

I can consistently find 3 dynamic memory addresses that appear to track ADS state. They each hold a 4 Byte value that is either 0 when ADS is inactive or 1 when it is active. The problems I'm facing are manifold however.

Firstly, though these addresses definitely have something to do with ADS state (they consistently toggle from 0 to 1 and back when ADS is activated and deactivated) they will sometimes, seemingly randomly (in that I can't replicate it) change their value to something else - say 33 or 663 or something. I cannot - no matter what I try - find any other addresses or values that correlate so closely with ADS state however.

Secondly, though I'm of course aware that dynamic addresses will change between game and OS restarts, these addresses don't even survive level or save reloads! I'm guessing they're on the heap and are probably something to do with Unreal 2's Actor object - so the object gets destroyed then recreated whenever a new level or save is loaded.

The thing is, logically, the game *must* have a way to track and set ADS state regardless of this. Therefore, surely, there must be a pointer chain *somewhere* that will always point to ADS state, right?

Having perfomed pointer scans on all the addresses I'm yet to find a pointer chain that doesn't break down almost immediately. I've tried chains that originate at the game's main executable (bia.exe) and also in multiple different DLLs. All of them break almost immediately - and the ones that remain don't survive a level or save reload, let alone a new game session.

I need to find a way to check the game's ADS state from my mod. I don't need to write to it at all. I'm going to post my most recent findings at the bottom of this post. I've named the addresses 'ADS 1-#' and included all the instructions that access and write to each address when ADS state is toggled.

Does anyone know what might be going on here? Why does ADS state not appear to be tracked, at least in the addresses I can find, as stably and reliably as menu state and SA view state? Why do the values sometimes change from 0 or 1 to something else, yet seem to be closely tied to ADS state in some way? I don't know enough about Unreal 2 to figure out what might be occuring under the hood here. Could it be some sort of Byte Array where ADS state is one bit flag in the array? Something else?

As an alternative approach I've tried searching for floats and doubles that might be related to FOV (as FOV decreases when ADS is activated and increases when deactivated). Scanning for decreased/increased values as ADS state changes in-game leaves over 800000 results however and I can't see any values in amongst them that might translate to the usual range of FOV values (30-70-90-whatever). The overwhelming majority of the values are in the 2.## to -2.## range.

If anyone can help point me in the right direction for finding a way to reliably read the game's ADS state I'd be much obliged. Thanks!


ADS 1-1 [0E231744]
------------------

Accesses:
02BAFA17 - 83 78 04 FF - cmp dword ptr [eax+04],-01
02BAFA3F - 3B 70 04 - cmp esi,[eax+04]
02BAFA56 - 8B 48 04 - mov ecx,[eax+04]
02BAFA7F - 8B 40 04 - mov eax,[eax+04]
02BD6BA4 - 8B 40 04 - mov eax,[eax+04]
02BD6CD5 - 83 7F 04 FF - cmp dword ptr [edi+04],-01
02BB052A - 83 7A 04 FF - cmp dword ptr [edx+04],-01
02BAE48E - 89 51 04 - mov [ecx+04],edx
109091E0 - C7 43 04 01000000 - mov [ebx+04],00000001
10908C6E - FF 49 04 - dec [ecx+04]
10908C74 - 8B 51 04 - mov edx,[ecx+04]
10908FFD - C1 E9 02 - shr ecx,02

Writes:
02BAE48E - 89 51 04 - mov [ecx+04],edx
109091E0 - C7 43 04 01000000 - mov [ebx+04],00000001
10908C6E - FF 49 04 - dec [ecx+04]
10908FFD - C1 E9 02 - shr ecx,02



ADS 1-2 [0EE5F9D4]
------------------

Accesses:
028209A9 - 8D 7B 2C - lea edi,[ebx+2C]
029E377B - 89 BE D4000000 - mov [esi+000000D4],edi
02A51780 - 8B 41 04 - mov eax,[ecx+04]
02962A46 - 8B 79 04 - mov edi,[ecx+04]
02962A4F - 89 71 04 - mov [ecx+04],esi
02BCB498 - 3B 48 04 - cmp ecx,[eax+04]
02BCB4A3 - 8B 48 04 - mov ecx,[eax+04]
02BD396A - 8B 86 D4000000 - mov eax,[esi+000000D4]
02BD3CF3 - 8B 8A D4000000 - mov ecx,[edx+000000D4]
02BD3D1A - 8B BA D4000000 - mov edi,[edx+000000D4]
02BD6A7A - 8B 83 D4000000 - mov eax,[ebx+000000D4]
02BD6B1B - 8B 83 D4000000 - mov eax,[ebx+000000D4]
02BD6B47 - 39 B3 D4000000 - cmp [ebx+000000D4],esi
02BD7531 - 8B 8B D4000000 - mov ecx,[ebx+000000D4]
0299E06D - 8B 46 04 - mov eax,[esi+04]
029746D0 - 8B 56 04 - mov edx,[esi+04]
029746F7 - 8B 46 04 - mov eax,[esi+04]
0297470A - 89 46 04 - mov [esi+04],eax
0299E0B4 - C7 46 04 00000000 - mov [esi+04],00000000

Writes:
028209A9 - 8D 7B 2C - lea edi,[ebx+2C]
029E377B - 89 BE D4000000 - mov [esi+000000D4],edi
02962A4F - 89 71 04 - mov [ecx+04],esi
0297470A - 89 46 04 - mov [esi+04],eax
0299E0B4 - C7 46 04 00000000 - mov [esi+04],00000000



ADS 1-3 [0EE5F9D8]
------------------

Accesses:
028209A9 - 8D 7B 2C - lea edi,[ebx+2C]
029E3781 - 89 BE D8000000 - mov [esi+000000D8],edi
02962A4C - 3B 71 08 - cmp esi,[ecx+08]
02962A85 - 89 51 08 - mov [ecx+08],edx
02954816 - 8B 46 08 - mov eax,[esi+08]
02BCB495 - 8B 4A 08 - mov ecx,[edx+08]
02BCB4A6 - 89 4A 08 - mov [edx+08],ecx
029746FA - 8B 4E 08 - mov ecx,[esi+08]
02974729 - 89 46 08 - mov [esi+08],eax
0299E0AD - C7 46 08 00000000 - mov [esi+08],00000000

Writes:
028209A9 - 8D 7B 2C - lea edi,[ebx+2C]
029E3781 - 89 BE D8000000 - mov [esi+000000D8],edi
02962A85 - 89 51 08 - mov [ecx+08],edx
02BCB4A6 - 89 4A 08 - mov [edx+08],ecx
02974729 - 89 46 08 - mov [esi+08],eax
0299E0AD - C7 46 08 00000000 - mov [esi+08],00000000

[ChildOfTux]

Apologies for bumping my own thread, but I've been trying my best to figure this out and may have some more information that could help. I decided to have another go at finding ADS state. Here's what I've done, and found:

Instead of scanning for changed values that may or may not relate to ADS state directly, I decided to scan for weapon ammo, as this is a known number I can scan for, change and scan for again consistently. I figure the ADS state has a good chance of being tied to weapon state, or whatever object manages weapons, so if I can find the address containing ammo I can search that memory region for an ADS flag.

So far, so good - using this method I am consistently able to identify a dynamic memory address that tracks ADS state for the *current* weapon. The Byte value of the address is 72 when ADS is inactive, and 200 when it is active (which is weird - but at least consistent).

Here's where the problems begin anew however!

I am unable to trace back from this address to find whatever base object it belongs to (either some sort of weapon struct or perhaps the player's pawn object). Most of the pointers I've found are rooted in gbxBase.dll and - so far as I can tell from my admittedly amateur sleuthing - the instructions that write to or access this address are also rooted in gbxBase.dll. I cannot, however, find *anything* (pointer chain, object, whatever) that remains stable across level or save reloads, let alone game sessions or OS restarts.

Weirder still, when I first started scanning for ammo values I managed - via a pointerscan - to find two pointer chains to memory locations that tracked current ammo regardless of which weapon was equipped in-game. For example if I had a rifle equipped that had 15 rounds in the chamber the value would be 15. If I then switched weapons to a side-arm that had 7 rounds in the chamber the value would dutifully change to 7. When firing, reloading, switching wepons etc. the address would always track the correct current ammo amount. This was great, because it seemed to belong to some sort of global or current-state struct/object. From here, looking at the memory region around it I was able to find an address tracking ADS state which was also weapon indepenent. However, in all my subsequent scans and investiagtions - following the exact same steps every time - I have not been able to find such a pointer chain or memory location. I can now only find locations that track ammo and/or ADS state on a per-weapon basis. I've tried everything I can think of - including scanning for an ammo value, then swithcing weapons and scanning for the new value - to no avail. I just cannot find *any* address that tracks weapon-independant ammo - it was only that first time! What is going on here?

Going back to the address that tracks weapon-specific ADS state (14B71284 in this game session), here's what accesses the address:

10637280 - 8A 87 84040000 - mov al,[edi+00000484]
10143743 - 85 11 - test [ecx],edx
10636F83 - 8A 86 84040000 - mov al,[esi+00000484]
029E4A23 - 84 98 84040000 - test [eax+00000484],bl
1063733E - 8A 87 84040000 - mov al,[edi+00000484]
106374D8 - 8B 8F 84040000 - mov ecx,[edi+00000484]
1063765B - 8B 8F 84040000 - mov ecx,[edi+00000484]
1063766D - 89 8F 84040000 - mov [edi+00000484],ecx
1014439F - 8B 07 - mov eax,[edi]
101443A8 - 89 07 - mov [edi],eax
101443B8 - 89 07 - mov [edi],eax

The first 8 instructions seems to constantly access the address - potentially every game tick, or at least every second or so. The last three instructions only access the address when ADS is toggled. The first when it is toggled either on or off, the second only when it is toggled on and the third only when it is toggled off.

As I said above: attempting to trace these instructions through the debugger, though I may have gotten it very wrong as I'm very new to this and don't fully understand assembly, leads me to believe the root structure originates somewhere in gbxBase.dll (but take that with a pinch of salt!). That's as far as I can get.

As an aside, if it's relevant, you can only carry two weapons at a time in the game. At first I thought the weapon-specific ammo and ADS flag addresses I'd found would at least be for weapon slot 1 and weapon slot 2, regardless of what weapon occupied the slot. However, upon picking up a third weapon (which replaces one of the currently equipped weapons) it became evident that isn't the case. I was able to find a third address tracking ammo for this weapon. So it seems likely either all possible weapons in the game are tracked independently, or perhaps just all weapons that are loaded into the level - regardless of if you have them equipped or not. I'm not sure how relevant this piece of (admittedly incomplete) conjecture is however.

It occurs to me also that the ADS flag appears to be at a consistent offset from the address tracking ammo - though I have not yet had chance to truly test this across multiple game sessions so it may just be coincidental. If that is the case however, I just need to pin down a stable pointer chain to the current ammo and I can find the ADS flag from there (though obviously a stable pointer chain directly to it would be beneficial).

Remember: what I'm really after here is a way to read the game's internal ADS state flag. Preferably a global, weapon-agnostic flag if one exists (which it seems to, though I can no longer locate it) but if not finding a flag for each weapon in the game will suffice if necessary. I need a way to reliably reach this state flag (or flags) across game launches and level/save reloads etc. This is where I'm primarily coming unstuck. None of the pointer chains I've found or manually constructed from my memory/assembly sleuthing survive even a level or save relaod.

Where do I go from here? I know there *must* be a way to achieve this but I'm all out of ideas right now. Thanks.