C#:
I have a standard win32 DLL from a vendor that talks to a hardware device. Is there any utility to automatically generate my interop code by discovering the exports in the DLL? This is not a COM dll. There is no def file, all I have is the DLL.
In general, all you can do is find out the exported function names. even then, it's possible (but very, very unlikely) that the names aren't there (a DLL that has only ordinals).
The names may have clues to the parameters (with the size of the parameters, or the mangled C++ names), but getting the actual paramters from this information would either be painful and prone to error (C++ mangled names) or not possible (if only the size is encoded in the name).
If it were a COM DLL, you still wouldn't be guaranteed that you could get the information you need, but it would be more likely that there was a TLB or some other meteainfo about the DLL, either separately or embedded in the DLL.
Related
If this question deals with too basic a matter, please forgive me.
As a somewhat-close-to-beginner-level programmer, I really wonder about this--whether the underlying code of every win API function is compiled altogether at the time of writing an app, or whether the machine code for executing win APIs stays in the memory as part of the OS since the pc is booted up, and only the app uses them?
All the APIs for an OS are used by many apps by means of function call. So I thought that rather than making every individual app include the API machine code on their own, apps just contain the header or signature to call the APIs and the API machine code addresses are mapped when launching the app.
I am sorry that I failed to make this question succinct due to my poor English. I really would like to get your insights. Thank you.
The implementation for (most) API calls is provided by the system by way of compiled modules (Portable Executable images). Application code only contains enough information so that the system can identify and load the required modules, and resolve the respective imports.
As an example consider the following code that shows a message box, waits for it to close, and then exits the program:
#include <Windows.h>
int main()
{
::MessageBoxW(nullptr, L"Foo", L"Bar", MB_OK);
}
Given the function signature (declared in WinUser.h, which gets pulled in from Windows.h) the compiler can almost generate a call instruction. It knows the number of arguments, their expected types, and the order and location the callee expects them in. What's missing is the actual target address inside user32.dll, that's only known after a process was fully initialized, and had the user32.dll module mapped into its address space.
Clearly, the compiler cannot postpone code generation until after load time. It needs to generate a call instruction now. Since we know that "all problems in computer science can be solved by another level of indirection" that's what the compiler does, too: Instead of emitting a direct call instruction it generates an indirect call. The difference is that, while a direct call immediately needs to provide the target address, an indirect call can specify the address at which the target address is stored.
In x86 assembly, instead of having to say
call _MessageBoxW#16 ; uh-oh, not yet known
the compiler can conveniently delegate the call to the Import Address Table (IAT):
call dword ptr [__imp__MessageBoxW#16]
Disaster averted, we've bought us just enough time to fix things up before the code actually executes.
Once a process object is created the system hands over control to its primary thread to finish initialization. Part of that initialization is loading dependencies (such as user32.dll here). Once that has completed, the system finally knows the load address (and ultimately the address of imported symbols, such as _MessageBoxW#16), and can overwrite the IAT entry at address __imp__MessageBoxW#16 with the imported function address.
And that is approximately how the system provides implementations for system services without requiring client applications to know where (physically) they will find them.
I'm saying "approximately" because things are somewhat more involved in reality. If that is something you'll want to learn about, I'll leave it up to Raymond Chen. He has published a series of blog entries covering this topic in far more detail:
How were DLL functions exported in 16-bit Windows?
How were DLL functions imported in 16-bit Windows?
How are DLL functions exported in 32-bit Windows?
Exported functions that are really forwarders
Rethinking the way DLL exports are resolved for 32-bit Windows
Calling an imported function, the naive way
How a less naive compiler calls an imported function
Issues related to forcing a stub to be created for an imported function
What happens when you get dllimport wrong?
Names in the import library are decorated for a reason
Why can't I GetProcAddress a function I dllexport'ed?
I know I can read the CLSID from a COM class object in the registry from Classes\<CLASSNAME>\CLSID\#.
I suspect on a registered COM interface I can read up the IID from Classes\<CLASSNAME>\IID\# or Classes\CLSID\<CLSID>\IID.
I've read the article COM IDs & Registry keys in a nutshell and this question is still open to me. Unfortunately, I have no test case right now.
The registry was not meant to be a programming resource, registry entries are only there when the COM infrastructure needs them. The CLSID key for example is necessary to help COM find the executable file that implements a server, the programmer has to supply the CLSID guid.
He needs to know the IID as well, passes it to QueryInterface() to obtain the interface pointer. There might be an entry in HKLM\Software\Classes\Interface but it isn't terribly common. The COM infrastructure needs it when an interface needs to be marshaled from one apartment to another, the registry key contains the CLSID of the proxy that helps to get that job done. A quick look with Regedit.exe in that key ought to convince you that it isn't likely to be helpful at all, there is no connection whatsoever with the server itself. Only if you are very lucky might you find a Type library LIBID there.
There are two basic ways that the COM programmer supplies you with CLSID and IID values. The unfriendly way is an .idl or .h file, several Windows components (DirectX, Media Foundation, WASAPI, etc) are like that. Good enough to see the IIDs back.
The friendly way is a type library, a language-independent description of the implemented coclasses and interfaces that just about any compiler knows how to read. Sometimes supplied as separate .tlb or .olb file but usually embedded as a resource in the executable file. Best way to have a look at it is with the Oleview.exe SDK utility. Use File > View Typelib and select the .tlb or .dll file. It decompiles the type library back into IDL, the language that a COM author uses to describe his component. You'll have no trouble finding the IIDs back. Only thing you have to know is the name of the executable file.
Be sure to take advantage of the type library in your compiler, assuming you found one. You can now use friendly names instead of raw GUIDs, get syntax checking on your code and rarely have to do anything dramatic when the version changes and the author properly used new IIDs. Be sure to talk to the author if you can't find one, a small hint can save you an enormous amount of trouble.
Most applications created with Microsoft developer tools need some kind of runtime to be installed first.
However most viruses never need any kind of runtime to work. Also they also seem to use undocumented core/kernel APIs without have lib files etc.
So what runtime/application do most virus /virus writers use ?
If the runtime is statically linked in (as opposed to dynamically), then an EXE will be self-contained and you won't need a runtime DLL. However, really, you don't even need a runtime library at all if your code can do everything without calling standard library functions.
As for Windows APIs, in many cases you don't strictly need an import library either -- particularly if you load addresses dynamically via GetProcAddress. Some development tools will even let you link directly against the DLLs (and will generate method stubs or whatever for you). MS tries to ensure that names for documented API calls stay the same between versions. Undocumented functions, not so much...but then, compatibility typically isn't the foremost of concerns anyway when you're deliberately writing malicious software.
How do you call IFileOpenDialog and IFileSaveDialog from VBA?
According to Microsoft, applications written for Windows 7 and later should use IFileOpenDialog/IFileSaveDialog API calls instead of GetOpenFileName/GetSaveFileName (see Using the Common File Dialog). This is especially important for full Library support.
Short answer: it's probably not worth the effort.
Longer answer: the CFD interfaces don't extend IDispatch, which makes them impossible to call via late binding from VBA. That doesn't mean they can't be called from VBA, but it means they require a typelib to describe the "shape" of the IUnknown-based CFD interfaces. Unfortunately, Microsoft doesn't provide the CFD interface definitions in a typelib. You can roll your own typelib by reverse-engineering the header files (or try to find the original IDL in the SDK), but you'd then have to register that typelib on every machine you want to use it on (the tools for which are not shipped on the machine, unlike regsvr32 for COM stuff). Assuming you did all that, you could then reference the typelib from VBA, and conditionally call it on Vista or higher OSes. You could also shim through to a small .NET assembly that would create a System.Windows.Forms.FileDialog-derived type and marshal the results back to VBA- that would be much easier, but still more-or-less require that you register the assembly on every machine (or use C++/CLI or other hacks to export a managed DLL function), and it requires you to take a .NET dependency.
They sure didn't make it easy... :) Good luck!
I know that dynamic link library are loaded in memory when an application loaded, the reference is resolved by operation system loader. For example, in windows kernel32.dll, user32.dll and gdi32 dll, so if my application reference a function in a kernel32.dll, for example CreateWindow, is that the whole dll must be loaded in the process, or just part of the dll?
Thanks
whole thing, but don't worry, it's not re-loading the dll over and over, there is one instance for all the programs that use it....another name for dll is so....or shared object, and that's the whole point, to share.
http://en.wikipedia.org/wiki/Dynamic_link_library
You reference one function, you get the whole DLL. You can't load just part of a DLL.
It's annoying because you get all of Shell32.dll just to find where someone's home directory is. Sigh.
Don't worry about this so much, when you "load" a DLL, it's really just a mapped memory file; the Windows OS uses the page fault mechanism to bring in pages on-demand; so if you only use a small piece of the DLL you aren't actually going to fault the whole thing in.
Only the functions you use in that DLL is required, do not worry about cramping the memory, as most of these DLL's are standard and not alone that they are dynamic, the very reason why only certain functions that your code uses are loaded, not the entire dll.
Hope this helps,
Best regards,
Tom.