MemoryModule and 64bit DLLs
Yay, I finally added experimental support for 64bit DLLs to MemoryModule! The code has moved to Github, so feel free to check it out and see if it works for your DLLs, too.
Yay, I finally added experimental support for 64bit DLLs to MemoryModule! The code has moved to Github, so feel free to check it out and see if it works for your DLLs, too.
nice, but it seems there is an error at line 245 of MemoryModule.c
LoadLibrary fails with NULL instead of INVALID_HANDLE_VALUE.
I need memorymodule.
Great, so feel free to download the source code from Github.
Hello Joachim. Your code is invaluable!
I am actually using it inside my application
and it works excellent with an exception.
I will try to go straight to the point and
be concise. One particular DLL library crashes
my application when I’m trying to load it from memory.
I have made an archive with a text document describing
the problem and the DLL. I am hoping you can investigate the problem.
Here’s the uploaded archive: http://www.megaupload.com/?d=1SWOVYW2
Note: the libraries are 32-bit modules and I’m using
Windows XP SP3 32-bit.
P.S.: I am sorry if posting twice bothers you, but this happes with a number of the DLLs I’m trying to
load and I’m hoping there’s a small trick I can’t get here and that solving it won’t take much of you’re time (I only know what I know from the MSDN documentation and from my C# experience, but I can see you’re a professional developer when it comes to windows os “insides”).
Thanks in advance, Zozel!
Hello Joachim.
I was wondering why did you delete all my posts?
Your comments have not been deleted, but for spam protection reasons, everything is moderated first and has to be manually approved.
Should be all visibly by now…
Hey. No problem, I understood as soon as I’ve seen them back.
I investigated the problem a bit more – about the _CRT_INIT function. Using OllyDebugger here’s what I found out: the _CRT_INIT function fails to return OK because at some point it calls the GetModuleFileNameW function. Calling this function it returns zero -> that’s the key! Using Olly Debugger I hooked immediately after this function, modified the EAX register (which holds its return value) from zero to one. And it worked like a charm! The problem is that now we’ve got 2 options:
we either hook the GetModuleFileNameW function so that, when it’s called with our module’s handle it returns a value different from zero, or we try to figure out how does LoadLibrary assign a file name to a specific handle – I’d choose option two, since it’s more “legal”. Here’s where I’m hoping you can help me or give me a hint: how does LoadLibrary “assign” a file name to the handle of the loaded module, making it “visible” to the GetModuleFileNameW function – the two functions work together, obviuosly. If we could find this out, I think the MemoryModule would be a one step closer to be complete!
The reason for the error is that the module that gets loaded by MemoryModule never gets inserted into the _LIST_ENTRY link list. This link list is used to store a PEB for each dll and .exe that gets loaded into memory. When you call GetModuleFileNameW, it ultimately has to refer to the double linked list to find the PEB that contains such information. No PEB, no file name to return.
Oh, haven’t noticed that I didn’t tell you about the CRT_INIT function on this page. It is my last post from http://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/
Thanks for the collaboration, Zozel!
You haven’t responded to any of my posts..
Please tell me if you don’t have the disposition to
respond to me or if you want me to stop “spamming”
the forum
Thanks, Zozel
Did u find a solution for your problem ? i am facing it
HI…
I was trying out your code. It works really fine.
EXCEPT: One is using SEH exceptions from GCC 4.8.
Here the application terminates as soon as an exception is raised using RaiseException() when the dll is loaded using memorymodule whereas it works fine when it is loaded using LoadLibrary().
Any clue what is going on here?
Thanks for your help,
Rolando