4

I'm trying to find all vulnerabilities in my given system.

Assume a malicious user has the executable (.exe file) of my .NET application (C#), and a malicious DLL he or she created. Can the DLL be injected into my executable to run code contained in the DLL?

3

The wikipedia article concerning Dll injection has nicely done summary of different techniques.

To summarize:

  • You can list a dll under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs and it will be loaded into every (new) process that links to user32.dll (i.e. pretty much every user-mode process)
  • Exploiting a weakness in a function that loads a library by path incorrectly (typically, placing a dll loaded by the target process higher in the search path) or simply replacing an existing library by your own.
  • Via CreateRemoteThread or CreateRemoteThreadEx. This is a bit more complex (and interesting) but lets you do that for existing processes.
  • Via SetWindowsHookEx. This is the easiest way to do it for a running process IMNSHO.
  • Suspending a thread and switching its context to your own code.
  • Writing a shim.
1

Yes, there are several possibility to do that, and a very big part of attacks are based on DLL hooking.

And this is also the cause, why newer and newer windows versions contains normally stricter and stricter policies about the dll handling.

The main goal is to build a fake dll, which only wraps some of the API calls in its original dll, and does also some other thing as well. The goal of the attacker is in such cases to let load the fake dll by the application to be cracked, against its original version.

The alternative to this solution is, when the original dll gets some type of binary hack. It is harder.

The internal working of the hooked dll is the following:

  • at open: it opens also the original, unmodifyed dll with a dllopen() call, and finds the address of the api calls also in it
  • it contains also the fake version of the hooked api calls

How can you the hooked dll inject in the app?

The most common solution is only to put this in the same directory where the exe to be hooked lives. On a starting an executable, windows looks for its dlls always in the same directory first. This is what is done by most software copy protection/activation cracks.

A second possibility is to put the wrapper dll somewhere in the PATH, but yet before C:\windows\... . The dlls are looked for in the PATH, as the executables as well.

A third possibility is to use a debugger, or the windows api originally intended for debugging. With it you can manipulate the dll opening code of the running exe. It is also hard as well, although it is also really useful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.