CE 7.1 Script Problems

[l0wb1t]

Guys i'm lost since i went to CE 7.1 i get now this after aob injection. why does that happen? it obviously corrupts the Memory. Does anyone elese noticed that? whats the reason for that?

I have this problem in almost any game x64, x32 doesn't matter
NOP dword ptr [rax+00] , i don't get it can't do anything anymore

[cfemen]

i also noticed it since CE 7.1



only few nopes are generating strange opcodes but they are not corrupting the code.

4+ NOPs = code(like your screenshot) that crashes the game :/

would also like to know why this happens,but i always replace too much NOPs with 0x90, that works

[l0wb1t]

4+ NOPs = code(like your screenshot) that crashes the game :/
would also like to know why this happens,but i always replace too much NOPs with 0x90, that works

For me it doesn't matter how much nops i have after jmp to allocated memory. it alwys corrupts my memory ínside allocated memory, when i put nothing into newmem, the problem is not happening, just when i type in costum code.
My jump needs only one NOP, its still getting corrupted.

to the NOP 2,3,4 Thing
Try to add the normal nops back instead of NOP 2 in the script and see if that helps, (it helped for me in Death Stranding )
But in this scenario theres only one NOP and the problem happens again

Maybe Erik/DB can tell us whats happening here

[Eric]

It's a replacement for ce's

Code: Select all

nop
nop
nop
nop

it would have normally put there

In short, it's just a nop and should not cause an issue.

[l0wb1t]

It's a replacement for ce's

Code: Select all

nop
nop
nop
nop

it would have normally put there

In short, it's just a nop and should not cause an issue.

I know that nop x is a replacement by nops

For example nop 3 represents 3 times nop.
My problem is that as soon i start writing something under newmem, ce is going to add nop dword ptr [rax+00]. That's not normal, also in death stranding it corrupts the memory right after the jump to allocated mem when I use the new default nop x method. Is that an byte length detecting problem? I remember having that in some older x64 titles aswell but it got fixed in a later release of CE. But this
Nop dword ptr [rax+00] thing is completely new to me and not normal!?

[l0wb1t]

I'm going to make a video

[Eric]

CE has always added nops after forward jumps that haven't specified the size
Now it just uses a different instruction that has the same execution effect (just faster)

the bytes after the jmp to newmem being corrupted in 64-bit is because you neglected to use a preferred base for the alloc parameter or there is no memory available to allocate near so CE will use a 14 byte jmp, but that is not one of these nop things


But what CPU do you have? CE should only fill it with multibyte nops if it detects the cpu can handle multibyte nops

[l0wb1t]

CE has always added nops after forward jumps that haven't specified the size
Now it just uses a different instruction that has the same execution effect (just faster)

the bytes after the jmp to newmem being corrupted in 64-bit is because you neglected to use a preferred base for the alloc parameter or there is no memory available to allocate near so CE will use a 14 byte jmp, but that is not one of these nop things


But what CPU do you have? CE should only fill it with multibyte nops if it detects the cpu can handle multibyte nops

I know about that nop 2,3 or more thing in the new cheat engine. that's not my problem atm. Somehow cheat engine is adding nop dword ptr [rax+00] in my allocated memory and that is causing crashes because of the corrupted memory.
Weird that it doesn't happen too all games just some. And if the memory after the jump is getting corrupted i have to use
Nop
Nop
Nop
Instead of Nop 3,this fixes this corrupted memory sometimes. But the Nop dword ptr [rax+00] bug makes ce completely useless in some games.

If you need more informations about that, let me know.
Thanks for the reply Eric

Oh and BTW..
My CPU is Ryzen 7 3700x

[mgr.inz.Player]

Multibyte nops are normal things these days. Many modern compilers use those.

Just attach CE to your game and do assemblyscan for "nop *" (without "). You will find plenty of them.

I know that nop x is a replacement by nops. For example nop 3 represents 3 times nop

"nop 3" will use "3 bytes nop", which is 0x0F 0x1F 0x00, not three 0x90.

Your "jne code2" is treated by CE as "jne far code2"...

What do you see when you use "long"

Code: Select all

cmp word ptr [esp+0],4902
jne long code2
nop
nop
nop
nop
code2:
  mov ecx,[eax]
  mov edx,[esp+04]

and "short" keywords?

Code: Select all

cmp word ptr [esp+0],4902
jne short code2
nop
nop
nop
nop
code2:
  mov ecx,[eax]
  mov edx,[esp+04]

PS: for 64bit processes you better use alloc third parameter.

[Eric]

Show a video where the nop [rax+0] causes memory corruption. Try stepping through it with the debugger.

Or are you using size specific jump that jump inside the middle of a nop row? Because that is just bad coding

[BADORGOOD]

use normal nops and remove nop X, or use db 90

And no is need use short and long jumps, can cause problems.

A short jump can be achieved using a relative offset from the current assembly instruction. For x86/32-bit, this is a 2 byte instruction, where the first byte is always EB, for short jump, and the second byte is the number of bytes before or after the current instruction to jump. The second byte is a signed 8-bit number, so the the furthest short jump on x86 is +/-127 bytes away. Anything past +/-127 bytes away is a long jump, E9, and must use the full 32-bit address; resulting in a 5 byte instruction.

This is important to keep in mind if you are inline patching assembly code.

ex. EB 0 would jump to the opcode following the short jump, not the line of code itself.

ex. EB 7F is the furthest jump down.


regards

[mgr.inz.Player]

@l0wb1t, do you still have problems when you use "jne short code2"?

Or you just do not like the look of multibyte NOP (I mean this "nop dword ptr [rax]").
Well, other disassemblers also show "0F 1F 00" as "nop dword ptr [rax]"
x64dbg:


In that case, you can override CE disassembler and just show empty lines.

[l0wb1t]

@l0wb1t, do you still have problems when you use "jne short code2"?

Or you just do not like the look of multibyte NOP (I mean this "nop dword ptr [rax]").
Well, other disassemblers also show "0F 1F 00" as "nop dword ptr [rax]"
x64dbg:


In that case, you can override CE disassembler and just show empty lines.

YEAH jne short fixed it lol

Thanks