|
Cheat Engine The Official Site of Cheat Engine
|
View previous topic :: View next topic |
Author |
Message |
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Fri Mar 10, 2017 7:41 pm Post subject: ASM script: offset variables in module address? |
|
|
For example, I have a module address like this:
Is it possible to store "1FA000" in a variable, and then use it as if it's part of a module address?
Something like this:
Code: |
mov [offSet],1fa000
mov eax,[offSet]<------------ offSet holds "1FA000"?
mov ebx,[game.exe+eax]
|
Is it doable?
Thanks a lot.
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
++METHOS I post too much Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Fri Mar 10, 2017 10:40 pm Post subject: |
|
|
If you are not setting this up so that the offset can be dynamic, then I do not see the point, as you could simply:
Code: | mov ebx,[game.exe+1FA000] |
I have never tried, but maybe something like this:
Code: | lable(offset)
registersymbol(offset)
newmem:
cmp [offset],0
je @f
push edi
mov edi,[offset]
mov ebx,[game.exe+edi]
pop edi
//code
originalcode:
//code
offset:
dd 0
//etc.. |
|
|
Back to top |
|
|
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Sat Mar 11, 2017 2:48 am Post subject: |
|
|
++METHOS wrote: | If you are not setting this up so that the offset can be dynamic, then I do not see the point, as you could simply:
Code: | mov ebx,[game.exe+1FA000] |
I have never tried, but maybe something like this:
Code: | lable(offset)
registersymbol(offset)
newmem:
cmp [offset],0
je @f
push edi
mov edi,[offset]
mov ebx,[game.exe+edi]
pop edi
//code
originalcode:
//code
offset:
dd 0
//etc.. |
|
Thanks for the example.
I do have a reason for this: the game's module addresses are changed after each update, and replacing the new address(offset) in multiple ASM scripts feels tedious. Moreover, some of them have the same assembly code, it's like same condition checks for different functions, so AOB scan is not an option.
BTW, what does "@f" mean in your code?
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
++METHOS I post too much Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Sat Mar 11, 2017 3:02 am Post subject: |
|
|
Yes, but the original method that you have proposed would require manually editing each script, right? That was my whole point and why I posted a solution that would allow you to alter that offset automatically, by setting up hotkeys for the various offset values. -Unless I am just not understanding everything.
Regarding the @f, see anonymous labels.
|
|
Back to top |
|
|
mgr.inz.Player I post too much Reputation: 218
Joined: 07 Nov 2008 Posts: 4438 Location: W kraju nad Wisla. UTC+01:00
|
Posted: Sat Mar 11, 2017 3:18 am Post subject: |
|
|
fmanager wrote: | BTW, what does "@f" mean in your code? |
Jump to nearest label, can be any label (not only anonymous), below (forwards in source).
"@b" - Jump to nearest label, can be any label (not only anonymous), above (backwards in source).
_________________
|
|
Back to top |
|
|
++METHOS I post too much Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Sat Mar 11, 2017 3:34 am Post subject: |
|
|
Right. So, in the example above, je @f would jump to originalcode. If it were written as je @b, it would jump to newmem.
|
|
Back to top |
|
|
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Sat Mar 11, 2017 10:37 am Post subject: |
|
|
++METHOS wrote: | Right. So, in the example above, je @f would jump to originalcode. If it were written as je @b, it would jump to newmem. |
@++METHOS
@mgr.inz.Player
Thank you both for the explanation.
@++METHOS
Actually I want to declare some sort of a global variable in ASM script for my other scripts, so I don't have to change each of them manually. Sorry for the misunderstanding. I think your solution can achieve that if it works.
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
++METHOS I post too much Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Sat Mar 11, 2017 11:45 am Post subject: |
|
|
The solution that I have provided will achieve that, exactly. After script activation, you can manually add an address to your table and put offset in the address field. Simply assign hotkeys to that address to set the offset value to whatever you want.
That said, if you know what the offset value will be across different versions, you can set this up to check against game version and automate the process, entirely. This is assuming that the target will not be updated anymore.
|
|
Back to top |
|
|
Zanzer I post too much Reputation: 126
Joined: 09 Jun 2013 Posts: 3278
|
Posted: Sat Mar 11, 2017 1:35 pm Post subject: |
|
|
In your specific scenario, the address you want is static.
You could use wildcards in an AOB scan and simply get the final address from the instruction.
Code: | aobscan(base_aob,8B 1D ?? ?? ?? ?? {plus more to make it unique})
label(base_ptr)
base_aob+2:
base_ptr:
registersymbol(base_ptr) |
Alternatively, why not just let the instruction resolve the value you need into EBX and ignore the offset completely?
Then simply save the value of EBX into a custom variable that you use throughout the table.
Code: | aobscan(get_base,8B 1D ?? ?? ?? ?? {plus more to make it unique})
code:
reassemble(get_base)
mov [base_ptr],ebx |
If the offset were being added to a register (mov ebx,[ecx+01FA000]) it would be slightly different.
You could still use an AOB scan, but now you'd have to save the offset.
Code: | aobscan(get_offset,8B 99 ?? ?? ?? ?? {plus more to make it unique})
label(offset)
get_offset+2:
offset:
registersymbol(offset) |
Now if you also had base_ptr, you could use the address "base_ptr+offset" and it would resolve correctly.
If you simply want to create a global variable "offset" and define its number in the table, add a userdefined symbol.
View > Userdefined symbols > offset: 1fa000 > Add symbol
|
|
Back to top |
|
|
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Sat Mar 11, 2017 8:00 pm Post subject: |
|
|
@++METHOS
Thank you as always, and I will try to see if I can automate the process.
@Zanzer
Thanks for the answer.
I have a couple of questions:
1. In this code:
Code: |
aobscan(base_aob,8B 1D ?? ?? ?? ?? {plus more to make it unique})
label(base_ptr)
base_aob+2:
base_ptr:
registersymbol(base_ptr)
|
Is "base_ptr" 2 bytes long or 4 bytes long? Is there a way to define the size of it?
2. The code in my game looks something like this:
Code: |
cmp eax,ecx
je game.exe+1FA30
call game.exe+1FB33
mov eax,00000011
cmp eax,ebx
jae game.exe+1BD893
call game.exe+1FD098
.......
|
So there are lots of offsets in this piece of code, they will all change after the update of the game. Do you think I should still use AOB scan?
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
Zanzer I post too much Reputation: 126
Joined: 09 Jun 2013 Posts: 3278
|
Posted: Sat Mar 11, 2017 8:33 pm Post subject: |
|
|
base_ptr would be treated as the size of a memory address. 4 bytes in 32-bit, 8 bytes in 64-bit.
If you used it in code, you'll tell it how many bytes to read from the address. Code: | mov eax,[base_ptr]
mov ax,[base_ptr]
mov al,[base_ptr] |
That method won't work for 64-bit targets. You'd have to implement a little Lua script instead.
In that code, I'm not seeing any pointers. Which offset are you trying to save and why?
Anyway, this AOB ignores all the offsets. Hopefully the other instructions and registers don't change between versions.
39 C8 0F 84 ?? ?? ?? ?? E8 ?? ?? ?? ?? B8 11 00 00 00 39 D8 0F 83 ?? ?? ?? ?? E8 ?? ?? ?? ??
Just don't know what you're trying to save in there to provide you a proper script.
|
|
Back to top |
|
|
++METHOS I post too much Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Sat Mar 11, 2017 10:02 pm Post subject: |
|
|
If you could better explain, in detail, what it is that you are really trying to accomplish or avoid, then I am sure that we can offer you better help...because it is still unclear to me. There may be a simpler/better solution.
|
|
Back to top |
|
|
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Sun Mar 12, 2017 10:42 am Post subject: |
|
|
@++METHOS
@Zanzer
Sorry for the poor explanation guys, English is not my first language.
So, the code looks like this:
Code: |
cmp eax,ecx
je game.exe+1FA30
call game.exe+1FB33
mov eax,00000011 <-------------------I want to inject here
cmp eax,ebx
jae game.exe+1BD893
call game.exe+1FD098
|
All the "numbers" and "letters" after the "+" symbol, which means "+1FA30", "+1FB33", etc., will change after the update of the game, so the byte codes are changed. If I use AOB scan, then I need to use lots of wildcards, and may not be accurate. Thats what I am concerned about.
How to accurately or more efficiently find the injection point in this situation?
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
++METHOS I post too much Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Sun Mar 12, 2017 11:05 am Post subject: |
|
|
There is nothing wrong with using an AOB signature to find the injection point. Using wildcard variables is also recommended if you want to account for possible changes where bytes may be dynamic. Nothing will be 100% fail-proof, as you will never know what the developer will decide to do for future releases and patches. However, these recommended steps can be used to help mitigate any potential issues.
Regarding efficiency, you my use AOBScanModule in lieu of AOBScan. AOBScanRegion may also be a viable option, although, I never use it myself.
Nonetheless, storing offsets and the like will be pointless if you are not able to find the appropriate injection location. Even if you decide to use module addressing for injection, I still do not see how storing the offsets will help you from a compatibility standpoint, since you will have to know what those offsets will need to be in the first place.
So, you either need to have the information beforehand, which would make all of this pointless anyway, or, you will need to have a good way to find the appropriate injection location across multiple versions that may or may not change.
With that said, you can create an AOB signature that is near your injection point, that may not have many potentially dynamic bytes, and that can be used for your signature in an effort to reduce possible issues with broken signatures.
Truthfully, though, with regard to wildcard variables, I do not believe that having more is a bad thing or will cause inaccurate signatures anymore than not having them. In my mind, having this:
Code: | 55 8B xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 03 D0 |
is just as good, if not better, than having this:
Code: | 55 8B EC 8B 45 08 56 xx xx 3C 03 C8 0F xx xx 14 8D 51 18 03 D0 |
If the signature breaks because an additional byte is added or removed, then both signatures will be broken. At least with the first example, you have a better chance of the signature not breaking in the event that a byte value simply changes.
...unless I am still not understanding you fully.
|
|
Back to top |
|
|
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Sun Mar 12, 2017 11:48 am Post subject: |
|
|
++METHOS wrote: | There is nothing wrong with using an AOB signature to find the injection point. Using wildcard variables is also recommended if you want to account for possible changes where bytes may be dynamic. Nothing will be 100% fail-proof, as you will never know what the developer will decide to do for future releases and patches. However, these recommended steps can be used to help mitigate any potential issues.
Regarding efficiency, you my use AOBScanModule in lieu of AOBScan. AOBScanRegion may also be a viable option, although, I never use it myself.
Nonetheless, storing offsets and the like will be pointless if you are not able to find the appropriate injection location. Even if you decide to use module addressing for injection, I still do not see how storing the offsets will help you from a compatibility standpoint, since you will have to know what those offsets will need to be in the first place.
So, you either need to have the information beforehand, which would make all of this pointless anyway, or, you will need to have a good way to find the appropriate injection location across multiple versions that may or may not change.
With that said, you can create an AOB signature that is near your injection point, that may not have many potentially dynamic bytes, and that can be used for your signature in an effort to reduce possible issues with broken signatures.
Truthfully, though, with regard to wildcard variables, I do not believe that having more is a bad thing or will cause inaccurate signatures anymore than not having them. In my mind, having this:
Code: | 55 8B xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 03 D0 |
is just as good, if not better, than having this:
Code: | 55 8B EC 8B 45 08 56 xx xx 3C 03 C8 0F xx xx 14 8D 51 18 03 D0 |
If the signature breaks because an additional byte is added or removed, then both signatures will be broken. At least with the first example, you have a better chance of the signature not breaking in the event that a byte value simply changes.
...unless I am still not understanding you fully. |
You are right to the point, my friend. Then I think I should stick to AOB scan.
I didn't know there was a thing called "AOBScanModule", I will do some research on that. Thanks a lot.
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
|