How do I go about hooking/redirecting a function in a DLL (say, CreateThread from Kernel32.dll) loaded in the current process?
(I don't have control over which pieces of code call CreateThread, so it's not like I can just have the code something else instead.)
The language doesn't matter much; I'm guessing C/C++ would be the best choices for this.
Update:
I forgot to mention: I'm not looking for solutions that require the bundling of extra libraries into my program; I was looking for a manual way of doing the hooking (such as by rewriting the address of the function), not for using an external library to do this.
But thanks to those who mentioned an external library; sorry I didn't say this earlier.
there's MS library for this: Detours
(This most likely would have been more appropriate as a "comment" under the "Detours" answer, but, as my "reputation" isn't enough yet to add comments I guess, let me post it as an answer)
This post under this thread ("DirectShow question") mentions a replacement/home-grown alternative to Detours (with some rough code example as well) by Alessandro Angeli.
I've actually first found it quoted in another thread ("problem in hooking cocreateinstance") while also searching for COM component creation hooking/tracing (This second thread is more focused on cross-process hooking though).
Let me also add a link for WinAPIOverride32 (by Jacquelin Potier) for convenience here as well. It seems to have "developer designed GUI" :) but, no complaints at all as it is open source (as mentioned above).
Check out http://easyhook.codeplex.com/
It's an API Hooking framework.
Its open source, very easy to use!
Related
I want to use Deviare V2 API to intercept winapi calls from a test application. The problem is the hooks and the system calls are in the same process and for this reason the calls aren't intercepted.
If I open separate processes for each of them then the interception will work. Does anyone else ever had this scenario/problem ?
The thing is I'm trying to add some unit test to a peace of code and instead of modifying existing production code to wrap/mock all system calls I thought I could simply intercept all this calls and fake them as I wish.
It's actually much easier to hook APIs in your own process (actually when you want to hook in another process you need to DLL inject into that process anyway, so basically when you're hooking in your own process you can just skip that step). It might be a bug with the library you are using. Try Microsoft Detours or if you're up to it, patch the memory yourself, it's not that hard actually, a few hours work if you're new to the subject.
What you need to be wary of is that some C++ compilers will in some cases (I think debug builds) use some jump stub or something like this, which can interfere with the hooking process. In that case you must take some extra care when hooking - MS Detours probably does this properly. You can try debug/release builds if that affects your success.
What I mean is to get the proper address of the API. If the function is in a DLL like is the case with WinAPI you can be sure you are getting the right address if you use LoadLibrary and GetProcAddress.
On a side note I don't think API hooking is a proper way to avoid mocking/stubbing for testing, although it should work.
If you are interested more in how hooking works you can check out my paper on it here: http://lkm.fri.uni-lj.si/zoranb/research/berdajs-bosnic%20SPE%202011.pdf
I need to list all open handles in current process.
Since i could not find any function like "EnumHandles", I was thinking of making a loop from 0 to 1000. The question is how i can retrieve the name of each handle?
I am using c++ and the OS is Win7 32-bit
EDIT:
The handle I need name of is a Mutex.
By comparing the name of the mutex, i want to get the handle id
I seem to have found solution using OpenMutex, but i don't know what to pass on 3rd parameter,
I believe you have to use the NTDLL.DLL. To my knowledge this is what all tools monitoring processes, handles and other system information, have to use in the end, under Windows. I used it in a small Win32 tool, however never had to list handles.
Check here for a good intro of that library and related to your question. http://forum.sysinternals.com/howto-enumerate-handles_topic18892.html
Also the GetObjectName function in the first post of http://forum.sysinternals.com/enumerate-opened-files_topic3577.html
Accessing this kind of information in Windows may seem to be a lot of work and looks frightening because Microsoft does not want to support it, but you will see that when the 'easy' API is not giving you what you need, you have to dig to NTDLL. This is what tools like ProcessExplorer use in the end. It is not so hard to use: load the DLL, get the right function pointers to fill the structs that you declare yourself with what you will find on the net.
I can't be clearer than my title. :P
I want to run my program whenever a user renames a file in Windows Explorer (and only within the Explorer). Here's a simple mock up:
A simple link to a tutorial will be very helpful. I couldn't find anything. :/
Thank you in advance.
P.S. I'm new in C++
It looks like Windows API hooking may be your best bet. You'll want to intercept all calls related to Windows file renaming (i.e. MoveFile, MoveFileEx, SHFileOperation, possibly more). There are a few commercial and open source solutions; Microsoft Detours, Madshi's madCodeHook, and the free, open source EasyHook.
This approach, when done correctly, will allow you to capture all file renaming on a system.
I would avoid hooking APIs as much as possible. It gets really ugly really fast.
There are 2 ways I see that you can approach this.
Both ways have a few common factors:
The ReadDirectoryChangesW API. For a very good implementation of that API, see this
article
You will need to minimize your dependencies, so... Use a Microsoft compiler, link to the DLL runtime, stick to C as much as possible etc. This reduces problems. Loading things into the shell memory space is already problematic enough.
Method one is to use ReadDirectoryChangesW from an Explorer shell extension that does nothing else. Keep it minimal. I'm reasonably sure I saw a "do nothing" shell extension as an example in some of Microsoft's documentation.
Method two would be to package your code as a DLL and use a system hook to get your DLL loaded into Explorer only. The system hook should only load inside Explorer to prevent spurious notifications via ReadDirectoryChangesW.
Hope this helps and that you're not using it for something Evil.
I was looking up something, and stumbled upon this code:
http://google.com/codesearch?q=kBrowserThreadNames
Where can I find the source for base::Thread?
(Thing is, in debugging something running under firefox.exe, I notice Gecko_IOThread is setting it's thread name in some kind of way and wanted to look up how.)
A quick Mozilla MXR lookup seems to indicate that it's defined in mozilla/ipc/chromium/src/base/thread.h
Edit:
I was also curious about the presence of Chronium code in Mozilla so I googled a bit and found this on the blog of Benjamin Smedberg the commiter of the code:
IPDL is a language which precisely
describes the messages that can be
passed between processes, and allows
developers to define a state machine
and error handling conditions for
messages and resources shared across
processes. IPDL layers on top of an
IPC stack that Mozilla copied from the
Chromium codebase
Just click your way into the code...
http://google.com/codesearch/p?hl=en#cFooKvxdTls/ipc/chromium/src/base/thread.cc&q=kBrowserThreadNames&d=2
I am trying to develop an IThumbnailProvider for use in Windows 7. Since this particular thumbnail would also be dependant on some other files in the same directory, I need to use something other than IInitializeWithStream to a path to work with, this being IInitializeWithItem. (Alternatively, I could use IInitializeWithFile, but that is even more frowned upon apparently.)
No matter what I do, I cannot get it to work. I have Microsoft's FileTypeVerifier.exe tool which gives the green light on using IInitializeWithItem, but when explorer calls it, it only seems to try IInitializeWithStream, ever. (This was tested by temporarily implementing said interface, and Beep()ing away in its Initialize()) Did I forget to configure something?
In short: how do I get this to work?
Okay, I finally found out what is the matter. To quote the Building Thumbnail Providers link on the MSDN website:
There are cases where initialization with streams is not possible. In scenarios where your thumbnail provider does not implement IInitializeWithStream, it must opt out of running in the isolated process where the system indexer places it by default when there is a change to the stream. To opt out of the process isolation feature, set the following registry value.
HKEY_CLASSES_ROOT
CLSID
{66742402-F9B9-11D1-A202-0000F81FEDEE}
DisableProcessIsolation = 1
I knew I was running out of process since I read elsewhere that thumbnailproviders ALWAYS ran out of process. But since that particular snippet is on almost -all- shell extension handlers, I interpreted it to be a overly happy copy-paste job, since it was -required- to run in-process the way I understood it.
And I was wrong. I hope this will help someone else in the near future. :)