Password Protecting VIs is Security Through Obscurity

Posted on Sunday 19 August 2007

lock_reduced.pngI have a huge problem with password protected VIs. It gives people false assurance that nobody will be able to see the intellectual property contained in a VI’s block diagram (the source code).

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.


24 Comments for 'Password Protecting VIs is Security Through Obscurity'

  1.  
    Rolf
    August 19, 2007 | 11:58 pm
     

    Well what you suggest would be the equivalent of a Macintosh fat binary ^ LabVIEW platforms ^ LabVIEW versions. It’s doable of course but would require you to have the licenses of every possible platform version and every possible LabVIEW version you want to support in your library. Not to mention that your library still can’t be provided in this way in a version that can be read by a future LabVIEW version.
    So who would make use of such a feature? Probably very few people.
    Would there be any way to make it work with already released versions? No!

    In short I think the way you envision it here would not be practical at all.

    Rolf Kalbermatter

  2.  
    Ben
    August 20, 2007 | 6:02 am
     

    I used to work as a security consultant to major banks. Even back then, the philosophy was to “make it more expensive to break in than what you would get if you did break in”.

    Alexander showed there was no knot that could not be loosened.

    If your code is that valualbe then you should only share VI’s without diagrams.

    Ben

  3.  
    Justin Goeres
    August 20, 2007 | 7:37 am
     

    To parallel with what Jim is saying, false security is even worse than no security.

    I’m not sure Jim is making an argument here about the practicality of any solution. I think he’s making an argument that this is a gathering storm. If LabVIEW continues to grow (which we all want it to), then someday, someone is going to throw the door wide open on VI password protection, and that will be a big deal to a lot of developers. It’s something that will require cooperation and support from NI to address, and if the best solution involves licensing changes then that should probably be on the table. But in any case, we should be talking about it now rather than when the horse has left the barn.

    “If your code is that valuable then you should only share VI’s without diagrams.” — This would break some of the most critical features of using LabVIEW to distribute software. If I have to remove the diagrams from my code to distribute it safely, I lose both its cross-platform(/cross-target) compatibility and the ability for my users to run the code in multiple versions of LabVIEW. If that’s truly part of NI’s calculus (I don’t think it is), then they should just come out and say that they don’t care about distribution.

  4.  
    Philippe Guerit (PJM_LabVIEW)
    August 20, 2007 | 10:10 am
     

    “If your code is that valuable then you should only share VI’s without diagrams.”
    This is not really practicable. Leaving the loss of cross platform compatibility aside (read that Justin answer above), let me give you an example of an other issue than can arise.
    Several years ago, I was a user of the excellent GToolBox by George Zhou. George does ship every VIs in this toolbox without any diagrams. I had a fairly large project relying quite extensively on this. During a LabVIEW upgrade, the entire project broke because these VIs were not re-compilable (and George did not have the new LabVIEW version available yet). To make a long story short, the downtime resulting from this was bad enough that it was decided that we would never use toolkits that ship VIs without block diagram.
    Therefore, shipping a toolkit with VIs without block diagram could be a source of issues for your customer.

  5.  
    George Zou
    August 20, 2007 | 10:19 am
     

    NI did a poor job for protecting LabVIEW programmer’s intellectual property.
    May be we should start a survey to see how many LabVIEW users want to see a change.

  6.  
    August 20, 2007 | 11:49 am
     

    Great article Jim.
    Personal opinion: Password protecting VIs doesn’t protect your IP. I use it solely as a means of ensuring some form of code control within our company (i.e. people have to come as for the code, versus just using it).

    Lets try to look at this from the point of view of other compilers for a minute though. Lets say I develop something in Visual C++. If I sell a “toolkit” based on this functionality I have 2 choices: Compile it, or sell rights to it. There is no “Password Protection” here.

    While I personally appreciate that LabVIEW is different, I don’t think NI should be responsible for protecting my IP…. So the best solution I see would be the ability to drop function blocks on the diagram like Primatives. These VIs should come from the forementioned DLL style code just like all other programming environments.

  7.  
    Joe Zoller
    August 21, 2007 | 7:41 am
     

    “Use platform-independent byte code that runs on a LabVIEW virtual machine”

    Wow. Not a trivial request ;). While byte code isn’t going to do anything for IP protection… where do I sign up?

    Byte code seems to promote so many desirable things: platform independence, IDE separation from the compiler, the ability to get past a portion of the high-level abstraction to actually *check* what’s going on under the hood…

    Unfortunately, the need for a runtime compiler doesn’t seem to play well with the notion of memory or processor restricted environments like RT or FPGA. Does this mean there would need to be both an intermediate byte-code and a compiled binary capable compiler?

  8.  
    August 21, 2007 | 8:37 am
     

    First, I found a discussion thread, here, on the NI forums that discusses this topic.

    Yes, there are many problems with bundling the executable code for multiple platforms inside a single VI — it certainly doesn’t scale well.

    It appears that we are between a rock and a hard place.

    First, we must not distribute VIs with block diagrams if our source code is of any value, but this is the ONLY way to be cross-platform (and cross-target: RT, FPGA) compatible.

    Second, a LabVIEW virtual machine that run platform-independent byte code would be wonderful, but would introduce significant performance penalties and not work well with FPGA, I think.

    I guess what I am after is acknowledgment by National Instruments that password protection is a very bad system for IP protection. IMO, they are building up a very large house of cards.

  9.  
    Guillaume Lessard
    August 22, 2007 | 4:11 pm
     

    The bytecode NI would need already exists: LLVM. It compiles under Linux, Mac OS X and Windows. LLVM bytecode can be recompiled to static code, so that provides functionality for RT targets. Whether it would be usable to target FPGAs is unclear, though.

    Of course, using an open-source package to solve a fundamental problem would fly in the face of NI’s all-proprietary, all-the-time attitude!!

  10.  
    August 27, 2007 | 12:46 pm
     

    Guillaume: Thanks for the link to LLVM — that’s very interesting! I think you’re right about NI not wanting to have an open source component at the foundation of LabVIEW. It might get people thinking about an open source graphical programming language…

  11.  
    Rolf
    September 28, 2007 | 11:49 am
     

    For an Open Source version of LabVIEW is the interested target audience way to small. There are many attempts for Open Source packages in the engineering world but very few succeed in being more than a nice plaything for a few enthusiastic people. Look at EDA software for instance. You can download GEDA and a few others and it’s nice to play with them but I would never consider using them for a professional project. LabVIEW’s audience is in comparison to that even smaller.
    You have either engineers who do real work and have not that much time to spend months of programming time on an open source project (and in the case of LabVIEW often, me included, don’t have the technical software engineering background to really pull of complicated system like LabVIEW) or students who may have the time and in a few cases the software engineering knowledge, but not very likely the interest for this.

    This leaves not many options.

    Rolf Kalbermatter

  12.  
    Vi_cracker
    July 12, 2008 | 2:24 pm
     

    I got a way to open password protected VI\’s .. no brute force.. no waste of time.. I am able to open up any password protected VI in seconds…I cannot decrypt the password.. but break open the Vi !
    Interesting? reach me at: ———— for any querries

    [edited by moderator]

  13.  
    July 12, 2008 | 2:30 pm
     

    Vi_cracker: Thanks for confirming that VI passwords aren’t safe. However, you most likely breaking the law by offering to help people crack password protected VIs.

  14.  
    Vi_cracker
    July 12, 2008 | 2:38 pm
     

    okies.. u can delete the post :)

  15.  
    crelf
    July 12, 2008 | 2:44 pm
     

    Vi_cracker – you can make a positive contribution to the LabVIEW community by letting NI know (in private, of course) about the method that you’ve found to crack VI passwords. I very strongly encourage you to do so.

  16.  
    tnewton
    November 20, 2008 | 4:23 pm
     

    Wouldn’t issues of legalitybe on the user’s end, not the crack developer’s?
    I’ve had issues with password protected code and the inability to contact the developer. THe code itself was the intellectual property of the company that hired (and eventually, fired) him.
    Unless it violates one of NI’s terms of use (or if that term is legally unenforcable), cracking the VIs with the permission of the owner should be legitimate.

    The repercussions of the knowledge getting widespread may be undesirable, but if the principle of my argument holds, that is something we may have to live with – like licensed drivers getting in car wrecks. :)

  17.  
    November 20, 2008 | 5:12 pm
     

    tnewton: legal issues can be very complex, vary by locale, and probably not understood, fully, until after proven in court. That said, the DMCA basically states that it’s illegal to give people a tool that can be used for bypassing IP/copy protections. Whether this is a good law, is a whole different discussion…

  18.  
    YukeeYang
    May 6, 2009 | 9:44 pm
     

    Yup, In China, I met a guy, who like “Vi_cracker”, he can remove the password, I don’t know how he did, maybe he is a so smart guy, at the begining, I can’t believe him, and make a 8 digits(contains Capital letter,Small letter,interpunction,and number) password protection vi, and he attach my block diagram to me just after 10 mins, WOW, I am very surprise with that. I know NI uses MD5 to password protect the vi, and Nonce no one can crack MD5, if blow up with 8 digits password with Loooooop…, it would take serval month at a super computer. so I agree VI password protection to protect your intellectual property is not a clever decision.

  19.  
    YukeeYang
    May 6, 2009 | 9:49 pm
     

    That legend is happening at LV8.6.

  20.  
    May 7, 2009 | 8:35 am
     

    YukeeYang: Thanks for the information. I’ve heard similar stories.

  21.  
    BH Chan
    September 28, 2009 | 6:19 pm
     

    I have problem to access VI which create by previous programmer. The VI now is protected by password. Can anyone tell me how to remove the password ?

    If not convinient to tell me, i can send you the VI and you help to remove it

    my email is binheng.chan@my.flextronics.com

  22.  
    Daniel
    September 16, 2011 | 4:36 am
     

    It’s easy to crack this “protection” because the source code is still attached to the VI, so it can be recompiled. The only protection is the LabVIEW-application that doesn’t allow you to open the block diagram without the correct password.

    You only need to alter the behaviour of the application so it doesn’t care about you providing the correct password.

  23.  
    Barac
    October 26, 2011 | 1:09 pm
     

    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.

    The author is being absolutely right!

    Cause someone did! See this LabView VI Password Recovery Tool.
    At the moment it seem to me that this App is deactivated but it proofs the possibility of easily breaking the VIs password.
    So! Do NOT trust in the password protection of LabVIEW!

  24.  
    October 26, 2011 | 1:58 pm
     

    It was bound to happen, sooner or later, unfortunately.

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post |

 

Bad Behavior has blocked 5045 access attempts in the last 7 days.