Re: Loading a DLL from memory
Tim Robinson
> I am trying to call LoadLibrary from a file that is in memory. I
> know the easy way would be to save the file to disk and then call
> LoadLibrary on the filename but my application specifically requires
> the file not to touch the disk.
>
> I have been experimenting with rewriting the ldrLoadLibrary call but
> it seems like this would either take really long to do or frankly be
> impossible. I was wondering if anyone else has done this before or
> might have some pointers to give me.
You really, *really* should save the file to disk. It's much easier than the
alternatives, and guaranteed to work, always (assuming your app can access
somewhere on disk).
Without disk access, you're entirely on your own.
The official Microsoft PE/COFF reference:
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
Recent Matt Pietrek articles about PE/COFF:
http://msdn.microsoft.com/msdnmag/issues/02/02/PE/default.aspx
http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/default.aspx
Inside the Windows 2000 PE loader:
http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx
Old Pietrek article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndebug/html/msdn_peeringpe.asp
--
Tim Robinson (MVP, Windows SDK)
http://mobius.sourceforge.net/
Raj
LoadLibrary() internally calling these system calls
NtOpenFile,NtCreateSection,NtCloseFile.
The section object will be passed to the other APIs. We can replace this behaviour. Right now i am writing an article. I hope soon i can come up source code.
- &Raj.
"Yog" wrote:
> Hi,
> I am trying to call LoadLibrary from a file that is in memory. I know the easy way would be to save the file to disk and then call LoadLibrary on the filename but my application specifically requires the file not to touch the disk.
>
> I have been experimenting with rewriting the ldrLoadLibrary call but it seems like this would either take really long to do or frankly be impossible. I was wondering if anyone else has done this before or might have some pointers to give me.
>
> Thanks in advance.
Alex the 1'th
"Raj" <R...@discussions.microsoft.com> wrote in message
news:4D637EC7-991F-4EB3...@microsoft.com...
>
> LoadLibrary() internally calling these system calls
> NtOpenFile,NtCreateSection,NtCloseFile.
>
> The section object will be passed to the other APIs. We can replace this
behaviour. Right now i am writing an article. I hope soon i can come up
source code.
Don't you think it's better to re-write LoadLibrary then to use some
undocumented api? Especally since it's not THAT difficult or impossible.
Raj
What i mean to say is same. While re-writing LoadLibrary,we need to replace NtOpenFilem,NtReadFile... & need to manage with section object.
- &Raj.
>
>
>
Tim Robinson
> What i mean to say is same. While re-writing LoadLibrary,we need to
> replace NtOpenFilem,NtReadFile... & need to manage with section
> object.
NtOpenFile -> CreateFile
NtReadFile -> ReadFile
NtClose -> CloseHandle
section object -> file mapping object
CreateFileMapping supports the SEC_IMAGE flag, so you could implement
LoadLibrary like:
HANDLE file = CreateFile(name_of_dll);
HANDLE mapping = CreateFileMapping(file, NULL, SEC_IMAGE, 0, 0);
HMODULE module = (HMODULE) MapViewOfFile(mapping, 0, 0, 0, 0);
I guess that this is what LoadLibrary is doing internally, except using the
equivalent NTDLL calls. You're still limited to creating a file mapping
backed by an on-disk file.
Guaranteed solution: Read up on the PE format and implement your own loader.
Or be willing to accept that you'll have to put the DLL on disk.