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

[OnlyOne]

How can i protect a functional global (FunctionalGlobal_ext.vi) from being changed?

I have one VI which checks a licence and writes the result into the functional global (01_CheckLicence.vi)

Then all other VIs read this functional global to check if they are allowed to execute (02_ExecuteCode.vi).

This works, but what can i do against that someone just inserts my FG into a new VI and sets
a new value to it?

Thanks for your help

Attached all 3 VIs (LV8.5)

[TCPlomp]

Place the FG and all the VIs that call the FG inside an LVLIB and mark the FG as 'private'

Ton

[chrisger]

Hi there

You could allow the "Set licence" only one time, e.g. using the "first call?" function. Or you add some sort if identification, e.g. by passing a password. Only if the password is correct, the licence state can be set.

[OnlyOne]

Hi Ton,

>Place the FG and all the VIs that call the FG inside an LVLIB and mark the FG as 'private'

I did this, but the lvlib-file only contains references to the files on disk. That means after marking it private i still can insert the FG into a new VI.

Message Edited by OnlyOne on 01-28-2009 04:44 AM

[TCPlomp]

But they won't be able to be called. (sorry I missed the changing part).

Ton

[TCPlomp]

Some ideas (based on lvlibs).

Lock the LVLIB, this way you cannot remove the VI inside the lvlib and replace it with a different one.

If you want to make sure you call the right VI (if it is replaced on disk outside LabVIEW):

Add a tag to the lvlib with the MD5 checksum of the license VI, in the VIs calling the license file you add a code that checks the MD5 value stored in the lvlib and the actual VI.

Ton

[mikeporter]

They may be able to be placed in a new block-diagram, but the VI will have a broken arrow and be nonexecutable.

Mike...

[dan_u]

When you need to lock/password protect VIs/lvlibs to achieve your goal this means you rely again on the LabVIEW password protection. If somebody can break the LV protection they can also disable your licensing (if I'm right that you're still working on this).

There's been several threads on LV password protection security (security through obscurity).

So IMHO this is not such a good path to go. I don't have any better suggestions right now, though.

Message Edited by dan_u on 01-28-2009 02:52 PM

[OnlyOne]

The idea with MD5 works very good for me.

Now i do in one vi

1. Run external dll to check if licence-file is valid, function returns 1 for valid

2. convert 1 to string and add a customword -> 1valid

3. Do a MD5 on this word

4. Pass this MD5-string into the FunctionalGlobal

5. Inside i create the same MD5-string and compare them

6. If equal i set the value of the shift-register

Now all following vi-functions can read this FG to check if they are allowed to execute

The FG is secured first by password and second by the MD5 and third by the customword.

Also if everone can execute the FG in a new VI noone can ever get the MD5-string to set the shift-register in the FG.

[dan_u]

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.