Force Project X
video game hacking tools
also cheats hacks and code
[Help] Wildcarding Problem
Wildcarding Problem Posted on: 04/10/2018 8:44pm
Quote Post

My question: Is there an easier way to wildcard with the way I'm doing it? It's kinda annoying to do.

The way I'm doing it is that, first I find a AoB code. I refresh to see if the AoB code has any bytes that changes. If it does, I find the AoB code and compare it with the first. Whatever byte that changed, I wildcard it.

To make sure I wildcarded it right, I refresh again and find the one AoB code. Once again, the AoB code start to change bytes that weren't changed before and I have to wildcard more bytes. Thus with that, I search the new wildcarded AoB code, but it doesn't find anything.
 
Rinse and repeat until I had the right AoB code with the right wildcarding.

Honestly, I may be doing something stupid, or my entire process is stupid, but anything would be nice. Thanks.

RE: Wildcarding Problem Posted on: 04/11/2018 10:48am
Quote Post
Ubi Maior Minor Cessat

tldr operators are static while operands can change, the operator is usually the first byte of a line. Cant do better with the details you provided

RE: Wildcarding Problem Posted on: 04/11/2018 11:40am
Quote Post
Insert Custom Title Here

To give an example of what Zen said, lets say we have the following code:

; d2
getlocal_2
; 12 0b 00 00
iffalse ofs0029
; 5d 0f
ofs001e:findpropstrict Qname(PackageNamespace(""),"addFrameScript")
; 24 01
pushbyte 1
; d0
getlocal_0


The operators that Zen mentions is the first bytes of the line. d2 corresponds to getlocal_2, findpropstrict corresponds to 5d, etc. The operands is the information given to the operator on what it needs to do. In this case, it needs to get the get the 15th item from the local namespace package which is this. Essentially, between compilations of the game, the index of the specific information that the operator is working with may change, but the operator itself would be constant. The same is true for pushbyte. A game dev may initially choose a random number like 45 for the damage of an item, but then rebalance it to 43. The pushbyte is still in the same relative location, but the information it works on has been change.

To wildcard the above code correctly, it would turn from d2 12 0b 00 00 5d 0f 24 01 d0 to d2 12 ?? ?? ?? 5d ?? 24 ?? d0

The signature is more ambiguous, but is now less prone to becoming obsolete due to recompilation of the game.




RE: Wildcarding Problem Posted on: 04/11/2018 3:09pm
Quote Post
Simple_AOB Posted on: 04/11/2018 11:40am

To give an example of what Zen said, lets say we have the following code:

; d2
getlocal_2
; 12 0b 00 00
iffalse ofs0029
; 5d 0f
ofs001e:findpropstrict Qname(PackageNamespace(""),"addFrameScript")
; 24 01
pushbyte 1
; d0
getlocal_0


The operators that Zen mentions is the first bytes of the line. d2 corresponds to getlocal_2, findpropstrict corresponds to 5d, etc. The operands is the information given to the operator on what it needs to do. In this case, it needs to get the get the 15th item from the local namespace package which is this. Essentially, between compilations of the game, the index of the specific information that the operator is working with may change, but the operator itself would be constant. The same is true for pushbyte. A game dev may initially choose a random number like 45 for the damage of an item, but then rebalance it to 43. The pushbyte is still in the same relative location, but the information it works on has been change.

To wildcard the above code correctly, it would turn from d2 12 0b 00 00 5d 0f 24 01 d0 to d2 12 ?? ?? ?? 5d ?? 24 ?? d0

The signature is more ambiguous, but is now less prone to becoming obsolete due to recompilation of the game.


Oh, I see. That makes more sense. Thanks for this. (To both Zenwaichi and Simple_AoB of course.)