 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
Noobrzor
Advanced Cheater
![]() Reputation: 0
Joined: 19 May 2014
Posts: 74
|
 Posted: Sat Sep 19, 2015 10:20 am Post subject: AAscript that works abnormally and irrelevant code is a fix? |
 |
|
Greetings
The following AAscript is for Dying Light. It's affecting Boosters (buffs) duration.
| Code: | [ENABLE]
alloc(newmem,2048,"gamedll_x64_rwdi.dll"+9987BF)
//alloc(BoosterHack,4)
//registersymbol(BoosterHack)
label(returnhere)
label(originalcode)
label(hack)
//BoosterHack:
//db 01
newmem:
cmp [rsp+48],gamedll_x64_rwdi.dll+A67D5E
je hack
jmp originalcode
originalcode:
movss [rcx+10],xmm0
jmp returnhere
hack:
//cmp [BoosterHack],0
//je originalcode
mov [rcx+10],(float)5
jmp returnhere
"gamedll_x64_rwdi.dll"+9987CA:
jmp newmem
returnhere:
[DISABLE]
dealloc(newmem)
//dealloc(BoosterHack)
//unregistersymbol(BoosterHack)
"gamedll_x64_rwdi.dll"+9987CA:
movss [rcx+10],xmm0 |
[rcx+10] holds the current duration of a buff, and xmm0 is the new one, updated after a short amount of time (floating point, and apparently it's counted as seconds).
The script I posted, however, instead of making the duration set and frozen on 5 seconds, causes the buffs to disappear instantly. I believe it's the:
| Code: | cmp [rsp+48],gamedll_x64_rwdi.dll+A67D5E (this checks whether the particular 'action' that's being carried out by the procedure being modified is related to buff duration, or something else.)
je hack |
at fault, causing the xmm0 to be zeroed, as after //-ing these two lines the booster duration behaves as default ingame.
Now, here's the part that's utterly mindboggling me. After unslashing everything that is slashed (the //'s in front of stuff about the BoosterHack), the script magically starts working. The buff duration is set to 5 and frozen there.
What's going on here? Why is this seemingly irrelevant code making the script work? And why isn't it working as intended in original?
Cheers
EDIT2:
I have concluded that:
cmp [rsp+48],gamedll_x64_rwdi.dll+A67D5E
Doesn't cause the 'bug' to happen on it's own. I used data dissect to modify the way I check for the boosts, and here's the new code - the bug still happens. With corresponding hack value set to 1 or else, the duration gets properly set to 5. With it set to 0, however, the boost is insta-over.
Here's the new code, the bug presents in it:
| Code: | [ENABLE]
//code from here to '[DISABLE]' will be used to enable the cheat
alloc(newmem,2048,"gamedll_x64_rwdi.dll"+9987BF)
alloc(ResistanceBoost,4)
alloc(StaminaBoost,4)
alloc(NightVisionBoost,4)
alloc(SpeedBoost,4)
registersymbol(ResistanceBoost)
registersymbol(StaminaBoost)
registersymbol(NightVisionBoost)
registersymbol(SpeedBoost)
label(returnhere)
label(originalcode)
label(hackResistance)
label(hackStamina)
label(hackNightVision)
label(hackSpeed)
ResistanceBoost:
db 01
StaminaBoost:
db 01
NightVisionBoost:
db 01
SpeedBoost:
db 01
newmem:
cmp [rcx],0001003D
je hackResistance
cmp [rcx],0001004F
je hackStamina
cmp [rcx],00010046
je hackNightVision
cmp [rcx],00010049
je hackSpeed
jmp originalcode
originalcode:
movss [rcx+10],xmm0
jmp returnhere
hackResistance:
cmp [ResistanceBoost],0
je originalcode
mov [rcx+10],(float)5
jmp returnhere
hackStamina:
cmp [StaminaBoost],0
je originalcode
mov [rcx+10],(float)5
jmp returnhere
hackNightVision:
cmp [NightVisionBoost],0
je originalcode
mov [rcx+10],(float)5
jmp returnhere
hackSpeed:
cmp [SpeedBoost],0
je originalcode
mov [rcx+10],(float)5
jmp returnhere
"gamedll_x64_rwdi.dll"+9987CA:
jmp newmem
returnhere:
[DISABLE]
//code from here till the end of the code will be used to disable the cheat
dealloc(newmem)
dealloc(ResistanceBoost)
dealloc(StaminaBoost)
dealloc(NightVisionBoost)
dealloc(SpeedBoost)
unregistersymbol(ResistanceBoost)
unregistersymbol(StaminaBoost)
unregistersymbol(NightVisionBoost)
unregistersymbol(SpeedBoost)
"gamedll_x64_rwdi.dll"+9987CA:
movss [rcx+10],xmm0 |
Also, reverting the compares - that is comparing [rcx] at each hackBoost rather than comparing [SomethingBoost] causes the bug to happen even when boosts are on 1.
EDIT3:
I figured this out. Scroll down to see the part of the code in action, and my conclusion what was causing the erratic behaviour. Thread closed, pretty much.
Last edited by Noobrzor on Sun Sep 20, 2015 2:07 am; edited 5 times in total |
|
| Back to top |
|
 |
STN
I post too much
 Reputation: 43
Joined: 09 Nov 2005
Posts: 2676
|
| Posted: Sat Sep 19, 2015 10:25 am Post subject: |
|
|
Probably because the compare is bad ?
_________________
|
|
| Back to top |
|
|
Noobrzor
Advanced Cheater
![]() Reputation: 0
Joined: 19 May 2014
Posts: 74
|
| Posted: Sat Sep 19, 2015 10:49 am Post subject: |
|
|
Which compare and why?
The one:
| Code: | cmp [rsp+48],gamedll_x64_rwdi.dll+A67D5E
je hack
jmp originalcode |
Is what I use in many, many games, and I had used several times while making hacks for the same game.
And the other compare I have no idea how it being 'bad' would make the code work o.O
I know the compare works properly at least to some degree, because it jumps to hack label properly - otherwise BoosterHack wouldn't ever be executed.
|
|
| Back to top |
|
|
deama1234
Master Cheater
![]() Reputation: 3
Joined: 20 Dec 2014
Posts: 328
|
| Posted: Sat Sep 19, 2015 7:23 pm Post subject: |
|
|
| If you start your script with "0" in all of your custom "hackboost" variables instead of "1"; does the buff run normally?
|
|
| Back to top |
|
|
Zanzer
I post too much
![]() Reputation: 126
Joined: 09 Jun 2013
Posts: 3278
|
| Posted: Sat Sep 19, 2015 8:00 pm Post subject: |
|
|
I believe that CMP doesn't work well in 64-bit games.
I believe you cannot compare a 64-bit literal.
You can try changing it to the following, but I'm not sure that'll work either.
| Code: | | cmp qword ptr [rsp+48],gamedll_x64_rwdi.dll+A67D5E |
You may need to do something like:
| Code: | push rax
lea rax,[gamedll_x64_rwdi.dll+A67D5E]
cmp [rsp+48],rax
pop rax
je hack
jmp originalcode |
|
|
| Back to top |
|
|
Rydian
Grandmaster Cheater Supreme
 Reputation: 31
Joined: 17 Sep 2012
Posts: 1358
|
| Posted: Sat Sep 19, 2015 8:35 pm Post subject: |
|
|
Sigh.
"You much change the reputation of a different member to be able to change reputation of the same member twice."
Zanzer is too helpful for the forum software to process.
_________________
|
|
| Back to top |
|
|
Noobrzor
Advanced Cheater
![]() Reputation: 0
Joined: 19 May 2014
Posts: 74
|
| Posted: Sun Sep 20, 2015 1:41 am Post subject: |
|
|
| Zanzer wrote: | I believe that CMP doesn't work well in 64-bit games.
I believe you cannot compare a 64-bit literal.
You can try changing it to the following, but I'm not sure that'll work either.
| Code: | | cmp qword ptr [rsp+48],gamedll_x64_rwdi.dll+A67D5E |
You may need to do something like:
| Code: | push rax
lea rax,[gamedll_x64_rwdi.dll+A67D5E]
cmp [rsp+48],rax
pop rax
je hack
jmp originalcode |
|
Thank you for your response. However, neither of these solutions worked. In both cases buffs still ended instantly, as per 'bug'. Also, I do not think cmp has any problems, because I did the identical thing in several other scripts in the same game, as I said, and in none case was this peculiar behaviour.
Moreover, your solutions do not relate to the second script I posted, in which I do not compare 64bit literals, but rather a dword and another self assigned dword, in which case the bug still persists.
Quite troubling, isn't it?
I tried to get things like cmpss, fcomi, etc to work instead of cmp, but my lack of understanding caused me to fail.
I think my cmp simply messes with earlier-set flags by overwriting them, causing the game to go numbnuts. I'll post the screenshot of the code in a moment:
A line or two above there's also movss xmm0,[rcx+10]
EDIT:
I have made a script that works flawlessly. I change the movss xmm0,[rcx+10] (line above top code presented) to have mov [rcx+10],(float)5 above it in hackcode and just the line in originalcode.
My conclusion:
In 32bit games xmm registers aren't used(i think? if they are, then, well, proceed as if it was 64bit game, the same rules apply), so there's zero risk of cmp instruction causing erratic behaviour like this.
In 64bit games compare loads the EFLAGS in the xmm registers, so if xmm registers are used somewhere in the code, one has to modify the script in which manner the xmm registers are reset to their original values before proceeding with the rest of the hackCode.
In this case, xmm0 holds the, say, 45 seconds of the buff's duration. Using cmp sets the xmm0 to 0, it seems. So, I need to have to 'reload' the xmm0 with the [rcx+10], which is the factual address and value of buff's duration in memory, otherwise the buff will end instantly, as simply cmp instruction in 64bit game changes/clears the xmm registers.
|
|
| Back to top |
|
|
Dark Byte
Site Admin
 Reputation: 470
Joined: 09 May 2003
Posts: 25785
Location: The netherlands
|
| Posted: Sun Sep 20, 2015 2:25 am Post subject: |
|
|
at what address is gamedll_x64_rwdi.dll located ?
If it's in the 80000000 to ffffffff range, then there is a bug in 6.4 release which will really mess things up. (Although if it's this bug, you'd more likely had a crash)
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
Noobrzor
Advanced Cheater
![]() Reputation: 0
Joined: 19 May 2014
Posts: 74
|
| Posted: Sun Sep 20, 2015 4:56 am Post subject: |
|
|
| Dark Byte wrote: | at what address is gamedll_x64_rwdi.dll located ?
If it's in the 80000000 to ffffffff range, then there is a bug in 6.4 release which will really mess things up. (Although if it's this bug, you'd more likely had a crash) |
I pasted the gamedll_x64_rwdi.dll into add address manually window. In CETable the new line shows address "7FFEB0DA0000"
Any way, it seems my 'bug' was due to my cmp overwriting another cmp or comiss, or otherwise overwriting the xmm registers. Ammending the code to manually reestablish the proper xmm registers fixed the strange behavior.
So I don't believe it was CE's fault, especially if you're saying it was supposed to crash the game.
Best Regards
|
|
| 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
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
