Hacker News Reader

Comment by huhtenberg | Hacker News Reader

Not always effective as it's trivial to protect against if the program bothers to do so.

What is trivial to protect against and how? I'm not aware of a general way to prevent an attacker within your user from accessing your process's memory, on any OS, except for a few newer capabilities on Windows, which are also bypassable.

Some software (mostly games) attempts to hook things like CreateRemoteThread or abort when they get the dll load/thread start events, but you can always patch those detection hooks to not run before you start your thread

Ends up being a cat-and-mouse game, but the power dynamics are even more unbalanced towards the red team: not only do they have control of the hardware, they also control your executable.

It's also why "anti-cheat drivers" have never gone away, they allow a greater level of control over what's done to your protected processes.

I'm not sure I am okay with that - there's only so much I'm willing to put up with to play some game - but I do understand why developers/producers would want such draconian solutions. In some game genres, cheating is rampant.

As per GP comment's context - it's trivial to detect system DLLs replacement, which is a common way to inject code without the use of trainers, loaders or exe patching.

Oh cool, yeah I wasn't sure if they were talking specifically about DLL hijacking or about injection in general.

Protecting against remote code injection is not just nontrivial, it's fundamentally impossible in general if the injector is more privileged than you.

Reply on news.ycombinator.com