Is there an application which allows me to see what is being sent to a DLL from a process?
I have a process and I have a DLL and I would like to monitor the parameters that are being sent to the functions so that I can use the DLL myself.
The EXPORT of the DLL is.
??0CCPCompressor##AAE#XZ
??0CCPExpandor##AAE#XZ
??1CCPCompressor##AAE#XZ
??1CCPExpandor##AAE#XZ
?Clear#CCPCompressor##QAEHXZ
?Clear#CCPExpandor##QAEHXZ
..Compress#CCPCompressor..
..Delete#CCPCompressor..
..Delete#CCPExpandor..
..Expand#CCPExpandor..
..Free#CCPCompressor..
..Free#CCPExpandor..
..Init#CCPCompressor..
..Init#CCPExpandor..
..New#CCPCompressor..
..New#CCPExpandor..
In general, this is a bad idea. Even if you have some set of captured parameters, without deep analysis of the DLL code you don't know what to do with those parameters and what ranges of parameters are accepted by certain methods. Example: if I call a method DoMathOperation(Add, 1, 2), you can mimic this call, but you won't be able to do DoMathOperation(Multiply, 2, 2) as you don't know that this is possible.
The simplest approach has been to simply relocate the original dll, and create a new dll that you make yourself, with the same exports. This dll would LoadLibrary the old dll from the alternate location.
This doesn't quite apply here - the dll is exporting c++ class members which has two consequences: c++ classes have to be statically loaded as there is no c++ mechanism to 'glue' c++ function pointers (obtained via GetProcAddress) into a class instance.
This means your shim dll would be in the unfortunate place of having to both import, and export, and identical set of symbols.
The only way around this is to write your shim dll in two parts:
Shim1:
One part would get the name of the original dll, and would export the same class defintion the original dll exported:
class __decldpec(dllexport) CCPCompressor {
...
Depends can crack the name decoration, or Undname.exe is distributed with Visual Studio.
This part would LoadLibrary() using an explicit path to shimdll2.dll located in some other folder, along with the original dll. GetProcAddress() would be needed to import functions exported by shimdll2.dll
Shim2:
The other shim dll would be located in a folder with the dll you are trying to intercept. This dll would have to import the class from the original compressor dll:
class __declspec(dllimport) CCPCompressor {
...
You can use the dll import library made by the first dll to actually link the symbols.
Then its a case of exporting functions from shim2.dll that shim1.dll will call whenever a CCPCompressor method is called.
NB. Other things: your version of the CCPCompressor class will need to have, at least, a large dummy array as you can't know from the dll exports how big the application expects the class to be (unless you happen to have an actual header file describing the class).
To decompose the exported names to build a class definition:
Open up the Visual Studio 20XX Command Prompt from the Start > Programs > Visual Studio 20XX -> Tools menu.
c:\...\VC>undname ?Clear#CCPCompressor##QAEHXZ
Microsoft (R) C++ Name Undecorator
Undecoration of :- "?Clear#CCPCompressor##QAEHXZ"
is :- "public: int __thiscall CCPCompressor:Clear(void)"
c:\...\VC>_
Do that for each function exported from the original dll (undname accepts some kind of text file to speed this process up) to find out how to declare a matching class def.
Is using detours compatible with your requirements?
From the site:
Overview
Innovative systems research hinges on the ability to easily instrument and extend existing operating system and application functionality. With access to appropriate source code, it is often trivial to insert new instrumentation or extensions by rebuilding the OS or application. However, in today's world systems researchers seldom have access to all relevant source code.
Detours is a library for instrumenting arbitrary Win32 functions on x86, x64, and IA64 machines. Detours intercepts Win32 functions by re-writing the in-memory code for target functions. The Detours package also contains utilities to attach arbitrary DLLs and data segments (called payloads) to any Win32 binary.
Detours preserves the un-instrumented target function (callable through a trampoline) as a subroutine for use by the instrumentation. Our trampoline design enables a large class of innovative extensions to existing binary software.
We have used Detours to create an automatic distributed partitioning system, to instrument and analyze the DCOM protocol stack, and to create a thunking layer for a COM-based OS API. Detours is used widely within Microsoft and within the industry.
The only reliable way is to debug your program (using any debugger like OllyDBG) and set breakpoint on required export function. Then you can simply trace the stack parameters sent to the calling function. This is only the start, you need to fully analyze function instructions within a debugger or disassembler to see what each parameter is doing and its type.
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'd like my Windows application to be able to reference an extensive set of classes and functions wrapped inside a DLL, but I need to be able to guide the application into choosing the correct version of this DLL before it's loaded. I'm familiar with using dllexport / dllimport and generating import libraries to accomplish load-time dynamic linking, but I cannot seem to find any information on the interwebs with regard to possibly finding some kind of entry point function into the import library itself, so I can, specifically, use CPUID to detect the host CPU configuration, and make a decision to load a paricular DLL based on that information. Even more specifically, I'd like to build 2 versions of a DLL, one that is built with /ARCH:AVX and takes full advantage of SSE - AVX instructions, and another that assumes nothing is available newer than SSE2.
One requirement: Either the DLL must be linked at load-time, or there needs to be a super easy way of manually binding the functions referenced from outside the DLL, and there are many, mostly wrapped inside classes.
Bonus question: Since my libraries will be cross-platform, is there an equivalent for Linux based shared objects?
I recommend that you avoid dynamic resolution of your DLL from your executable if at all possible, since it is just going to make your life hard, especially since you have a lot of exposed interfaces and they are not pure C.
Possible Workaround
Create a "chooser" process that presents the necessary UI for deciding which DLL you need, or maybe it can even determine it automatically. Let that process move whatever DLL has been decided on into the standard location (and name) that your main executable is expecting. Then have the chooser process launch your main executable; it will pick up its DLL from your standard location without having to know which version of the DLL is there. No delay loading, no wonkiness, no extra coding; very easy.
If this just isn't an option for you, then here are your starting points for delay loading DLLs. Its a much rockier road.
Windows
LoadLibrary() to get the DLL in memory: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
GetProcAddress() to get pointer to a function: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
OR possibly special delay-loaded DLL functionality using a custom helper function, although there are limitations and potential behavior changes.. never tried this myself: https://msdn.microsoft.com/en-us/library/151kt790.aspx (suggested by Igor Tandetnik and seems reasonable).
Linux
dlopen() to get the SO in memory: http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html
dladdr() to get pointer to a function: http://man7.org/linux/man-pages/man3/dladdr.3.html
To add to qexyn's answer, one can mimic delay loading on Linux by generating a small static stub library which would dlopen on first call to any of it's functions and then forward actual execution to shared library. Generation of such stub library can be automatically generated by custom project-specific script or Implib.so:
# Generate stub
$ implib-gen.py libxyz.so
# Link it instead of -lxyz
$ gcc myapp.c libxyz.tramp.S libxyz.init.c
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 am writing a Win32 DLL library that can be redistributed. I am using different versions of the windows API because I want to support Windows 7 functions, but still have support for Windows 2000 (with some function disabled). What I have currently is MyLib2000.dll, MyLibXP.dll, and MyLibVista.dll, and my application chooses which library to load at runtime. I want a way to have a single DLL (MyLib.dll) that stores the other three in itself and when it's being loaded, it extracts the correct DLL out of itself and loads it.
I know this is not the best way to do this, so suggestions on another method of doing this is welcome.
Use delayloading and implement the dliNotePreLoadLibrary notification hook to load the correct version of your DLL. The linker-provided delay load logic will then pull in all the functions from whichever DLL you loaded.
http://msdn.microsoft.com/en-us/library/z9h1h6ty(v=VS.100).aspx
Or use delay-loading and implement your functions to check the OS version before calling any function that could fail to be loaded (since it doesn't exist on the old OS).
Why not just abstract out the OS-version dependencies in a software layer, implemented in terms of something like STLSoft's dl_call() function template suite.