Loading process from memory

I was wondering if it was possible? If it is, is this how you do it:

I was thinking, load the entire exe file into memory.. and call a function like CreateProcess to load it from memory and not from file

Code:

BYTE bData[/*sizeof(exe file)*/];

//get data from file into bData

CreateProcess(...bData, *FROM_MEMORY);

Ofcourse ive never done this before so im just making it up as i go along, the reason i want to do this is so that instead of releasing alot of EXE's, i cud pack them all into 1 exe and use a main program that basically extracts them from a DAT file or something and decrypts it and loads it from memory...

Anyway, im not even sure if thats how its supposed to be done..
Any help would be appreciated,

Thanks

Interesting. Are the independent processes something you developed or are they from a third-party? DLL is a more secured solution if you want to safeguard your code.

Check out MSDN.

http://msdn.microsoft.com/library/de..._reference.asp

Kuphryn

Its something i developed, i was just wondering though cause if i had to convert all the programs to DLL it would be take a lot longer.. so I just thought that this might work out.. ill check out the link and find out

also, what if i wanted the processes to be loaded as independant processes.. i dont think thats possible with DLLs? An example of what im trying to do would be the sample browser that comes with the Microsoft DirectX SDK.. although it just loads the EXE's using createprocess or shellexecute or something similar, and that leads to alot of files.. what im trying to do basically is make a sample browser... that runs off 1 exe and 1 dat file which contains all the other exes..

well a search on msdn for 'load process from memory' and 'create process from memory' got me nowhere.. only thing useful i found is:

http://msdn.microsoft.com/library/de...n_manamemo.asp

it seems interesting.. memory mapped files, from what little i read, its a way to read files through memory, or atleast thats what i understood, its probably not what im looking for though.

once again, any help is appreciated.

There is no API support for running an EXE from memory. Manually loading an exe and preparing it for execution is no trivial task (code is not for Windows), although I'm sure there are utilities and code out there that do it. The typical solution is to dump the image to a temporary file and run it from there.

Wouldnt dumping the image to a temp file be inefficient and slow? lets say the image file is.. 5 mb or so, on a slow computer, it could take a few minutes or so.. the reason i said that is because most of my friends have really umm.. antique computers. Besides, most of them dont even have any disk space to spare, its really surprising how they survive with less than 5gb...

And for the link you gave me.. wow, this is going to take a while, first i gotta understand it, then i gotta make it work on windows..

thanks for the help though

well so far it doesnt seem to be going well.. whats the equivalent for kernel.exe in windows? (XP/NT/2000).. im guessing its nt.dll?

in the meantime, does anybody have any other method? or can someone help me port the code that anonytmouse provided to Windows?

thanks again

[edit] i was wondering, if its such a hard task to perform, how do UPX and all those other file packers do it?

>>what if i wanted the processes to be loaded as independant processes..

>Wouldnt dumping the image to a temp file be inefficient and slow?

You could create a 'stub' exe that dynamicly(sp?) calls/links the DLL's (LoadLibrary() and GetProcAddress() ). Write the stub as a temp and get it to run the appropriate DLL.

what do you mean by DLLs? im trying to load processes.. (EXEs), converting all the EXEs to DLLs is just a waste of time.

All you have to do is tell the compiler that you are creating a DLL instead of an exe and cut and paste the code in.

ah.. i didnt know you could do that, so i should convert all the EXE's to DLLs.. and make the loader call the DLLs and that should run the EXE?

Try with one.

In the Stub make sure to include the LIB hte DLL produces. Then call LoadLibrary() (loads DLL) and then GetProcAddress() (creates a pointer to a function in DLL) and finally ReleaseLibrary()

To use a function (ThisFunctionFromDLL) from a DLL (ThisDLL) where the path is stored in sThis_Dll_Path.
Define a function 'type' to match the ThisFunctionFromDLL prototype

Code:

//if this is your function prototype
//int ThisFunctionFromDLL(HINSTANCE hWndParent, char* sWorkingDir, char* sText);
//use a type define like
typedef int (CALLBACK* FuncDefine)(HINSTANCE , char*, char*);
//declare function prototype
FuncDefine   ThisFunctionFromDLL;

//load lib
hThisDLLInst = LoadLibrary(sThis_Dll_Path);
if(hThisDLLInst)//loaded without error
{
	ThisDLLFunction = (FuncDefine) GetProcAddress(hThisDLLInst,"ThisFunctionFromDLL");// lock function down
//error check then use

}
//when finished clean up
FreeLibrary(hThisDLLInst); add error check

If your going to create .dlls then you may as well create .lib and .h files to go with them so they can be linked like any other dll avoiding the use of LoadLibrary/GetProcAddress.

An EXE in memory is not quite the same as the same exe on disk. For one the PE loader fills in the exe's import table with the addresses of dll functions it imports. Packers like UPX aren't creating a seperate process in memory, the stub unpacks the compressed areas and then jumps to where the origional start location was. I think the exe packer stub must fill in the import table too.

I wish you look with this.

I think ill try attempt to do it the same way UPX does it.. ill add all the EXE's to the main EXE (compressed ofcourse), then use the main EXE to extract the individual EXE's and decompress them then load them by jumping to their start location.. Im not sure if this would work, but i guess its worth a try.

Originally Posted by X PaYnE X

I was wondering if it was possible? If it is, is this how you do it:

Try boxedapp sdk from BoxedApp :: About . You create a "virtual" file, WriteFile() all data of your exe, then use WinExec. That's all.

Hope it helps.