Click here to Skip to main content
13,045,285 members (57,085 online)
Rate this:
Please Sign up or sign in to vote.
How can a x64 compatible application launch a process from memory (for example, loading this process data from a resource), with no existence of any executable (not even a "stub" one)?
Posted 7-Mar-13 3:19am
Eugen Podsypalnikov 7-Mar-13 9:28am
Hm... why not just the using of a temp file from a temp directory ? :)
Michael Haephrati 7-Mar-13 13:44pm
A 100% virtual file system requires no temp files.
Hm. Really interesting question, my 5.
Michael Haephrati 7-Mar-13 14:41pm
Thanks. I try to ask questions that I really can't find an answer for, but believe there should be an answer to...
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

It looks like you can launch a process from memory, but it's not easy at all.

First of all, I actually already started to explain how x86, x86-64 and Itanium hardware protection can protect population of memory the way it can be executed of code, but later realized that OS should provide a backdoor for such things.
(I don't want to discuss such detail as starting a new child process; the whole topic is so difficult that let's limit our discussions by the problem of putting some code in memory in a custom way, in particular, from some data stored in memory, in other words, without calling CreateProcessEx, and — most difficult part! — actually executing the loaded code.)

This hardware protection in the CPU protected mode is a very interesting and big topic. For some basic information, please see:[^],[^].

At the same time, there is such thing as the OS loaded working when CreateProcessEx is called. The contradiction is actually resolved in the following way: these CPU have 4 protection rings:[^].
Windows uses only two rings (0 and 3) and forms so called kernel mode in the ring 0, and user mode in ring 3.

The population of memory marked as executable is only possible in kernel mode. Not only data execution is prevented, but also modification of executable memory pages is prevented. The kernel mode part of the loader writes in memory (translating relative addresses stored in PE files and doing a lot of other things). The method I'm familiar with is making an alias memory descriptor with read-write access pointing to the same physical memory, writing code as data, and them removing all the alias descriptors. One or another way, this is possible, and possible only in the kernel mode. When something invokes the loaded (which can be started from the Shell or by explicit call to CreateProcessEx), eventually the kernel-mode code described above is also invoked through the mechanism described here:[^].

However, Windows leave the user-mode backdoor to making executable pages of memory, so the code can actually be executed as data execution prevention won't affect those executable pages. I realized it when I remembered about the operation of .NET and especially Mono (importantly, 3rd-party) JIT-compilers:[^].

Indeed, just look at the Virtual Memory Windows API:

First of all, you can allocate or commit a region of pages in virtual address space with VirtualAlloc, VirtualAllocEx:[^],[^].

Now, here is the key point: you can change the access protection of the allocated memory with VirtualProtect or VirtualProtectEx:[^],[^].

Pat attention that you can first give a write access to memory, and later give it execution rights, again, in order to avoid data execution protection:[^].

See also:[^],[^].

For the whole topic, start here:[^].

As I say, the problem is really difficult but looks solvable. I could only provide a top-level overview and considerations.

Now, in practice, I cannot imagine that you really want to dig into this. Your question is interesting, but it lacks the explanation of your ultimate goals. I really doubt they require anything that fundamental. In practice, you should not really try to execute anything from memory you populate from your code, unless you are trying to create something really fundamental. If you want it, we can discuss it if you explain your real goals.

Michael Haephrati 8-Mar-13 4:18am
Thanks for your top level coverage of the question and possible solutions.
My ultimate goals? Well, there are products that aim to create a temporary virtual environment, isolated and protected. For example, see: and I was looking for a way to run an executable from memory and noticed that BoxedApp, for example, uses a "stub" process, which is a real file, to which the real contents of the memory to be run, is copied into. The process is created but suspended. Then the memory is replaced and finally the process starts. I was wondering if that is possible without such "stub" process, i.e. without any real executable (even not a fake one). There are working example of implementing such, but these work only on x86 (Win32) environment and not on x64 ones.
See: . Some of the good examples of such questions can be only found at, etc. and not in MSDN.
By the way, regarding the discussion about DLLs and executables, you are right about the fact that these are both PEs, and are the same. The difference is the entry point. In the source code level there is very little difference and you can take the source code of an executable and easily compile and build it as a DLL and vice versa. In fact, the purpose of creating DLLs is to make certain functionality available to other applications via interfacing with it.
Michael Haephrati 8-Mar-13 5:19am
Sergey, how about this solution?
Did you try it? It's not clear what kind of image it expects, so I don't know yet how to even test it. I'll take a look, thank you for sharing...
Michael Haephrati 8-Mar-13 11:34am
In the example, it looks like the image is loaded form a EXE file... It would have been better proof of concept if the image was loaded from an internal resource. I guess it will not compile with a x64 environment, because the _CONTEXT data structure is different between x86 and x64.
I'm not sure it's loaded from EXE file, but maybe. Will you try? You can use x86 as it is supported on 64-bit systems via WoW64. Of course you host application should be compiled to x86 target. It's not a great difference, 64- vs 32-bit systems, it's rather the matter of the principle...
Michael Haephrati 8-Mar-13 12:11pm
Honestly I haven't tried yet. I'll let you know. I am quite sure WoW64 won't work, same as it is required to create separate versions for NT services, drivers, etc.
I'll try something like that:

bool RunFromResource(int iResource,char* pResourceSection)
HRSRC hResInfo;
LPVOID lpMemory;
long int lSize;
HMODULE hModule;
bool bReturn;
hModule = GetModuleHandle(0);
bReturn = false;
return bReturn;
hResInfo = FindResourceA(hModule, MAKEINTRESOURCEA(iResource), pResourceSection);
return bReturn;
hResData = LoadResource(hModule, hResInfo);
return bReturn;
lpRes = LockResource(hResData);
return bReturn;
lSize = SizeofResource(hModule, hResInfo);
lpMemory = new LPVOID[lSize];
memcpy (lpMemory, lpRes, lSize);

// Here should come the call to the "run process from memory" routine

delete [] lpMemory;
return bReturn;

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

You can use the LoadLibraryEx function[^], although I do not think that will work from managed (e.g. C#) code.
Michael Haephrati 7-Mar-13 11:52am
I am not interested in c#, but nevertheless, to the best of my knowledge it will not work. Launching a process from memory is very tricky, especially when it comes to x64.
For example: (which will only work on Win32 machines)
Richard MacCutchan 7-Mar-13 11:54am
If you know it will not work then why ask the question?
Michael Haephrati 7-Mar-13 11:56am
This specific solution will not work, which is why I am asking for a solution that will work. I certainly believe there should be a way
Richard MacCutchan 7-Mar-13 12:16pm
Without being able to map addresses in the code and link them to DLLs correctly, I think it would be extremely difficult. However, there are probably much simpler ways of solving whatever problem you have.
Michael Haephrati 7-Mar-13 12:28pm
There is no DLL involved. The question is about executables. The need relates to virtualization and isolation of files or Menory Mapped files. If you create such virtual file and this file is a program, the solution would be how to run it without having a physical file behind the process.
Richard MacCutchan 7-Mar-13 13:27pm
Your first two sentences possibly contradict each other. Any executable is likely to require DLLs unless they link to static libraries, in which case they are likely to be quite (if not very) large. The remaining comments are, I am afraid, not clear enough for me to comment. I would suggest you close this question and open a new one with a clear description of what problem you are trying to solve.
DLL is executable. There is different terminology, sometimes it's called executable, sometimes not. I prefer calling all files with code executables, because it reflect the essence of things. EXE and DLL files are very close, the differences are minor. You probably know that it's PE files.
If you solve the problem with DLL, even if you simply load a DLL into existing process, this is "almost" the same as solving the problem you posed.
By the way, such possibility would be a serious security issue.
Michael Haephrati 7-Mar-13 15:49pm
The difference between a DLL and an executable is that in most cases you need an executable to use a DLL, as a DLL will not start by itself (for example, you can't double click a DLL to run it). Same is with other types of files such as drivers (.sys files).
Double click... :-). Even with "double click"... It depends where you double click it and how you host it. You can easily create your sub-system where DLL (by content, not by name) with some special interface can play the role of EXEs, and this technique is really used in all kind of applet-like systems. It's not just nit-picking, it's a fundamental approach: PE (or other shared library) architecture is a primary thing, EXE as a special kind of PE (by content, not by name), is a very top-level peculiarity...
Nevertheless, it looks like writing executable code directly to memory is in principle possible, at least I understand why is it so.
I'll try to answer later; this is a difficult topic...

LoadLibraryEx of course does really not count; it only writes the executable memory, but not directly from memory (and the use of temporary files if just the excuse :-)... If you really want from memory to memory, and then execute loaded code (right?), that's not it...

Michael Haephrati 7-Mar-13 13:42pm
Executables don't have to use any DLL. Linking to static libraries doesn't create huge executbles. I personally create a single executable (and a single file) applications. Such applications are more portable. Most of them don't require installation. You just double click and run. If there is a need to use DLLs, it has nothing to do with my question. There is no problem embedding a DLL as a resource and extracting it during runtime.
I see no point having this discussion about using or not using DLLs because it has nothing to do with my question. Assume there is an "hello world" stand alone executable you wish to run from memory.
In practice, all EXEs use some DLLs. Do you count OS API DLLs? Can you imaging the process not using any? No output at all, not on screen, not to files/network... There is nothing you can do without DLLs. (And not all are called *.DLL, but the way, this is only a naming convention.)
Michael Haephrati 7-Mar-13 15:55pm
Sergey, you are right that all EXEs use DLLs, but these are Windows DLLs which are part of the OS and you can rely on their existence. However, an EXE can base on a single file (itself) and not necessary require other files to be included, in order to make it run. It depends on the type of the application. If you use MFC, for example, you can chose between requiring the MFC DLL (which some user might not have already), or statically link to MFC, which will increase the size of the executable, but will not create a 'huge" executable (it's a matter of a few hundred KB). Applications that don't use MFC, but use Win32 API directly, (including ATL and WTL) don't have to include any DLL in the package given to the end user. So a single executable can be downloaded and double clicked. If you check my own articles, most of them contain source code of such applications that don't require any additional DLLs. As I have written before, in this discussion, additional files which are included in a software, can be kept in internal resources, and extracted during runtime. These include data files, DLLs, and even drivers.
Of course. Still, the difference is quite subtle. And it's possible to use EXE code a the library...
Anyway, all those differences in not the point. You essentially need to duplicate an OS loader on a lower level, to be able to get code as data from whatever source and write to memory, make it executable the way you can actually execute it. The entry point and its use is just one tiny detail of it.
The keyword is "included" EXE or DLL do not include other file, they reference them. Both of them do. It's important to understand that there are no any technical difference between user-level DLL of the OS and of the application. The difference is only OS integrity, guarantees (contracts), packaging, deployment, etc... Excuse me, I think the rest is just unrelated detail...
Gentlemen, I put my answer. The problem is really very difficult. Please see; I think it's pretty interesting...
Michael Haephrati 8-Mar-13 4:24am
The discussion began over the question whether executables must have / use external DLLs. Well, all Windows applications use the OS DLLs (but one can assume these files exists on the computer where the software will be installed on), so my point was there is no necessary a need to deploy any DLLs as part of the application. Then the discussion went to the question if DLLs and EXEs are the same. Well, they are almost the same and at the source code level, the difference is a matter of changing the project's type and changing the entry point. DLLs are meant to pack a functionality or a set of functionalities and make them available to any application which include this DLL. I also mentioned that it is quite easy to pack inside one executable any additional file which is required, and extract them during runtime. These can include not only DLLs, but also drivers (.sys), data files.
Richard MacCutchan 8-Mar-13 4:34am
The discussion actually began with your question How can a x64 compatible application launch a process from memory (for example, loading this process data from a resource), with no existence of any executable (not even a "stub" one)?.

I made a suggestion for something to look at (LoadLibraryEx), but we then got a bit sidetracked about EXE vs DLL files. I did suggest earlier that you close this question and open a new one with the specific details of what problem you are trying to solve.
Michael Haephrati 8-Mar-13 4:38am
You are right: the question was (and still is): How can a x64 compatible application launch a process from memory. This is what I meant to ask, and as Sergey wrote, it is a very difficult one. There is no need to rephrase it.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170713.1 | Last Updated 7 Mar 2013
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100