Cheat Engine

[catfood]

.




.

[++METHOS]

Search using hex values. In the memory viewer, there should be a 'bytes' column. You can highlight several instructions (for a unique array) and right-click, select Copy to clipboard --> Bytes only (no address).

Alternatively, just highlight the instruction that you want to search for, and let CE build a script using AOB injection under the tools/auto assemble window.

Searching assembly code should work, but I'm not sure how it handles module addressing. Perhaps turn that off before you search. You can turn off module addresses in the memory viewer...select View from the drop-down menu, and uncheck Show module addresses.

[catfood]

. .

[ParkourPenguin]

If you're just looking for intra-module jumps to a specific address, then go to Memory Viewer -> Tools -> Dissect Code. Select the module(s), and after it's done, you can go to that address and see everything that jumps to it.

If you're looking for any instruction that could jump to any address inside that module, then that's much more complicated. You'll need to understand how jumps are encoded and how to use Lua in CE. Search for the opcodes in executable memory only using an AoB scan, and use the bytes after any found opcodes to determine whether or not it's jumping inside the module. Even then, there's no guarantee the jump or the destination is aligned in such a way that it's likely to be executed. You might a fake jump lying within another instruction (or two).

[++METHOS]

[catfood]

. .

[++METHOS]

Did you try as I suggested to see if the module that you are looking for even shows up?

[catfood]

yeah, that leads me to where they start in memory. but doesnt help me find the location they actually hook at, to create the memory in the first place.

(my end goal here is to modify the hook point so that the hack.dll can not properly hook to my game)

[ParkourPenguin]

If you only protect that one single point, then the only thing that'll do is invalidate the .dlls for that version. You don't have to make a hook at a specific point, so doing this isn't really going to stop anyone. Protect the entire thing, however, and you may get some results depending on how good your protection is.

Regardless, have you tried setting breakpoints inside that .dll?

[++METHOS]

[catfood]

. . .

[++METHOS]

Okay...I see what you're trying to do now. In that case, as ParkourPenguin suggested, this method of protection is not ideal at all.

Also, depending on how the cheats were written, they could call a function inside their dll, in lieu of jumping to it. In that case, you'll have to analyze the stack to see where the calls are coming from. With ollydbg or x64dbg, you can view all intermodular calls, making it easy to see all of the calls to that particular dll module.

But...what's to stop them from simply renaming their module or changing the location of their hook? Or are they using one of the game's dlls?

I can't help much in the way of protection, so someone else will have to chime in. I know that there are many ways to do it...such as packing the file, obfuscating code, running memory integrity checks etc., but if they're good enough, nothing you can do will stop them unless everything is server-sided with additional protective measures in place.

By the way, why do you care if people cheat? Are you implementing micro-transactions/DLC or something? Does your game have online components that would even warrant any anti-cheat measures?

[++METHOS]

I guess the OP didn't want his 'advanced' anti-cheat measures publicly disclosed.

[Zanzer]

woops