Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ C# Windows security
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 4:19am
Comments
Eugen Podsypalnikov at 7-Mar-13 9:28am
   
Hm... why not just the using of a temp file from a temp directory ? :)
Michael Haephrati at 7-Mar-13 13:44pm
   
A 100% virtual file system requires no temp files.
Sergey Alexandrovich Kryukov at 7-Mar-13 14:40pm
   
Hm. Really interesting question, my 5.
—SA
Michael Haephrati at 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
good
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:
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
  Permalink  
Comments
Michael Haephrati at 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: sandboxie.com and www.boxedapp.com. 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: http://www.rohitab.com/discuss/topic/31681-c-run-program-from-memory-and-not-file/ . Some of the good examples of such questions can be only found at www.rohitab.com, 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 at 8-Mar-13 5:19am
   
Sergey, how about this solution?
http://www.rohitab.com/discuss/topic/37801-question-memory-execution/page__p__10083457#entry10083457
Sergey Alexandrovich Kryukov at 8-Mar-13 11:29am
   
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...
—SA
Michael Haephrati at 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.
Sergey Alexandrovich Kryukov at 8-Mar-13 11:46am
   
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...
—SA
Michael Haephrati at 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)
{
HGLOBAL hResData;
HRSRC hResInfo;
LPVOID lpRes;
LPVOID lpMemory;
long int lSize;
HMODULE hModule;
bool bReturn;
hModule = GetModuleHandle(0);
bReturn = false;
if(!hModule)
return bReturn;
hResInfo = FindResourceA(hModule, MAKEINTRESOURCEA(iResource), pResourceSection);
if(!hResInfo)
{
return bReturn;
}
hResData = LoadResource(hModule, hResInfo);
if(!hResData)
{
return bReturn;
}
lpRes = LockResource(hResData);
if(!lpRes)
{
FreeResource(hResData);
return bReturn;
}
lSize = SizeofResource(hModule, hResInfo);
lpMemory = new LPVOID[lSize];
ZeroMemory(lpMemory,lSize);
memcpy (lpMemory, lpRes, lSize);
 
// Here should come the call to the "run process from memory" routine
 
FreeResource(hResData);
delete [] lpMemory;
return bReturn;
 
}
Rate this: bad
good
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.
  Permalink  
Comments
Michael Haephrati at 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 at 7-Mar-13 11:54am
   
If you know it will not work then why ask the question?
Michael Haephrati at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
0 Maciej Los 310
1 OriginalGriff 285
2 Afzaal Ahmad Zeeshan 200
3 Sergey Alexandrovich Kryukov 195
4 BillWoodruff 180
0 OriginalGriff 6,499
1 Sergey Alexandrovich Kryukov 6,048
2 DamithSL 5,193
3 Manas Bhardwaj 4,657
4 Maciej Los 4,120


Advertise | Privacy | Mobile
Web01 | 2.8.1411022.1 | Last Updated 7 Mar 2013
Copyright © CodeProject, 1999-2014
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