4 ms·
> 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
by Const-me 6y ago
> 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.
- eps 6y agoUsually, 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.
- Const-me 6y agodwm.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.
- eps 6y agoAh, right. Missed the part it was dwm.exe
- garaetjjte 6y agoThough some core system DLLs are specified in KnownDLLs registry key, and thus not loaded from application directory.
- deleted 6y ago[deleted]