Cheat Engine Forum Index Cheat Engine
The Official Site of Cheat Engine
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


ASM script: offset variables in module address?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine
View previous topic :: View next topic  
Author Message
fmanager
Master Cheater
Reputation: 1

Joined: 17 Feb 2016
Posts: 433

PostPosted: Fri Mar 10, 2017 7:41 pm    Post subject: ASM script: offset variables in module address? Reply with quote

For example, I have a module address like this:
Code:

game.exe+1FA000


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. Smile

_________________
**************

A simple example is better then ten links. Very Happy
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 73

Joined: 29 Oct 2010
Posts: 3569

PostPosted: Fri Mar 10, 2017 10:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
fmanager
Master Cheater
Reputation: 1

Joined: 17 Feb 2016
Posts: 433

PostPosted: Sat Mar 11, 2017 2:48 am    Post subject: Reply with quote

++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. Smile

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. Very Happy
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 73

Joined: 29 Oct 2010
Posts: 3569

PostPosted: Sat Mar 11, 2017 3:02 am    Post subject: Reply with quote

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
View user's profile Send private message
mgr.inz.Player
I post too much
Reputation: 143

Joined: 07 Nov 2008
Posts: 4068
Location: W kraju nad Wisla. UTC+01:00

PostPosted: Sat Mar 11, 2017 3:18 am    Post subject: Reply with quote

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
View user's profile Send private message MSN Messenger
++METHOS
I post too much
Reputation: 73

Joined: 29 Oct 2010
Posts: 3569

PostPosted: Sat Mar 11, 2017 3:34 am    Post subject: Reply with quote

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
View user's profile Send private message
fmanager
Master Cheater
Reputation: 1

Joined: 17 Feb 2016
Posts: 433

PostPosted: Sat Mar 11, 2017 10:37 am    Post subject: Reply with quote

++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. Very Happy
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 73

Joined: 29 Oct 2010
Posts: 3569

PostPosted: Sat Mar 11, 2017 11:45 am    Post subject: Reply with quote

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
View user's profile Send private message
Zanzer
I post too much
Reputation: 118

Joined: 09 Jun 2013
Posts: 3198

PostPosted: Sat Mar 11, 2017 1:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
fmanager
Master Cheater
Reputation: 1

Joined: 17 Feb 2016
Posts: 433

PostPosted: Sat Mar 11, 2017 8:00 pm    Post subject: Reply with quote

@++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. Very Happy
Back to top
View user's profile Send private message
Zanzer
I post too much
Reputation: 118

Joined: 09 Jun 2013
Posts: 3198

PostPosted: Sat Mar 11, 2017 8:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
++METHOS
I post too much
Reputation: 73

Joined: 29 Oct 2010
Posts: 3569

PostPosted: Sat Mar 11, 2017 10:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
fmanager
Master Cheater
Reputation: 1

Joined: 17 Feb 2016
Posts: 433

PostPosted: Sun Mar 12, 2017 10:42 am    Post subject: Reply with quote

@++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. Very Happy
Back to top
View user's profile Send private message
++METHOS
I post too much
Reputation: 73

Joined: 29 Oct 2010
Posts: 3569

PostPosted: Sun Mar 12, 2017 11:05 am    Post subject: This post has 1 review(s) Reply with quote

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
View user's profile Send private message
fmanager
Master Cheater
Reputation: 1

Joined: 17 Feb 2016
Posts: 433

PostPosted: Sun Mar 12, 2017 11:48 am    Post subject: Reply with quote

++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.

Smile

_________________
**************

A simple example is better then ten links. Very Happy
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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


Powered by phpBB © 2001, 2005 phpBB Group

CE Wiki   IRC (#CEF)   Twitter
Third party websites