OTClient Simple anti-cheat - prevent from being NOP'd out?

[Source]

Just curious if any seasoned reverse engineers has any tips on how to prevent an anti-cheat function being NOP'd out.

I've thought of creating a second function that's called "everywhere" that checks at the same interval as the anti-cheat whether the anti-cheat has been executed within the last interval by inspecting some values used and stored from the anti-cheat function, but this function can simply be returned at the beginning (if finding all the entries to NOP them out is too much work).

I think the best idea conceptually or theoretically is to add crucial or necessary function calls for the client to work at all to the anti-cheat function.
But I can't think of any yet that has global scope.
The only idea I got right now is to move the anti-cheat function to the scope of a necessary function and move all the crucial functionality into the anti-cheat xd

Thoughts?

 

[Night Wolf]

I have a bit of experience in the area, enough to tell you anti-cheats are in their majority just to prevent wannabe hackers to mess out your files/game. They will work for people who are not devs or jr devs with no actual experience of reverse engineering.

What I have seen companies doing out there is similar to what you're proposing, checking from time to time or even pulling a lot of validations of the anti-cheat to their core functions however this has a strong assumption which is that the anti-cheat will caught any actual harmful cheater, which is not always true.

I'd say there's 2 major things devs can do to maximize their chances:
1. Develop focusing in security. Everything should always be validated by the server. Assume the client is hijacked already.
2. Think as hacking as a means to get profit. If you take out the amount of money these people can make or make it hard enough so it won't be attractive you should be fine for 99.9% of the cases.


Now, if someone wants to hack your game purely by the challenge or will to do so. Just know that most likely they will be able to. Question is how you can identify this in the middle of the process so you can take actions before they succeed?

 

[Source]

@nightwolf
Sure.
I'm aware of the principles and efficacy of client-based security (TLDR you can never protect your files 100% running on someone else's computer).
Like you mention in point 2, I'm just trying to make it hard enough that it's not worth it for them.
Thanks for confirming that what I propose is the standard practice or theory if I understand you correctly.

For anyone seeking to accomplish a similar level of security with your otclient but don't know where to start, here's the steps I've taken that has been all relatively feasible/successful:
1) Replace init.lua with init in C++.
2) Use AES-WBC or other keyless standardized encryption to encrypt your files and only decrypt temporarily OTF, this should protect agains memdumps. This encryption will be slower and can't really protect sprites etc due to how slow it is, but will protect your Lua files and checksums in step 4.
3) Use luajit to compile to bytecode, just for a second layer of security, in case Lua files are compromised, they will be less useful.
4) Generate signatures using an up-to-date checksum algorithm like SHA256 of DLLs used by the client, embed it within your encrypted files, temporary decrypt at runtime, use this as a basis for whitelisting (NOT blacklisting; this is futile) DLLs.
5) Check DLLs loaded at runtime continuously, don't create an isolated separate function that can simply be NOP'd, embed, rather than merely calling, this functionality within the core of the application loop with the rest of the application loop code.
6) Hide or obfuscate strings.
7) Ship client with all the verified DLLs. There will be a lot of DLLs, the zip will be relatively large, but this is the only true anti-cheat solution for OTs without using invasive methods.
8) Don't forget to at the bare minimum disable terminal and otclient.log and strip otclient.exe before releasing.

At least in theory this should work, now it's just a matter of seeing if my otclient.exe release will be a success or not within the next 7 days.
I'm sure there will be some hiccups, as I run Windows10 and some will probably run Windows11 for instance, but hopefully this will be resolved; I've already created the functionality to dump missing DLLs to a txt file when unknown DLLs appears.