I’m interested in finding out how attack-defense style CTFs are affected by slopping. ENOWARS skorbor will probably significantly differ from the last time around.
Games very much are using server-side statistics analysis for cheat detection. Valve made a presentation about it and Epic has an API for feeding game state data to ML anticheat for aimbot detection (game-specific and in addition to their existing anticheat measures)
Either everyone on Earth who’s working on this has a skill issue (which is probably hubris?) or there’s not enough differing humanized enough aimbot from human aim (note: Valve manages to screw up even here, with cheaters in Premier basically rage aimbotting these days IIRC)
In addition, there’s not much these things can do against subtler stuff like ESP.
I’m interested in how LLMs handle obfuscated code. Throw LLM with IDA MCP at EasyAntiCheat_EOS.sys or the like (as the most common examples of heavily obfuscated software) and see how far they can get.
Anticheats will still have obfuscated code for obvious reasons (they don’t want to be reversed). Not sure they don’t induce some performance drop too - though maybe smaller compared to bad Denuvo implementation.
One has experience writing secure, stable code for drivers, memory management, etc that is subject to broad review by other experienced devs. The other is looking at those things adversarially and pushes out whatever they think is good enough. Crowdstrike served as a useful reminder for who should be allowed in kernel space, and video game anti-cheat has far less justification to be there.
Do the cracks still need you to disable Hyper-V (which leads to disabling WSL and whatever else)?
In addition, I’m not sure why they’re enabling test signing instead of using kdmapper or the like. Sure, anticheats will get way more mad at you having a manual mapped driver, but one imagines rebooting once (after playing your cracked video game) beats rebooting twice (to enable test signing, then after playing the game).
reply