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 


Getting random bytes in my code when patching with AA

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> General Gamehacking
View previous topic :: View next topic  
Author Message
Burningmace
Grandmaster Cheater
Reputation: 5

Joined: 17 Feb 2008
Posts: 520
Location: Inside the Intel CET shadow stack

PostPosted: Sat May 31, 2014 9:36 am    Post subject: Getting random bytes in my code when patching with AA Reply with quote

I'm not really sure what's happening here, as I'm not as familiar with AA as I am regular assembly.

Here's my script:

Code:
[enable]
alloc(BatteryCodeCave, 1024) // our code goes here
alloc(CheatData, 1024)       // our data goes here
label(BatteryReturn)

CheatData:
dd 459C4000 // 5000.0 as IEEE 745 Float

BatteryCodeCave:
movss xmm1, [CheatData] // load 5000 battery to xmm1
movss [rcx+0DC], xmm1   // save to game mem
jmp BatteryReturn

"game.exe"+0021A202:
jmp BatteryCodeCave
nop // pad with 2 nops to cover the difference in bytes
nop
BatteryReturn:

[disable]
dealloc(BatteryCodeCave) // cleanup
dealloc(CheatData)

"game.exe"+0021A202:
movss [rcx+0DC], xmm1    // restore
call "game.exe"+00219E50
add rsp, 20
nop
ret


Here's what the code at 0021A202 looks like:

Code:

game.exe+21A202 - F3 0F11 89 DC000000   - movss [rcx+000000DC],xmm1
game.exe+21A20A - E8 41FCFFFF           - call game.exe+219E50
game.exe+21A20F - 48 83 C4 20           - add rsp,20
game.exe+21A213 - 90                    - nop
game.exe+21A214 - C3                    - ret
game.exe+21A215 - CC                    - int 3
game.exe+21A216 - CC                    - int 3


Here's what it looks like once I've enabled the script:

Code:

game.exe+21A202 - FF 25 00000000        - jmp qword ptr [game.exe+21A208]
game.exe+21A208 - 00 00                 - add [rax],al
game.exe+21A20A - 92                    - xchg eax,edx
game.exe+21A20B - 12 00                 - adc al,byte ptr [rax]
game.exe+21A20D - 00 00                 - add [rax],al
game.exe+21A20F - 00 90 902090C3        - add [rax-3C6FDF70],dl
game.exe+21A215 - CC                    - int 3
game.exe+21A216 - CC                    - int 3


Where did those 00 00 92 12 00 00 00 00 bytes come from? Where did the bytes of the subsequent call go? My two nops seem to have been placed further down the code at 21A210, which is very strange.

Now, if I take the two nops out of my code, it still looks weird:

Code:

game.exe+21A202 - FF 25 00000000        - jmp qword ptr [game.exe+21A208]
game.exe+21A208 - 00 00                 - add [rax],al
game.exe+21A20A - 93                    - xchg eax,ebx
game.exe+21A20B - 12 00                 - adc al,byte ptr [rax]
game.exe+21A20D - 00 00                 - add [rax],al
game.exe+21A20F - 00 83 C42090C3        - add [rbx-3C6FDF3C],al
game.exe+21A215 - CC                    - int 3
game.exe+21A216 - CC                    - int 3


This time we have 00 00 93 12 00 00 00 00 appearing, and the code after still gets trashed.

The odd thing is that the disable part writes everything back perfectly.

If I manually alloc and patch in the disassembler, it all works fine. What's the reason for this? Have I made a mistake somewhere?

_________________
It's not fun unless every exploit mitigation is enabled.
Back to top
View user's profile Send private message
justa_dude
Grandmaster Cheater
Reputation: 23

Joined: 29 Jun 2010
Posts: 891

PostPosted: Sat May 31, 2014 10:30 am    Post subject: Reply with quote

I think it's a quirk of 64-bit. Note that the jmp actually takes up 14 bytes rather than the six you're counting, because it is including the target address immediately after the jump, eg
1) jump to address that follows in mem
2) 8 byte address
3) your nops
4) whatever else was already there

I'm not sure if there's a jump instruction that takes an 8-byte immediate target.

Also, stylistically, you could replace the alloc for BatteryCodeCave with a label and your hard-coded float with a (float) cast. But, of course, that's not going to fix your error in this case.

_________________
A nagy kapu mellett, mindig van egy kis kapu.
----------------------
Come on...
Back to top
View user's profile Send private message
Burningmace
Grandmaster Cheater
Reputation: 5

Joined: 17 Feb 2008
Posts: 520
Location: Inside the Intel CET shadow stack

PostPosted: Sat May 31, 2014 6:09 pm    Post subject: Reply with quote

I just noticed the memory address for the call is for the "instruction" directly after the call. So basically it's pointing to some data it made straight after the call. Perhaps it's to get a literal call rather than a relative one.

My patch code now looks like this:

Code:

"game.exe"+0021A202:
push BatteryCodeCave
ret
BatteryReturn:
nop
nop


With BatteryCodeCave like this:

Code:

BatteryCodeCave:
movss xmm1, [CheatData] // load 5000 battery to xmm1
movss [rcx+0DC], xmm1   // save to game mem
jmp BatteryReturn


This works now, because I'm generating my own literal jump and return. I'm guessing CE couldn't work out how to do a relative call. It's a shame CE messes this up - surely it should be reasonably simple to compute the offset for a relative call based upon the source address (from the alloc or label) and target address (from the instruction itself)?

_________________
It's not fun unless every exploit mitigation is enabled.
Back to top
View user's profile Send private message
Dark Byte
Site Admin
Reputation: 457

Joined: 09 May 2003
Posts: 25262
Location: The netherlands

PostPosted: Sat May 31, 2014 6:47 pm    Post subject: Reply with quote

it's either this solution, or the usual error message with middle finger icon saying that your code is wrong and that you have to recode it

to explain:
in 64-bit jumps are still limited to a signed 32 bit distance jump

if the distance between origin and destination is bigger than 0x7fffffff then it is impossible to encode such a call/jump

with the way you used alloc, you didn't specific a preferred base, so the chance that the address you get is bigger than that limited distance is very high

In that case cheat engine will see the mistake and substitute the bad instruction with a piece of code that results in the same affect (just more bytes and not disassembler friendly)

---
But, if you wish to prevent this headache of memory distances being bigger than 0x7fffffff then just give a prefered base address
e.g:
Code:

alloc(BatteryCodeCave, 1024, "game.exe"+0021A202)

that will find the closest memory block that is free near "game.exe"+0021A202 and allocated the memory there, which is most of the time within 0x7fffffff (unless it really eats up a LOT of memory)

_________________
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
View user's profile Send private message MSN Messenger
Burningmace
Grandmaster Cheater
Reputation: 5

Joined: 17 Feb 2008
Posts: 520
Location: Inside the Intel CET shadow stack

PostPosted: Sun Jun 01, 2014 7:12 am    Post subject: Reply with quote

Aaaah, see now that makes sense. I had considered that it was trying to do a far call to beat the 31-bit limit, but I thought it might just have mis-encoded it.

Also, newfound respect for CE / AA being able to do that "nearest" allocation trick. That's frickin' awesome.

I'll keep that in mind for future, cheers Smile

_________________
It's not fun unless every exploit mitigation is enabled.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> General Gamehacking All times are GMT - 6 Hours
Page 1 of 1

 
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