The basis of my argument is that, behind the scenes, LabVIEW accesses a VI’s block diagram to recompile it for other platforms (operating systems and processors) and newer LabVIEW versions. This means that:

1. Some people within NI can access your block diagrams.
2. Someone outside NI, if they were sufficiently clever (and there are many clever people in this world), might be able to fool LabVIEW into unlocking your VI’s block diagram.

Password protecting VIs is a scheme that relies on “security through obscurity”, which is, IMO, a very bad idea. (But, don’t just take my word for it — google “security through obscurity” and read some of the articles.)

So, why do I bring this up? LabVIEW is becoming more and more of a general purpose programming language and many people are building commercial products using LabVIEW, including reuse libraries and components. Customers of LabVIEW reuse libraries and components expect to be able to use them in future versions of LabVIEW as well as use them on any platform or execution target supported by LabVIEW (such as LabVIEW RT and FPGA targets). The only practical way for vendors to achieve this is to ship the reuse libraries with password protected block diagrams.

What would happen if, some day, a hack were to be discovered that could unlock the block diagram of any VI? What would be the implications for NI? What would be the implications for LabVIEW users? What would be the implications for LabVIEW tools vendors? I’ll bet you that many people would be VERY pissed off and there might even be legal actions taken.

The longer we rely on the fallacy of password protected VIs, the more catastrophic the consequences to all of us, once the scheme is cracked.

So, what now?

1. First, do not rely on password protection for any VI with intellectual property that must not be made public.
2. Second, demand (from NI) a better scheme for cross-platform execution of VIs.

So, what can NI do to devise a better scheme to lessen the need for distributing password protected VIs?

1. Give VIs the ability to store the executable code for multiple platforms and execution targets
2. Use platform-independent byte code that runs on a LabVIEW virtual machine
3. Support old versions of VI executable code (for example, a VI saved in LabVIEW 6.1 on Windows without a block diagram should be callable by LabVIEW 8.5 on Windows). This can almost be done right now by building your reuse library into a DLL and providing VIs (with source code) that wrap the DLL. However, this technique still requires one version of the DLL for each platform (Mac, Linux, and Windows) and would not work well for targeting LabVIEW RT or FPGA.

Is the world coming to an end? No, not really. But, things are getting worse as time goes by. The longer people rely on password protected VIs and the more popular LabVIEW becomes, the larger the consequences when the scheme is eventually cracked.

In LabVIEW, when we build an executable application, there are a lot of security issues. For example, while working on VI Package Manager, we (JKI) employed several mechanisms to address LabVIEW security issues. One significant security limitation of LabVIEW, is that the subVI call boundary is inherently not secure. At run-time, LabVIEW dynamically links parent VIs (callers) to subVIs (callees). It is therefore possible (and, yes it’s been done) to fool a VI in a built application into calling a different subVI than was specified at build time. VIs can be inserted into the hierarchy of a LabVIEW application in order to intercept and modify data — we call these intruders “mole VIs”. I’m not going to explain the process of creating and inserting mole VIs, but I will tell you (only) a couple of the things that we’ve done to thwart the problem.

One technique that we used, is in-lining of subVIs. This is basically the inverse operation of Create SubVI from Selection, except that you merge a subVI into its caller’s block diagram (often recursively). We were working on a way to do this, using scripting (and had it nearly working), when we discovered a native scripting function that does it for us. Ironically, we noticed that someone on LAVA discovered this, too, just about a week after we did — small world! Of course, we were trying to solve two different problems (our issue was security and their issue was execution optimization) but is was interesting, nonetheless.

Another technique that we used is obfuscation (garbling) of VI names inside the executable, so that VIs’ real/descriptive names cannot be seen — for example a VI named “Is Password Valid.vi” might be renamed to something like “0BFE026AEEB3CF0FDDA37505B49D846C”. In VIPM, we achieve this by doing a programmatic renaming of all the VIs, during the build process. Now, this doesn’t really prevent someone from inserting a mole into your application hierarchy, but it makes it a lot harder to figure out what’s going on in your application.

Finally, I should note that both of the aforementioned techniques are executed programmatically during the build process. We use OpenG Builder to build VIPM and we have over a dozen separate build steps and also execute several call-backs that operate on VIs as they are copied from the source location to the build output location. Honestly, I couldn’t imagine creating a commercial software product, written in LabVIEW, that was not built using OpenG Builder. In future articles, I’ll describe more of the cool ways that we use OpenG Builder to overcome software engineering challenges.

In closing, I should also mention that insecure software is also a very serious problem — please, show your software some love and make sure that it is secure

Want to discuss this article? Please post to the LAVA discussion forum thread, here.