Making application load dll at start

Question

I've added some functionality to existing application which works through dll injection - my dll loads and patches some stuff.

I would like it to be added to this application permanently so I don't have to inject it manually every time - I know there are some solutions such as:

1. Loader - another application that runs target application and then injects a dll
2. Patch EP - patch entry of target application so it loads my dll before executing rest
3. AppInit_DLL - making it loads to almost every process through this register entry and then checking if we are in the right one, unload otherwise

But are those options most optimal? First and second requires some work (maybe there are some already existing tools of which I don't know and which allows it? so I don't have to prepare it all myself), and third seems a bit over-excessive. Just to expand my knowledge - what are the other options?

Answer 1

You could also add the DLL to the EXE's Import Table. This has the benefit of not loading the DLL into every process that loads user32.dll (which is an issue with #3), and you can do this Import Table addition easily with a tool like IIDKing:

Answer 2

Here's what i did some time ago, when i had your problem.

• Use dependency walker to find a DLL that's imported by the main executable, from which the .exe imports only one or two functions. For the sake of example, let's assume your application someprog.exe used a dll vendor.dll, from which it imports the ShowCopyright function.
• Using a hex editor, change the string vendor.dll in the executable to hacker.dll.
• In the startup of your DLL, use LoadLibrary("vendor.dll") and GetProcAddress("ShowCopyright") to get a function pointer to the real ShowCopyright function.
• Also, in your DLL, provide a ShowCopyright export that does nothing but jump to the ShowCopyright address you just retrieved.
• Rename your DLL hacker.dll and put it into the application's search path.

Note this depends a bit on how many DLLs the executable program imports, and if you find one where you don't have to "simulate" several dozen API entries, or resources, or whatever can be linked to a dll.

EDIT:

After finishing my post, i found Jason's answer, which seems to be a bit more professional and easier. But, at least, my solution needs no tools except a hex editor :-)

Answer 3

Strange as it is, two other methods have not been mentioned. The AppInit_DLLs approach you mentioned doesn't work anymore to the best of my knowledge. At least not as easily, especially when UEFI Secure Boot is enabled.

• DLL placement attack
• ImageFileExecutionOptions

In both cases it depends on the target binary, so let's go through it.

DLL placement attack

I've run this in the past on Windows 7, but the rules have changed since then. The way I made it work was as follows. I figured out one (vendor-provided) DLL loaded by the program without a full path (I picked the one with the least number of imports). I then wrote a stub DLL which would simply pass through all function calls to the real DLL (loaded by full path) and print out useful info for me. The return value would simply be returned.

It's easy to figure out the function prototypes of exported functions, so this was the lazy option for me.

ImageFileExecutionOptions

This method is used by Process Explorer to make itself a replacement for Task Manager. Here's how that looks in action:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe]
"Debugger"="\"C:\\PATH\\TO\\PROCEXP.EXE\""

Now the value name probably gives it away already, this was previously used for a totally different purpose.

Either way you can (ab)use it to achieve what you want. You write a little stub loader, acting as the "debugger". There isn't much to it, you don't even have to implement any of the debugger APIs, although you could.

All you'll want to do is to use CreateProcess or similar to create a process with its main thread in suspended state upon "start". You can pass on the command line arguments as you wish (although it is, admittedly) a bit involved with CreateProcess and friends.

The suspended main thread is where you can detour to your own code ... typically a simple piece of shell code that does nothing other than load your DLL and then return to the original entry point. Et voila, you have loaded your DLL into an application.

The nice part about this second method is that it scales pretty well, since you basically only have to write this sort of "debugger" (loader) once. So it can be kept generic.

This method amounts to doing (from the command line):

loader.exe C:\path\to\hijacked\application.exe argument1 argument2 and more arguments

... except that to the user this will be transparent. And I think inside your loader you can even use argv[0] to get the path to the hijacked executable, IIRC.

Now you may think that this is some weird security issue and wonder why it's gone unnoticed. It's not a security issue insofar as you have to be privileged to set the ImageFileExecutionOptions in the first place.

As a side-note: I think it's even permissible to name the containing key (taskmgr.exe in the above registry file) with the full path to the executable to be hijacked.

Answer 4

As Jason Geffner said, you can add your DLL to the import table of your .exe. Other tool than IIDKing that can add your dll to the import table of a PE file is called Stud_PE, which, unlike IIDKing, doesn't crash if your dll doesn't have any entries in the export address table(EAT):

Answer 5

Another program which can do what you're looking for is CFF Explorer: