ASM Community

Is it possible to run an executable from memory, is a question that has turned up several times on the board. With intent to find out if it is possible i have made a deep dive in the process of creating a process. The attachment is the result of creating a process from a file on the disk. Normaly you start it with kernel API CreateProcess. The code only works on win2K.

I have turned the code out and in and came to the conclusion that it is not possible to run an executable from memory. You have to use the nativ API NtCreateSection to map the file into memory and the only way to do that is via a disk file.

If someone has another opinion please tell me. Feel free to play about with the code to try to map from memory.

Best regards

Hi minor28, when I'm right you have to get rid from the PE-Format fist, bevor you can run it.
When the pure source leaded in the memory it might be possible let it run with the MP instruction. - Am I right ?

Greets

if you strip of the PE header then you wont know where the OEP is...

also you loose the memory rights to the program...

also you will loos where the date ,code and other sections are located...

so just for that you would have to record everything or store the header some where..


after that you have to adjust the import table and any other parts of the code that call jmp dword ptr...

which can be a pain...

what most people are looking for is a way to properly load the exe into memory so that it has its own heap and stack and so that it can be executed with out code modding..

oh and a side note... the memory access of a file on xp can befully write able and execute able with out messing up the program but on win 9x you are not allowed to in all areas...

this is true because i made a WriteProcessMemory Replacement and i originally got the file size and unprotected the whole exe in memory... xp had no problems but win 98 se did..

well the theory would be (not sure this would be as easy for an exe but should work for a dll)...

virtualalloc memory block of the size of the image (from the pe header)
build up the image in the virtualalloc mem block from the section information
find the iat, and fill the imports, use the .reloc information in the dll to rebase
the image you have now loaded in memory patching the va's it lists with the base
adjustment (using the virtualalloc mem block start as the base), that should
in theory work, the only downside is that possibly loading resources mightnt work
but code should... also remember to virtualprotect the sections (after doing all the work above) to the states specified in the section info from the pe header, then
call the entrypoint with the 3 parameters typical for dll_process_attach... for an
exe its slightly trickier but im sure its doable, regardless of the system being 9x or 2k/xp/nt, and i really dont think you'd have to use ring 0 for it either, if the system can do it, why cant you? ;).. again, for an exe it'd require a different strategy

might try and do some code for it later on after i've finished my current project

I have tryed virtual allocated memory and global allocated memory with the expanded image. Not working. The nearest I have come is the attached example (this has been on the board this summer)

The dialog.exe reside as as rcdata resource in the EXERES app. From loaded resource the dialog image is expanded into a global allocated memory. EXERES then pushes the parameters for WriteProcessMemory and pushes the returnaddress to the entrypoint of the dialog.exe. Next a jump to kernel function WriteProcessMemory. The function replaces the EXERES code in process memory with the dialog.exe code. The return goes to entrypoint of dialog.exe. The dialog.exe starts executing but the dialog never shows up. I suppose the exe is not properly registrated. You can't fool windows.

I think I have tryed the most. You can't run an exe from memory. If someone has another opinion then prove it.

Best regards

this has all been discussed before, more than one time.

As ancev says, as long as the exe doesn't have resources (and a couple things that are not so standard), it's pretty easy to execute a PE yourself - but it will not appear as a new process and there's all sorts of catches.

If you find a non-dirty/ring0 (use of NT Native API accepted, though) way to more properly run a piece of code from memory (ie, create a new process), don't hesitate to post info =)

minor28,

take a look in elicz site... maybe you can discover how create a process taking a look in how he create remote thread

ancev

"dirty" means that it's not reliable, in other words that it could be changed by Microsoft in any patch. So non-dirty means using only official API's and semi-official API's like the NT native API (Microsoft can't change this because some programs by other people depend on them).

Hi minor28

> ObOpenObjectByName to ObOpenObjectByPointer.
>5. Calling ntoskrn.exe!ObOpenObjectByPointer
>The return value is STATUS_OBJECT_TYPE_MISMATCH.

I'm not sure but the problem here might be one that occurs when dealing with several kernel functions which require a pointer to an OBJECT (be it thread, event, mutex...), rather than a HANDLE, which is what is generally returned with several other kernel functions that actually *create* the thread, event, mutex...

To convert the Handle to a Object you need to call ObReferenceObjectByHandle.
ObReferenceObjectByHandle increments the reference count of the object, so requires ObDereferenceObject to lower it's reference count when finished with it.

I'm not sure about your ObOpenObjectByName, but it may also return a handle, and ObOpenObjectByPointer requires an object pointer I believe.


I've had to do this for both Events and Threads. For example, a convenient way of synchronizing communication between a user app and driver thread (remote or otherwise) is to use a Named Event using IoCreateNotificationEvent. This function returns an event HANDLE, but to use the event in other functions you need to convert it to a direct OBJECT pointer with ObReferenceObjectByHandle first. i.e.

[size=12]

invoke RtlInitUnicodeString, offset pUNICODE_STRING, offset EventName

invoke IoCreateNotificationEvent, offset pUNICODE_STRING, offset EventHandle

invoke ObReferenceObjectByHandle, [EventHandle], EVENT_ALL_ACCESS,\

                  NULL, KernelMode, offset pEventObject, NULL



; we've converted an EventHandle to an EventObject,

; now it can be used in other functions...



; (if you don't need the handle you can delete it since we

; have a pointer to the actual object structure now)

; invoke ZwClose, [EventHandle]    ; (will call ObDereferenceObject)



; IoCreateNotificationEvent creates an event in the signalled state,

; set it to unsignalled

invoke KeInitializeEvent, [pEventObject], NotificationEvent, FALSE



;...



; elsewhere we can wait for the Event to be signalled from user

; mode with OpenEvent / SetEvent...

; (note that driver created named events must be placed in the

; system directory \BaseNamedObjects\<eventname>  to match

; any User event name (automatically placed in that directory))





;...in a PsCreateSystemThread created thread far, far away...

invoke KeReadStateEvent, _pEventObject ; returns 0 = non-signalled



; Wait indefinitely for User mode to wake up this thread by

; signalling event...

invoke KeWaitForSingleObject, _pEventObject, Executive, \

                                          KernelMode, TRUE, NULL



; after returning, event is in signalled state 

invoke KeReadStateEvent, _pEventObject ; returns 1 = signalled



;...



invoke ObDereferenceObject, _pEventObject



;(PsTerminateSystemThread required if thread created

; in system context) 

[/SIZE] 

You might also go through the same process with threads of converting a thread handle to a thread object pointer if you wanted to use a function such as KeSetPriorityThread for example.


DO make sure you call ObDereferenceObject wherever necessary to avoid memory leaks. The system *might* clean up for you but I've had some slow lockups while developing that might be tied to this. I believe ObDereferenceObject returns the current reference count, but I haven't been able to see it de-reference down to '0', the current reference count in various places in my code seems higher than I would have expected by any associated calls to ObReferenceObjectByHandle or prior creation calls.

As a side-bar to this, there is an undocumented function called ObGetObjectPointerCount that also returns the current reference count on an object (matches that returned by ObDereferenceObject). However, I could not directly Invoke the function ObGetObjectPointerCount and had to call its address directly by using MmGetSystemRoutineAddress first.

Good luck with this, it will be interesting to see the results.

Regards,
Kayaker

Hi

There does seem to be some confusion with the definition of ObOpenObjectByPointer. This may help, it is defined as the following in
Building NT File System Drivers, A Developer's Guide, O'Reilly. Rajeev Nagar

[size=12]

In the description of the ZwCreateSection() routine, I mentioned the existence

of an Object Manager routine that can be used to obtain a handle to an object

in the context of any arbitrary process, given a pointer to that object.

This routine is called ObOpenObjectByPointer() and is defined as follows:



NTSTATUS

ObOpenObjectByPointer(

IN PVOID Object,

IN ULONG HandleAttributes,

IN PACCESS_STATE PassedAccessState OPTIONAL,

IN ACCESS_MASK DesiredAccess OPTIONAL,

IN POBJECT_TYPE ObjectType OPTIONAL,

IN KPROCESSOR_MODE AccessMode,

OUT PHANDLE Handle

) ;



Typically, you can pass in NULL for PassedAccessState and for

the ObjectType. Be careful to request only the type of access in

the DesiredAccess argument permitted by the original open operation

(from which you obtained a pointer to the object). The HandleAttributes

can be obtained from the previous invocation to

ObReferenceObjectByHandle(). That routine returns Handlelnformation,

which in turn contains the returned Handle-Attributes.



There is also a routine called ObReferenceObjectByPointer(),

which simply increments the object reference count for the

specified object. This function is defined in the Windows NT IPS kit

as follows:



NTSTATUS

ObReferenceObjectByPointer(

IN PVOID Object,

IN ACCESS_MASK DesiredAccess OPTIONAL,

IN POBJECT_TYPE ObjectType OPTIONAL,

IN KPROCESSOR_MODE AccessMode, };

[/size]

I might be off base here but one thing I noticed with your code, if I'm reading it right, is about using the pMem location of the MZ header (this is a pointer to SECTION_OBJECT_POINTERS I believe?) in a Locally declared FILE_OBJECT structure as opposed to a Global one. From this you generate a FileHandle by using either ObOpenObjectByName or ObOpenObjectByPointer which is used back in usermode by NtCreateSection, then immediately deleted. The FileHandle identifies the file from which to create the section object (the executable image).

Since memory locations of LOCAL variables can be overwritten once out of the proc, even if this is in kernel mode, it seems to me the Section object defined by the FILE_OBJECT structure (and which the FileHandle refers to), may be invalid, both in permanency and perhaps in context. Handles can come and go, but I would think the underlying object must be a permanent structure for its lifetime.

If you are running your created section image from disk (the successful part), is the FileHandle actually necessary with NtCreateSection?, or does it simply act as if the FileHandle is zero (as defined) - the VMM creates a section object backed by the paging file (piece of shared memory) rather than by a named file in the file system.

Cheers,
Kayaker