Running executable from memory

Question

I'm trying to run an executable directly from a byte[] representation of this executable as a resource in C#.

So basically i want to run a byte[] of an PE directly without touching the harddisk.

The code I'm using for this used to work but it doesn't anymore.

The code creates a process with a frozen main thread, changes the whole process data and finally resumes it so it runs the byte[] of the PE. But it seems like the process dies if the thread is resumed, i don't really know whats wrong.

So here is the code in a pastebin because its too long for here i guess...

http://pastebin.com/18hfFvHm

EDIT:

I want to run non-managed code ! Any PE File ...

Answer 1

i found that sample, hope it will be useful for you. http://www.cyberhackers.mybbnew.com/showthread.php?tid=178

Answer 2

I haven't tried this, so it's purely specutive, but I believe you want to load in into the AppDomain:

byte[] myAssm = ...
AppDomain.CurrentDomain.Load(myAssm);
AppDomain.CurrentDomain.ExecuteAssemblyByName(nameOfMyAssm);

Answer 3

I'm not sure if this will be much help, but here is where I answer running straight x86/x64 assembly opcodes from a C# program.

Answer 4

This code may help: Dynamic Process Forking of Portable Executable by Vrillon / Venus: http://forum.gamedeception.net/threads/16557-Process-Forking-Running-Process-From-Memory

Answer 5

I believe your problem is that you are asking for a security hole.

To run any PE, you are asking -- "Let my secure/managed .NET app run an insecure/unmanaged app -- In a way which bypasses normal security".

Let's say I run you application (which I assume is secure). I've not given it permission to write to sensitive folder; it can't overrun buffers; it can't touch my win32 mode code. You then build, byte-by-byte, a malicious application in a byts[], and launch that. Where does Windows step in to ask me if I want to let this happen? And what does that warning say ? "Is that array of bytes from a trusted source?"

Answer 6

Here is some code to execute native code (inside a byte array). Note that it is not exactly what you are asking for (it's not a PE file bytes, but a native procedure bytes ie. in assembly language)

using System;
using System.Runtime.InteropServices;

namespace Native
{
    class Program
    {
        private const UInt32 MEM_COMMIT = 0x1000;
        private const UInt32 PAGE_EXECUTE_READWRITE = 0x40;
        private const UInt32 MEM_RELEASE = 0x8000;

        [DllImport("kernel32")] private static extern UInt32 VirtualAlloc(UInt32 lpStartAddr, UInt32 size, UInt32 flAllocationType, UInt32 flProtect);
        [DllImport("kernel32")] private static extern bool VirtualFree(IntPtr lpAddress, UInt32 dwSize, UInt32 dwFreeType);
        [DllImport("kernel32")]
        private static extern IntPtr CreateThread(
          UInt32 lpThreadAttributes,
          UInt32 dwStackSize,
          UInt32 lpStartAddress,
          IntPtr param,
          UInt32 dwCreationFlags,
          ref UInt32 lpThreadId
        );

        [DllImport("kernel32")] private static extern bool CloseHandle(IntPtr handle);
        [DllImport("kernel32")] private static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);
        static void Main(string[] args)
        {

            byte[] nativecode = new byte[] { /* here your native bytes */ };

            UInt32 funcAddr = VirtualAlloc(0, (UInt32)nativecode.Length, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
            Marshal.Copy(nativecode, 0, (IntPtr)(funcAddr), nativecode.Length);
            IntPtr hThread = IntPtr.Zero;
            UInt32 threadId = 0;

            hThread = CreateThread(0, 0, funcAddr, IntPtr.Zero, 0, ref threadId);
            WaitForSingleObject(hThread, 0xFFFFFFFF);

            CloseHandle(hThread);
            VirtualFree((IntPtr)funcAddr, 0, MEM_RELEASE);
        }
    }
}

Answer 7

In theory, if you are running full trust, there is nothing stopping you from doing CreateProcess on rundll32.exe, unmapping rundll32.exe, and performing the initial EXE load yourself.

The way I'd go about it is inject a thread into the target process that does the work in an unmanaged way. Yes, this means piles of relocatable assembly.

The general idea is to call LdrUnloadModule to get rid of rundll32.exe, call LdrLoadModule to load the EXE, fixup the load chain to indicate it was loaded first, then restart the main thread.

Good luck to you.