24 comments

[ 4.2 ms ] story [ 39.5 ms ] thread
(comment deleted)
(comment deleted)
> While security researchers love the entropy of randomized function layouts

I don't think any competent security researcher has anything positive to say about "security through obscurity"

at best this is lawyer position

You can consider obscurity as concealment. You can't be attacked if you are not seen. And to be seen attacker needs much more resources to see you.
You would think but in my experience, if you ask to just open something up they'll start talking about "defense in depth" and it suddenly matters a lot.
Echoing the other comments here - why? What is the threat model here and how does this protect you from it?
This is decidedly not what I’d expect to be discussed at Thotcon. That said, super interesting!

As an avid pirate, I’ll say these days even the Denuvo game which were going years without cracks now have “cracks”, although they rely on hypervisor fixes and disabling secure boot and giving the hypervisor cracks unfettered access to your system to intercept the Denuvo checks. [0] It’s a dangerous game we’re playing to keep these AAA games bottom lines fat.

[0] https://www.thefpsreview.com/2026/04/03/denuvo-has-been-brok...

Secure boot is the first thing that gets disabled on any machine of mine. Why is this a bad thing?
Essentially secure boot is supposed to validate that only properly signed drivers are loaded on system startup. That allows you to block malicious/cheat drivers from being loaded because a signed AV/anticheat driver was loaded before and now it can properly control drivers that are being loaded after it.

Without it you are risking that the malicious driver will be loaded first and then make itself invisible to the later drivers.

Of course there are ways to bypass this too, but it adds a whole other layer of complexity.

Tldr

Secure boot is there so drivers loaded at boot time can trust that nothing was tampered with before they were loaded.

(comment deleted)
oh fascinating. i just finished reverse engineering Aegis and now working on their newest Eidolon. pretty cool technology.
The amount of work that goes into moats, for stuff that nobody will care about in 6 months, is kind of insane. I understand it for security reasons, but in video games? Just more bloat for nothing
I'm a bit perplexed by the choice of Nintendo Switch as the example hardware. I was under the impression that the switch was locked down and you can't run offset based cheat software like cheatengine on it.
The early Switches had an exploit in the Nvidia graphics processor that was so low level that the operating system can't be patched to get rid of it, so there are a lot of hackable Switches around.
Between this and rootkits masquerading as anticheat, video games are starting to look indistinguishable from malware
there is an immense difference between obfuscating the binary you ship for your game and requiring rootkit-level anti-cheat systems to play your game.

it is wild to imply they are remotely the same in their effect on the user. one is literal malware, and the other shares 0 of the capabilities or effects of malware.

They do employ former malware writers to work on some of this stuff from what i hear.
When hacks exist that use FPGA's to MITM PCI-e level data, I'm not sure what else you can do. The problem contradicts itself: You want a secure, unhackable game, but without essentially root/kernel access?

Heuristic-based anticheat seems to have fallen out of favor.

I honestly believe we should return to dedicated servers + admins. This hacker/anti-cheat arms race is never going to end.

I’ve noticed that LLMs can effortlessly read minified JS. How does it do with obfuscated binary code? I wonder if the days of obfuscation are numbered when the tedious job of de-obfuscation can be automated.