How to protect a Functional-Global from being changed outside of my code?

[Ben]

---

dan_u wrote:

Again, if somebody can break the password of the FG the other two "protections" are useless.

But probably this is still good enough, depending on the application.

---

Hi Dan,

The password protectin of LV VIs quite sustantial. The only time I have ever seen it cracked was when there was some information about the password that was known by the cracker. Even then it was not trivial. So if we keep our passwords secret and distrbute our code without the block diagrams, then we can be resonably assured our code is safe and protected.

Ben

[TCPlomp]

No, you would be able to replace the VI on disk, upon load LabVIEW will mention 'the library claims this VI, but the VI doesn't know that, do you want to update the VI'.

My proposal was storing the MD5 of the FGV inside the LVLIB.

Another method is sending a string through the FGV, the FGV does some calculation on this string, the owning VI checks the input and output to verify to that the FGV was the correct FGV.

Ton

[dan_u]

---

Ben wrote:

The password protectin of LV VIs quite sustantial. The only time I have ever seen it cracked was when there was some information about the password that was known by the cracker. Even then it was not trivial. So if we keep our passwords secret and distrbute our code without the block diagrams, then we can be resonably assured our code is safe and protected.

Ben

---

This thread states something different about security of password protection, but I agree it should be good enough for most purposes.

@TonP: I like the idea of MD5 of the VI. One thing to keep in mind is that a VI is recompiled in a newer LV version so MD5 will change.

[Ben]

---

dan_u wrote:

...

This thread states something different about security of password protection, but I agree it should be good enough for most purposes.

...

---

We agree.

Security:

Years ago when I just started with computers (1979) and PCs where just stating to hit the market, most computers where used by the military, universities and banks since they were the only organizations taht had a need for them and the resources to purchase and maintain same. So I took a job with Diebold Incorporated since they where selling alarm systems and cash machines to banks. So when the cash mahcines where all working, I would do a lot of work in the security area and consulting on the types of sensors and equipment that would be used to protect things. I learned a lot of cool stuff like a burn-bar (a steel tube with O2 pumped through it, usually used to to cut up scrap in steel miils) could burn through a re-inforced concrete wall in matter on minutes. So they could be detected by imbedding linings in the concrete that would be cut when the wall was cut and set off an alarm. So for most threats there was a solution. But there came a time to decide how much protection do you through at something? The answer was explained to me as "You want to make it cost more to break in than they would get if they did." So if you are protecting $1M, then makes usre it cost $2M to break in.

So applying that rule of thumb to software, I have never been involved in any code that was worth the trouble working so hard to protect it.

Just sharing a war story,

Ben

[dan_u]

Interesting story and very good point with security measures should be adequate to secured items.

Thanks for sharing!

[parthabe]

---

Ben wrote:

Hi Dan,

So if we keep our passwords secret and distrbute our code without the block diagrams, then we can be resonably assured our code is safe and protected.

Ben

---

Just came here through a search...

Ben, is it necessary to password-protect the VIs that are to be distributed without diagrams?

[Ben]

---

parthabe wrote:

---

Ben wrote:

Hi Dan,

So if we keep our passwords secret and distrbute our code without the block diagrams, then we can be resonably assured our code is safe and protected.

Ben

---

Just came here through a search...

Ben, is it necessary to password-protect the VIs that are to be distributed without diagrams?

---

Again it depends on how vaualbe your code is. If your code could save the life of a hacker's child, then they may put in the effort to reverse engineer the code starting with the machine code and working backwards. Similarly if it was national defense or an extreme valuable ($$$) peice of code (I can't think of any code off-hand as an example).

So removing the block diagram is usually good enough, but this is just my opinion.

Ben

[Dennis_Knutson]

Imho, distributing code without block diagrams is just plain wrong and you should use a password. A VI without a block diagram cannot be loaded with a newer version of LabVIEW. A password protected VI can. Many years ago, I bought a toolkit that had no block diagram. When I upgraded my version of LabVIEW, the toolkit was worthless and the company that had created it was no longer around. I will never, ever use code from someone that removes the block diagrams.