decompiling 2009 executable

[James_R]

Wow what a security hole!

try opening up an executable built in LV2009 with winrar

 

[Mike Webster]

Just confirmed this behavior.  You can even extract them.

However, beyond just seeing the VI names, the VI's with front panels have no accessible block diagrams and other VI's have no front panel at all, so won't open in the Labview editor.

[Coq_Rouge]

I can not see any danger or security risk in this. The diagram is removed and the "source code" is protected. It is just like in Labview 7.x then the exe was renamed to .llb

Just relax and sit back. It is no sensation in this 

[James_R]

Mike

yeah but the user may use these vi's in other applications

how do I now protect my IP ?

[Dennis_Knutson]

Prior to 8.x, all that you had to do was change the file extension to llb.

[James_R · Accepted solution]

I just pulled out one of the VI's in my .exe  and used it in a new vi and it worked

the trick is not to drag and drop it on your block diagram but to call it dynamically

yes you cannot see the front panel or block diagram but you can still use the code

I think this is a HUGE security hole when it pertains to Intellectual Property. 

For example I am licensing an algrothim and paying alot of money for it and if the user can extract this algrothim and use it at will and not have to pay for the licence fee then that sucks

I currently use a HASP usb security key for protection and I tried protecting the executable and this does prevent this from happening , so I guess there is protection for this but you have to do it outside of LabVIEW

Message Edited by James R on 09-25-2009 04:13 PM

[Dennis_Knutson]

You've got a type specifier with a path and string input, etc. Was there any way to get this information from the exe or did you create the specifier because you wrote the original code? If you can't get the connector pattern and data types from the exe, is it really a HUGE security risk?

[James_R]

yes you can get this information from the exe

when I used the open vi reference I created a constant for the type specifier then right clicked it and chose the vi that I extracted from the exe and it populated the connector pattern

[tst]

This is nothing new, really.

As already said, prior to 8.x, the EXE was basically an LLB.

In 8.x, this was changed to support Windows Vista compatibility, but I'm fairly sure you could still get to the VIs if you really wanted to.

Now, the EXE structure was changed to a ZIP to allow placing the library VIs which have the same name in a single file.

As you point out, the VIs still exist with their executable code and their connector panes, so they can be used like that. Some companies (JKI, for instance) have a process where they make VIs in EXEs harder to use (they rename the VIs and the controls, they move the controls on the FP, they remove documentation, etc.) which is something you can do as well. I believe Jim Kring has more on this in his blog (as well as some of the other problems with security in LabVIEW).

It should be pointed out that this isn't decompiling, nor does it give the user access to the algorithm (which is generally considered the main thing you want to protect as your IP). You should note that even if NI changed this, someone could still do an actual decompile to try to look at what you're actually doing.

[rolfk]

I agree with all the other answers. The only thing one gains is the name of the VIs used in the application and the possibility to run them.

However as tst has pointed out if you are really that paranoid you can write your own obfuscator like what JKI does with some of their code. It moves around controls on the front panel, reshuffles the entire diagrams to an unrecognizable mess that does work right but looks anything but intelligent, removes all the labels from all controls and renames all the VIs to some random character string. Smart? Not really! Effective? Probably.

All I can say is that reverse engineering a DLL, where I actually get more or less the exact code of what the original source code was doing is a lot easier than reverse engineering a built LabVIEW executable to the same state. Sure the VI names can give me some hints as to what the application does and how it might be doing it and I could go and call all VIs dynamically and run them through zillion test vectors to get some idea what they are doing and how they are doing it, but at the time I have done that I have probably rewritten the entire application 10 times from scratch.

So as all the others said: cool down, take a deep breath and think peace. Unless you go through some highly sophisticated obfuscators, many other programming environments pose actually a lot less trouble to reverse engineer your IP than LabVIEW does. Not because LabVIEW is so much safer but because it is a niche product, its actual code generation is proprietary and therefore not easy to reverse engineer at all, unlike running a DLL through a simple disassembler. The assembly listings modern disassemblers can generate are actually fairly easy to translate back into some C code. Yes that is manual work but someone having some experience with it and possibly with the compiler you used to create that DLL can be quite effective in that.

Basically you can assume that the only way to really be sure that nobody can steal your IP is to lock the only copy of software you have into a safe, put that safe in a concrete block and the key in another concrete block, drop these two concrete blocks on the opposite sides of the globe into the sea and destroy any backup copies you still have.

But the reality is that most IP is just as easy or easier recreated from scratch than going through any elaborate ways of reverse engineering. And that reverse engineering LabVIEW compiled code is actually a lot harder than the same code compiled with a C compiler. 

Rolf Kalbermatter

Message Edited by rolfk on 09-26-2009 09:01 PM