3 ms·
Not always effective as it's trivial to protect against if the program bothers to do so.
by huhtenberg 6y ago
Not always effective as it's trivial to protect against if the program bothers to do so.
- staticassertion 6y agoWhat 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.
- kevingadd 6y agoSome 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
- nathanlied 6y agoEnds 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.
- huhtenberg 6y agoAs 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.
- staticassertion 6y agoOh cool, yeah I wasn't sure if they were talking specifically about DLL hijacking or about injection in general.
- deleted 6y ago[deleted]
- saagarjha 6y agoProtecting against remote code injection is not just nontrivial, it's fundamentally impossible in general if the injector is more privileged than you.