Return to Answer

This has been addressed by Microsoft in certain ways, although the only real solution is proper implementation on the application side. But then, many developers haven't even grasped NT security even though we have to deal with it ever since Windows 2000 became the first consumer OS based on the NT platform.

Whenever an application uses a DLL, and you can tell the load order with Dependency Walker or under a debugger, you can pick one of the DLLs it imports and replace that (in its current location) or placing another DLL in a path that precedes the existing DLL in the load order.

Here's a simple Python script based on pefile which I wrote for another answer over at StackOverflow:

You could adjust it to create function forwarders instead of a simple module definition with exported names.

Instrumentation and hooking have been mentioned already. Detours is an often mentioned example of hooking with an inconvenient EULA for most practical purposes. Refer to the existing answers for this kind of approach.

You can also use the AppInit_DLL registry value to inject a DLL early on. Or you could write a little launcher with a debugger loop and use Image File Execution Options to have your target launch your debugger first. A debugger can also influence the DLL loading or simply intercept - conveniently - calls at the boundary between executable and DLLs.

This has been addressed by Microsoft in certain ways, although the only real solution is proper implementation on the application side. But then, many developers haven't even grasped NT security even though we have to deal with it ever since Windows 2000 became the first consumer OS based on the NT platform.

Whenever an application uses a DLL, and you can tell the load order with Dependency Walker or under a debugger, you can pick one of the DLLs it imports and replace that (in its current location) or placing another DLL in a path that precedes the existing DLL in the load order.

Here's a simple Python script based on pefile which I wrote for another answer over at StackOverflow:

You could adjust it to create function forwarders instead of a simple module definition with exported names.

Instrumentation and hooking have been mentioned already. Detours is an often mentioned example of hooking with an inconvenient EULA for most practical purposes. Refer to the existing answers for this kind of approach.

You can also use the AppInit_DLL registry value to inject a DLL early on. Or you could write a little launcher with a debugger loop and use Image File Execution Options to have your target launch your debugger first. A debugger can also influence the DLL loading or simply intercept - conveniently - calls at the boundary between executable and DLLs.

Here's a simple Python script based on pefile which I wrote for another answer over at StackOverflow:

Here's a simple Python script based on pefile which I wrote for another answer over at StackOverflow:

You'll notice how you can sort these approaches into the categories Ed McMan mentioned in his answer already. However, I'll leave that as an exercise to the reader :)

You'll notice how you can sort these approaches into the categories Ed McMan mentioned in his answer already. However, I'll leave that as an exercise to the reader :)