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.