I have a C++ DLL which was written in 1998, and I want to view the members (properties, fields, methods, constructors etc). I am of the understanding that the company who wrote the DLL is no longer about, but it is still used.
If I have only the DLL, is this possible? Or do you have to just know what is inside the DLL to work with it. If it is possible how would I go about this?
I am looking to work with the DLL from .Net via P/Invoke.
Get this: http://www.dependencywalker.com/ , use depends.exe to open the DLL, then activate "Undecorate C++ Functions" in the "View" menu. I mainly use it to find dependencies, but it also exposes entry points of DLLs.
This is not fool proof, because a DLL that exposes a class doesn't have to export its methods. For example, pure virtual method layout is sufficiently uniform that you can expose your instances as interface pointers with maybe a factory function. But it might solve your problem.
And regardless, you need a copy of dependency walker. :)
You can use a tool like IDA to dissasemble the binary and try to make out function names, but this can be hard. Why do you only have the DLL? It would be much easier to get the info from the export table of the associated lib or, even better, header files.
you can use VS Command prompt
a simple command is:
dumpbin /exports <nameofdll>
NirSoft offers 'DLL Export Viewer'
https://www.nirsoft.net/utils/dllexp.zip
Convinient UI application which can display dll members.
Related
I have CamerSampleSDK.exe C++ application which is using CameraSDK.dll. By unknown reasons company decided not to provide CamerSampleSDK.exe source code to all users who bought their camera. The main question is it possible somehow to find out which functions from CameraSDK.dll application CamerSampleSDK.exe is calling? Which application can be used in this case?
It is a bit complicated when you don't know functions prototypes and them parameters. But you try to do a small research:
Find all functions names which your DLL is exporting (Your target is DLL export table). You can use 'PE Tools' application: open your DLL in PE Editor, 'Directories' -> 'Export directory'. You will see functions names and them addresses:
If you can use IDA Pro, it will be better solution. Try to disassemble your DLL, explore each exported function and deduce parameters types and result by decompiled code. It is more complicated thing in research, you need knowledge of assembler, system architect and machine codes.
If you're familiar with debuggers like WinDBG, OllyDBG or another Windows usermode debugger, try to debug application which uses DLL: put breakpoints on each DLL exported function. Check that deduced signatures are correct and find correct call order
Try to use DLL in your project with LoadLibrary/GetProcAddress and correspond to deduced parameters and call order.
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
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.
I have an application that's suppose to be realized in plugin pattern.
Plugins are located in dll files and I'm loading them on the fly, depending on the parameter given from a user via command line. That is, if user wants to use plugin1 he types that name as a parameter in command line when running the app and I am supposed to load it on the fly.
Since I'm using plugin pattern I have an interface (since working in c++ it's an abstract class), that all of the plugins classes implement.
My dilemma is where to put the interface class? In order to have dlls built I will have to have a declaration of interface in every dll.
I want to avoid the need for changing the interface in all of dlls when there is a need for change in interface.
On the other hand if I declare interface class in main app my dlls wont be compiled and built?
Do you have a suggestion on how to extract the interface class from dlls and put it in the main app, so when I want to change it's code, wouldn't need to change it in a dozen of places (that is, in every dll).
Thanks in advance,
Cheers
You will have to store the interface definition in a common location (separate .h file in say \inc subdirectory) and you will have to recompile all the libraries once you change the interface. There's no way around that in C++. If you need the ability to uniquely indentify interfaces you can use something like COM and change interface id each time you break the interface (again you will have to recompile the implementations, but with COM the client will not run into undefined behavior because of DLL hell).
If by "interface" you are talking about the header file that describes your base-abstract class, I see no real issue.
You can share and use a file (here, a "header file") among several projects (a "project" is either your main application or one of your plugins). In your case, it actually makes perfect sense.
Every DLL needs to have the same exported function that returns a pointer to your interface. Each DLL should be responsible for instantiating the 'interface' (Really subclass actually).
So the main app will come along, call LoadLibrary on the DLL, and then using GetProcAddress, will call the exported function on the DLL. The exported function should then instantiate the concrete interface and return a pointer to it.
Question:
"Where to put the interface"
Answer:
In your 'public' API folder.
I once did this in C#, but maybe it can help you. I created an interface and abstract class in a separate project, which the main app and the plugins reference to. That way there is only one place for edits if necessary.
Main App.exe <-> PluginInterface.dll <-> APlugin.dll
Not sure how you would accomplish this in C++, I guess you could create a separate dll for the plugin interface and load it from your exe and your plugin dll's.
Hope that helps.
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.