^ Here you go; detailed, since you want my attention:
"First of all, how did you locate the thread function that triggers anti CE? I don't mean actually, I mean logically. When you sit down and say "let's find the anti-ce function" what do you do? Are there particular routines that you try? For me I just try to launch CE, get the message box, and trace the call stack and break on the caller function."
I've been doing RE for a long time that I kind of know what APIs to poke at to get stuff solved fast
MessageBoxA/W or MessageBoxIndirectA/W in this case. Then most of the shit is most likely (as you've seen) triggered from
threads; as such, using hardware breakpoints (to also avoid CRC32 corruptions, if using software bps -> 0xCC) on CreateThread and checking the thread functions helps. Then CE can be detected in several ways: certificate (easy to solve, as you've seen), window elements, opening the actual process and scanning for crap (enableDRM() in Lua helps with this) and lastly driver detection. That last step is like the final check. You know all other user-mode checks (replicated in kernel as well) won't help you with anything if bypassed, since the anti-cheat driver kicks in and nuts you. See
EasyAntiCheat
So yeah, whichever: bp on notification APIs or back-tracing.
"Second of all, there are 5 looping threads:
- Thread 16 (what I posted earlier) in charge of Anti-CE
- Thread 17 (directly after thread 16) in charge of exiting the game on crc fail
- Thread 21/23 (I'm unsure) in charge of reading the running process names (open procmon you'll notice CreateFileW opens every process u have)
- Thread 80/81 (unsure) in charge of spamming CreateFileW on all hid devices
- Main Thread keeps looping around for some reason"
Like I said, using numbers is stupid, as the thread creation order isn't the same on 2 different CPUs. Both the Anti-CE and Memory Integrity threads are VERY EASY to spot because the fuckers @ Nether use Denuvo with
crypt markers to shield those functions (if not virtualization, then mutation to deal with lag). When that happens, any protector puts its representative code in there, so you can fucking tell by just checking the ThreadStartAddress. You'll find some spaghetti push + ret + jmp crap that doesn't resemble any normal x64 ASM flow. That's how you know you're to kill those as the first try. I mean, they used mutation and other protection crap, but don't even bother checking if thread is still alive, killed or suspended T_T. No comment. As far as the other threads, I don't care about them. If you check the start addresses, they are legit. Killing them might fuck some game functionality.
"My other question is once I disabled Threads 16, 17, and 21/23 (simply terminate in x64dbg) the game would throw exception violation instead of crashing (which proves that I did sth right?), but I can't move forward as game cannot progress anymore. This deemed it impossible for me to run AOB Injections in CE since changing the code still forces game to quit, so can you tell me what approach did you do so that you caused the game to resume properly?"
Terminating threads like crazy will often result in crashes due to timing. Try suspending them first, resuming for sync, then killing them.
Not interested in crypto
"Your work interest me as Reverse Engineering is one of my favorite fields, and I feel like I can learn a lot from you. The video posted by Tim last week was my first attempt at x64dbg, and I would love to say that because of it I was able to create a Mod Loader for the game. Thanks to both of you for your amazing work."
You're welcome.
BR,
Sun