Strings being obfuscated in exe's produced in LabVIEW 2010?

[Thomas_robertson]

We upgraded from LV 8.6 to LV 2010.  In doing so, it seems that all the strings in the compiled version of our code (the exe file) have disappeared.  Previously we could search through the exe file with a hex editor and find our companies name, the presidents name, strings on front panels, etc...  We were using such strings to determine that someone stole our code and compiled them into their own executables.

Is the LabVIEW 2010 compiler doing some sort of compression or encryption which is causing our strings to disappear?

Is it still possible for people to extract VI's from compiled executables?

[Jarrod_S.]

I believe the issue you are seeing is related to the fact that LV executables now store their internal files in a zip format. The data is being compressed. There should be an option in the App Builder to maintain the LV 8.6 layout, which builds executables based on the old LLB format with no compression.

[gmart]

A follow up to Jarrod's post. Since LabVIEW 2009, LabVIEW executables store the internal files using a zip format. There is no compression of the data. Using the option Jarrod mentioned to build using the old layout does not result in the use of LLBs. A zip format is always used.

[Jarrod_S.]

Thanks for the clarification, George!

[Coq_Rouge]

If someone are willing to go through the trouble of using your code. The change is that they also will be able to see through your way of creating watermarks also will be very big. It has been discussed before on this page. And it is a consensus. That "code" without diagram is kind of worthless.

[Coq_Rouge]

---

@gmart wrote:

A follow up to Jarrod's post. Since LabVIEW 2009, LabVIEW executables store the internal files using a zip format. There is no compression of the data. Using the option Jarrod mentioned to build using the old layout does not result in the use of LLBs. A zip format is always used.

---

If I remember correct a exe file from Labview 2009 could be opened by winrar. But this loophole was removed in 2010. Or at least done much harder to figure out.

@Thommas here is a link to such a discussion regarding unwrapping Labview EXE files http://forums.ni.com/t5/LabVIEW/decompiling-2009-executable/td-p/991662/page/3

[Thomas_robertson]

Thank you for linking to that other post.  So, am I to understand that it is much more difficult to extract VI's from compiled executables in LabVIEW 2010? 

The reason we're doing this is that we have two competitors selling our product or their own derivative based on subsets of our code (in China where it's very hard to take legal action). 

This watermark plus a mathematical check for the watermark in order for the code to work was a method I devised to try to protect our code.  Now I'm a little unclear what to do, since, if they extract our vis and call them from their program which they compile to exe the compiler will zip the vis and obscure the watermark anyway.  So my method is not usefull.

It may not be a problem if they can't extract vis from our exe, but I'm unclear as to whether that's the case or not.

[paul_a_cardinale]

I just checked.  It is possible to extract VIs from .EXEs in LV 10.

[Dennis_Knutson]

You should be using the new licensing option to protect your code.

[F._Schubert]

If you want a custom protection, here my first-coffee idea:

Place a control on the SubVIs you want to protect. This control should not be wired to the ConPane. When the SubVI executes, it checks the value of this control if the input is valid (e.g. Watermark + Checksum).

Your Main-VI is opening a ref to the SubVI via VI server and initializing the control with watermark+checksum before calling it the normal way.

To make it even more difficult for them, don't let your SubVI just abort but behave stupid, like throwing a file-error requesting a call to support, always returning a temp-reading 2° to high or the like. Make it a bit of a hassel for them to reuse the stolen code.

Second idea: Store a SubVI as an encrypted binary (default value of a string control). During runtime, decrypt it and make it a VI which is called dynamically. I'm not sure if you can do this in memory only (preferable in secure mem) or you need to save it in a temp folder (which would make it much to open for them).

Felix