Running programs within programs.

nobodythere · 25-12-2005 04:03PM #1

I'm making a program for the sake of learning C++ that I could run other programs from within that program, where the program code would be held in a string. I.e. I want one EXE file which holds a bunch of programs inside it. Each programs machine code will be held in a big string like "\x00\x01" etc etc.

Is there any way to run the programs inside it by copying the string to memory and running it or do I have to output the string to an EXE file and then do a system call to open that file?

And while we're at it, what is the equivalent to system() in C++

Thanks

pH · 26-12-2005 01:21PM

First of all, this does not seem a very clever way to learn c++, but let's say you really want to do it.

Why write functions in machine code and store them as strings, why not just write the functions as c++ functions and call them. Unless you are a machine code guru, you need to learn to handle the stack, passing parameters and return values, this will lead to a lot of learning about intel assembly language but little about c++. Error handling will also be tricky.

Certain architecture may not like to executing code marked as being a data segment, and how to set it all up will be dependent on the compiler your using and the OS.

One possible way is to use function pointers. You will need to cast the address of your string to a function pointer and call it, but as I said understanding and replicating c++ stack management in your own assembly code may be tricky.

Capt'n Midnight · 26-12-2005 02:11PM

As has been said about debugging - "within every program there is another struggling to get out"

The simplist way to do it is to use a batch file that pipes itself into debug.

A far better way is the old fashioned way of generating objects and then linking them. the objects can be written in any language, provided all come from the same family and can use the same Linker.

Overall bad idea as it may resemble a virus and be blocked in the future by intelligent AV apps. Debugging would be a nightmare. And then you have the whole data / execute problem. The 68000 series of CPU's that IBM could have used in the 80's when they designed the original IBM PC can have AFAIK separate areas for data and code. Intel is finally moving that way as is Windows. This means that i you got the pogram to work it would be a dead end as in future under wintell you would no longer be able to transfer control to a data string.

At present the only reason it would work is instruction backward compatibilty that goes back to an 8 bit cpu released in 1972 so you have to assume the early design work was done in the late 1960's ( was the 8008 code compatible with the 4004 in which case you are going back to a 4 bit cpu "! )

And people wonder about things like the Y2K bug and 1MB limit in Dos :rolleyes:

RazorEdge · 26-12-2005 03:49PM

Which platform (i.e. Windows, *nix) are you trying to run this under? I'm going to assume Windows.

If you have external EXEs ( as opposed to code in DLLs) then there is NO way that you can run them from data CORRECTLY within your own memory space. They need their own separate memory space that only the OS can setup. You must copy them to a file and call CreateProcess on that file.

A useful tip if you are using Visual C++ is to include the external EXE as a binary resource within your resource file. You eliminate the complexity of getting the external EXE into your own EXE on your own then.

Ignore this information if you have the source for the external utilities or if the code you want to call is in a DLL or if the platform is not Windows.

pHs suggestion about function pointers will not work if the code is in an compiled EXE as an EXE is not just a block of executable instructions. It is in a format called PE that the OS will examine when requested to run. Lot's of things need to be completed (stacks, memory space, externally linked functions) before the program entry point will be called.:)

nobodythere · 26-12-2005 05:00PM

For the sake of clarity, i'm gonna call the program the self-extracting EXE.

pH wrote:

Why write functions in machine code and store them as strings, why not just write the functions as c++ functions and call them. Unless you are a machine code guru, you need to learn to handle the stack, passing parameters and return values, this will lead to a lot of learning about intel assembly language but little about c++. Error handling will also be tricky.

You misinterpret

I'm trying to store ANY executable inside the one file. For example lets say there were 5 different files I wanted to run on a bunch of computers. I simply would have to deploy this one file over the network and run it, which would then extract and run all of the files that are contained within that one EXE. Kinda like a self-extracting EXE. It's just an experiment and I'm just curious to learn.

There are no 'backwards compatibility' problems etc etc etc, doesn't windows copy the whole program to memory before doing anything else with it? What I'm trying to do is to copy the code of ANOTHER EXE from within the self-extracting EXE to memory and then run it, as opposed to having to extract it to a file on the system first and then run it.

True, this thing does have the potential to be used as a trojan but it's one of those hammer scenarios. You can use a hammer to build a shed or you can use it to beat someone to death with it. I don't think it will be picked up by AV's because if I ever use it it will be for personal use.

Incidentally, the idea of this actually came from examining the source to Back Orifice (a trojan) and thought it was fascinating how it could modify all of the options by modifying the executable. What I'd like to do is have a seperate config file where you could choose which executables the self-extracting EXE would call

Thanks for the definite answer RazorEdge, that's exactly what I was asking. Can I ask where you learned all about PE executables, Microsoft's guide is long and tedious (as technical documentation often is)?

So my plan for the program is to have a string in the EXE which can be modified as it will be in plaintext. The string will contain information such as the filename of the program, whether it is to be run or just extracted, where to extract it etc...

There's the problem of holding the files I wanna run in strings, because their length will be variable and it would be WAAAAY too difficult for me to modify the assembler code dynamically to alter the size of the string. I don't know much about Windows EXE but I think I remember reading that anything after the last \x00 of the program everything is ignored. So it'd be worth a try to append the EXE on the end of the program and then the offset for this so-called "string" would be the original size of the self-extracting EXE, and the offset for the second EXE would be the original size of the self-extracting EXE plus the size of the first EXE.

It's worth a go, for exception handling reasons I can put a 'jmp' to the exit functions of the program after the last \x00 in case the code keeps running.

Thanks for the replies all.

Capt'n Midnight · 26-12-2005 05:28PM

Sounds like you are looking for a packager to deploy your multiple install files as a single EXE or MSI.

nobodythere · 26-12-2005 05:48PM

Yeah but silently without the need for user interaction, i.e. the program can just be run on a bunch of computers without having to go around and go click click click to each one of them.

I just find the idea of self-modifying exe's interesting.

Capt'n Midnight · 26-12-2005 06:20PM

You mean a push install...

Many patches / updates use a -S -U /U to perform a Silent or Unattended install. (microsoft take a bow for not standardising on command line switches)

The psexec utility from sysinternals allows you to run the command remotely, the -u allows you to choose which user to run as.

You could also push a stub over which then pulls down the appropiate files for that OS/update level.

RazorEdge · 26-12-2005 06:23PM

<Edit: My reply is out of sequence now...didn't see the previous two replies. Sorry!>

Sounds something like that alright I guess....

In answer to your question grasshoppa, I have done work in the past with the executable file formats of various systems, one of which is PE\COFF. In fact, most of these executable file formats contain the same sort of information presented in different ways. I have read the document that you refer to and it does make "good" reading alright.

It is clear that you want to embed a number of executables in one executable. I think that you are thinking that if you could just find the correct address to call that you could execute that EXE via a function call of some sort. You are looking in the PE format for this information I guess.

This will not work. You cannot execute this executable code from your own process memory space like this. Have a read about the virtual address spaces of processes if you want to look into it a bit more.

You will have to extract it from your own executable file to the file system first and call CreateProcess on it.

I think that I have done something similar to what you are trying to achieve. I wanted to run certain utilities on other people's (Windows) machines. Those utilities were not present on those machines so I had to supply them. However, I only wanted to distribute one file.

I embedded the other executables in the first executable as resources. These were then extracted to temporary files as needed and executed. When complete they were deleted from the file system. This was written in Visual C++.

I can supply details if you think it might be useful to you (tomorrow).

pH · 26-12-2005 06:29PM

I understand now - the reference to Strings threw me!

Have a look at resources - these are arbitary binary data chunks that you can add to an executable during linking. You should have no problems writing these to a temp directory and executing them. Your program can then be generic.

nobodythere · 26-12-2005 08:03PM

Much thanks for replies, I think I'll do some studying (many new terms...) for the next few days then have a crack at a few different ways of approaching the program.

That resources thing sounds good. Thanks a lot, I'll tell ye how I get on.

nobodythere · 27-12-2005 05:54PM

Well yesterday I found out that Win32 apps can be coded in C! WTF am I learning C++ for!

Argh. I have some issues though, I'm trying to do a simple write to a file. I include <windows.h> and <stdio.h> and I write in the C code (file *ifp etc etc). When I have it set to a Win32 Application in Visual C++ it doesn't actually write to the file. When I copy this code into a command-line program though it works just fine.

Help?!?!

Capt'n Midnight · 27-12-2005 06:38PM

grasshopa wrote:

Well yesterday I found out that Win32 apps can be coded in C!

theexis · 27-12-2005 08:50PM

RazorEdge wrote:

This will not work. You cannot execute this executable code from your own process memory space like this. Have a read about the virtual address spaces of processes if you want to look into it a bit more.

Its definately possible but is probably more work that you want to be doing. You would effectively simulate what the kernel does -> load the PE, fixup and load dependancies, read entry point address and spawn a thread at that address.

nobodythere · 28-12-2005 01:48AM

Cap'n Midnight - what's so funny

I think what Razoredge was trying to say was that it would be only able to copy the code within its own memory page (or whatever you kids are calling it these day), and then the kernel wouldn't be able to give that process a memory page because it would be stored in memory that is already allocated to another program, yes?

RazorEdge · 28-12-2005 11:57AM

Its definately possible but is probably more work that you want to be doing. You would effectively simulate what the kernel does -> load the PE, fixup and load dependancies, read entry point address and spawn a thread at that address.

Interesting. I was thinking this afterwards as well. Probably not a road that grasshoppa should go down though.

I think what Razoredge was trying to say was that it would be only able to copy the code within its own memory page (or whatever you kids are calling it these day), and then the kernel wouldn't be able to give that process a memory page because it would be stored in memory that is already allocated to another program, yes?

I don't think I said this.

Argh. I have some issues though, I'm trying to do a simple write to a file. I include <windows.h> and <stdio.h> and I write in the C code (file *ifp etc etc). When I have it set to a Win32 Application in Visual C++ it doesn't actually write to the file. When I copy this code into a command-line program though it works just fine. Help?!?!

Use the debugger to see what is happening. That's what it's there for.:)

Two things to know that might be helpful. If you don't specify an absolute path for the file when you open it, it will go into the working directory which might not be where you expect. The other thing is if you are writing these files yourself is that the entry point for a Win32 Application is WinMain and not main.

theexis · 28-12-2005 09:27PM

RazorEdge wrote:

Interesting. I was thinking this afterwards as well. Probably not a road that grasshoppa should go down though

I second that - total over engineering for what I think is the aim of the exercise....but quite fun on the other hand

nobodythere · 29-12-2005 03:22AM

Fun eh?

nobodythere · 08-01-2006 11:39PM

Cool, I finally finished the program... Not bad for an absolute programming noob. I went with the append-to-EXE approach, it's pretty small and simple and if anyone's curious for source code PM me or ask me to put it up here.

One thing though... This is windows. And my program creates no window. And therefore I can not declare a handle for the window and have no hwnd variable as this is usually returned from CreateProcess. Therefore I cannot close my window because DestroyWindow requires a window handle.

So the program stays open forever....

democrates · 09-01-2006 12:59AM

grasshopa wrote:

Cool, I finally finished the program... Not bad for an absolute programming noob. I went with the append-to-EXE approach, it's pretty small and simple and if anyone's curious for source code PM me or ask me to put it up here.

One thing though... This is windows. And my program creates no window. And therefore I can not declare a handle for the window and have no hwnd variable as this is usually returned from CreateProcess. Therefore I cannot close my window because DestroyWindow requires a window handle.

So the program stays open forever....

Is there no DestroyProcess? That's it I'm switching back to the spectrum and poking hex for lord zilog. Where's that rusty tape drive...

RazorEdge · 09-01-2006 04:12PM

I assume that you are trying to close the program that you started from within your own program. Correct?

From what you say, it is a console application that you opened. Has this completed its work or is it waiting for some input from you to close.

If it is waiting for some input, then override the default standard input (parameters to CreateProcess) and send in the characters required to close the program naturally.

Brute force method is to call TerminateProcess using the information returned in the PROCESS_INFORMATION structure that CreateProcess returns. Not recommended.

Do you rember to call CloseHandle?
See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/creating_processes.asp for what I mean.

Tell us what state the called program is in and it can be answered better. Is it running? Waiting for input? A windows program that didn't create a window? A console application?

More info needed

nobodythere · 09-01-2006 06:19PM

Actually wait I noticed it was running in a loop waiting for messages. Cool, done.

As a new learning exercise since I've done no GUI stuff with VC++ I've to create an interface to modify what files the EXE runs... as opposed to my trusty hex editor

Thanks all

Martyr · 10-01-2006 10:36AM

By the way, if you were to run any code in memory, it must be relocatable..i don't think you would need to use it, but a virus writer named 'Z0MBiE' wrote some code which demonstrates the theory if you want a look in future, also programmer Y0da with a PE protection utility.
usually the operating system decides where in memory the executable runs, but its possible to manually do it..but for nefarious purposes usually.

Running programs within programs.

Comments