Launch a process form memory (x64 version)

Question

5.00/5 (2 votes)

See more:

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

Michael Haephrati

Add a Solution

Comments

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.

Sergey Alexandrovich Kryukov 7-Mar-13 14:40pm

Hm. Really interesting question, my 5.
—SA

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...

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Sergey Alexandrovich Kryukov · Answer 1 · 2013-03-07T13:54:00

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:
http://en.wikipedia.org/wiki/Data_Execution_Prevention[^],
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366553%28v=vs.85%29.aspx[^].

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: http://en.wikipedia.org/wiki/Protection_ring[^].
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:
http://en.wikipedia.org/wiki/Protection_ring#Interoperation_between_CPU_and_OS_levels_of_abstraction[^].

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:
http://en.wikipedia.org/wiki/Just-in-time_compilation[^].

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:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx[^],
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366890(v=vs.85).aspx[^].

Now, here is the key point: you can change the access protection of the allocated memory with VirtualProtect or VirtualProtectEx:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).aspx[^],
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366899(v=vs.85).aspx[^].

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:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786%28v=vs.85%29.aspx[^].

See also:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366785%28v=vs.85%29.aspx[^],
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366912%28v=vs.85%29.aspx[^].

For the whole topic, start here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366779%28v=vs.85%29.aspx[^].

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.

—SA

Richard MacCutchan · Answer 2 · 2013-03-07T05:47:00

Solution 1

You can use the LoadLibraryEx function[^], although I do not think that will work from managed (e.g. C#) code.

Posted 7-Mar-13 5:47am

Richard MacCutchan

Comments

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: http://www.rohitab.com/discuss/topic/31681-c-run-program-from-memory-and-not-file/ (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.

Sergey Alexandrovich Kryukov 7-Mar-13 15:09pm

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.
—SA

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).

Sergey Alexandrovich Kryukov 7-Mar-13 19:19pm

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...
—SA

Sergey Alexandrovich Kryukov 7-Mar-13 15:34pm

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...

—SA

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.

Sergey Alexandrovich Kryukov 7-Mar-13 15:12pm

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.)
—SA

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.

Sergey Alexandrovich Kryukov 7-Mar-13 16:11pm

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.
—SA

Sergey Alexandrovich Kryukov 7-Mar-13 19:22pm

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...
—SA

Sergey Alexandrovich Kryukov 7-Mar-13 19:54pm

Gentlemen, I put my answer. The problem is really very difficult. Please see; I think it's pretty interesting...
—SA

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.