2

I'm working on a project that involves receiving a byte[] from a web page in a .net program, then loading that byte[] as a dll. However, the dll is not a .net assembly, it is a native assembly. I can't use loadlibrary because I would have to write to disk, and I want to keep the native dll in memory. I can't use c++ /cli, because this is all being done in mono, and mono doesn't support c++ /cli. Is there a library or project somewhere that allows me to load a native dll from a byte[], in c#? I've seen this tutorial: https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/, but this is c++.

user51990
  • 31
  • 1
  • 3

3 Answers3

0

This will help you, or lead you somewhere.

This is basically a wrapper for the project you have sent, I will keep the repo up for anyone who wishes to look at It. Untested on 32bit OS, so It might do an overhead.

https://github.com/dretax/DynamicDllLoader

It basically does what you want. Expects a native dll's byte array, and loads it into the current process.

DreTaX
  • 760
  • 2
  • 9
  • 22
-3

Just use Assembly.Load (if that's .Net assembly) https://msdn.microsoft.com/en-us/library/h538bck7(v=vs.110).aspx.

Otherwise, use PInvoke with unmanaged DLL's.

Dmitry Zvorygin
  • 473
  • 6
  • 14
  • 1
    "use PInvoke with unmanaged DLL's" does not provide enough information to even search for an answer, definitely not making this post a good, complete answer. – Alexei Levenkov Sep 22 '17 at 21:14
-3

I will give you a short rundown on where problems with that lie:

  • You are receiving a DLL from the internet. Every adminsitrator will wonder if he just got insane or that really stands in the "how it works" description. We had enough problems with remote code excecution and code injection on data arrays in the last century to know how this will fail without needing to try.
  • Anything in the design of the managed .NET Runtime is there so you can not do shit like that. You propably have to go to unamanged code. And at that point, you might as well write in native C++.
  • It might even trip over some run off the mill virus scanners heuristics just for trying to pull this. Because that is on the short list of things a visitor to my Operating System should never try to pull.

You really, really should just burry that idea and live without it. If you got a boss that wants this, say him it is between impossible and figuratively insane. Possibly even literally insane. Even if you could make it, no admin of sound mind would install it.

If that has not detered you: It might be best to move this into a helper process of some sort, then transmit data/results via Interprocess Communication. When calling old, umanaged, never-migrated-to-64-bit DLL's from a .NET Application, missmatching binarity is often a problem. A helper process (that always runs at x32 to match the DLL) can help with that. And once you got a helper process, it can be programming in something like Native C++ where these kinds of shenanigans are easier and you even go a example.

Christopher
  • 9,634
  • 2
  • 17
  • 31
  • There are legitimate reasons to do this. He asked for an answer not an opinion. – rollsch Nov 03 '19 at 20:27
  • You can also sign your code to ensure the dll is not manipulated. Pinn the cert and have both verify each other if you really want. – rollsch Nov 04 '19 at 08:34