Loading and running EXEs and DLLs from memory

[Vortex]

Hi friends,

Based on Chetnik's code to run EXEs from memory, I coded a small static library named PEmem.lib extending Chetnik's method to load and call functions from DLLs embedded to the main application. This means that you can use DLLs like static libraries. Eliminating the dumping of DLLs to HDD, I think this method could be an insteresting one to use decompressing modules ( DLLs ) embedded to the main executable.

Here are the functions :

LoadEXEfromMem PROC pEXE:DWORD

This functions loads a  PE / DLL from memory and does all the initializing procedures

   pEXE   :   pointer to the PE or DLL in memory

Return values :
   
   eax   :   entry point of the "virtual" PE / DLL

   edx   :   pointer to the PE / DLL loaded to the allocated memory
         eax holds a handle to the "virtual" PE / DLL

GetProcAddr PROC hModule:DWORD,func:DWORD

This function gets the adress of a function from a "virtual" DLL

   hModule   :   handle to the "virtual" DLL
         edx holds this value after a call to LoadEXEfromMem

Return values :

   eax   :   address of the "virtual" DLL's exported function "func"

You will find two demos in the attachment, one for running EXE from memory, the other one calling function from an embedded DLL

I used Hutch's fda.exe to embed to EXE and DLL to the main executables. ( Many thanks Hutch for your nice tool :U )

Many thanks to Chetnik for his pemem demo inspiring  me to code this library :U

If you have the time, could you test the two demos PEmem.exe and DLLmem.exe ? ( Please specify also your operation system )

[attachment deleted by admin]

[Ghirai]

Great job  :U

Works fine on XP Pro SP2.

[Vortex]

Following f0dder's suggestions , I modified LoadEXEfromMem and I added a function to release the allocated memory :

LoadEXEfromMem PROC pEXE:DWORD,pModule:DWORD

This functions loads a  PE / DLL from memory and does all the initializing procedures

   pEXE   :   pointer to the PE or DLL in memory
   pModule   :   pointer to module value, block of memory allocated to initializethe embedded PE / DLL

Return values :
   
   eax   :   entry point of the "virtual" PE / DLL

FreeEXEfromMem PROC hModule:DWORD

   hModule   :   pointer to the PE / DLL loaded to the allocated memory

Basically FreeEXEfromMem does the job of the VirtualFree function.

[attachment deleted by admin]

[JMGK]

hi vortex,

if i use your routines to load, lets say, calc.exe, it will work?

do you handle resources and like?

jmgk

[Vortex]

Hi JMGK,

Welcome to the forum.

According to my test results, this method doesn't allow executables with resource sections. You should use resource templates instead of the conventional resource files ( .rc )

[Vortex]

Here is the second version. This time, I tried to maintain the library code to make it more readable. Preserving Chetnik's methode, I merged some portions of the the source code to make one compact module, the new version of LoadEXEfromMem

[attachment deleted by admin]

[Vortex]

My apologies for members who downloaded the second version of the library. LoadEXEfromMem didn't preserve esi,edi and ebx, I fixed it. New upload above.

[ragdog]

hi vortex

i wil use your dll from mem

can your help me my program works not

greets

ragdog

[attachment deleted by admin]

[Vortex]

Ragdog,

Here is the problem :

Code Select Expand

%resname%.obj

This is the resource converted to MS COFF object module with cvtres.exe

I mentioned in this topic that the EXE\DLL from memory method does not support resources. Instead, you should use Hutch's fda.exe or my bin2coff tool to convert binary data to MS COFF. To handle resouces, you must to convert them to binary resource templates. Have a look at the PE example coming with my example project PEmemLIB20.zip, it explains how to do it.

[ic2]

I just finish testing  it on ALL Windows OS with and with-out Service Packs with the exception of Window 2000 and NT which i don't own and it works perfectly an all of them.  Machine type P2, P3, 400-800mhz and AMD 1000mhz

Could you post some comments about the Pro and Con of Loading from Memory.

My guest is the Window Loader is not used at all and only the processor and ram are affected because the program use allocated memory to connect with the physical   memory to load the program.  Is this right.  Also when do windows come in other than api being called  and realized something new is running on the system.  My guest is it just start doing it job as an any operating system is suppose to do.  I am only guessing.  I'm usually wrong even when it seem to make since to me then find out other-wise years latter.  Hope others will shed some light about this.  I refuse to dream thought again.

Anyway Great work!!!

Vortex, you also just made learning about the PE format a thousand times so much easier.  You done did it AGAIN...

[Vortex]

Hi ic2,

Many thanks for yout testings. Much appreciated.

The advantages of this method :

- Creating SFX archives expanding themselves in memory.

- Packing DLLs like UnRAR.dll This should be interesting to code installers distributed with only one executable.

- Encryption \ protection of the child application. Loading from memory is probably not the best method for this task but it should work.

The disadvantages :

- DLLs have a relocation section by default but PEs to be executed from memory should strictly have a relocation section so the loading from memory method does not work with executables coming without source code. Linking the object files to build the child applications with the /FIXED:NO switch is mandatory.

- No ordinary resources. Executables with resources cannot be run from memory. This method does not support resources but there is no  problem with binary resource templates. You can easily use those templates to handle resouces in the child applications.

- The GetProcAddr routine to handle API functions is slow and simple. Depending on the API function(s) imported by the child image, the procedure can search the whole export section of a DLL.  This procedure should be replaced with another version using the binary search method to locate the API functions.

As you mentioned, the windows loader is not used. Depending on the size of child executable, only a portion of the memory is consumed to run the exe \ DLL

This method simulates one of the tasks of the OS, the windows loader. Naturally, my loader is a modest attemp as the relocation job and the initialization of resources is handled properly by the original OS loader.

Once again, many thanks for your support. You are always welcome to post your suggestions \ ideas.

[ragdog]

Hi Vortex

I use your PEmem successfully in other projects but it works not with a compiled Borland Delphi dll :(


greets

[Vortex]

Hi ragdog,

It should work with other tools like Delphi but you need to be careful with the calling conventions which is the most sensitive element for your task. Do you call correctly the PEmem functions from your DLL?

[ragdog]

I can use your lib with 2 ways

1.way convert a dll do hex with bin2db this works fine
2.with convert to obj like your example

by two ways have i this error

i have make a test only with LoadLibary and Getprocadress and it works fine
Now have i convert it to hex or Obj this dll and it Crash it


I use your lib allready in other projects but only with this borland dll crash it your Procedur LoadEXEfromMem

greets

[Vortex]

Hi ragdog,

Be sure that your EXE or DLL does not to have a resource section. It may be the case that my PE loader cannot handle properly your DLL. I am not a Delphi coder and it's not easy to make a comment without a detailed testing of your case.