c++ PE injecting additional functionality - c++

Question

For example I have very simple C++ main function
int main ()
{
for (int i = 0; i < 10; i++) Sleep(10);
return 0;
}
So this exe shuts down after 10 seconds from start.
Now the question:
Is there a way to JOIN(concatenate) two PE-applications?
I am trying to do a program C++ which will unite two apps into a new one. For example:
Ill run my program with parameter to app:
My_app.exe %windir% / calc.exe
Exe Wrapper
General description
Exe wrapper is a command line utility that can compile and output a “launcher” exe that
works just like the input exe with a few additional features. The wrapper must be command
line based on takes three input variables:
1. Any windows executable file
2. An expiry datetime
3. URL to server instructions and “download exe”
Example command:
wrapper.exe “input_exe.exe” “20150528
15:00:00”
“http://pemainin.
com/launch_askar.php?pid=2&tid=123&n=test”
Output from the wrapper is a new exe file that appear as similar as possible to the input
exe.
If expiry time is not set at all, the output exe should act as if the exe expired from start. The
output exe should act as follows

Answer 1

What you describe is not feasible. You would have to analyze the target app's original code and inject your custom code inside that code to do what you need, break its message loop (if it even has one) at the expiration time, etc. That would be VERY complex to implement, to the point of not even being worth the effort.
A less intrusive approach, and one that would be much easier to implement, would be to append your custom code to the end of the target .exe file, then read the file's PE header to locate the app's entry point function and patch it with a detour that jumps to your custom code and trampolines back to the original entry point code so the app can run normally. Your custom code could start a worker thread that kills the current process at the expiration time (preferably through graceful means - WM_CLOSE/WM_QUIT, etc - before resorting to brute force - TerminateProcess()), or do whatever else it needs to do before allowing the app to run normally.
Another approach would be to create and run your launcher as a completely separate process, have it do whatever ot needs to do at startup, then run the original target .exe file normally and kill it at the expiration time. If you want to merge the two .exe files into a single .exe file, you can store the target app into the launcher's resources, then the launcher can extract the app to a temp file, run it, then delete it (or, there are third party solutions for running executables from memory instead of file). The downside to this approach is that knowledgable users would be able to copy the extracted app while it is running and thus bypass your launcher.

Answer 2

What you are trying to build is called a "binder". You can achieve the effect you want by having the wrapper "join" two PE files, the stub and the decoy. The stub will implement the main features you outlined (downloading from the link, timeouts e.t.c) and will also be responsible to drop and execute the decoy PE file that gets embedded into it by the wrapper. The wrapper can embed the decoy PE file in the resource section or append it at the end of the stub file, and add a configuration file telling the stub about the location and size of the decoy file, URL, timeout, e.t.c into the resource section. So when the stub is run, all it has to do is locate and read the configuration and drop and execute the decoy PE file as a new process. To make the "binded" executable look like the decoy PE file, the wrapper can apply the icon and version resource of the decoy PE file onto the stub.
Here is my implementation of a binder with a source code.