Distribtuion of Labview Code

[hugh]

I have software that I want to be selling to customers how easily can someone take an exe that is installed on their computer and reverse engineer it to see the algorithms in my code

[MikaelH]

QUOTE(hugh @ Nov 15 2007, 06:41 AM)

I have software that I want to be selling to customers how easily can someone take an exe that is installed on their computer and reverse engineer it to see the algorithms in my code

You can extract all VIs from the executable very easy, but of cause you access see the block diagram (since it's not included)

But you can see the hierarchy of you VIs and if you haven't renamed the VIs name and modified the icons, you could get a quite good idea how the code is constructed.

But to understand the algorithm you use, you have to look into the compiled code in every VI and understand it. And only NI has the capability to do that.

So I would say your code it really safe.

Cheers

Mikael

[jdunham]

When you build an EXE, your VI diagrams are stripped away, so that gets you pretty far. By nature, someone could put the EXE through a disassembler to see the compiled code, but I can't imagine it would be easy to make sense of a disassembled LabVIEW program.

I have no idea what magic your software does, but most people savvy enough to reverse engineer your LabVIEW program would probably not be buying labview-based EXEs in the first place.

Mikael is right that you may want to make sure your VI names don't tell the whole story.

Good luck with your product,

Jason

[hugh]

Assuming that someone really wanted to reverse engineer my executable like a large corporation. they send it to Russia and throw a ton of money at it.

But I dont make any sense of my internal VI names would they be able to accomplish this and could I make it even harder for them to do this. I am a small company and the last company my partner started got ripped off by a huge company who just infringed on our patents and put us out of business and we just did not have the money to battle them in court.

QUOTE(MikaelH @ Nov 14 2007, 03:45 PM)

You can extract all VIs from the executable very easy, but of cause you access see the block diagram (since it's not included)

But you can see the hierarchy of you VIs and if you haven't renamed the VIs name and modified the icons, you could get a quite good idea how the code is constructed.

But to understand the algorithm you use, you have to look into the compiled code in every VI and understand it. And only NI has the capability to do that.

So I would say your code it really safe.

Cheers

Mikael

[jdunham]

QUOTE(hugh @ Nov 14 2007, 01:01 PM)

Assuming that someone really wanted to reverse engineer my executable like a large corporation. they send it to Russia and throw a ton of money at it.

But I dont make any sense of my internal VI names would they be able to accomplish this and could I make it even harder for them to do this. I am a small company and the last company my partner started got ripped off by a huge company who just infringed on our patents and put us out of business and we just did not have the money to battle them in court.

Most companies (but not all, I guess) are sensible enough to throw that ton of money at you and get your insight and the code at the same time, rather than sending the same ton of money to Russia and hoping they can tease your algorithms out of the code.

Nevertheless, it is reasonable to want to protect trade secrets in your code. I don't know whether subvi names are still accessible from a built EXE. I had thought this potential hole was plugged. Looking a little bit, you can't use VI Server to get a list of All VIs in memory, but you can use it to get a specific VI's callers and callees. If you make a good guess about a vi.lib VI which might have been used, and use it as a starting point, you may be able to rebuild the hierarchy of all of the VI names in a built executable.

To get around this, you could write a VI server routine to rename all of your subVIs with random names right before building. It seems like your time would be better spent finding venture capital partners who can provide funding and lawyers to fight off the poachers.

Aside from getting the VI names out of the executable, I don't think there is much someone could learn by attacking the EXE file, but that would really be a question for National Instruments since the system and the file formats are proprietary.

Jason

[Aristos Queue]

This is a question that I would recommend cross-posting to forums.ni.com because the folks best able to comment on this issues are more likely to monitor that forum than this one.

If you do cross-post to NI, make sure you post a link to that post here so that people interested can follow the conversation.

[Michael Aivaliotis]

QUOTE(hugh @ Nov 14 2007, 01:01 PM)

Assuming that someone really wanted to reverse engineer my executable like a large corporation. they send it to Russia and throw a ton of money at it.

But I dont make any sense of my internal VI names would they be able to accomplish this and could I make it even harder for them to do this. I am a small company and the last company my partner started got ripped off by a huge company who just infringed on our patents and put us out of business and we just did not have the money to battle them in court.

You can try contacting NI but I think they will just give you a fluffy answer. Please prove me wrong.

I would recommend doing whatever it takes to secure your app:

• Name mangle your VI names
  
• blank out the icons
  
• Remove all comments or descriptions
  
• strip the diagrams
  
• http://forums.lavag.org/VI-s-vs-SubVI-s-t3897.html' target="_blank">in-line critical code
  
• Use unnamed queues etc.
  

Also, price your product so that it's cheap enough to purchae instead of hacking. For example, instead of selling it for $10,000 make it $100 and sell more.

[Mikkel]

QUOTE(Michael_Aivaliotis @ Nov 15 2007, 05:08 AM)

• Name mangle your VI names
  
• blank out the icons
  
• Remove all comments or descriptions
  
• strip the diagrams
  
• in-line critical code
  
• Use unnamed queues etc.
  

I would consider buying something that does the above for me automagically, when I build a LabVIEW application...

If such a thing existed.

(Something like Obfuscator for C#)

-Mikkel

[hugh]

QUOTE(Mikkel @ Nov 15 2007, 03:35 AM)

I would consider buying something that does the above for me automagically, when I build a LabVIEW application...

If such a thing existed.

(Something like Obfuscator for C#)

-Mikkel

I have heard that C is much easier to reverse engineer than Labview so I do not think I would. i also have contacted Labview and here is their reply

Hey Hugh,

This is Ryan from National Instruments. As in my previous email, in

version 8.0 and less you can change the file name of the .exe

application to .llb and see a list of the vi's that are used in the

program. You cannot get back to the block diagram from a .exe. If

you want to add a further layer of protection then you can completely

remove diagrams from the source code before you even compile down

into a .exe. Make sure you back up your program because when you

remove the block diagrams you can't get them back.

Here is a link on how to remove the block diagrams from the source code:

And here is a link to what is exactly happening when you remove them from

the source code:

I have verified this information with a LabVIEW Platinum member. Let me

know if this answers your question.

Regards,

Ryan Northington

Applications Engineering

National Instruments

[LAVA 1.0 Content]

QUOTE(Aristos Queue @ Nov 14 2007, 08:53 PM)

This is a question that I would recommend cross-posting to forums.ni.com because the folks best able to comment on this issues are more likely to monitor that forum than this one.

If you do cross-post to NI, make sure you post a link to that post here so that people interested can follow the conversation.

This thrad is cross posted on the NI forums and can be found here.

Another way to increase the complexity of reverse engineering code would involve including a lot of flse leads. From my limited reverse engineering experience (no, not LV. I used to do crash dump analysis which was all reverse engineering with hardware failures thrown just to spice it up) you want to start by finding some reference point in the code that can be used to start walking through the code. This could be machine code that has a valid form of a loop, code loading, etc. To make it more difficult you could include a lot of false leads. One method of doing this involves imbedding bogus VIs within your VIs. In the "Obfuse Code" thread I presented a VI that had another VI imbeded in it as a constant on the diagram. The VI, when run, wrote the data to file and then opened and ran the VI using VI server. So to reverse engineer that VI you had to distinguish between the code of the top-level VI and the VI embedded there in. So if you included in your VI the raw data of 99 bogus VIs (that almost implemented your algorithm but all had fundamental flaws) then the reverse engineering would have to pick out the "1-out-of-100" to figure out what your code was doing. You could even through some encrytion into the data saved (in the block diagram) to add another hurdle they have to cross before they even get to the 1 in 100 chance.

Security in general

I used to work as a security consultant to the Federal Reserve Bank. The rule of thumb was "Make it ten times more expensive to break in than what was stored in the vault." So if your code is worth $100K then make it cost $1M to reverse engineer.

It also seems that a conversation with a lawyer ahead of times. It seems with the proper EULA the law suit should be stream lined greatly.

Ben

[Ton Plomp]

QUOTE(MikaelH @ Nov 14 2007, 09:45 PM)

And only NI has the capability to do that.

Are you sure about that?

You mean NI can reverse engineer any VI? Or do they need to read the machine code and make very good guesses?

Ton

[Rolf Kalbermatter]

QUOTE(tcplomp @ Nov 15 2007, 08:34 AM)

Are you sure about that?

You mean NI can reverse engineer any VI? Or do they need to read the machine code and make very good guesses?

Ton

Well not really, and they have much better things to do with their time. But in theory a few guys there have actually an idea how their compiler aligns machine code and where it puts it inside the binary VI structure so it would be possible to extract it and point a decent disassembler at it and guess from that the original code. But disassebling code is very hard, even more time consuming and in the end result you normally end up with a code construct that sort of resembles the functionality of the original code.

However a machine code to LabVIEW code disassembler is definitely not available. The best you could get is some machine code to pseudo C code I would guess. Anything else would simply be way to much work, especially since the actual LabVIEW compiler evoles over time due to new VI elements as well as better code optimization. Machine code generated by LabVIEW 3 for sure will look diffferent than the same diagram compiled in LabVIEW 8.5.

Rolf Kalbermatter