Cheat Engine

[shakib187]

Is there a way to fix this? I cannot stealthedit my game

[Dark Byte]

the problem with 64bit is that address specifiers can be RIP relative. That means that relocated code needs to be rewritten, which causes shifts in opcode locations, which causes other code to break.

it can be fixed, but will require a person to manually fill in the relocated block of code

[shakib187]

[shakib187]

bump, com on DB please help

[Dark Byte]

First you'll need a stealthedit compiled to 64-bit. (probably not going to happen anytime soon)

Then instead of such a script, you need a script that's about 5000 times bigger.

For every possible entry point into the page(including the page boundary instructions), you must make a different redirect which points to a standalone path from that point. Rewriting all RIP relative accesses to direct memory accesses, until you're out of the page, and then jump back

In short: I think it might be easier to find the integrity check routines, and change those to read a copy instead

[justa_dude]

[Dark Byte]

Because jumps do not modify/rely on updated data so don't need to be rewritten.
Address specifiers do need to be rewritten when their position changes

e.g:

[justa_dude]

[Dark Byte]

Relocating is easier yes, but that's not what stealthedit does

When it encounters the non-executable page it jumps to the copy, but all it's data access must still point to the original addresses.(stack pointers are unaffected as well)

In 32-bit this is easy because once the module has been loaded the relocation table has updated all the opcodes that access data inside the module to point to the correct address. So when that gets copied they still point to the exact address before the copy(they point to the original module)
So when a function in the copy is executed, like acquiring a critical section lock, it will acquire the lock on the variable in the original memory and not in the copy, so other threads that want to acquire the lock, and currently aren't executing in the copy, can see the lock has been obtained and wait till it's released
In 64-bit with rip relative addressing it would lock the critical section in the copy, and no other thread would see it

Calls and jumps inside the module are fine since they do not get changed during runtime. So if the copy calls another function it executes the same type of code as the original. Eventually returning to the original module thanks to the stack, or a hardcoded address jmp

An alternate solution is to write an x86 emulator that emulates the execution of the protected page.

If you're one of the few lucky people that can use dbvm, then it might be easier. With that i can set specific callbacks on reads, and ignore executions.(only on newer cpu's so even less people can use it)

[justa_dude]

[shakib187]