Given a native DLL, with no documentation or anything, and assuming it is not a COM component, is there any way to extract some sort of interface from that DLL so it can be called from C#?
I know about PInvoke, but that requires me to already know the method names and signatures. I don't have those.
Is it even possible?
You can use a PE reading tool to list the exported functions. For example Dependency Walker will do that for you.
There's not a right lot you can do with that information though. There's no metadata with a native DLL that tells you how to call those functions, what their signatures are. Or even what the parameters represent.
Something has gone wrong with this project. A DLL on its own is not enough. You need a header file and some documentation.
Related
I'm working on a Solidworks Addin using VB.NET that utilizes the Solidworks API and CAMWorks API.
Basically, Solidworks has integrated a free version of CAMWorks dubbed "SolidworksCAM". The API dll reference for CAMWorks and SolidworksCAM are different, each with a unique GUID, but maintaining the same simple name of "Interop.CAMWorksLib.dll". The API functions are 100% the same, just each software ships with a different GUID for their API. This GUID ties back to the COM assembly loaded in Solidworks, so if Solidworks has SolidworksCAM loaded and my addin is complied with the CAMWorks API reference it will fail to retrieve the COM object.
How can I achieve compatibility between these two APIs without having two projects? Is it even possible? Thanks!
Whenever I post a question to a board it seems like I always solve it soon after.
For future reference, I used Reflection to dynamically load the Dlls. Below is some more detailed information.
I put the Dlls in two different folders in my project and set them to Copy. I then used Assembly.LoadFile to load the dll and get its assembly. I used this assembly to get the constructor class "CWAppClass" and fed its type into Activator.CreateInstance to get an instance of the main CWApp class. This way you can use whichever one doesn't error. Thanks for the help!
After taking advice to not use LoadFile(), i have found that there is a method in the Solidworks API that allows you to do this. By using Sldworks::GetAddInObject you can get the addin object for whichever addin you choose. Then you can use the CAMWORKSADDINLib to interact with this. Thanks for the suggestion, this it the perfect solution for my problem.
Is there a way you can open and view the code in a DLL (i.e., see functions/methods, signatures, and the code inside those functions or methods?)
Is there a way to view any headers inside the DLL as well as the authorship information for a DLL?
for non-.Net windows DLLs, there is this one here:
http://www.dependencywalker.com/
If they are .NET DLLs, you can find out a remarkable amount, including disassembling the code, using redgate's free tool "Reflector" - see http://www.red-gate.com/products/reflector/
I think you will find what you need (and more) in Dependency Walker
Maybe you want to do it programmatically and write your own tool. Then have a look at the import and export tables of the COFF format.
Some other tools with source code doing it are:
Texe and LordPE
As material for my own lectures for Reverse Engineering, I developed PeStudio (www.winitor.net/en/pestudio.html). Using this tool you can snoop many details about imported and exported functions. You can even undecorate these when these have been decorated by a compiler.
I recently ran across a DLL installed on my system that Dependancy Walker (and every other utility I tried) says has zero exports by name or ordinal, yet the file is approximately 4mb in size. I thought the sole purpose of a DLL was to export functions for use by other code so what would be the purpose of a dll with no visible exports?
One way to think of a DLL is as a container for functions. Exporting a function from a DLL makes those functions visible to callers outside of the DLL. While exporting functions from a DLL is perhaps the most common way to provide access to them, many platforms provide other ways to access functions which have not been exported such as reflection in the .NET Framework and Java and (I think) LoadLibtary / GetProcAddress in Win32
Reasons for doing this are varied, often it is because it is beneficial to the developer to have functions in a library but undesirable for those functions to be called from external applications
Resource-only DLL, maybe? Those are used quite often for localization purposes, for example.
EDIT: it's also possible to have a DLL with code that does something in DllMain() to somehow make its functionality available. The DLL can register itself with some global dispatcher, for example, or create named kernel objects...
I have an application that uses many different .NET managed DLL's as objects (each DLL implements a common interface). Each DLL also has a version number in the file name.
Suppose I create the object "Shape~01.dll." The application will use that DLL but it can't be replaced while the application is running. So, if I want to "upgrade" the shape dll I have to create "Shape~02.dll" and the application has to dynamically search for and load the newest dll everytime a shape is created and/or the user has to restart the application. It get's worse, each dll depends on the main .exe thus has to be rebuilt with the main .exe.
Is there an easier method to have dynamically "replaceable" objects?
Well, this isn't the best solution (still thinking about it), but you can unload dll files which will allow them to be replaced. That might be a quick stopgap solution until you come up with a better idea.
You don't mention which language/platform you are trying to accomplish this in, so I will answer for the .NET Framework.
If you want to do it the hard way look at Shadow Assemblies, this is the method that ASP.NET uses to keep the site updateable though it is using the files.
For a much easier method look at the new System.Addin namespace, this uses Shadow Assemblies under the hood and should do what you want.
Instead of polling when creating an object, why not just request notification from the system when the file system changes?
The class is System.IO.FileSystemWatcher in.NET.
For native code there are a few ways to watch a folder, but IANAND (I am not a native developer ;).
Although having said those things, you probably want to rethink the reason you need to change your objects so frequently, because it will probably take a lot of work to make it work.
You used the dynamic tag, so maybe you should try a dynamic language? :)
As the question states - is there a good tool out there which lists methods an unmanaged DLL exports? I would like it to list COM methods and interfaces too.
For DLLs, use the Dependency Viewer (depends.exe).
For COM objects, use oleview.exe
Take a look at Dependency Walker to get a list of unmanaged functions exported from a DLL.
You can't easily get a l list of COM classes exported from a DLL. What you'd have to do is something like to through the registry and find all objects that reference the DLL in question. DLLs advertise their classes via registration in the registry...
As an application packager we use a utility that monitors (or dumps) the registration information - WiseComCapture.exe - this is part of Wise Package Studio however which isn't free.
It spits out a .reg file of all it's registration information.
A bit of noodling around with google may 'expose' it