Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29008 Discussions

Protecting Applications written in IVF

acar
Beginner
3,169 Views
Hi, I am writing an engineering application that I intend to sell sometime in the future. I, clearly, need to protect this application and for this purpose have written a rudimentary licensing mechanism using the mac address. There are switches in the program that enable me to allow or disallow access to specific features for a particular user. I have tested the method out and it works well. However, I am concerned when I see very well known and professional software vendors having their code 'cracked'. Clearly there is no foolproof protection method so I need to ensure that I have availed myself of all possible tricks to avoid this.
Obfuscation seems to be a good route but although I have found obfuscation code for the C/C++ languages, I have not been able to find such code for FORTRAN.
Questions:
1) Is/are there features in IVF or from Intel that will help me in my task.
2) Does anyone know of any obfuscating code that can be used for FORTRAN.
I have looked at professional license managing software but this is unrealistically expensive for a start-up and, as some of the well known software vendors have had their codes 'cracked' then I am suspicious that this route is also not fool-proof.
Thanks,
ACAR.
0 Kudos
1 Solution
Steven_L_Intel1
Employee
3,169 Views
Once the source is compiled and linked, no variable or routine name information is present (assuming a "Release" build with traceback disabled.) One can perhaps determine the assembly code, but there's no practical way to "uncompile" a sizeable Fortran source from an executable.

The key on license management, etc, is to balance cost to you and pain to the end user against risk and cost of piracy. Sure, a poorly-implemented license manager can be thwarted - how much effort do you want to put into protecting against this instead of improving your application? If you do use a license manager, you'll want to add at least some manner of protection for the license checking code and avoid plaintext strings that are used for keys.

View solution in original post

0 Kudos
11 Replies
anthonyrichards
New Contributor III
3,169 Views
I have used QuickLicenseManager in the past. Have you tried it?
Test a copy from here, it is quite straightforward.
http://www.interactive-studios.net/Products/QuickLicenseManager.aspx

You can tie the license to a particular machine which should remove the risk of the same license code being passed on to another user. My version cost me 78 approx.

P.S. I have no commercial involvement with the company.
0 Kudos
acar
Beginner
3,169 Views
I've had a look and it does indeed look to be the answer. They don't appear to support FORTRAN but presumably I can interface through a C/C++ dll. I shall get in contact with them - Thanks for the suggestion. ACAR.
0 Kudos
anthonyrichards
New Contributor III
3,169 Views
If you know C++, that would appear to be the way to go. Looking at my code, I used the Fortran Module Wizard on the QuickLicense DLL and Type Library to generate Fortran calls to the methods in the DLL.
0 Kudos
acar
Beginner
3,169 Views
I can, when forced, cope with C++ but if there is a Fortran option then I will go for that. Thanks.
0 Kudos
jirina
New Contributor I
3,169 Views
Hi, it might not be what you are looking for, but my company uses Safenet Sentinel Hardware Keys to protect applications. You need to purchase a hardware key and the application is then protected by two different mechanisms - by so called code cover enclosing the application in a "shell", and by calling Sentinel API functions from within the source code. We have successfully tested that this works with IVF 11, IVF XE 12 has not been tested yet (it might not be supported by Safenet yet).
0 Kudos
acar
Beginner
3,169 Views
Hi Jirina, thanks for the suggestion. Hardware keys, dongles or hasps, are one way that I could go and there are advantages and disadvantages of this approach. The main disadvantage as far as I can see is simply the need to deal with the administation of the hardware itself, i.e. preparing and posting it.
0 Kudos
Neels
New Contributor II
3,169 Views
I use PLS from Polyhedron - it is a purely software license and works well.

http://www.polyhedron.com/pl_pricelist.php?cat=pls
0 Kudos
onkelhotte
New Contributor II
3,169 Views
I use a combination of username, machine name and Windows license number. These three strings are thrown in a hash algorithm and the resulting hash is stored in a DLL.

This DLL is part of my solution and there all allowed users, along with an authorization level, are stored.

At startup, the actual hash will be generated and compared to the hashs that are stored in the DLL. If the hash is not found, the program pops up with a message box followed by a STOP.

When the user gets a new laptop or a new Window license, he has to generate a new hash and gets a new DLL.

Markus
0 Kudos
acar
Beginner
3,169 Views
The replies to this thread are very helpful. However I have a question. As I understand it all licensing software can be cracked by a determined hacker through reverse engineering techniques see;http://en.wikipedia.org/wiki/Software_cracking. It is certainly the case in the finite element world that top software vendors have had their code cracked with the inevitable loss of revenue and possible loss of IP. If the source code is obfuscated prior to compilation then, I understand, that this makes matters considerably more difficult for the cracker as the meaning of variables etc is not given away by their name etc. I may be being over-cautious as well as probably over-simplifying the issue but I wonder if anyone has any experience of obfuscating Fortran source?
Thanks, Angus.
0 Kudos
Steven_L_Intel1
Employee
3,170 Views
Once the source is compiled and linked, no variable or routine name information is present (assuming a "Release" build with traceback disabled.) One can perhaps determine the assembly code, but there's no practical way to "uncompile" a sizeable Fortran source from an executable.

The key on license management, etc, is to balance cost to you and pain to the end user against risk and cost of piracy. Sure, a poorly-implemented license manager can be thwarted - how much effort do you want to put into protecting against this instead of improving your application? If you do use a license manager, you'll want to add at least some manner of protection for the license checking code and avoid plaintext strings that are used for keys.
0 Kudos
acar
Beginner
3,169 Views
Thanks for that Steve. I am reassured but need to remember to switch to release and disable traceback. Also I agree - it is worth paying a third party to deal with the license management and the responders to this thread have given me some good ideas in this respect.
Thanks to all.
ACAR.
0 Kudos
Reply