Loading dynamic libraries from memory

Is there any crate or existing work to help me with this ?

Basically i'm looking for something similar to .NET's Assembly.Load(Byte[]) on Windows.

1 Like

This maybe helpful. Blog

1 Like

Usually you'll load dynamic libraries using a function provided by your platform (e.g. dlopen() or LoadLibrary()), and the libloading crate provides nice cross-platform bindings to these mechanisms. However these functions (deliberately) only work with libraries on disk.

Looking at this stackoverflow question it doesn't seem like there's an easy way to do this for native libraries without writing the library to a temporary file first or reimplementing your own version of ld.so.

I'm guessing the .NET runtime can provide Assembly.Load(Byte[]) because it's already got access to its own has dynamic linker and loader as part of being a JIT compiler.

Some other useful links:

My scenario is remote process DLL injection so loading from disk is annoying.

Alright, that's what I thought. I just wanted to check if someone already tried it in Rust.

Thanks for the detailed answer !

Ah yeah, I see what you mean. If you loaded from a temporary file then it'd be a pain to make sure it gets cleaned up properly.

How is this normally implemented? I know on Windows you'll typically create a new thread in the other process and tell it to call LoadLibrary(), but LoadLibrary() only works with files on disk as far as I'm aware.

It looks like .NET core has a NativeLibrary.Load() function for loading native libraries (i.e. not a managed assembly), but that only accepts a string.

If the library you're wanting to inject is already in memory (e.g. because it's running at the moment), it might be possible to map/copy the code section into the victim process's memory space and then run a well-known function. This will probably fail for anything non-trivial though, because all symbols in the code will have been resolved to system functions relative to the current process's memory space and not the victim's (i.e. MessageBox() from User32.dll may be at a different address, so trying to call it will probably segfault)... That may give you just enough that you can bootstrap the rest of the injection/attack though.

EDIT: Oh, it seems like this approach is already a thing. Apparently it's called Reflective DLL Injection.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.