When I find a green address, this is static, correct? Meaning that there is some sort of offset from the base address of the program that will always lead to this, right?
I am trying to save that address to a table so when I reload the executable that the table will point to the correct address.
How do I do this? If I save the address it points wrong when the base address of the executable is changed.
I have searched for this but I may not be able to word it concisely enough for search engines to be fruitful.
I am certain this may be frustrating to see as I am just as certain that this question has been asked before.
Please forgive my ignorance, I am putting effort to finding out on my own without bugging you all.
Thanks you lovely bastards.
Saving Static Addresses to a Table
Re: Saving Static Addresses to a Table
^ "a green address, this is static, correct?": yes and no; that address can change on how the game uses it. however, there is a good chance that it is referenced in the opcode (somehow).
that said: the best approach here is:
a. do simply 'what accesses... ?", and notice if CE returns opcode which references this address. if it does, then you'll need to collect that address via an aob/lua script
b. if it does not, you can do:
b1. search for the "previous"/reference pointer to this address; then apply point a. to any static address it returns
b2. more likely, you'll need to run a pointerscan on this address. "weed" it out for a couple of days - run game, check valid chains, then quit; etc - till you get a manageable amount of scans. then do a 'what accesses... ?" on the base address - not the "end" address of that ptr_chain, as this should be your initial static address; probably changed several times by now - and look for opcodes that reference that base address...
btw: b2. is my base approach. using pointerscans is always a good way to find out how the game "gets to that address/value". or said in another way: create a structure with the 'base_address' of the pointer_chain as startaddress, and then follow the ptrs up in the chain. if you are already using some values - by means of some ptr-references - you'll probably also find some "cross-linking" (~ the path of one value_chain crosses the path of another in your table)...
tip: if you do find an opcode, but is not really useable, then do a 'search ~ find assembly code' (via memViewer) on that particular base_address. If that returns plenty of opcode, you'll know you've got a winner !
an example: you have your health_value, based on a ptr_scan (chaining 5 offsets for example). then you find the oxygen-value (or adrenaline, coordinates, etc) of your player (obtained in another ptr_scan). if you start comparing both paths, you might find a moment where both paths cross... practically: that means that you can use the 1st ptr_chain to "link" to that other value !
=> important: i only make use of ptr_chains in my table, if the (static) base_address is collected via an opcode reference.
E.g.: deadspace2.exe+CA9A91: 8B 35 40 B0 0A 02 - mov esi,[deadspace2.exe+1CAB040] <= using either asm or lua, you can collect that (dynamic) address
some notes:
1. i'm sure my wording is not quite in par here
2. you'll need to practice this in order to get grip on the matter
3. most of my tables make use of aforementioned technique ~ check out 'getStaticAddr()'
* lua : this is just one way of doing it - you'll find similar routines in plenty of other tables as well
* asm: you'll need to apply a specific rule to collect that address (especially with x64 games)
that said: the best approach here is:
a. do simply 'what accesses... ?", and notice if CE returns opcode which references this address. if it does, then you'll need to collect that address via an aob/lua script
b. if it does not, you can do:
b1. search for the "previous"/reference pointer to this address; then apply point a. to any static address it returns
b2. more likely, you'll need to run a pointerscan on this address. "weed" it out for a couple of days - run game, check valid chains, then quit; etc - till you get a manageable amount of scans. then do a 'what accesses... ?" on the base address - not the "end" address of that ptr_chain, as this should be your initial static address; probably changed several times by now - and look for opcodes that reference that base address...
btw: b2. is my base approach. using pointerscans is always a good way to find out how the game "gets to that address/value". or said in another way: create a structure with the 'base_address' of the pointer_chain as startaddress, and then follow the ptrs up in the chain. if you are already using some values - by means of some ptr-references - you'll probably also find some "cross-linking" (~ the path of one value_chain crosses the path of another in your table)...
tip: if you do find an opcode, but is not really useable, then do a 'search ~ find assembly code' (via memViewer) on that particular base_address. If that returns plenty of opcode, you'll know you've got a winner !
an example: you have your health_value, based on a ptr_scan (chaining 5 offsets for example). then you find the oxygen-value (or adrenaline, coordinates, etc) of your player (obtained in another ptr_scan). if you start comparing both paths, you might find a moment where both paths cross... practically: that means that you can use the 1st ptr_chain to "link" to that other value !
=> important: i only make use of ptr_chains in my table, if the (static) base_address is collected via an opcode reference.
E.g.: deadspace2.exe+CA9A91: 8B 35 40 B0 0A 02 - mov esi,[deadspace2.exe+1CAB040] <= using either asm or lua, you can collect that (dynamic) address
some notes:
1. i'm sure my wording is not quite in par here
2. you'll need to practice this in order to get grip on the matter
3. most of my tables make use of aforementioned technique ~ check out 'getStaticAddr()'
* lua : this is just one way of doing it - you'll find similar routines in plenty of other tables as well
* asm: you'll need to apply a specific rule to collect that address (especially with x64 games)
Who is online
Users browsing this forum: No registered users