Filtering Out Players From a Script

[arlight1]

Hey everyone. Had a question regarding running a script on enemies only. I've got a 1-hit-kill script I got working in ME: Andromeda that only affects enemies and not the player because the data structure for players/enemies has a byte that I compare that differentiates the two. For instance, [rbx-80] will contain the HP of all players/enemies when the HP decrease function is being run. And I found [rbx-40] to be either 0 (player) or 60 (enemy), and that is always true. So with that, I can run a cmp in my script for enemies and player and so on.

I've run into a little problem for a different hack, however. I'm attempting to edit coordinates for all enemies and exclude players from script. Problem is the method I used before can't be used again. The data structure for players/enemies does not have any unique comparisons I can do between the two groups. I've done -1000 bytes to 4096 bytes past the referenced coordinates, and there's nothing that stands out or stays constant between game restarts. On top of that there isn't really unique assembly code that only works on enemies vs. the player, it runs for all entities in the current world.

Are there any alternate methods anyone can think of for removing players from being affected by a script? I thought about referencing the 1-hit-kill hack from before and using the byte comparison used previously, but of course that function is used at a different condition and rate than xyz updates so that wouldn't work. Any ideas?

[++METHOS]

Alternative methods for finding a unique ID for code segregation:

• You can use a pointer address for your filter, inside of your script, for the value that you are trying to manipulate.
• You can use pointer trees inside of the data structure to find something viable.
• You can shift the data structure (+ or -) and/or expand its size to find something useful.
• You can use the structure spider to find workable strings and/or for comparative analysis.
• You can check the register values by attaching the debugger or setting a breakpoint to see if something can be used for your filter.
• You can check to see if there are any instructions that are exclusive to the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
• You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
• You can analyze assembly code to see if an identifier is being checked or assigned somewhere.
  Et al.

[Squall8]

Also try debugging on addresses around the coordinates, not the coordinates themselves. Make sure you can still point to your coordinate values.

[arlight1]

Alternative methods for finding a unique ID for code segregation:

• You can use a pointer address for your filter, inside of your script, for the value that you are trying to manipulate.
• You can use pointer trees inside of the data structure to find something viable.
• You can shift the data structure (+ or -) and/or expand its size to find something useful.
• You can use the structure spider to find workable strings and/or for comparative analysis.
• You can check the register values by attaching the debugger or setting a breakpoint to see if something can be used for your filter.
• You can check to see if there are any instructions that are exclusive to the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
• You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
• You can analyze assembly code to see if an identifier is being checked or assigned somewhere.
  Et al.

Thanks for the list Methos. Here are the ones I've attempted so far and the reason they didn't work:

• You can use a pointer address for your filter, inside of your script, for the value that you are trying to manipulate.
  Not sure if CE is guessing the correct data types for the structure containing XYZ for each player/enemy, but the ones it designates as pointers seem to be constantly changing. They change to an address which exists inside of the process and then change to something that doesn't point anywhere (e.g. 13CCCCCCC)
• You can shift the data structure (+ or -) and/or expand its size to find something useful.
  I've attempted this. Going >20 bytes negative from xyz results in strange looking data that seems to be constantly in flux. Going 4096 bytes from xyz initial location results in some data that is applicable to players/enemies, but is constantly changing as the game runs. (at a rate of one change per several seconds)

Could you expand on these points and what you mean by them?

• You can use pointer trees inside of the data structure to find something viable.
• You can check to see if there are any instructions that are exclusive to the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
• You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
• You can analyze assembly code to see if an identifier is being checked or assigned somewhere.

[arlight1]

Also try debugging on addresses around the coordinates, not the coordinates themselves. Make sure you can still point to your coordinate values.

Can you elaborate on what you mean by this? What would watching and tracing the addresses around the coordinates allow me to do?

[Squall8]

If you debug on an address around your enemies coordinates you might be able to find an instruction with fewer or no shared addresses than what you might currently be working with. The instruction might end up being unique to the enemy. It could also pull some different comparison values to work with. If the address is within the same memory region as your enemy's coordinates, you can still use it to point to the coordinate values you're looking for.

[++METHOS]

Also try debugging on addresses around the coordinates, not the coordinates themselves. Make sure you can still point to your coordinate values.

Can you elaborate on what you mean by this? What would watching and tracing the addresses around the coordinates allow me to do?

-He is basically referring to:

• You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.

That being said, setting up a filter may not always be required. Any of the OTHER values inside of the same data structure may have instructions that access them, exclusively, thus allowing you to inject your code there.

Thanks for the list Methos. Here are the ones I've attempted so far and the reason they didn't work:

• You can use a pointer address for your filter, inside of your script, for the value that you are trying to manipulate.
  Not sure if CE is guessing the correct data types for the structure containing XYZ for each player/enemy, but the ones it designates as pointers seem to be constantly changing. They change to an address which exists inside of the process and then change to something that doesn't point anywhere (e.g. 13CCCCCCC)

-It's hard to say without looking. However, I would not recommend going this route unless you have absolutely no other choices. That being said, the pointer may not be resolving correctly simply because you have not gone deep enough and/or found a stable pointer yet.

Could you expand on these points and what you mean by them?

• You can use pointer trees inside of the data structure to find something viable.
• You can check to see if there are any instructions that are exclusive to the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
• You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
• You can analyze assembly code to see if an identifier is being checked or assigned somewhere.

1. Pointer trees -- when you analyze a data structure, you'll notice that some of the offsets are pointers, and not traditional values. This is CE's best guess...but you can manually change them all to see if they are really pointers, as well as add offsets that may be missing etc.. You can expand these entries and see entirely different structures inside of them. Sometimes, you can find important values that can be used for your compare, by not limiting yourself to the base structure that you are originally analyzing. You may have to go several levels deep (inside of other pointer trees) to find what you need.

2. Exclusive instructions for targeted address -- when you right-click on an address in your cheat table and check to see what is accessing it, the debugger window will pop up and instructions should populate the list. If you right-click on an open, white space inside of that debugger, you have the option to 'check if found opcodes...'. Doing so will show you if any of the instructions that are accessing your targeted address are exclusive to your targeted address (i.e. you'll see if any of the instructions are ONLY accessing your targeted address and nothing else). A new number will appear inside of the 'count' column, indicating how many addresses are being accessed ( 1 through 8 ). If you see an instruction with a (1), then it may be exclusive to your targeted address...meaning...you can inject at that instruction and use it and/or and save off the address that it is accessing. You can use a custom symbol to save it and use it inside of your primary script, for your compare. So, in your primary script, the instruction may access your targeted address and loads of other addresses, but all you have to do is compare the addresses to the address that you have stored, and filter out all of the unwanted addresses. Even if the targeted address changes during each run/level etc., the instruction that you are using to save off that address should always be storing the correct address.

3. Exclusive instructions for any of the other addresses inside of the same data structure as your targeted address -- same as above, accept, you have a ton of other addresses that you may be able to use to find an instruction that is exclusive to any one of the other addresses inside of the same data structure as the targeted address that you are wanting to manipulate.

4. Analyzing assembly - this is advanced and not something that can be easily explained, as the circumstances will vary. However, this step is pretty much NEVER needed.

[sbryzl]

Something along the lines of exclusive instructions is to use a return pointer on the stack. Setup an injection point at the return location and use that address to compare to the pointer on the stack.