10

Can I load a library from a memory stream? For example my library is encoded a file. I check some conditions and decrypt the file into a memory stream. Now I need to load the decrypted library from that stream into my application and use its functions etc.

Angew is no longer proud of SO
  • 167,307
  • 17
  • 350
  • 455
Andrey Bushman
  • 11,712
  • 17
  • 87
  • 182
  • 1
    Found this for OSX : http://stackoverflow.com/questions/11821955/load-dynamic-library-from-memory and this for windows : http://stackoverflow.com/questions/638277/loading-dll-from-a-location-in-memory – koopajah Aug 20 '13 at 10:21
  • I need the solution for the Windows and Linux. – Andrey Bushman Aug 20 '13 at 10:22

1 Answers1

6

In windows, A DLL can only be loaded from a file - as the links suggested, you can create a ramdisk and install that as a drive, but there is no way around the DLL needing to be loading through an file that exists in a filesystem. Part of the reason for this is that the DLL is "demand loaded", that is the system does not load the entire file into memory at once, it loads the parts that are actually being used, 4KB (typically) at a time. It is also not swapped out to the swap area, it is just discarded and re-loaded from the DLL if the system is running short of memory.

Linux works in a very similar way (I know it uses the same kind of demand-loading by default, but not sure if there is a way around it), so I don't believe there is any other way there either, but I haven't looked into it at depth.

Of course, if all you want is a piece of code that you can use in your application, and you want to store that as encrypted/compressed/whatever in your exectuable file, what you can do is allocate some executable memory (in Windows, you can use VirtualAlloc to allocate executable memory). However, you need to ensure that you relocate any absolute memory addresses in your code if you do that, so you will need to store the relocation information in your executable.

Clearly, the easy solution is to unpack your content into a file in the filesystem, and load from there.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • 1
    See https://github.com/fancycode/MemoryModule for an arguably better solution than ramdisk (if there is a "good" or "better" solution at all, I don't think it's a good idea to try from the start). – Damon Aug 20 '13 at 10:40
  • @Damon: That is doing what I describe in the third paragraph, from what I can tell (I didn't got through ALL of the code in detail). – Mats Petersson Aug 20 '13 at 12:11
  • @MatsPeterson: Yes, it's exactly what it does. It's a working implementation (I tried it some years ago) and slightly better than the "ramdisk" approach for what the OP wants (since you could just read the non-encrypted file from the ramdisk anyway). Though of course, I still don't deem it a good idea to tamper with that stuff to begin with, as it seriously interferes with VM management and it somewhat contradicts the concept of a shared library, too. The point in having DLLs being file based is that you can map the same pages to several processes, throw them away, and reload on demand. – Damon Aug 20 '13 at 12:32
  • Indeed. Any almost anyone with at least a little bit of skill in reverse engineering would be able to figure it out anyway! ;) – Mats Petersson Aug 20 '13 at 12:34