Software protection

[Dec]

Hi all

I am hoping somebody out there may be able to help me with this one. I am trying to determine the best way of protecting an application we have built using LabVIEW7.

The application:
The application is an ATE system with the equipment control software written using LabVIEW7 and the tests sequenced using Teststand2. The application was built around TestStands operator interface for LabVIEW using LabVIEWs application builder. The required .seq files and a library of required LabVIEW functions (save using LabVIEWs “application distribution” “save with options” tool) were included in the build as support files. We also created an installer as part of this build.

On the target system
When the installer is run on the target machine, the .exe will simply be TestStands operator interface for LabVIEW. When run the user will select the appropriate .seq file to run (.seq files are present as support files after installation). The .seq file run will in turn call the appropriate LabVIEW functions from the support labVIEW.lib file.

Questions.
How do I protect the application when I want to create an application installer? Dose the protection have to come in as part of the build process or can you rap around the entire installer?
Software protection packages (non dongelized) such as “cryptkey” seem to simply rap around a built .exe, so how would this work with an installer?

If I do manage to protect the.exe the end user could still simple obtain a copy of TestStand and run the sequence files directly from there, bypassing the protected operator interface. Any ideas how to protect against this?

The Sentinel SuperPro seems to be implementation we are leaning towards at the moment. If anyone has experience with this product do they think it would provide the required protection baring in mind the issues listed above?


I apologise about the length of the post but any advice on solving any of these issues would be much appreciated as I have zero experience in the distribution of applications to an end user.

Also any information of NI licencing issuses in selling such an application to an end user would be much appreciated

Looking forward to you input

Kind regards

Declan

[Dennis_Knutson]

First, I question putting your protection scheme on an exectuble (the TestStand OI) that you didn't create. It was created by NI and is not your intellectual property. Second, like you mention, all a user has to do is buy TesStand themselves to open a .seq file and run it. If for example, you have hardware protection, and a DLL call to it as a test step, someone with the sequence editor could simply delete that step. For that matter, a .seq is a text file and can be edited with something as simple as Notepad. Third, if you distribute the test steps as VIs and an llb, someone could purchase LabVIEW and open the VIs end edit. So if you put a hardware protection scheme in the VIs, you would need to either remove diagrams or password protect them. I'm not that familiar with software protection but maybe it's possible to create an exe for each of your steps and protect them individually. You might also be able to do something similar if you create dlls out of the LabVIEW test steps. Lastly, consider who your customers might be. Most, in my experience, are honest about buying legitimate copies of software and you need to balance the time you're going to spend on protection schemes versus how much you think you'll lose from illegal copies.

For licensing information, it's best to contact NI directly. At the least, you would need TestStand run-time licenses.

[Alberto]

Hi Declan,
I explain you breefly how the mentioned key works: you can protect your software in two ways, automatic and integrated protection. I attach part of the help file that expains the two methods.



The frequency of software locks within your application, and the action taken if no key is found, is left up to you. The more locks you add to your application, the more difficult it will be for potential hackers to break your application’s protection.
When using integrated protection, you must understand the API function calls used to support the protection strategy you have designed, and manually add them to your code.>

Keep in mind that the automatic protection can only be used to protect .EXE or .DLL files.
In your case there's not much you can do on the .SEQ file, but as long as you are calling LV vis you have developed, then you can modify the vis to make periodic calls to the key and lock them if it is not present (integrated prot.. These calls are quite easy to embed; as I said on the other thread the key's software disk is shipped with some LV example.
The key obviously needs a driver that has to be installed on the target machine, it's very small in size and can be distributed without any licence; you can include it in your distribution package and do a silent install.

Anyway there are several other devices similar to the Sentinel key, I think you should check their features and see if can fit you better.
This is far the longest post I ever did on this forum... I just hope it was helpful!
Alberto

[Enrique]

Hi Declan;

I wrote about that in a similar discussion. Below is the message, I hope it is useful:

---

@Enrique wrote:

If you want your program to run on a specific machine, you need to know about that machine so your software is somehow "made" exclusively for that machine. If you can make the software so it utilize resources very specific to the target computer, then you are ok. It is difficult to come up with the right analogy. Let say it is like somebody make a uniform specifically for you and take into consideration all your exact measurements like size, weight, etc. (we are assuming a little here, like those measurement won't change). It can be argued that there maybe somebody in the universe that is like you, but the chances can be sufficiently low so it is acceptable to you to take the risk. All this is usually very difficult and expensive.

A more common approach is to know information that can uniquely identify the computer and then create the application so it first ask the computer to identify itself. Upon correct identification, the application provide its services. An analogy is that I am the one who provide the services and I have your name and driver license number on file. If you request service, I ask you for those identifiers and once I verify your identity you are good to go.

A more secure approach will be that we share a secret like a password. I, as the application, ask you (the computer) to authenticate, that is, to provide identification and the password. An alternative is to have something that, although is not secret, it cannot be forged (at least, within certain probability). Let say I ask you for your signature. The bundle human presence + signature cannot be forged.

A way to implement the latest one may go like the following: each copy of your software has a unique identifier (SI) and a unique key (K) that enable the application. You ask the target computer for its unique identifiers (CUI). You generate a random string (R) for the secret and then create a function f such that: K = f(SI, CUI, R). To get the right key K that enable your software, all the other parameters must be the right ones.

If this is done right, the security of the application will depend on the secret (R), so you better generate and manage R right. Also, you want to make sure the function f() cannot be bypassed (i.e., direct insertion of K is not possible).