'Safe' DLL Injection

3
votes

Not a terribly good question, sorry.

I have a program that needs to be alerted when a file is opened from explorer (i.e. ShellExecute(A/W) is called).

Unfortunately, Microsoft removed the COM interface (IShellExecuteHook) that allows you to hook these events in Vista and up, supposedly because older code could cause a crash due to changes. There was a work-around to re-enable this feature, but it no longer works.

I've done some research and it looks like the only way to catch calls to ShellExecute is to re-route the call to shell32.dll. At the moment, I'm looking at injecting my own DLL into the explorer process, then copying the IAT entry for ShellExecute to some address allocation in my DLL, and finally modifying the IAT entry for ShellExecute to point to my function, which will notify the program that a file was opened and jump to the original ShellExecute function, whose address we stored earlier.

My biggest concern here is antiviruses. Will they care that I'm injecting into explorer? Will they care that I'm modifying the IAT?

Another concern is whether this is safe; is it possible (or rather likely) for explorer's security priveleges to not allow injection via CreateRemoteThread? If so, is there a better way to do this injection?

Is there a better way to do this in general?

EDIT: For anyone who comes across this in the future, explorer.exe has no IAT for shell32.dll; it has a header, but the thunk is full of junk values, so there's no way (as far as I can tell) to retrieve the entry for any imported functions.
Looks like code tunneling is the only way to hook this.

4
c++cwinapihookshell32
Since it seems that there's no easy workaround, you may explain what feature of your application you're trying to implement in this way: maybe there's a simpler method to do that. – Matteo Italia
We mark newly downloaded files as UNREAD. When a user opens the file we want to mark it as READ. There's no possible catch-all to accomplish this, but we want to be as accurate as possible. The alternative is writing a driver to get notification of CreateProcess and parsing the arguments for filenames, but it's not as preferable as a hook. – Collin Dauphinee
You didn't mention what kind of files, but files may be opened by the application without Explorer being involved. Could you monitor the "viewer" app instead? – Vlad Feinstein

4 Answers

3
votes

Most good antivirus heuristics should pick up on import table patching as being a red flag for a trojan.

The online documentation for madcodehook has some extended articles on various code injection techniques, their benefits/drawbacks, and the API provides some options for specifying "safe" hooking: http://www.madshi.net/madCodeHookDescription.htm

3
votes

The Detours library:

http://research.microsoft.com/en-us/projects/detours/

From Microsoft Research allows arbitrary hooking of functions. You might give that a shot.

3
votes

Some more resources on API hooking:

Easy hook: http://www.codeplex.com/easyhook

Deviare: http://www.nektra.com/products/deviare-api-hook-windows/

An interesting post: http://www.codeproject.com/KB/system/hooksys.aspx

When doing API hooking it is very important to asses in which environments you need to run. Not all libraries support x86/x64 for example.

Detours only supports x64 in the licensed (payed) version. Easy hook supports x86 and x64.

-2
votes

Windows Explorer in Windows Vista and Windows 7 doesn't even call ShellExecuteA or ShellExecuteW.

No point bother. Lol :-)

AND, if i may add, i have tested by hooking both functions with both 32 bit and 64 bit inline hooks.

Sorry. Lol :-)