LabVIEW
Practices in Protecting VI by Removing Block Diagram and Use it in Different Platform(OSs)
Code being deployed to an RT can be compiled without debugging, eliminating the block diagram. But once a VI is saved without a block diagram, it is useless to any other OS or LabVIEW version. If you want to protect your IP, then lock the VI with a password.
mpanganiban wrote:I would like to know your practice in protecting your VI by removing its block diagram and be able to run it in different platforms(OSs).
Just password protect the VI's.
It's not much for a protection, but it's a hard limit that should tell potential hacker that what they are doing is not legal. Like a lock on the door. A burglar can break it in less then 2 minutes, but it's clear what he's doing is wrong.
Other scheme's are just not worth it. Removing the diagrams will not only make it incompatible between OS's but also between LabVIEW versions. So you need a .., 2013, 2014, 2015, 2016, 2017 version and that twice for 32-bit\64-bit (and that 3 times for Mac, Linux and Windows). So you'll end up maintaining 30 versions...
Note that you need to remove those diagrams on each of those versions. So you need to actually have those 30 versions (OS\LV\bitness) and maintain them. And you have to open your project 30 times and remove the diagrams 30 times. Just not worth the effort.
I have read related things about this and I am aware of the basic stuff such as: a VI that has its block diagram removed using a computer with a specific operating system(e.g. Windows) can only run/work in another computer with the same OS(Windows).
Exactly, and 32-bit is a different OS as 64-bit.
I don't know if others (who are also doing the same thing) have a workaround for this, let's say removing VI's block diagram in both Windows and Linux OS then do some logic to select between the two if run into another computer - I am saying an idea here that I don't even know if it is possible. But my main goal is to protect my VIs by removing the block diagram and be able to deploy/run it in another target (i.e. cRIO Linux RT).).
Here's a few ideas. And I have thought about this a lot... Let me know if you get this working, it's too much work for me right now.
So you make a distribution with VI's. These VI's are not stored normally, but encrypted. They still have their diagrams. The only way to install them is to use a decryption algorithm, using a key from an online resource. The decrypted VI's are loaded in memory (scripting) and compiled and stored without diagrams. Sounds good? Well, it's security by obscurity. All ingredients are there to manually decrypt the VI's and store them without removing the diagrams. But it will be hard.
Or make a downloading installer. The installer will download the (encrypted) VI's with diagrams. Then it compiles, removes the diagrams and saves the VI's. Again, once the construction is known, it can be bypassed. It will be more difficult, since a hacker would probably need a few tries to figure it out. A server can detect or block this...
Source code is well defined. In C\C++ supplying source code also means you can't remove comments etc.. So in LV, you can remove all free labels, sub VI control labels etc. Disconnect enums and replace with normal integers. You can even rename all VI's with their hash (as old? quick drop library). You can use scripting to mess up the diagram (can be undone easily with diagram clean up), etc.. this is called obfuscation, and it's fairly easy. Then, password protect the diagrams. Is this still source code? All context is gone...
Ask yourself who you're doing this for. Will there actually be people that try to hack your code, and if they do, will they try to resell it? If they hack it to avoid a license fee, is that worth your effort to prevent it (they probably won't by it anyway if they can't crack it). Most companies I know have licensing policies, and illegal software isn't allowed. Most civil countries have law enforcement to check these companies.
I gave up worrying about it. Do what's easy: obfuscate a bit and password protect. Send it out into the world and find honest people will pay. Forget about the rest.
Search LabVIEW like a graph! The encryption idea exists only in my head... I might have done some rudimentary experiments one day. Not with real encryption, but a simple XOR cypher. It is feasible but as I mentioned, not air-tight from a security point of view. The client PC needs to decrypt, so it needs a key, so it can be hacked.
There are fundamental reasons why "real" protection is not possible. LabVIEW needs the diagram to re-compile. So it must be available to LabVIEW if you want to use the VI on different OS or LV version. If it's available to LabVIEW, it's available to all.
Theoretically (if NI significantly changed LabVIEW), it would be possible to remove the source code (the diagram heap), and store the DIFR or LLVM instead. The DIFR or LLVM code is enough to compile, and it would be much harder to reverse. Reversing DIFR\LLVM is obviously still possible, but so is assembler...
In general, if enough people want to hack your code badly enough, it will be done. If it's a mass market product, at some point it will be hacked just for the challenge.
