 |
Cheat Engine The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
Zander3709 How do I cheat?
Reputation: 0
Joined: 06 Aug 2019 Posts: 6
|
Posted: Thu Dec 19, 2019 11:20 am Post subject: 2 methods producing the same output but a different outcome |
|
|
So I have been trying to make a game compatible with other aspect ratios besides 16:9 [1.78]. I have sucessfully managed to remove letterboxing and make the game show more on the sides of the screen. The side effect of this though is that the UI will be zoomed in. I already know how to decrease the UI size again, but wanted to apply this change automatically instead of using a fixed value like 21:9 [2.38]. The problem i am having is that if i insert a calculated value into the xmm register which is used to scale the UI, it doesn't work. But if i manually insert the exact same value, even in hex to avoid any decimal point difference, it works perfectly.
This is what i have by now:
| Code: |
alloc(aspectratio,4)
newmem:
movss xmm6,xmm3 { 1.7777778 }
divss xmm6,[GameAdress+Offset] { 1.7777778 / 0.5 = 3.5555556 }
mov [aspectratio],(float)2.3888889 { fixed value for now }
movd xmm14,[aspectratio]
divss xmm14,xmm6 { 2.3888889 / 3.5555556 = 0.671875 }
pxor xmm6,xmm6
|
xmm14 should now contain the value "0.671875" and it does, but the UI which gets scaled based of that doesn't reflect that, it's way too tiny.
If i comment out the last divss and do this instead with a random address which happens to nearly have the same value i want, it works.
| Code: |
divss xmm14,[SomeAddress] { ~3.5555556 }
|
Another method:
| Code: |
push eax
mov eax,(float)0.671875 { 2.3888889 / (1.7777778 / 0.5) }
movd xmm14,eax
pop eax
|
This one works even after being executed after the one that doesn't work. So i don't believe that my other code messes up some flags etc. I have even set breakpoints to confirm that every address contains the same value after the code execution.
I am really baffled on what i did wrong, so i would really appreciate some input from someone else. I may have overlooked something i don't know about yet since i am still new to assembly.
|
|
| Back to top |
|
 |
ParkourPenguin I post too much
Reputation: 155
Joined: 06 Jul 2014 Posts: 4777
|
Posted: Thu Dec 19, 2019 12:33 pm Post subject: |
|
|
What does the original code look like, as well as the code around the injection point?
May you post the full script instead of just a snippet?
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| Back to top |
|
 |
Zander3709 How do I cheat?
Reputation: 0
Joined: 06 Aug 2019 Posts: 6
|
Posted: Thu Dec 19, 2019 1:27 pm Post subject: |
|
|
| ParkourPenguin wrote: | What does the original code look like, as well as the code around the injection point?
May you post the full script instead of just a snippet? |
Here is the full script:
| Code: |
[ENABLE]
aobscanmodule(uiAOB,DetroitBecomeHuman.exe,F3 44 0F 10 35 6B 9C 2D 01)
alloc(ui_newmem,$1000,"DetroitBecomeHuman.exe"+BB3FD4)
alloc(aspectratio,4)
label(originalcode)
label(ui_return)
registersymbol(uiAOB)
registersymbol(aspectratio)
ui_newmem:
movss xmm6,xmm3 { 1.7777778 }
divss xmm6,[DetroitBecomeHuman.exe+1E8DC48] { 1.7777778 / 0.5 }
mov [aspectratio],(float)2.3888889
movd xmm14,[aspectratio]
divss xmm14,xmm6 { 2.3888889 / 3.5555556 }
pxor xmm6,xmm6
originalcode:
//movss xmm14,[DetroitBecomeHuman.exe+1E8DC48] { 0.5 }
jmp ui_return
uiAOB:
jmp ui_newmem
nop 4
ui_return:
[DISABLE]
uiAOB:
db F3 44 0F 10 35 6B 9C 2D 01
unregistersymbol(aspectratio)
unregistersymbol(uiAOB)
dealloc(aspectratio,4)
dealloc(ui_newmem)
|
I can't really post the entire code around the injection point since it's too long. It does a lot of other stuff until it calls a function which will use the value inside the xmm14 register to do some other stuff and write a new value into an address which decides the UI scaling etc.
As you can see the origial code just writes the number 0.5 into the xmm14 register. I need a 0.67, doing that manually works, but calculating it with divss etc. even if it's the same number, somehow doesn't work.
|
|
| Back to top |
|
 |
ParkourPenguin I post too much
Reputation: 155
Joined: 06 Jul 2014 Posts: 4777
|
Posted: Thu Dec 19, 2019 2:39 pm Post subject: |
|
|
The aspectratio alloc isn't guaranteed to be located near the ui_newmem alloc. Directly addressing aspectratio might fail. You might get lucky and it'll be fine, but you should use the same third parameter for all the allocs all the same.
Also dealloc only takes a symbol (CE remembers how much it allocated).
Alternatively, remove that alloc entirely and use some of the memory in ui_newmem:
| Code: | ...
label(aspectratio)
...
ui_newmem+400:
aspectratio:
dd (float)2.3888889
... |
You're lucky that script activated at all. Or was that what you meant by "it doesn't work?"
You don't need to post the entire function the injection point is in- just the code around it is fine. e.g. give and take 10 instructions
If you used the aobscan template, it should've made a comment at the bottom with the code around the injection point.
Why pxor xmm6,xmm6?
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| Back to top |
|
 |
Zander3709 How do I cheat?
Reputation: 0
Joined: 06 Aug 2019 Posts: 6
|
Posted: Thu Dec 19, 2019 3:10 pm Post subject: |
|
|
| ParkourPenguin wrote: | The aspectratio alloc isn't guaranteed to be located near the ui_newmem alloc. Directly addressing aspectratio might fail. You might get lucky and it'll be fine, but you should use the same third parameter for all the allocs all the same.
Also dealloc only takes a symbol (CE remembers how much it allocated).
Alternatively, remove that alloc entirely and use some of the memory in ui_newmem:
| Code: | ...
label(aspectratio)
...
ui_newmem+400:
aspectratio:
dd (float)2.3888889
... |
|
I have adjusted my code like this, but the problem still persists so it must be something else.
| Code: |
alloc(aspectratio,4,"DetroitBecomeHuman.exe"+BB3FD4)
...
//mov [aspectratio],(float)2.3888889 { removed if i use a label instead of allocating new memory }
...
dealloc(aspectratio)
|
| ParkourPenguin wrote: |
You're lucky that script activated at all. Or was that what you meant by "it doesn't work?"
|
Sorry i didn't express myself properly. By "it doesn't work" i meant that the UI is scaled wrongly. The lower the value, the bigger the UI and vice versa. The injection works, but the UI is extremly small, almost invisible. So it looks like a wrong value is being used.
| ParkourPenguin wrote: | | Why pxor xmm6,xmm6? |
To clear xmm6 like it was before and therefore avoid messing up calculations done after my injection.
| ParkourPenguin wrote: |
You don't need to post the entire function the injection point is in- just the code around it is fine. e.g. give and take 10 instructions
If you used the aobscan template, it should've made a comment at the bottom with the code around the injection point.
|
| Code: |
{
// ORIGINAL CODE - INJECTION POINT: "DetroitBecomeHuman.exe"+BB3FD4
"DetroitBecomeHuman.exe"+BB3FB3: 8B C6 - mov eax,esi
"DetroitBecomeHuman.exe"+BB3FB5: F3 48 0F 2A C0 - cvtsi2ss xmm0,rax
"DetroitBecomeHuman.exe"+BB3FBA: F3 44 0F 5E D8 - divss xmm11,xmm0
"DetroitBecomeHuman.exe"+BB3FBF: EB 04 - jmp DetroitBecomeHuman.exe+BB3FC5
"DetroitBecomeHuman.exe"+BB3FC1: 45 0F 28 DC - movaps xmm11,xmm12
"DetroitBecomeHuman.exe"+BB3FC5: 48 8B 03 - mov rax,[rbx]
"DetroitBecomeHuman.exe"+BB3FC8: 48 8B CB - mov rcx,rbx
"DetroitBecomeHuman.exe"+BB3FCB: FF 50 10 - call qword ptr [rax+10]
"DetroitBecomeHuman.exe"+BB3FCE: 48 8B 03 - mov rax,[rbx]
"DetroitBecomeHuman.exe"+BB3FD1: 48 8B CB - mov rcx,rbx
// ---------- INJECTING HERE ----------
"DetroitBecomeHuman.exe"+BB3FD4: F3 44 0F 10 35 6B 9C 2D 01 - movss xmm14,[DetroitBecomeHuman.exe+1E8DC48]
// ---------- DONE INJECTING ----------
"DetroitBecomeHuman.exe"+BB3FDD: 44 0F 28 C0 - movaps xmm8,xmm0
"DetroitBecomeHuman.exe"+BB3FE1: F3 45 0F 59 C6 - mulss xmm8,xmm14
"DetroitBecomeHuman.exe"+BB3FE6: FF 50 08 - call qword ptr [rax+08]
"DetroitBecomeHuman.exe"+BB3FE9: F3 0F 10 A3 D0 00 00 00 - movss xmm4,[rbx+000000D0]
"DetroitBecomeHuman.exe"+BB3FF1: 41 0F 28 D4 - movaps xmm2,xmm12
"DetroitBecomeHuman.exe"+BB3FF5: F3 0F 10 AB D4 00 00 00 - movss xmm5,[rbx+000000D4]
"DetroitBecomeHuman.exe"+BB3FFD: 41 0F 28 DC - movaps xmm3,xmm12
"DetroitBecomeHuman.exe"+BB4001: F3 41 0F 59 C6 - mulss xmm0,xmm14
"DetroitBecomeHuman.exe"+BB4006: F3 0F 5C D4 - subss xmm2,xmm4
"DetroitBecomeHuman.exe"+BB400A: F3 0F 5C DD - subss xmm3,xmm5
}
|
|
|
| Back to top |
|
 |
Csimbi I post too much
Reputation: 98
Joined: 14 Jul 2007 Posts: 3428
|
Posted: Thu Dec 19, 2019 3:37 pm Post subject: |
|
|
So, what do you need in that XMM register for this to work?
- int,
- float,
- or double?
The instructions you use are mixed while we don't actually see what's at the memory location when it works.
|
|
| Back to top |
|
 |
Zander3709 How do I cheat?
Reputation: 0
Joined: 06 Aug 2019 Posts: 6
|
Posted: Thu Dec 19, 2019 3:55 pm Post subject: |
|
|
| Csimbi wrote: | So, what do you need in that XMM register for this to work?
- int,
- float,
- or double?
The instructions you use are mixed while we don't actually see what's at the memory location when it works. |
Well i was under the impression that i can't use int, since i have decimal point values. Didn't really take double into consideration, since the values deciding the scaling are also floats.
What baffles me is that why are there two different outcomes? Both times xmm14 has the exact same value, even in hex, so there shouldn't even be a different outcome right? It's not like i am chaning some flags or registers which might mess up some calculation further down the road.
Last edited by Zander3709 on Thu Dec 19, 2019 4:52 pm; edited 1 time in total |
|
| Back to top |
|
 |
ParkourPenguin I post too much
Reputation: 155
Joined: 06 Jul 2014 Posts: 4777
|
Posted: Thu Dec 19, 2019 4:05 pm Post subject: |
|
|
Based on what you said did work in your first post, the only thing I can think of is that xmm3 doesn't hold the value you think it does. Or maybe you had another script active at the same time that messed things up. I can't tell what the problem is without debugging it.
This shouldn't fix the problem, but instead of xmm6, I'd use xmm8. xmm8 is immediately clobbered afterwards by movaps which means nothing is using it at the code injection. I can't see where xmm6 is used either, but that doesn't mean it isn't used.
If you insist on using xmm6, pxor isn't a good solution to restore it unless you can see that it's set to 0 on all code paths to the injection point. Back up the old value to some memory location and use that to restore it (e.g. sub rsp,10 / movups [rsp],xmm6 / movups xmm6,[rsp] / add rsp,10).
Edit: they're all floats; I don't know what Csimbi is referring to.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| Back to top |
|
 |
Zander3709 How do I cheat?
Reputation: 0
Joined: 06 Aug 2019 Posts: 6
|
Posted: Thu Dec 19, 2019 4:28 pm Post subject: |
|
|
| ParkourPenguin wrote: | Based on what you said did work in your first post, the only thing I can think of is that xmm3 doesn't hold the value you think it does. Or maybe you had another script active at the same time that messed things up. I can't tell what the problem is without debugging it.
This shouldn't fix the problem, but instead of xmm6, I'd use xmm8. xmm8 is immediately clobbered afterwards by movaps which means nothing is using it at the code injection. I can't see where xmm6 is used either, but that doesn't mean it isn't used.
If you insist on using xmm6, pxor isn't a good solution to restore it unless you can see that it's set to 0 on all code paths to the injection point. Back up the old value to some memory location and use that to restore it (e.g. sub rsp,10 / movups [rsp],xmm6 / movups xmm6,[rsp] / add rsp,10).
Edit: they're all floats; I don't know what Csimbi is referring to. |
I have used pxor because i saw that xmm6 had the value 0 in it when i was injecting code. Thats why i was clearing it aftewards. Using xmm8 is definitely a better solution, i see that know. Sadly it didn't resolve my issue, but you were still right. xmm3 was the problem. When i was setting a breakpoint, xmm3 was always holding 1.78, but since this code is getting executed over 100 times a second, a few iteration might not and therefore mess up the calculation. I have created a new label and set it's value to 1.78 somewhere in memory and then used this for calculation and voila, everything worked. Since i have also found out now which exact addresses decide the scaling, i could see that they didn't have the proper value in them. To clarify, the one address i was using earlier was just used for calculation purposes and not the actual scaling. Nevertheless, thank you so much for your help.
One last question though. I get that when the function gets called, there might be different values in the registers, but who wins in this case? Because every time i set a breakpoint, xmm3 was 1.78. Now if he function writes 100 times a second into that address and 20 times xmm3 isn't what i wanted, the calculated value is wrong and might create some UI issues, like pop in etc. since it's value keeps getting changed. But in this case, i saw nothing. The value was always the wrong one. I can't understand how that can happen unless i was really unlucky with my breakpoints and they happened to contain the value i wanted 1 in a 100 times.
|
|
| Back to top |
|
 |
ParkourPenguin I post too much
Reputation: 155
Joined: 06 Jul 2014 Posts: 4777
|
Posted: Thu Dec 19, 2019 5:05 pm Post subject: |
|
|
Something different was happening when you had a breakpoint set. There are too many possibilities as to the reason why for any one to have notable significance... maybe it had something to do with which window was in focus, or an operation took a few microseconds longer with a breakpoint set.
The act of observing a program can change what the program does even if you yourself don't change anything.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| Back to top |
|
 |
Zander3709 How do I cheat?
Reputation: 0
Joined: 06 Aug 2019 Posts: 6
|
Posted: Thu Dec 19, 2019 5:27 pm Post subject: |
|
|
| ParkourPenguin wrote: | Something different was happening when you had a breakpoint set. There are too many possibilities as to the reason why for any one to have notable significance... maybe it had something to do with which window was in focus, or an operation took a few microseconds longer with a breakpoint set.
The act of observing a program can change what the program does even if you yourself don't change anything. |
I understand now. Thank you very much for your explanation and help.
|
|
| 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
|
|