I'm currently having issues figuring out what calls an application is making, and was thinking of implementing a way to hook all of the exports inside of a dll, for example user32.dll, instead of having to hook them one by one in hopes of hooking the correct export that an application is calling. I would be using this code for debugging purposes so then I can add the exports that are getting called to my main code.
I was thinking of implementing this by:
Using Visual Studio's dumpbin and calling /EXPORTS from it to get all of the exports names inside of a dll.
Parsing winuser.h to find the functions from the export names that I obtained earlier from Step 1 and then saving their parameters.
Hooking every export from Step 1 with their corresponding parameter from Step 2.
My question is if this is a good way to go about this, or if this method will work at all?
Related
I want to call functions defined by caller of a dll from dll. I am working on a C/C++ application. Main application may or may not use certain dlls as per the configuration provided and both the sides(Main application and dll) need to invoke each others functions. These example explained fairly well how one can create a dll and call it's functions at runtime.
https://learn.microsoft.com/en-us/cpp/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp?view=vs-2019
https://learn.microsoft.com/en-us/cpp/build/linking-an-executable-to-a-dll?view=vs-2019
However it doesn't explain how can I call functions defined in Main application from dll.
When I try to declare the same function in dll's headers it throws error saying failed to find function.
How can I tell to linker that certain function will be available at run time. In gcc there is --export-dynamic. This can be used for exporting the symbols and later shared object is able to use these symbols. Is there something similar in windows?
Edit:
Following discussion gives a possible solution, Here caller must pass the function to dll as argument.
How to call a function defined in my exe inside my DLL?
This will be little cumbersome to use in my situation. I am trying to port here a linux application on windows. There are many methods which are called by dll. Passing all of them to dll as function doesn't sound as a good idea however this can be doable as last resort. Other downside I see on taking this approach is, this will require Main application to be changed on every time plug in(dll) wish to use some new function of Main application.
Is there a way to get all function used in code.
Actualy I have a big dll which provides me an api of third-party system and now I need list of functions from this dll I'm using.
Is it possible? What way is better: macro or vs extension?
I guess, the API has a separate namespace. Unless you use explicit calls like: Third.party.namespace.ClassName.Method() you can remove using clauses and then filter somehow the errors the compiler shows you while rebuilding.
Or you can start by removing the references to the 3rd party assemblies, which will generate errors for all usings. Then you remove the using and then see every bit of code that relies on them. As I said unless there are explicit calls (which means there were some ambiguities) this should work.
Is it possible to use js-ctypes to call a Windows DLL and have it return a nsISupports instance?
The Windows DLL does XPCOMGlue, but by not needing NSModule I hope I can improve the registration process.
I was hoping there was a ctypes.nsISupports type defined to use as return value, so if it's possible, how do I declare the call?
From my reading and experimentation, no, it doesn't look like you can. However, you could do the next best thing.
1. Create a win32 DLL exporting plain "C" symbols.
2. Create a "wrapper" XPCom component using JavaScript.
http://kb.mozillazine.org/Implementing_XPCOM_components_in_JavaScript
3. Plumb each plain "C" function exported by the DLL into the JavaScript object.
Possible improvement: create a generic JavaScript shim that does the plumbing automatically.
I have a TCL application that is intented to run on Windows only and uses twapi to access some Windows-specific functions.
Now I need to call some C function that are in a custom DLL.
I know I can load the DLL with twapi::load_library (should be the same as LoadLibraryEx()) but I can't understand how to call a function within the DLL itself!
What did I miss?
I would prefer to avoid other dependencies (like critcl, for example) and to avoid to have to transform the current dll in a tcl extension (e.g. via SWIG) so a twapi only solution would be really helpful!
TWAPI doesn't seem to provide any public binding of GetProcAddress (the Windows API function for getting from the name to the address of a function in a DLL).
Use ffidl for simple APIs (i.e., where there are no callbacks) or critcl (for all kinds of APIs, including those with callbacks, because it can do much more extensive code generation; more effort to use though).
twapi's load_library command is there for manipulating the resources in a dll (string tables, icon etc.). It's not intended for calling functions in the dll since that, as Donal points out, requires marshalling and some code generation.
Looks like you'll have to use ffidl to do the job.
When one should implicitly or explicitly link to a DLL and what are common practices or pitfalls?
It is fairly rare to explicitly link a DLL. Mostly because it is painful and error prone. You need to write a function pointer declaration for the exported function and get the LoadLibrary + GetProcAddress + FreeLibrary code right. You'd do so only if you need a runtime dependency on a plug-in style DLL or want to select from a set of DLLs based on configuration. Or to deal with versioning, an API function that's only available on later versions of Windows for example. Explicit linking is the default for COM and .NET DLLs.
More background info in this MSDN Library article.
I'm assuming you refer to linking using a .lib vs loading a DLL dynamically using LoadLibrary().
Loading a DLL statically by linking to its .lib is generally safer. The linking stage checks that all the entry points exist in compile time and there is no chance you'll load a DLL that doesn't have the function you're expecting. It is also easier not to have to use GetProcAddress().
So generally you should use dynamic loading only when it is absolutely required.
I agree with other who answered you already (Hans Passant and shoosh). I want add only two things:
1) One common scenario when you have to use LoadLibrary and GetProcAddress is the following: you want use some new API existing in new versions of Windows only, but the API are not critical in your application. So you test with LoadLibrary and GetProcAddress whether the function which you need exist, and use it in the case. What your program do if the functions not exist depend total from your implementation.
2) There are one important options which you not included in your question: delayed loading of DLLs. In this case the operating system will load the DLL when one of its functions is called and not at the application start. It allows to use import libraries (.lib files) in some scenarios where explicitly linking should be used at the first look. Moreover it improve the startup time of the applications and are wide used by Windows itself. So the way is also recommended.