Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Comunicados
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29283 Discussões

How to ensure my Fortran executable is called from a specific application

Edouard_YF
Principiante
2.169 Visualizações

Hello everyone,

 

I work in a company that produces scientifics softwares, consisting in a .NET GUI calling a Fortran executable to carry on computations.

 

We would like to make sure that a malicious customer can not use the Fortran executable as a standalone. 

In other words, we would like to make sure that the executable runs properly only if it is called through the GUI.

 

Is it even possible ?

If not, would you have any other recommendation on how to protect our executables ?

 

Any help would be much appreciated,

Thanks in advance

0 Kudos
1 Solução
Edouard_YF
Principiante
2.019 Visualizações

Hi all,

 

Thank you very much for your time and answers.

I think we are going to explore the CLA solution first as it is really easy to implement.

 

Wishing you a nice day,

Edouard

Ver solução na publicação original

6 Respostas
GVautier
Novo colaborador III
2.155 Visualizações

Hi

You can add a "non printable" argument (below 32) in  the call parameters that can only be included in a program call or a "coded" argument that can be checked by he program.

jimdempseyatthecove
Colaborador honorário III
2.144 Visualizações

Using a secret argument might be easy to capture (create a fake program of same name as your Fortran program to capture the command line arguments).

 

An alternative method could be to set bInheritHandles in SECURITY_ATTRIBUTES and then use a handle to something more obscure/difficult to discover. For example, a memory mapped file, a pipe, event, mutex, etc... any of which that you can construct your "secret handshake".

 

Jim Dempsey

GVautier
Novo colaborador III
2.133 Visualizações

Passing a timestamp (even coded) to the program and check that it's not too old may avoid basic hacking.

All depend on the cost/benefit balance.

David_Billinghurst
Novo colaborador III
2.112 Visualizações

We have a similar situation.  I know the outline of our solution, but not the details.

We digitally sign the main function call to Fortran using one of the standard digital signature algorithms.   We use two sources of data:

  • parameters hard coded into the Fortran DLL - essentially a private key shared with C#.  I think we try to conceal the definition of it using TRANSFER but this is probably a waste of time
  • values concealed in "unused" fields in Fortran subprogram array arguments.  These are initialized to random values and then selected bytes are set to contain the values of interest.  These are extracted and combined in Fortran.

Initially we extracted eights scattered bytes of interest, XORed four bytes with our "32-bit private key" and compared them to the other 4 bytes.  We just return an internal error if authentication fails.  EDIT: We now use a proper crypto algorithm.

I think we now generate the GUI data in C++ as we were concerned about the security of the C# application.

 

JohnNichols
Colaborador valorado III
1.939 Visualizações

I was thinking about your problem over the weekend, as I sat for two hours in a football traffic jam.  

There is no security in a C# program, the jetbrains people give you a free viewer.  Lisp used to have an obsquring program.  

Strand in Australia, which is a Fortran program use a HASP, that works well.  It is quite annoying you have to find the HASP.  

Edouard_YF
Principiante
2.020 Visualizações

Hi all,

 

Thank you very much for your time and answers.

I think we are going to explore the CLA solution first as it is really easy to implement.

 

Wishing you a nice day,

Edouard

Responder