Compiling Password Protected VIs

[ShaunR]

How do you re-compile a password protected VI?

I have a couple of VIs that are password protected, and a little tool that goes through a project, recompiles it and returns any errors and what they are (which then goes into a database)

The mass compile copes with it no problem and simply compiling from 2009 to 2010 shouldn't be a security problem. But I can't find a way to do it.

The open VI reference takes a password parameter so I presume you can't get a reference with that. And getting the reference from a project returns error 1040 (password protected) when the compile script node executes. Any ideas?

[jgcode]

I am thinking that if you don't have the password you can only just skip over them.

[ShaunR]

I am thinking that if you don't have the password you can only just skip over them.

Indeed. But not really solution though. I'm hoping I'm just missing something obvious since the mass compile (and presumably the VIPM) can do it, however the mass compile only scans directories, rather than project trees.

[jgcode]

Indeed. But not really solution though. I'm hoping I'm just missing something obvious since the mass compile (and presumably the VIPM) can do it, however the mass compile only scans directories, rather than project trees.

Sorry, I wasn't being smart, I was saying the solution is to skip them (in your script).

I doubt VIPM can do it, and I hope NI can't do too - as that means there is a security issue with using PP in my VIs (if I choose to) IMHO. I am pretty sure Locked VIs also get skipped during a mass compile in LabVIEW.

[ShaunR]

Sorry, I wasn't being smart, I was saying the solution is to skip them (in your script).

I doubt VIPM can do it, and I hope NI can't do too - as that means there is a security issue with using PP in my VIs (if I choose to) IMHO. I am pretty sure Locked VIs also get skipped during a mass compile in LabVIEW.

Hmmm.

I wasn't aware that mass compile skipped anything.It doesn't say anything about skipping in any logs when it comes across a password protected VI.

Thats unfortunate. It means that a password protected VI is no more portable than a VI with the diagram removed. I had always thought of password protecting to be a better solution because having the diagram meant you could re-compile for different platforms/versions.

[Rolf Kalbermatter]

Hmmm.

I wasn't aware that mass compile skipped anything.It doesn't say anything about skipping in any logs when it comes across a password protected VI.

Thats unfortunate. It means that a password protected VI is no more portable than a VI with the diagram removed. I had always thought of password protecting to be a better solution because having the diagram meant you could re-compile for different platforms/versions.

Password protected VIs definitely get recompiled on load when they are not in the current LabVIEW version. I'm also not understanding why Open VI Reference should fail to return a VI reference for a password protected VI when you don't provide a password. The password really only is required to make the diagram visible, so the Open BD method and some other operations are all that should fail on such a VI reference, but not the Open VI Reference itself. Have you tried to play with the flags parameter to Open VI Reference?

And jgcode can you enlighten me what would be the security issue with allowing to get a VI reference on a password protected VI and being able to execute the Compile method on that? I totally fail to see any security issue with that.

[jgcode]

Happy to stand corrected... Well wouldn't LabVIEW need access to your block diagram in order to compile it? Meaning password protecting your VI's isn't completely secure? If I PP a VI - I want no one to access it - not even NI!

[ShaunR]

Password protected VIs definitely get recompiled on load when they are not in the current LabVIEW version. I'm also not understanding why Open VI Reference should fail to return a VI reference for a password protected VI when you don't provide a password. The password really only is required to make the diagram visible, so the Open BD method and some other operations are all that should fail on such a VI reference, but not the Open VI Reference itself. Have you tried to play with the flags parameter to Open VI Reference?

And jgcode can you enlighten me what would be the security issue with allowing to get a VI reference on a password protected VI and being able to execute the Compile method on that? I totally fail to see any security issue with that.

The open vi reference will supply valid reference (ignoring projects for now). But the "compile" property will fail with 1040.

(See attached)

Happy to stand corrected... Well wouldn't LabVIEW need access to your block diagram in order to compile it? Meaning password protecting your VI's isn't completely secure? If I PP a VI - I want no one to access it - not even NI!

Nothing is password protected with time and soft-ice It just depends on how badly you want it (in most cases for me....not badly enough...lol)

Edited February 23, 2011 by ShaunR

[Rolf Kalbermatter]

The open vi reference will supply valid reference (ignoring projects for now). But the "compile" property will fail with 1040.

Well, it is unfortunate but not really a problem. If the VI needed recompiling at all, it already is recompiled when opening its reference and if it didn't need, well then why to try to force it anyways?

Happy to stand corrected... Well wouldn't LabVIEW need access to your block diagram in order to compile it? Meaning password protecting your VI's isn't completely secure? If I PP a VI - I want no one to access it - not even NI!

Well and that is where you go wrong. What you propose is no different than removing the diagram code altogether. There LabVIEW can't recompile the diagram on load anymore since it isn;t there so loading a VI into a LabVIEW system that is not the same version or platform breaks the whole hierarchy. With password protection the diagram is still there and LabVIEW can access it for recompilation when necessary. It simply won't let anyone open the diagram to look at the code. Is it absolutely safe?

Of course not, the only way to be 100% safe is not to distribute the diagram at all in any way and even better yet not distributing the VI at all since theoretically anyone with enough time at hand can go and try to find the compiled code, analyze that and reverse engineer the original diagram.

The only safety here is that locating that compiled code and reverse engineering it is a lot more complicated and time consuming than doing the same with a normally compiled C/C++ program.

[jgcode]

So... I have no idea what your point is?

All I said above is that I 'hope' NI can't do it and if they can then IMHO I think it means it's not 100% secure - which you just agreed with above??

The other thing I said is that 'I think' Locked VIs get skipped because when I tried mass compiling these they still take ages to open in a new version leaving me to believe that each time onload the compile would happen but it would never save the changes due to the Locking property - which leads to a loading performance issue. That's the reason I gave up on Locking for distributing code.

Again happy to stand correct.

[ShaunR]

All I said above is that I 'hope' NI can't do it and if they can then IMHO I think it means it's not 100% secure - which you just agreed with above??

The point is. Under windows. No dialogue based password system is 100% secure whether it's from NI or not (although I bet NI wouldn't have to spend as long as me circumventing VI passwords ) Password protection is like a key to your front door - it only keeps out law-abiding citizens Of course. I'm a law abiding citizen, so I would never consider circumventing NIs protection .

[jgcode]

Does that mean you already have??

[Rolf Kalbermatter]

So... I have no idea what your point is?

All I said above is that I 'hope' NI can't do it and if they can then IMHO I think it means it's not 100% secure - which you just agreed with above??

The other thing I said is that 'I think' Locked VIs get skipped because when I tried mass compiling these they still take ages to open in a new version leaving me to believe that each time onload the compile would happen but it would never save the changes due to the Locking property - which leads to a loading performance issue. That's the reason I gave up on Locking for distributing code.

Again happy to stand correct.

My point is that the password does disallow looking at the code, but does not encrypt it in any way. And why should it, if it did this would serve almost no purpose at all, since it would be functionally almost equivalent than removing the diagram altogether. The only difference with that would be that if you remove the diagram and loose the original then you lost all your work, with the password protection as long as you remember the password you still can get at it, even if you loose the unprotected original. But that is a minor difference that would not justify spending much resources at all to be put in LabVIEW, since loosing a password is actually easier than loosing original VIs, if you do some kind of useful backup, and we all do that, don't we?

As far as LabVIEW is concerned the password protection still allows LabVIEW to load the diagram and compile it, that is a given and not just an assumption. As such NI can create an internal LabVIEW prototype that would allow opening password protected diagrams. Of course they don't just as there is nobody out there who admits openly to have broken the password protection yet.

Bottomline: If the security of your diagram is life threatening to you, don't distribute it, password protected or not. LabVIEW can get at the diagram and so could a sufficiently determined hacker. It's not easy but certainly not impossible.

Is it safe enough to prevent usual theft? Yes I believe so! But then I have not used the password feature at all so far and don't feel it useful for the work I do, and I have even released quite a bit of code as open source, so maybe I'm just not paranoid enough to care about the password protection of LabVIEW diagrams .