hello i have some c program that use from those in my c# program. i dont want send those c exe to client. that mean i dont want user can see those exe. i want to load those byte to memory and run its from memory.
how i can do that.
thanks a lot.
+3
A:
If the program is unmanaged code, which a C program is, you cannot launch it directly from within .Net memory. What you can do is pack it as a resource, stream it to disk (a temp folder) and then start it with the System.Diagnostics.Process class. But it would show up in the process list.
But I agree with the comment from @tdammers, why can't you just include it alongside your program? Why do you have to hide it?
If it had been managed, you could get hold of the embedded resource (exe file), get it into a byte array and load it with Assembly.Load.
If your C program was a dll, you could embed as a resource, stream to disk and use p/invoke to execute it.
Mikael Svenson
2010-10-09 18:37:20
Actually, if it was intended to run in-process (which is what a DLL does), it would be very straightforward.
Ben Voigt
2010-10-10 01:22:58
Specifically, putting unmanaged code in memory buffers and calling it directly, with no corresponding disk file, is what the CLR just-in-time compiler does for every single function in your managed program.
Ben Voigt
2010-10-10 01:44:18
@Ben did you read the question? OP is asking for C program, which is unmanaged.
Eugene Mayevski 'EldoS Corp
2010-10-10 06:26:32
@ben: Clarified my answer regarding program and dll. And I guess you han call p/invoke on the exe as well.
Mikael Svenson
2010-10-10 07:11:33
p/invoke is needed for DLLs in general, but if you designed the C code with this in mind (i.e. no imports, accept the kernel32.dll `HMODULE` and a function pointer to `GetProcAddress` as parameters so that the C code could load every other function it wanted), you could just make a function pointer to your memory buffer containing the machine code. P/invoke is not actually necessary for running native code.
Ben Voigt
2010-10-10 15:15:22
On the other hand, p/invoke cannot be used to run code from an exe in most cases. This is because exe files don't have the information necessary to fix them up and run from an alternate base address -- only if the exe base address was not already in use in the .NET process could that possibly work.
Ben Voigt
2010-10-10 15:17:16
@Ben: Thanks for the insight on this :) I have used native DLL's from time to time, but always with p/invoke. Do you have an example of using function pointers from with .Net?
Mikael Svenson
2010-10-10 17:11:36
@Mikael: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.getdelegateforfunctionpointer.aspx
Ben Voigt
2010-10-10 17:31:58
A:
This is not possible, a hard requirement for Windows is that an EXE is started and loaded from a file on disk. This is core to the way Windows is designed, associated with memory mapped files.
You will have to ship the unmanaged EXE along with your C# program. Doing something nasty like extracting the EXE from your resources at runtime is not going to be appreciated by either your customer, the virus scanner she uses nor UAC. You can run it silently by using the ProcessStartInfo.CreateNoWindow property.
Hans Passant
2010-10-09 20:05:37
There's no requirement that the code being run actually match the file the .exe was launched from.
Ben Voigt
2010-10-10 01:20:48
Nice observation :) However, I think we can all agree that the OP probably doesn't want to map the EXE into the process, create a new LDR_DATA_TABLE_ENTRY and link it up, set NtCurrentPeb()->ImageBaseAddress, etc.
wj32
2010-10-10 01:27:44
@wj32: I don't know what "map the exe into the process" has to do with it, you'd use `VirtualAlloc` and `WriteProcessMemory` to avoid the need for a file mapping and an actual disk file, but creating the process suspended and overwriting the instruction pointer of the initial thread would be the key to success, so you're thinking in the right direction.
Ben Voigt
2010-10-10 01:34:03
A:
EXE program can't be run from memory - Windows requires it to be stored on the disk. So you need to save it somewhere - either on regular disk or possibly on the virtual disk, such as the one created by our CallbackDisk or SolFS products.
However, as comments said, your request and your actions would look suspicious to the end user.
Eugene Mayevski 'EldoS Corp
2010-10-09 20:06:23
Windows may require every process to be associated with a .exe file on disk, but that's not the same as requiring the code to be on disk. A virtual disk is only one of several ways to get around that.
Ben Voigt
2010-10-10 01:23:59
Windows requires that there's something on the disk to be used as a base for the process. One can modify the code later (in memory), but still there must be something on the disk.
Eugene Mayevski 'EldoS Corp
2010-10-10 06:28:03
"something on the disk" could be notepad.exe. With `CreateProcess(CREATE_SUSPENDED)`, there doesn't have to be any overlap at all between code that executes and code in the .exe file.
Ben Voigt
2010-10-10 15:11:36
That's right, yet with this approach you will end up having to rewrite the loader. This goes far beyond OP's question (even if it were used for legitimate purposes).
Eugene Mayevski 'EldoS Corp
2010-10-10 16:33:36
If you want to run an arbitrary native .exe, yes you'd need to do the same work as the loader. But you can run snippets of native code with a lot less work.
Ben Voigt
2010-10-10 17:33:36
+1
A:
Doing what you want is the key to create a virus. Windows doesn't want you to
djechelon
2010-10-10 01:14:02
Definitely should be a comment, not an answer, but you don't have the rep for that yet. At least you've got the only answer that doesn't display a deep lack of understanding of code execution. +1
Ben Voigt
2010-10-10 01:21:51
A:
I'm in agreement with all the people telling you this is a bad idea. But it's far from impossible.
The only thing standing between you and running code that you have in some buffer in memory is DEP, and a call to VirtualProtectEx will fix that (if you're loading the code in-process rather than into a new process, VirtualProtect (not -Ex) will be sufficient). Do make sure the buffer is pinned and not subject to being moved by the garbage collector though (using a native allocator is probably a good idea).
Ben Voigt
2010-10-10 01:25:50
How about them? You'll have to find where ntdll.dll and kernel32.dll are mapped, call GetProcAddress, and write some function pointers before calling into the code. Non-trivial, but as I said, "far from impossible".
Ben Voigt
2010-10-10 01:31:41
True, but you make it sound too simple - the OP is going to have false hopes. Take a look at the loader code in ntdll - it's pretty damn big.
wj32
2010-10-10 01:35:05
Obviously writing the payload in a way that minimizes imports would make it a lot simpler. The generic case for an .exe that's available only as a binary would pretty much require duplicating the OS loader logic which, as you say, is quite a tall order.
Ben Voigt
2010-10-10 01:37:36