Hi all
I want to know how we can make a process from a buffer in memory except a normal executable PE?
Remember that in this question,I don't want to write my own loader,and I need to use system loader and force it to use a buffer except a normal PE file(with some ways like hooking,memory mapping,...).

Is there anyway to do this?or do you every seen any article for this problem?

Regards

Hero, could you elaborate a little on what you mean by saying except a normal executable PE? Do you mean instead of ?

A convoluted solution that comes to my mind is to have the Father process create a small virtual disk in RAM (Plenty of open source projects and small programs with available code can be found around), move your buffer executable there, which needless to say has to have a valid PE structure for disk, then spawn the process with regular Windows API as if it were read from a disk.

Just curious, why do you want to do this?

virtual disk in ram is probably well out of his league or even the league of most reversers
virtual disk will also most likely require drivers.....

oops, awfull english...
I was suppose to use instead of....
And as evlncrn8 said,I think making virtual disk on ram should need driver,Then i prefer not use ways like this.

For more details,i draw this:

------------------
PE1-the loader program
------------------
section1:a FULL PE
------------------

if loader program need to run the attached programin section1,it normally needs to create a file on disk and copy content of this section to that file and run it use CreateProcess,or try writing full PE loader that can be buggus.
I wana find a way to run this attached full PE,without need to transfer to disk using system loader(or CreateProcess API).

Regards

I am just babbling here, but it seems to me that you need to emulate or hook CreateProcess API making it read your memory buffer instead of virtual or real device or stream.

In this site and the references there-in:

http://www.programmersheaven.com/2/Cluster-Computing-Virtualization-in-Windows

They give a cursory description of the native (Zw) APIs that CreateProcess uses to perform such feats.


On a different thought, your diagram is almost identical to what a typical PE unpacker/decryptor does: The actual PE is loaded as a section(s) inside the original PE1 loader, it is decrypted in memory, the Import table and other goodies are setup on the flight by the stub, then starts the "Made In Virtual Memory" copy of the PE by jumping to the OEP. The difference is no new process is started.

Is it mandatory that a new process, besides the loader, be started??

But the question still remains, in the great scheme of things, what is the problem of writing, even transiently, your PE file in disk?

Given the intricacies of virtual memory, you know that, in one way or another, parts or the whole of the PE contents are going to be written to the disk, into the paging file. . .

Thanks for info...
But there is a special benefit if you could force loader to load this portion of memory, it means there is no need to make deferent codes for deferent architectures.
For example if the attached file is a normal exe file or a .NET file,the loader that is needed for executing both of these codes will be same.
And the reason for don't writing on hard disk... I should say I only don't like copying a section of my executable file on disk... There is no special reason,but I only want to force create process to use my buffer rather than a normal PE in hard disk.

Regards

Here's the approximate source for CreateProcessW(...) -- http://www.reactos.org/generated/doxygen/d4/dbe/dll_2win32_2kernel32_2process_2create_8c.html#a10
It begins by trying to open the target PE file and then calling BaseMapFile(...) (line 963). You can just continue from there since you already have the file mapped into memory.

I hope your "buffer" don't call any windows' api.

Wouldn't be simpler to spawn yourself in a suspended state, and fix such image before windows loader do its job? No additional image, only few, fixed bytes to change (which you could determine at runtime too).
Doing what you ask without passing by Windows is hard, as you cannot create the virtual memory space of the process by yourself.
Historically speaking, that was possible at dos times, becasu you were able to attach the DOS version and the Windows version within the same file -whenever executed on DOS -it were running on ODS, executed on Windows -it ran the Winversion...

My buffer is a full PE file(from MZ signature to end of file,that can be contain IT,fix-ups,and everything else.) that is embedded into another file.

sorry,But i didn't get what you mean from here.you mean that my application create another suspended process from itself,then somehow change the loaded image to point to that buffer?

Regards

Btw inside Windows Internals (4th edition) at page 300 you can get all the info you want.

I stayed out of the discussion because I wanted to see how contrived your solutions would be

What OP wants is a packer that... doesn't pack.

All the loader has to do is resolve imports and call to OEP.

If you want this to be a second process, CreateProcess() on the "packed" (not really) file.

Also OP don't like copying a section of his/her executable file to disk, but in his/her diagram you have the full executable after loader stub.