How would I go about calling a dll from kernel mode?
I have tried making a custom lib file using multiple techniques but I cannot get anything to work. I have also researched on google but cannot seem to find anything. I was also curious if it was possible to create entries in the import address table from c++ or at link time?
The fundamental issue for a DLL in kernel mode is whether the DLL calls any user-mode code. If a DLL contains anything other than native kernel API calls, you'll get linker errors if you try to link your driver with it when you build (and the kernel wouldn't load it anyway)
check the following link
Calling a DLL in a Kernel-Mode Driver
Edit:
Another useful link
DLLs in Kernel Mode Tim Roberts
Related
Our Mac application can (sadly) only build and run in 32bit-only. Reason is: a huge bunch of very old 32bit-only C++ code shared with other platforms (Windows, Android, Linux, etc.). This is cross server-client networking-protocol code, so it can't really be replaced. Until EVERYONE needs is 64bit, we're bound to build our app 32bit only.
Now I'm building a new module for this application as an external private dynamic framework. I'd like to use ARC, and the new niceties of modern Obj-C runtime, but these are only available in 64bit-only builds.
So… Could my 32bit Mac Application link, and use, and load a 64bit-only framework?
Well, I found the answer, which is on the whole --- NO.
Here are the details, and a work-around.
First off, a 32bit process can’t load 64bit code. The linker complains when you try to link the 64bit-only framework to your 32bit app.
I was offered two ways around this, both rely on parting the 32bit-only code and the 64bit-only code into 2 different processes, talking using XPC.
The first way would be to create a "host" 64bit process that will load my 64bit framework, and the 32bit application can then use XPC to talk to it.
The second option would be to extract all the 64bit-unsafe code (things I MUST compile 32bit-only) and put THAT in a special 32bit-only process then I can make my application 64bit only on Mac, add the new framework, and talk via XPC to the 32bit helper process.
I'm embedding mono in C++ application, and I'm linking it via dll library, which is then loaded into application via LoadLibrary.
When the application starts and the dll runtime linking happens, the mono runtime seems to fail to initialize itself with "Too many root sets" message. I'm unsure when and how the runtime itself is initialized (I thought it happens on mono_jit_init, but the error pops up before any call to any of the mono functions. It occurs exactly at LoadLibrary should I try load it manually instead of relying on mono.lib import library).
I succesfuly embedded it in standalone application, so I assume it is something specific to the way my dll is loaded by the application, but I don't know what exactly.
Any clues?
This may be a limitation of the way the Boehm GC works in windows: it hooks to the operating system at LoadLibrary time to get notifications of the created threads and loaded libraries (this is why you get the issue at LoadLibrary() time and not on mono_jit_init()).
Or it may be that you have really many threads and libraries loaded by the time the GC is initialized. If you link the app to mono directly, does the problem go away? If yes, that should be your current workaround.
In the future (or if building mono from git) you may be able to use the SGen GC which shouldn't suffer from this problem.
I am using a WINCE framework for development called WINDEV.
This framework has some DLLs that are to be loaded, but on some WINCE platforms, the loading (tested with a c program with the LoadLibraryEx instruction) does not work ....
The results vary from one platform to another ....
What are the hypothesis to be checked ?
Thank for your help.
What does exactly mean "does not work"?
According to MSDN, LoadLibraryEx on failure returns NULL, and "To get extended error information, call GetLastError."
Some ideas:
- is the DLL you are trying to load in the same directory of the executable?
- is the DLL a valid Windows CE binary?
- does LoadLibraryEx work if you try to load some known system DLL?
Sorry, without more details I cannot think of anything more.
Since Windows CE is a modular OS not all Windows CE platforms include all the components. It might be that your Dll is dependent on one of these components and thus fails to load.
As Benedetto suggested, get the last error and add the information to the question.
You can also use DependencyWalker to see what Dlls your library depends on so you can check whether they are available on the non cooperatives platforms.
We created a plugin; it is a DLL (Run-Time Dynamic Linking) which uses a 3rd party library (wxWidgets) and also links dynamically to that. The host software seems to scan our plugin, but exported functions are not called. We checked all dependencies with DependencyWalker.
We see in the debugger that the plugin is loaded, but the DllMain is not called, and the plugin is unloaded.
We tried loading our plugin from a simple test application using LoadLibrary and GetProcAddress which recognized and called the exported functions.
Having wxWidgets linked statically worked fine, though.
Does anyone have an idea why the exported function, respectively DllMain are not called, or can point out a tool which is capable to monitor the whole DLL loading process?
If wxWidgets is loaded already into the process address space before your plugin is loaded (the host app could do that, or there might be another plugin linking to wxWidgets which is loaded before yours), then there might be a chance that it is another version, missing some of the entry points that your plugin needs. Running the host app under DependencyWalker or WinDbg should show you which wxWidgets DLL is loaded, and you could try to load your plugin from your test app using exactly the same wxWidgets DLL. That should reveal whether there are missing dependencies.
Perhaps the host software does some funky things when loading the plugin and doesn't like wxWindows.
Anyways, try using the ProcessExplorer from the SysInternals suite to check what the process is doing.
We need to interface to 3rd party app, but company behind the app doesn't disclose message protocol and provides only Windows DLL to interface to.
Our application is Linux-based so I cannot directly communicate with DLL. I couldn't find any existing solution so I'm considering writing socket-based bridge between Linux and Windows, however I'm sure it is not such a unique problem and somebody should have done it before.
Are you aware of any solution that allows to call Windows DDL functions from C app on Linux? It can use Wine or separate Windows PC - doesn't matter.
Many thanks in advance.
I wrote a small Python module for calling into Windows DLLs from Python on Linux. It is based on IPC between a regular Linux/Unix Python process and a Wine-based Python process. Because I have needed it in too many different use-cases / scenarios myself, I designed it as a "generic" ctypes module drop-in replacement, which does most of the required plumbing automatically in the background.
Example: Assume you're in Python on Linux, you have Wine installed, and you want to call into msvcrt.dll (the Microsoft C runtime library). You can do the following:
from zugbruecke import ctypes
dll_pow = ctypes.cdll.msvcrt.pow
dll_pow.argtypes = (ctypes.c_double, ctypes.c_double)
dll_pow.restype = ctypes.c_double
print('You should expect "1024.0" to show up here: "%.1f".' % dll_pow(2.0, 10.0))
Source code (LGPL), PyPI package & documentation.
It's still a bit rough around the edges (i.e. alpha and insecure), but it does handle most types of parameters (including pointers).
Any solution is going to need a TCP/IP-based "remoting" layer between the DLL which is running in a "windows-like" environment, and your linux app.
You'll need to write a simple PC app to expose the DLL functions, either using a homebrew protocol, or maybe XML-RPC, SOAP or JSON protocols. The RemObjects SDK might help you - but could be overkill.
I'd stick with a 'real' or virtualized PC. If you use Wine, the DLL developers are unlikely to offer any support.
MONO is also unlikely to be any help, because your DLL is probably NOT a .NET assembly.
This is a common problem. Fortunately, it now has a solution. Meet LoadLibrary, developed by Tavis Ormandy:
https://github.com/taviso/loadlibrary
I first stumbled across LoadLibrary in an article on Phoronix by Michael Larabel:
A Google researcher has been developing "LoadLibrary" as a means of
being able to load Windows Dynamic Link Libraries (DLLs) that in turn
can be used by native Linux code.
LoadLibrary isn't a replacement for Wine or the like but is intended
to allow Windows DLL libraries to be loaded that can then be accessed
by native Linux code, not trying to run Windows programs and the like
on Linux but simply loading the libraries.
This project is being developed by Tavis Ormandy, a well known Google
employee focused on vulnerability research. He worked on a custom
PE/COFF loader based on old ndiswrapper code, the project that was
about allowing Windows networking drivers to function on Linux.
LoadLibrary will handle relocations and imports and offers an API
inspired by dlopen. LoadLibrary at this stage appears to be working
well with self-contained Windows libraries and Tavis is using the
project in part for fuzzing Windows libraries on Linux.
Tavis noted, "Distributed, scalable fuzzing on Windows can be
challenging and inefficient. This is especially true for endpoint
security products, which use complex interconnected components that
span across kernel and user space. This often requires spinning up an
entire virtualized Windows environment to fuzz them or collect
coverage data. This is less of a problem on Linux, and I've found that
porting components of Windows Antivirus products to Linux is often
possible. This allows me to run the code I’m testing in minimal
containers with very little overhead, and easily scale up testing."
More details on LoadLibrary for loading Windows DLLs on Linux via
GitHub where he also demonstrated porting Windows Defender libraries
to Linux.
Sometimes it is better to pick a small vendor over a large vendor because the size of your business will give you more weight for them. We have certainly found this with AV engine vendors.
If you are sufficiently important to them, they should provide either a documented, supported protocol, a Linux build of the library, or the source code to the library.
Otherwise you'll have to run a Windows box in the loop using RPC as others have noted, which is likely to be very inconvenient, especially if the whole of the rest of your infrastructure runs Linux.
Will the vendor support the use of their library within a Windows VM? If performance is not critical, you might be able to do that.
Calling the DLL's functions themselves is of course only the tip of the iceberg. What if the DLL calls Win32, then you'd have a rather massive linking problem. I guess Wine could help you out there, not sure if they provide a solution.
IMO, the best bet is to use Sockets. I have done this previously and it works like a charm.
An alternate approach is to use objdump -d to disassemble the DLL, and then recompile/reassemble it. Don't expect to be able to recompile the code unedited. You might get pure, unadulterated rubbish, or code full of Windows calls, or both. Look for individual functions. Functions are often delimited by a series of push instructions and end with a ret instruction.