Hacker News Reader

Comment by Namidairo | Hacker News Reader

One of the many dll injection methods possible in Windows, if I recall correctly.

Although I do usually just end up hijacking a dll already used by the program when I want to sneak my own code within a process that I don't have the source for, for the sake of future usability. (When patching the executable on-disk isn't desirable, and you don't want to go insane running an injector each time you start the process.)

View on HN

> end up hijacking a dll already used by the program

That’s hard to do for an OS component, due to the anti-viral measures in the OS. Modern windows freaks out when you replace DLLs in c:/Windows/System32 directory.

Last time I used CreateRemoteThread was when a client wanted Windows 7 equivalent of Desktop Duplication API (introduced in Windows 8). I injected my DLL into the desktop compositor (dwm.exe process), hooked IDXGISwapChain.Present and IDXGISwapChain.ResizeBuffers methods, and wrote some C++ to copy desktop image into another ID3D10Texture2D in VRAM, and share the copy with the video capturing process.

Usually, you don't need to replace a system dll at all. You can just drop an alter ego in exe's own directory or even in a launch directory. Default search order in Windows is such that it'll pick up from the latter two first and check PATH second.

Once the process is up and running it has the control over this (with LoadLibraryEx and SetDefaultDllDirectories) and it's also possible to tighten search logic at the OS level (with a registry patch), but if the machine is under attacker's control, the only option is to validate loaded module list from within the app.

dwm.exe is in the same directory, c:/Windows/System32. The process is launched by Windows automatically, immediately after login. The desktop capture app I was working on is launched way later than that, by user.

Ah, right. Missed the part it was dwm.exe

Though some core system DLLs are specified in KnownDLLs registry key, and thus not loaded from application directory.

Shameless plug for a .NET library I wrote to help interop between compiled x86 binary and .NET: https://github.com/blurt/X86.Interop

Guide to inject your .NET dlls into a native process: https://www.codeproject.com/Articles/607352/Injecting-NET-As...

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