I've snooped around a little bit in MS-Office DLLs, and I noticed that some of the DLLs don't have any exported functions. What I don't quite understand, how an application can use these DLLs without any functions exported ?!
I mean, the dllmain() does get executed on LoadLibrary(), but whats the point? Why would anyone create a DLL without exported functions?
thanks! :-)
One way of dealing with versions of a program destined for different languages is to put all of the resources into a language DLL. The DLL doesn't contain any code, just resources that have been translated to a target language. When the main program starts up, all it needs to do is load the proper language DLL.
I haven't looked at the DLLs in question; but it's possible in something like MSOffice Microsoft have done this to obfuscate the DLL to make it more difficult to debug / reverse engineer.
However, as you ask how would you use such a DLL? Well if the application knows the layout of the DLL then it can create a function pointer with the address of a known function and call it.
If you really want to dig further you could objdump the DLL and look for standard C / C++ ABI function prologues & epilogues and possibly work out where the functions start.
When you call LoadLibrary the DLL gets call of its DllMain.
That is DLL entry point. It is called on process attach and thread attach.
So you do have entry point.
As soon as it has at least one entry point then it can create instance of some interface (e.g. factory) an set it in e.g. TLS variables where other modules will pickup them.
So you can can have COM alike system of interfaces that are not exposed outside except to the application. Something like that - many over variations are possible.
Resources
The DLL likely has resources, like string tables, images, icons, etc., used by the rest of Office.
Always possible that they just don't export them as C interfaces. A DLL isn't magic, it's just bits and bytes, and nothing says that you can't get code out of a DLL if you don't ask Windows for it. I believe that .NET takes this approach- they save metadata in the DLL that tells the CLR what's in it, instead of making .NET functions available by the normal GetProcAddress approach. Unless you explicitly ask for it.
Related
I'm updating a DLL for a customer and, due to corporate politics - among other things - my company has decided to no longer share source code with the customer.
Previously. I assume they had all the source and imported it as a VC++6 project. Now they will have to link to the pre-compiled DLL. I would imagine, at minimum, that I'll need to distribute the *.lib file with the DLL so that DLL entry-points can be defined. However, do I also need to distribute the header file?
If I can get away with not distributing it, how would the customer go about importing the DLL into their code?
Yes, you will need to distribute the header along with your .lib and .dll
Why ?
At least two reasons:
because C++ needs to know the return type and arguments of the functions in the library (roughly said, most compilers use name mangling, to map the C++ function signature to the library entry point).
because if your library uses classes, the C++ compiler needs to know their layout to generate code in you the library client (e.g. how many bytes to put on the stack for parameter passing).
Additional note: If you're asking this question because you want to hide implementation details from the headers, you could consider the pimpl idiom. But this would require some refactoring of your code and could also have some consequences in terms of performance, so consider it carefully
However, do I also need to distribute the header file?
Yes. Otherwise, your customers will have to manually declare the functions themselves before they can use it. As you can imagine, that will be very error prone and a debugging nightmare.
In addition to what others explained about header/LIB file, here is different perspective.
The customer will anyway be able to reverse-engineer the DLL, with basic tools such as Dependency Walker to find out what system DLLs your DLL is using, what functions being used by your DLL (for example some function from AdvApi32.DLL).
If you want your DLL to be obscured, your DLL must:
Load all custom DLLs dynamically (and if not possible, do the next thing anyhow)
Call GetProcAddress on all functions you want to call (GetProcessToken from ADVAPI32.DLL for example
This way, at least dependency walker (without tracing) won't be able to find what functions (or DLLs) are being used. You can load the functions of system DLL by ordinal, and not by name so it becomes more difficult to reverse-engineer by text search in DLL.
Debuggers will still be able to debug your DLL (among other tools) and reverse engineer it. You need to find techniques to prevent debugging the DLL. For example, the very basic API is IsDebuggerPresent. Other advanced approaches are available.
Why did I say all this? Well, if you intend to not to deliver header/DLL, the customer will still be able to find exported functions and would use it. You, as a DLL provider, must also provide programming elements with it. If you must hide, then hide it totally.
One alternative you could use is to pass only the DLL and make the customer to load it dynamically using LoadLibrary() + GetProcAddress(). Although you still need to let your customer know the signature of the functions in the DLL.
More detailed sample here:
Dynamically load a function from a DLL
Is it possible to load a native (C++) DLL as an executable?
preferablly straight from the memory without creating EXE on the hard-drive or something similar?
Microsoft provides Rundll32.exe which can be used to execute DLL functions that have been explicitly coded to support this usage.
What, specifically, would this mean? For example, what entry point would it use in the DLL?
The only way this would actually work would be if the DLL was specifically written to allow it. And if that were the case, then it's not exactly clear why you would not just create an executable file instead of a DLL in the first place.
Case in point is the RunDLL32.exe stub. It's designed to execute a function from a DLL with a specific signature as the entry point. If the DLL wasn't specifically designed to comply with this signature, then things don't go well. If you need functionality like this, you might want to consider matching the function signature required by RunDLL32.exe and using it to "execute" your DLL.
Look up rundll32.exe. But you'd better know exactly what you're doing. I'm not sure, honestly.
You can use LoadLibrary WinAPI call to load a DLL.
Currently, I have a C++ exe project, which dynamic load N DLLs.
Those DLLs will perform calling to the functions which is re-inside exe project.
Now, within my exe project, I wish to know the callers are coming from which DLLs.
Is it possible to do so using any available Windows API?
It depends on what your actual goal is. You cannot do it if you're expecting the DLLs to be possibly malicious (that is, if you're expecting them to try to trick you). But if it's just for debugging or logging or something relaitvely harmless like that, you can look at the stack and get the address that the ret instruction will use to return to the caller, enumerate through the loaded DLLs and test which of them that address is inside of.
To get the "return address", you can use the _ReturnAddress intrinsic in Visual C++, and then you can use the GetModuleHandleEx function, passing in GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS to get a handle to the DLL that the address is inside of.
But I must repeat: you cannot base security decisions off the results of this test. It is very easy for malicious code to fake and "trick" your program into thinking it's a "trusted" or "safe" DLL. As I said, if it's just for debugging or logging or something, then go right ahead.
Also, this will obviously only tell you the DLL the immediate caller is inside of. You can't do it if you're 5 levels deep or something....
If you have given the same callback to multiple DLL's, then it is up to them to provide you with information about who's who. Most API callback have a parameter you can pass to the callback. If this is so for your callbacks, you can use this to identify the DLLs.
It probably isn't possible considering that the call stack will come back down to your exe anyway.
EDIT: By the look of your post, is this a hypothetical situation?
Is this helpful? Check the parameter 'GetModuleBaseRoutine'
If you're architecting the exe, and you're not assuming the DLL's are hostile (see Dean's answer), you might be able to achieve the effect by providing each DLL with a different set of pointers for the callback functions, which each in-turn forward to the actual callback functions. You could then associate the calls with the calling DLL, based on which pass-through callback was actually called.
Of course, this assumes you're providing the callback addresses to the DLL's, but presumably this would be the normal design for an application where a DLL called back into the calling exe. It won't work if the DLL is mucking around in your process memory for internal functions, of course, but then you're probably into the hostile situation.
I have a application and two Dlls. Both libraries are loaded by the application. I don't have the source of the application, but the source of the libs. I want to instantiate a class in lib A and want to use this instance also in lib B.
How do I do this? I'm not sure, but I think that both libs are used in different threads of the application.
I have no idea where I have to search for a solution.
No. Think about DLL as just normal library. Both can be used in a single thread.
If you want to use a class A in library X, you must pass a pointer/reference to it. The same applies to library Y. This way both libraries can work with same class/data.
Two dll's loaded into the same process is a fairly simple setup.
You just need to be careful with module scope, which will be the same as dll scope.
e.g. each dll will have its own set of static instances for any static objects.
Next you need to understand how to reference functions/classes across the boundary and what sort of types are safe to use as arguments.
Have a look on any documentation for dllexport and dllimport - there are several useful questions on this site if you search with those terms.
You have to realize that even though your DLLs are used by the host application nothing prevents you (that is your DLLs) from using your DLLs as well. So in your DLL A you could load and use your DLL B and call functions and stuff. When DLL A is unloaded, free DLL B as well. DLLs are reference counted, so your DLL A will have a reference of 1 (the host application) and your DLL B 2 (the host application and DLL A). You will not have two instances of DLL B loaded in the same process.
Named pipes might be the solution to your problems.
If you're targetting windows, you can check this reference
[EDIT] Didnt see you wanted to work on the same instance. In that case you need shared memory spaces, however, you really have to know what you're doing as it's quite dangerous :)
A better solution could be to apply OO Networking principles to your libs and communicate with, say CORBA, using interprocess middleware or the 127.0.0.1 loopback interface (firewalls will need to allow this).
Seems the simple solution would be to include in some initialization function of library A (or in DllMain if needed) a simple call to a function in library B passing a pointer to the common object. The only caveat is that you must ensure the object is deleted by the same DLL that newed it to avoid problems with the heap manager.
If these DLL's are in fact used in different threads you may have to protect access to said data structure using some kind of mutex.
Is there a quick way to hook a dll in c++? I know there is Microsoft's Detours thing, but isn't there a quick a simple way just to hook a few dll functions?
For example I want to hook a the function void mytestfunction() in the dll mytestdll.dll to hook_mytestfunction().
thanks in advance!
Probably the easiest way is to put your own wrapper DLL with the same name in the directory of the EXE, and put a copy of the hooked DLL in the same directory with a new name. Then, in the IAT of your wrapper DLL, redirect any non-intercepted call to the wrapped DLL (export forwarding), and implement the others yourself.
To redirect functions, put the following line in your .DEF file: Foo=wrapped_mytestdll.Foo where Foo is the (mangled) function name and wrapped_mytestdll is the new name of the copied DLL.
As a result, the affected EXE loads your wrapper DLL, and in turn the wrapped DLL. Functions in your wrapper DLL take precedence over the wrapped DLL. The only calls not intercepted are calls by the wrapped DLL to itself, as those don't go through your IAT.
(I've since found a link to a tool to generate a basic ".DEF" file, but haven't tested it myself. Use at your own risk.)
Detours is the quick and simple way!
I assume if you're hooking a DLL that you're hooking the exports of that DLL?
In that case you can perform a simple IAT (and potentially EAT if necessary) hook.
The advantage of IAT/EAT hooks over Detours is that the application and removal of the hooks is 100% safe (as you're not replacing code, you're replacing a pointer, so there is no chance of a race condition), and it's easy to do the hooks on native x64 processes too (which Microsoft's Detours library can't do unless you fork out 10 grand for the Prof edition).
Yes, there are 3rd party detour libraries which have x64 support and take care of most of the race conditions and what-not, but some of them are really expensive, and others are just a pain to work with.
IAT/EAT hooks are quick and easy, and there is sample code for performing them available in the book "Windows via C/C++" (along with a multitude of places on the interwebs).
This is a fairly generic answer I know, but it's hard to go into more detail without more information on what you're trying to do exactly.
I've used this some times ago with success :
http://software.intel.com/en-us/articles/intercepting-system-api-calls/
However I google it and could find something new at code project with great grades :
http://www.codeproject.com/KB/winsdk/LibMinHook.aspx
Just call GetProcAddress(hDll, "mytestfunction"), and write jmp hook_mytestfunction there, then place instructions at start of mytestfunction in hook_mytestfunction.
It's really quick and easy, of course if you understand it. If you don't - use MS Detours or another library. Usually you can do it without understanding of how it works.