I know it's impossible to reverse a dll into a c++ code so I would like to collect as much as possible details from it.
It's not my dll, so I don't have the source code of course. Which program should I use?
Well, if you are skilled you can disassemble the DLL and understand all of its functions. This takes a substantial amount of time, but if you do that you can reverse it back to source by hand.
Otherwise, you can start by using a tool like Dependency Walker to get the DLLs and functions it depends on, and the functions it exports. From there you can find functions that interest you, and use a disassembler like IDA to see what they do.
You can see the list of exported functions by using the dumpbin tool. If C++ functions are exported, you might be able to infer parameters by the name mangling.
You can extract all the resources from the DLL by just "opening" it as a file for resource viewing in Visual Studio. If the DLL is a COM based DLL, there's a small chance the Type Library is embedded as a resource inside it. And if you have the Type Library, you can #import it to reconstruct the header files for the public interfaces.
That's about as good as it gets.
You need a PE file viewer. This will tell you the exports from the DLL and you can get the data in the .text section to see the machine code.
Related
I would like to protect my dll file from easy disassembly. I have found some programs like Dotfuscator, Crypto Obfuscator - but they aren't made for c++. Have you got any idea what program i could use or how to change my code to make it harder for hacking?
Most important for me, is to hide Strings from being seen.
There are C++ executable files protectors exist: E.g. SoftwarePassportTM (ex. Armadillo library). It uses different methods to prevent disassemble and debugging of the application. Now sure how it fits to single dll protection
i have some huge c++ projects, all of then are compiled with msvc++ 2010.
i want the DLL file to be smaller,
can anyone give me some inspiration?
Compile for release, use Link Time Code Generation (LTCG), remove unused references (OPT:ICF), put the CRT in a DLL. Don't export things from the DLL unless necessary.
In addition to the other answers, you can use upx to compress the dll, or some other compressor.
http://upx.sourceforge.net/
In addition to the above suggestions, Make sure in Project Properties->C/C++->Favor Size Or Speed, Favor small code (/Os) is selected.
Compile as release, not debug.
Link with MSVCRT dynamically instead of statically. This means you likely have to distribute the MSVCRT DLL with your program. Depending on how your program is structured, changing the links of CRT can have unintended side effects.
Remove all the code that isn't needed. Use a profiling or code coverage tool to identify code that doesn't appear to be getting called. You might be able to remove it.
Look at all the corresponding .obj files for each .c or .cpp file. If any one obj file is excessively large relative to the size of the code file, that might be a hint something could be reduced there.
Minimize the use of global instances or global data in your DLL. The binary size will bloat by the number of bytes of global variables declared.
Only export the very minimal number of functions you need to have other EXEs and DLLs import. Run "dumpbin /exports yourfile.dll" to get the list of exported functions. Only export functions that are directly called by the code relying on the DLL. If you are exporting something that no one outside of the DLL is going to call directly, don't export it. The linker will optimize it (and it's dependents) from being used if nothing internal is calling it.
Don't export entire C++ classes. Export simple C wrapper functions if your DLL is C++ code.
I have third party dlls that I need to use with my application. The interface is defined in the third party dlls and I have to make the interface call from my application. I have the function prototype of the interface, but no lib files or header files. It looks like loadlibrary should be used, but is it possible without the header files ? Is there a way to generate such header files? Would also greatly appreciate some explanation for the loadlibrary, as I am still grasping the idea yet.
Thanks!
You can use QLibrary::resolve() (or its static convenience brethren) to lookup a symbol in a DLL, and call it.
You load the library with the API function LoadLibrary. After loading the DLL you use GetProcAddress to get the entry point for a specific function.
If it's a C++ library, you may have to care for the decorated names. The tools dumpbin and undname may help to identify what is really exported by the DLL.
I've encountered a strange behavior in __declspec(dllexport) in my project.
I have a C++ project that uses classes, namespaces, try-catches and more cpp elements.
When exporting any dummy function in this DLL, no other C project will be able to load it with LoadLibrary (Getting error 'module not found').
Is it possible to load dynamically C++ dlls through C projects?
These projects are Windows Mobile projects, but they should behave the same as on regular PC win32.
I'm stuck on it and any help will be appreciated.
Thank you,
Emil.
LoadLibrary is completely oblivious to the language used to compile a module. If LoadLibrary says it can't find the module, then it's very likely the case that it really can't find it. Make sure you've specified the right file name. If you've included a drive and path, make sure they're correct, too. If you haven't included a drive or path, then make sure the file exists somewhere where LoadLibrary can find it. The places it searches are listed in Dynamic-Link Library Search Order. Also consider whether Windows Vista's directory-virtualization feature might be interfering.
Once the DLL is loaded, you may have any number of other issues in using the C++ DLL from your C code. The C++ compiler may have mangled the function names, so you'll need to provide the right names when you call GetProcAddress. The C++ code might use a different calling convention from what your C code expects, so you may need to change declarations in the C++ code, the C code, or both. If the C++ functions expect to receive pointers to classes or other C++-specific types, you'll need to change your C++ code so that its API is compatible with C. If your DLL allocates memory that the host program should free, or vice versa, you'll need to make sure that both modules can use the same memory manager.
All that is separate from the problem you're reporting, though, which is simply that the OS can't find your file. Focus on that first.
I found the problem. It was really a dependency dll problem. It was not found in the directory of the loading DLL.
Thank you all.
I know that if I have an .a or .so file and a header file for that library (for example for SystemC), I should
1. include header file
2. link the appropriate library.
But I can't handle with only .dll file as I can link it as well, but don't have a hearer file to include and to use commands. Con someone explain me what kind of .dll-s exist and how they are possible to use? Is it possible to use any .dll file or it should be a specific kind of .dll to be able to integrate to my application?
A DLL is functionally equivalent to a .so file (also know as a 'shared object' or 'shared library'). You need a header to declare the functions that are available inside the DLL and you need to link against a library which handles the business of loading and executing DLL calls (mostly delegated to the OS).
It is possible to use a DLL without any sort of header. You can directly call Win32 API's which will dynamically load a DLL into your programs virtual address space and call other API's which will give you what are essentially function pointers. However, you need to know the signatures of the function pointers to use the properly so what you're effectively doing in that case is declaring a tiny subsection of the actual DLL header for your use.
This wikipedia article may help, especially the section on shared libraries
Unlike Linux, Windows libraries are seperated into two forms: DLL (for runtime linking) and LIB for symbol declarations. link.exe (the windows linker) expects .lib files to resolve symbols being used by your program's headers during build time. More information here:
http://msdn.microsoft.com/en-us/library/ba1z7822(VS.71).aspx
Note that if you load a DLL compiled in C++, you hvae to avoid passing object pointers across the interface, as they are in general not portable. You have to keep to basic C calls and calling conventions, as that is what is defined by the Windows or Linux platform ABI.