Cheat Engine

jim2point0 · Posted: Wed Nov 12, 2014 7:43 pm Post subject:

The primary motivation for them using anti-cheat measures is to keep people from giving themselves free money, therefore circumventing the microtransactions.

Unfortunately it's getting in the way of me doing a free camera hack which I SO DESPERATELY want to do in this game Sad

Dark Byte · Posted: Wed Nov 12, 2014 8:02 pm Post subject:

Get the cracked version (Really, any game with DRM like this I always suggest getting the cracked version. Not only will it make cheating easier, it often makes the game a lot faster/more playable)

Also, the cracked version might still have the integrity check, but debugging might be easier, so you might then be able to apply that on the release

Anyhow, regarding debugging. Have you done all the tests and checks ?
While the game is running debug the tutorial
Does the game close ?

If it does, you might need an undetected CE (go get the ce sourcecode and start editing)

If not, restart cheat engine and the game (you can not reuse a ce after it has used the debugger even if it was a different target, and the target can not be reused if veh has been tried before)
make sure VEH debug is enabled in settings (also make sure it's NOT set to int3 breakpoints. hardware breakpoints for now)

Do NOT open the target process
Go to memoryview->view->debug events

keep that windows open and go to the processlist, select the process, and click on "Attach debugger to process"

Did the game crash ?
If yes, perhaps the event log may contain why
If no, it's detecting the way you set breakpoints

In memoryview go to view->threadlist and expand the first few thread
Do the DR# fields have a number set besides 00000000 ?
If yes, disable "override existing breakpoints when setting breakpoints"

If after that it doesn't crash, but it won't find anything either, then that means all debug registers are used up.

If it did crash or no results, then restart both ce and the game and change the prefered breakpoint to page exception
Again, attach the debugger using the processlist and wait till it has cooled down a bit (check the debug event log)

If it crashes, check the debug event log, it may show why

Just wondering, are you one of the few rare people that can use DBVM? If so, you may have a bit of luck with global debug (although if all debug registers are used up that won't help much, i might be assed to add some priority to page exceptions in dbvm, or even implement the non-readable execute only physical memory regions making a hardware level stealthedit)

flarn2006 · Posted: Wed Nov 12, 2014 8:12 pm Post subject:

jim2point0 · Posted: Wed Nov 12, 2014 11:16 pm Post subject:

No crash when I debug the tutorial.

When I attach the debugger to ACU.exe, Cheat Engine actually freezes. The game continues running though. I have to force close Cheat Engine.

The threadlist looks like this.

I was actually able to attach a debugger this time. When a create a script that hooks into an opcode and executes the same original code, it still crashes.

It is apparent to me that I have no idea what I'm doing when it comes to debugging this kind of thing Sad

I did try a cracked version. I'm getting the same results though.

++METHOS · Posted: Thu Nov 13, 2014 12:53 am Post subject:

omoe · Posted: Thu Nov 13, 2014 4:43 am Post subject:

The game sure use a lot of scanners , I managed to bypass all of the scanners ,It wasn't that hard to do, Here are some addresses if anyone is interested to get you started .

V1,1
"ACU.exe"+54159C5
"ACU.exe"+5417472
"ACU.exe"+26EBF8E
"ACU.exe"+5414089
"ACU.exe"+2821F23
"ACU.exe"+5418E9D
"ACU.exe"+5432761
"ACU.exe"+5418D0D
"ACU.exe"+5418842
"ACU.exe"+540D240

Dark Byte · Posted: Thu Nov 13, 2014 6:13 am Post subject:

Jim2point, yeah, debugging shouldn't be a big issue (dr=0) but before you can do a code injection you must first do another code injection that turns off all scanners at the same time(perhaps someday someone will post a table with such a bypass somewhere)

Alternatively, as i mentioned before, a change register on breakpoint could suffice

omoe · Posted: Thu Nov 13, 2014 6:24 am Post subject:

No prob , I would also suggest you guys pause the game before injecting the scripts because the game uses 3 threads to scan itself like others have mentioned and it will crash 90% of the time if you don't pause it .

jim2point0 · Posted: Thu Nov 13, 2014 10:47 am Post subject:

omoe · Posted: Thu Nov 13, 2014 11:02 am Post subject:

Xblade Of Heaven · Posted: Thu Nov 13, 2014 6:41 pm Post subject:

ce dont work very good in x64 targets, you use kernelmode?, kernelmode alloc in x64 proccess are bugged, the code injected is corrupt, try disabling

and look in memory viewer when you enable a script, the code some time no is correct.

regards

Dark Byte · Posted: Thu Nov 13, 2014 6:52 pm Post subject:

report instructions that are wrong.

Anyhow, the important thing is that you use the 3th parameter of alloc to specify that the range is within 32-bit (and disable kernelmode read/write process memory), or deal with the fact that jmp has a chance of being 14 bytes

DarkIceCore · Posted: Thu Nov 13, 2014 7:23 pm Post subject:

using "hardware breakpoints", all works. mby wrong?

with "int3 instr." only on access other making crash's.

with "page exceptions" just nothing.

I can make an injection on "end" of code,
somewhere like "ACU.exe"+5A46FA4 and etc, for push something or read from memory, but all my decisions have no success.

many times saw some "protection" parts, but not sure how to "loop" them all.

now know about some functions/instructions for getting right addresses for all inventory, money, points. stuck how to use it without injection in protected parts, just how to read them from there.

Dark Byte · Posted: Thu Nov 13, 2014 8:42 pm Post subject: