Application Builder Problems for LvClass

[LAVA 1.0 Content]

I'm not sure why this is a problem...

Just don't want to make it too easy for our competitors to figure our techniques and tricks.

[Jim Kring]

I'm not sure why this is a problem... in previous versions of LV, you could load the VIs even if they were inside the EXE using various magic tricks. It's only recently that you couldn't -- and more people have complained about not being able to access the VIs inside the EXE than have complained about not being able to access them.

I think that it's wonderful that people can't unbuild executables.

I believe that those people who were complaining about not being able to access the VIs inside of EXEs were probably just using this distribution technique as a kludge to make up for a lack of features in the LabVIEW application builder. :2cents:

[Mike Ashe]

Option 1 can be defeated by providing a VI with the same name and connector pane.

Yep, this is not hard security. But they have to know about the VI's pane, etc. A slight variation is that the subVI has only one output, a string from a key constant inside. If the returned key does not match, then no run. That is fairly secure, assuming you use a long key string of a secure letters-numbers-special_char combination.

Option 2 is possible, but requires a bit of thought+work and incurs performance penalties.

Yep, but so does any real security. Guess it depends on how valuable your stuff is and how much you need to secure it.

Now, there is a game that I can play on the C side of the code that I've used a couple of times for hiding VIs... I have the equivalent of a string control whose value is the save image of the VI and then I load the VI from the string instead of loading from disk. Thus there is no VI anywhere on disk that is the VI that I'm loading. I have no idea if any such mechanism exists on the G side of the code. Has anyone ever done something like this?

Yes, I did this several years ago with both VIs and templates for Access databases. It worked pretty well. My implementation was not so secure in that I wrote it to first copy the VI or databse to disk. If someone was watching they could abort the program and then analyze the resulting VI, but then again I wrote it more to protect against someone accidently deleting stuff, so I would always be able to restore defaults. The basic technique worked. I think it could be upgraded to be more secure.