block direct execution

Question

I have a "Main app" that runs an external process like this:

sortProcess = new Process();
sortProcess.StartInfo.FileName = "app.exe";
sortProcess.StartInfo.UseShellExecute = false;
sortProcess.StartInfo.RedirectStandardOutput = true;
sortProcess.StartInfo.RedirectStandardError = true;
sortProcess.OutputDataReceived += new DataReceivedEventHandler(SortOutputHandler);
sortProcess.ErrorDataReceived += new DataReceivedEventHandler(sortProcess_ErrorDataReceived);
sortProcess.Start();
sortProcess.BeginOutputReadLine();
sortProcess.BeginErrorReadLine();
sortProcess.WaitForExit();
sortProcess.Close();

The external process needs to be very simple to communicate to main app and multilingual, something console like, like this:

        Console.WriteLine(@"started");
       //do stuff
        Console.WriteLine(@"something done");
        //try to do more stuff
        throw new System.InvalidOperationException("Logfile cannot be read-only");
        //could do
        Console.WriteLine(@"done without errors");

The app.exe has the Output type as Windows Application, how can I on the app.exe block the execution of the exe from any other place unless it's ran by my main app

In short, you can't. You can possibly made it harder so that they really have to try to do it, but you can't stop them entirely. If you just want to make it so that it won't do anything if someone hits the wrong exe by accident (rather than being mean or malicious) then there are solutions. — Servy, Jul 05 '12 at 17:53
Maybe you could do some sort of encrypted handshake between the two programs to authenticate before doing anything. But as @Servy says, if you're giving the users the app.exe file, it's going to be possible (difficult, maybe) for them to run it in a way you didn't intend. You should try to approach your problem from another angle. You haven't given us enough info to really help there. — Tim S., Jul 05 '12 at 17:55
1. Why are you using an external .exe instead of a dll if you're only ever intending to call it from the main process. 2. Why do you want it to be impossible to run directly? — Anders Abel, Jul 05 '12 at 17:55
possible duplicate of [How can I get the PID of the parent process of my application](http://stackoverflow.com/questions/2531837/how-can-i-get-the-pid-of-the-parent-process-of-my-application) — Hans Passant, Jul 05 '12 at 17:59
@TimS. & HansPassant in both cases you could either decompile app.exe to remove the check, decompile the main app to determine what the secret key (or encryption algorithm key), dump the memory of app.exe to see what the command args were (or sniff the communication in some other way), and I could keep going. You can make it harder, but you can't make it impossible given that all of the code is already accessible to the user. — Servy, Jul 05 '12 at 18:09
@HansPassant That question isn't a duplicate. Knowing the parent thread's PID still doen't tell you for sure whether or not the executable was called from your app or not. — Servy, Jul 05 '12 at 18:34

Steve Wortham · Answer 1 · 2012-07-05T19:17:02.400

I'm not sure of a bulletproof solution for blocking other applications from calling the exe.

But if your main concern was to prevent app.exe from launching when a user double-clicked it, then you could do that by immediately closing app.exe (maybe display a message box first) when it's called without the proper arguments.

And in your main application you might pass an argument like this...

sortProcess.Start("app.exe", "please");

See Process.Start and this Command Line Parameters Tutorial (assuming app.exe is a .NET application).

score 0 · Answer 2 · answered Jul 05 '12 at 18:33

0

If obscuring it from the user is all you need, e.g. so they won't double-click it, you can fix this by renaming the file, e.g. to app.bin.

answered Jul 05 '12 at 18:33

Tim S.

55,448
7
96
122

block direct execution

2 Answers2