How to restrict execution with double click?

[Roberto_Soares]

Hi,

I have a main program (written in C++) that calls two executables (written in Fortran). My question is how to restrict access to these two executables and ensure they can only be used from the "parent" program.

In other words, I need to somehow check the user is not double clicking on them and the "parent" program is indeed the one calling each executable.

Any ideas would be appreciated,

Roberto

[mecej4]

One simple way:

Have the parent pass an argument, and have the child check for the presence of that argument. Fortran 2003 gives you portable access to the number of program arguments, so you don't need to call the OS API for this information.

When the child is opened directly, the number of program arguments will be zero.

[joerg_kuthe]

Passing an argument to the Fortran program may not be sufficient, since neither GETARG nor GET_COMMAND_ARGUMENT deliver the program's name that invoked the Fortran program. It would be easy to fake that call, e.g. in a .bat file. There are tools freely available which allow to find out what the command line looked like (under Windows I could name at least one).
To become system independent, you might create a file in your C++ program which for example contains a time encoded value. When the Fortran program starts, it opens the file created before, checks the decode time and maybe someother piece of "security information" that you might provide to make a hack more difficult.

Joerg
www.qtsoftware.com

[joerg_kuthe]

Passing an argument to the Fortran program may not be sufficient, since neither GETARG nor GET_COMMAND_ARGUMENT deliver the program's name that invoked the Fortran program. It would be easy to fake that call, e.g. in a .bat file. There are tools freely available which allow to find out what the command line looked like (under Windows I could name at least one).
To become system independent, you might create a file in your C++ program which for example contains a time encoded value. When the Fortran program starts, it opens the file created before, checks the decoded time and maybe someother piece of "security information" that you might provide to make a hack more difficult.

Joerg
www.qtsoftware.com

[GVautier]

Hello

Pass a non printable character (0x1a for example) in the first argument and it will be impossible to simulate it in a batch file.

[Steven_L_Intel1]

If the Fortran code is not intended to be used directly, why not make it into DLLs and call it from the C code?

[jimdempseyatthecove]

Since this is a Windows forum I will assume this is a Windows application.

Invent your own handshake.

Start the program with passing the hex of a handle of something convienentowned by the parent program, but accessible to the sibling when it starts. Upon startup, the sibling checks its arg list, if NULL then exit (report error to user too), if notNULL, see if hex format number, if notthen exit, convert hex arg to HANDLE, then attempt to use object on handle in manner expected by parent. e.g. this could be a handle to a pipe or whatnot.

Alternately, pass a file name of a file open (shared) by parent. When sibling run, sibling opens file (if not found - abend), else check file for known "secret" word, if not present - abend, else write some knownother secrete word,flush, wait looking for word to change again, if word changes to next secrete word - assume parent is running, else after nn seconds - abend


Jim Dempsey

[anthonyrichards]

Steve's suggestion of making the programs into DLLs is clearly the neatest solution.
Just replace PROGRAM START1...end Program, with SUBROUTINE STARTPROGRAM1()...end subroutine and create a DLL rather than an EXE and invoke it with CALL STARTPROGRAM1(). You could add an argument for a status report when the program completes.

P.S. It might be prudent to not use such an obvious subroutine name as STARTPROGRAM1, as that can be found when you do a DUMPBIN on the DLL. Be inventive! Also, on further thought, it would be prudent to add some arguments which must have certain values in order for the program to actually function, or for the subroutine (or function) invocation to be recognised as allowed.

[jimdempseyatthecove]

The DLL would require running the code in the same Virtual Machine (process). Depending on the applications requirements, this may or may not be an available option. Being a DLL would(could) have the benefit of eliminating a temporary file for app to app communication. An additional problem is should the code called app now DLL crash, it takes down the parent process, as opposed to the parent process handling an exception condition.

Jim Dempsey