LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How secure is LabVIEW exe

Solved!
Go to solution

Hi all,

Is it possible for somebody to break the code in a labVIEW exe file ? I just wonder about the integrity of my code when I send to the customer !

Thanks

 

0 Kudos
Message 1 of 9
(7,692 Views)

"back in the day" of "debug" I used to read the machine langauge code to deduce what the code was doing. So in theory all code is hackable.

 

The exetent to which you can protect it is really determined by the potential threat.

 

What do you see as your greatest threat and let's see if we can get you some more suggestions.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 9
(7,691 Views)
Solution
Accepted by dphan128

 


@dphan128 wrote:

Hi all,

Is it possible for somebody to break the code in a labVIEW exe file ? I just wonder about the integrity of my code when I send to the customer !

Thanks

 


 

If you mean "how easy is it for them to see my block diagram when I do not want them to" then the answer is difficult, if not impossible.

If you give them the VI with a password protected block diagram, rest assured they will not see it.

There have been numerous discussions regarding the feasability of cracking the password, and due to a deliberately incorporated wait function placed by NI, it would be nearly impossible to brute-force guess the password.

If you simply gave them a built executable, their odds are even worse Smiley Tongue. To my knowledge, there is no way they could possibly get from an executable to the block diagram.

Cory K
Message 3 of 9
(7,680 Views)

I think if the executable has debugging turned on then the block diagram is saved in the exe.

With debugging turned off it would be extremely difficult to decompile into some form of block diagram (and the result would likely wouldn't look much the original).

 

My understanding of the password system makes it look like a DRM system which makes it theorically breakable. But I'm not sure how much effort/skill it would take. Anyway unless someone has made such a tool and put it out in the open, it's very unlikely for it to be broken.

0 Kudos
Message 4 of 9
(7,629 Views)

At first get the main 'bussiness deal': If it is easier to rewrite the code than to hack, pay me to rewrite it and not to hack it. As Ben wrote above, technically we can always hack it, but economically???

 

I've never done or tried of the following and I'm not sure if my information is correct, but that are possible ways to attack your code:

* brute force (on pwd protected diagrams): it might be possible to decrypt a single vi by brute force if you get intimated knownledge of the inner formatting. Ignore the encryption section (unbreakable encryption to store the key protected by the pwd) and brute force attack the FP section and test against the lables/captions. Thus you can ignore the LV imposed delay. If the BD is removed, you would need to be able to parse the compiled code and generate a BD from it.

-> Works on single vi's, depends on a deep knownledge how they are stored. With this knownledge, it's much better to rewrite the code.

* Extract the VI from the exe: It should be possible to extract a vi from an exe and reuse it in your own code without BD (so steal the work but not able to alter the code).

* Get your own vi's called by an exe (instead of the correct ones): Yes, that's possible. There was a 'community nugget' about this.Could be helpful to improve the attacks listed above.

 

Well, doing any of the above is illegal (and I think economically it's much better to rewrite the code, illegal option and still cheaper is to steal/bribe the source), but I wonder if we could find a way to get a hidden (c) notice in our code so we would be able to prove the origin when it's stolen ....

 

Felix

0 Kudos
Message 5 of 9
(7,614 Views)

As I mentioned above all code is hackable.

 

LV is no exception!*

 

The amount of effort you put into protecting it is determined by the threat.

 

Ben

 

* Some of the methods have been discussed previously on this forum. In the interest of keeping thoses holes covered, I will not mention those methods.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 9
(7,571 Views)

 


@Ben wrote:

 

* Some of the methods have been discussed previously on this forum. In the interest of keeping thoses holes covered, I will not mention those methods.


 

I'm not sure how I feel about this.  By not talking about it I feel that we are portraying LabVIEW as not crackable because if it was people would be talking about it.

 

I mean earlier in this post someone said "if you give them the VI with a password protected block diagram, rest assured they will not see it."  That's not true at all.  Simply because NI put a wait between retries doesn't mean I can't analyze the file independent of NI and get the password.  In just random experimentation I've been able to get the password of a couple NI VI's in the vi.lib.  Sure they just contained a DLL call but as a test it is very possible to crack a VI.  I've often thought about posting a topic of how I did it but figured it would simply be taken down because of how malicious people would use it.

 

That being said I dont' believe that a built EXE (without debug on) contains any block diagrams.

Message 7 of 9
(7,487 Views)

 


@Hooovahh wrote:

 

... doesn't mean I can't analyze the file independent of NI and get the password.  In just random experimentation I've been able to get the password of a couple NI VI's in the vi.lib.  Sure they just contained a DLL call but as a test it is very possible to crack a VI.  I've often thought about posting a topic of how I did it but figured it would simply be taken down because of how malicious people would use it.

Admitting you did that would, in my opinion, put you in violation of the License Agreement, which explictly states: "You may not: (i) reverse engineer, decompile, or disassemble the SOFTWARE". Given that, I think NI would be well within their rights to either null your license or possibly even sue you. But then, I'm not a lawyer - I'm just a regular human being. Smiley Wink

 

0 Kudos
Message 8 of 9
(7,468 Views)

 


@smercurio_fc wrote:

 

Admitting you did that would, in my opinion, put you in violation of the License Agreement, which explictly states: "You may not: (i) reverse engineer, decompile, or disassemble the SOFTWARE". Given that, I think NI would be well within their rights to either null your license or possibly even sue you. But then, I'm not a lawyer - I'm just a regular human being. Smiley Wink

 


 

I don't want to hijack this thread but I could make the argument that I didn't decompile reverse engineer or disassemble any software...but someone could argue that I did, being able to reverse engineer source code seems like a foreign concept.

 

I'm not a lawyer either and I'm also just a regular human being, and I'd hope that NI realizes that I would never do anything intentially malicous with their code and that my goal is simply to see how secure my own code would be, knowing that I am trusting their password scheme to secure my IP.

Message 9 of 9
(7,456 Views)