Cheat Engine

[Arondai]

While debugging a modification I wrote for a specific piece of software, I was puzzled by the fact that the software crashed when applying my modification,even though I thought to be absolutely sure I did not do anything wrong. After alot of debugging I found the problem to lie in ntdll code that assumed some of the data on the stack to be aligned on 16-byte boundaries.
My solution was pretty simple actually and something I wanted to share with you guys.

So, the problematic instruction in this case was the movaps instruction, which assumes that a source or destination memory operand starts on a 16-byte boundary. This basically means that the lowest nibble of your address (the rightmost 4 bits of the address) needs to be 0. In that case, the address is aligned correctly for movaps to function. The alignment is necessary,because such a SIMD instruction can retrieve multiple data elements (four floats for instance) at once, instead of using two or more instructions. This only works in case the data is in aligned blocks and/or is written to aligned blocks. In the case of the movaps instruction, a single register can be loaded with four floats with a single instruction call for example. Or the 128-bits of data can be written to memory in one instruction.

In case the data is not aligned on a 16-byte address you will get a general protection fault, pretty nasty.

Now, there is also a version of the movaps instruction that does the same, but does not need the 16-byte boundary enforcement. Thats the movups, where you might guess that the u stands for unaligned. The drawback however is manifold:

1. You need to change that instruction and what if you don't want
to modify code that resides in kernel modules (a wise choice btw, not to change kernel modules unless you have a VERY good reason!);
2. What if you are unaware of the amount of these aligned instructions deep down in a routine you are trying to execute from your modification?;
3. No parallellism possible and as such we arrive at reason 4:
4. Slightly less optimized piece of code

Point 4 is often not a big issue, unless alot of these instructions are used heavily.

Now there are more of these aligned instructions (google is your friend) and compile/link time it can be enforced that your data is on aligned boundaries but runtime you are on your own, the trees are planted in the forest and you can't simply reposition them and assume that it will work.

Now I thought of a solution that is quite elegant if I may say so and in my case it was a simple solution as the data relied on the stack pointer. I simply need to make sure that the stackpointer was pointing to 16-byte aligned addresses. Now how do you that? Simple: just truncate the rightmost nibble to 0. Is it that simple? Almost, by truncating, you are ruining the stackpointer of course. Popping of values from the stack after truncating has undesirable effects (you do the math). So instead, store your stackpointer in a temporary variable, subtract 16 from the stackpointer so you can safely truncate without pointing halfway to data that was already pushed onto the stack, like this for instance:

[mgr.inz.Player]

We usually just use movups instead of movaps.


and if you need addps, we are doing something like this:

[Arondai]

Ah yes, so me adding explanation to this does make sense I guess and therefore this post is still useful I guess.
It is not my goal to try and show what I thought of, as I am fully aware that nobody really invents new things. People learn if they are given explanations.

Forgive me for asking, but who is we?

And it's better to adhere to given constraints, as this results in less buggy code. Knowing why you do something, which options you have, will let you make decisions that make sense.