Loading a DLL without LoadLibrary

[Kensho]

Hi all, long time no see

Ok, today I've got an advanced question... It's about DLL's, or PE files... everyone knows how to load a DLL... just call LoadLibrary (or dlopen in unix), and that's it... Well... I need something different. The thing is, I don't have the dll on the disk, or at least, alone... I have it on a chunk that I load up to the memory. So, what I need, is to load one DLL directly from a memory chunk... in other words, write my own LoadLibrary...

I theory, this is one of the solutions:

1 Allocate a big enough virtual memory block, preferably at the preferred address of the DLL.
2 Unpack the DLL into the memory, according to section alignment. Patch relocation if relocated.
3 Load new DLLs needed by the DLL
4 Patch DLL's import table.
5 Call DLL's entry point.

Well... this is a very standard theory... from this point forward, I need more details... Can anyone help me out?

Thanks in advance...

[Kensho]

Hmm no one? ???

[Tim]

Why can't you dump the DLL to disk and call LoadLibrary? It's much easier. The only alternative is to write your own full PE loader, which isn't fun.

[Kensho]

Yes, that is the esiest way to do the stuff, BUT, there's always a but I can't... Imagine that you have lots of modules, with 3 or 4 Megs each... not that fun... I don't think that is a very clean way... Other solution, would be to have a RAMdisk, but that isn't that easy to implement... Even another solution, but too crazy for my taste, would be to inject the API calls, and intercept some... too dirty... so, the solution is, indeed, my own PE loader... loadlibrary, dlopen, or whatever... I know the theory, but need more details... and more, I do not intend to use this only under win32, but also under my own OS, to mantain some "compatibility"...

Anyway, thanks for the reply

[Tim]

Seriously, what's wrong with putting the DLL on disk?

Code: Select all

GetTempFileName(filename);
write_module_to_file(filename);
hinstance = LoadLibrary(filename);

[Kensho]

It would be no problem, if we were talking about a few modules, but I have something that will be needing to load lot's of modules... and big ones... writting them to temp files all the time wouldn't be very clean... besides, like I said, I don't want something win32 dependant, but completely aside. I wan't compatibility, not dependency...

[Tim]

1. Any solution using LoadLibrary is Win32-dependant.

2. Writing your own PE loader is possible, but will take time and introduct bugs. Why bother when you can wrap LoadLibrary with a portable interface?

3. Don't worry about writing to disk. When you call WriteFile, you're not actually writing to disk but doing an elaborate memcpy into the system cache. The contents of the DLLs need not make it to the disk itself.

[Kensho]

...let me put it this way.... from the environment I'm running, I have no kernel32.dll, so, I have no LoadLibrary... I REALLY need my own way to load PE files. About writting to a temp file, WriteFile DOES write to disk, even if we're talking about temporary files (I tried it)... even though the filesystem tries to use the cache, he will eventually flush it to the disk; besides, like I said before, I have no WIN32 API available. :-\

[Tim]

So you're writing your own OS? It looks like you've decided on writing your own PE loader anyway.

If you're on Windows, you should use LoadLibrary unless you've got some very good reasons not to. If you want to load a PE file on your own OS, then you do need to write a PE loader. But you knew that already...?

[Kensho]

Well... it's like this; I have two places were I want to use this... one is a sort of VM under win32, the other is my own OS, and yes, this is the most important thing. But I would like to find some way to use the same strategy on both sides. Can you tell me where I can find more info about writting my own PE loader then? I know I'm being a bit of a pain in the @$$, and probably didn't explain myself correctly, but my question is still the same from the first post.

Thanks for the replies...

[Tim]

There are a few PE references at http://www.wotsit.org/. Also, do a Google search on "peering PE" for some tutorials.

I wrote a PE loader in Mobius, so if you grab the source, look in coreos/kernel/mod_pe.c.

[Kensho]

Thanks for the help; I've looked at the source of the Mobius kernel.. guess it won't be easy to make something that can be used on both... maybe not worthwile, I need to study this a bit more. Anyway, now I have something to study from

Thanks [[ ]]

[Tim]

For what it's worth, I got the Mobius PE code working unmodified on Win32. I had to replace the Mobius memory management functions with their Win32 equivalents (including a mocked-up page fault handler), but I didn't need to modify mod_pe.c. Great for debugging.

[Kensho]

Hmm, I've tried to implement some of the code explained on the Mobius kernel, but I'm having some problems on the win32 implementation part... I think it must be related to memory alignment. Here's what happens...

1. When calling a function that returns an int, all goes well
2. When calling a function that returns a char *, it goes wrong!
3. If I do a LoadLibrary behind it, and still call the function directly from memory, it goes well

I haven't handled the imports yet, may it be related to it? If not, probably the memory alignment, but I don't know how to... I'm using VirtualAlloc to allocate memory, but I'm not very confident on it. Something's missing?

[Tim]

I don't think the return type is the problem. On x86, the code to call an int function is the same as that to call a char* function.