Comments on: Password Protecting VIs is Security Through Obscurity http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/ an unfiltered stream of data flow consciousness Tue, 7 Oct 2008 04:15:53 +0000 http://wordpress.org/?v=2.6.2 By: crelf http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-12622 crelf Sat, 12 Jul 2008 21:44:50 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-12622 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. 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.

]]> By: Vi_cracker http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-12620 Vi_cracker Sat, 12 Jul 2008 21:38:25 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-12620 okies.. u can delete the post :) okies.. u can delete the post :)

]]> By: Jim Kring http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-12619 Jim Kring Sat, 12 Jul 2008 21:30:07 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-12619 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. 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.

]]> By: Vi_cracker http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-12618 Vi_cracker Sat, 12 Jul 2008 21:24:38 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-12618 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] 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]

]]> By: Rolf http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-1262 Rolf Fri, 28 Sep 2007 18:49:01 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-1262 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 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

]]> By: Jim Kring http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-871 Jim Kring Mon, 27 Aug 2007 19:46:02 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-871 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... 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…

]]> By: Guillaume Lessard http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-830 Guillaume Lessard Wed, 22 Aug 2007 23:11:26 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-830 The bytecode NI would need already exists: <a href="http://llvm.org" rel="nofollow">LLVM</a>. 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!! 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!!

]]> By: Jim Kring http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-823 Jim Kring Tue, 21 Aug 2007 15:37:50 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-823 First, I found a discussion thread, <a href="http://forums.ni.com/ni/board/message?board.id=170&message.id=192756" rel="nofollow">here</a>, 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. 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.

]]> By: Joe Zoller http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-821 Joe Zoller Tue, 21 Aug 2007 14:41:10 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-821 "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? “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?

]]> By: Matt Holt http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-816 Matt Holt Mon, 20 Aug 2007 18:49:05 +0000 http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/#comment-816 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. 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.

]]>