Cheat Engine

[iliketotestsecurity]

Can you test your skills on this? and can you even crack this? or use cheat-engine on this O_O?
(If you don't trust it, use on an virtual-machine if you want to.)
drive(.)google(.)com/file/d/1AwgctbJb4vajLDcf3LKzEoyk9OecPftW/view?usp=drive_link

virustotal(.)com/gui/file/b1cb6329f16fe1d59f96e47aaff756bad10969a69c172dcf951dbd1756cf3a6c/detection

[atom0s]

Cracked/Hacked proof:


Notes

Your application has full debug info left in, via DWARF information entries.
Your application startup is very easily visible and understandable.
- Starts by initializing the internal Vault for the save info.
- Hashes the text section and stores that in a global value.
- Starts the anti-debug integrity check thread.
- Creates the window and begins the normal message pump.

Your anti-debugging / integrity check thread is fairly basic and easy to bypass.
- Uses IsDebuggerPresent.
- Uses CheckRemoteDebuggerPresent.
- Uses NtQueryInformationProcess to do some process checks.
-> Checks ProcessDebugPort
-> Checks ProcessDebugObjectHandle
-> Checks ProcessDebugFlags
- Uses FindWindow to scan for common named tools (incorrectly):
-> C
-> cheatengine-x86_64.exe
-> cheatengine-x86.exe
-> x64dbg
-> x
-> OllyDbg
-> IDA -
-> IDA Pro
-> WinDbg
-> P
-> Process Hacker 2
-> M
- Checks the .text section hash.

This is all easily bypassed by various means. You can completely kill the anti-debug thread without the app doing anything making all of that pointless. If you leave it enabled, you can easily bypass all of the other checks it does by doing simple hooks or stubs for the APIs being used. You can easily patch the returns to fake the expected data as well.

For the window name checks you can simply just rename things or mod them to use a different window name which will bypass all of those checks. (ie. you can just rename Cheat Engine to something else like c86.exe and it will work fine.)

You can search for the memory values afterward and make direct edits without issue either. None of the memory addresses or values are protected either so you can make direct edits without issue. If you want to go the extra mile, you can just directly call the function addresses or make direct edits to the needed globals to directly edit things as well. There's no real protection on the values outside of your vault stuff but that does not seem to be implemented in a manner that actually protects anything.

Here's an example of one of the functions to do an upgrade:

[iliketotestsecurity]

yeah its pretty easy i thought it was hard Lol but thx for trying it out