Reverse engineer a CVI app?

[TonyG614]

We've been working on a CVI simulation of a new product which contains some code that may eventually be used in the actual product.  Marketing would like to release the simulation to potential customers, and we're concerned about the possibility of someone reverse engineering or disassembling the CVI app and recovering our code.  Does a release build in CVI include any debug information that could be used to reverse engineer the program?  Is it possible to disassemble the final EXE?  How big of a risk is this?

[Ian.W]

If someone has your code, the reality is they can do what they like with it given enough time, skill and motivation. The question is whether it is worth their effort.

You can make it harder for them by doing simple things like embedding the UIR in the code (if there is logic in the UIR you'd like hidden), or by using an external optimizing compiler, which I believe will make the code slightly harder to disassemble than the unoptimized CVI compiler output.  You could also add your own artificial complexity to key sections of your code. The next step up is to use a "code obfuscator" to make it much harder to disassemble.  Third party packages are available to do this.

Another option is to keep the code internal, and run several demos of the product on your PC while recording with a utility that allows you to publish a Flash-based amination on your web page. Such utilities are readily available and dead-easy to use. The "user" just watches the demo in their browser, so it won't be interactive. But you won't be (irreversibly) releasing your code to the world!

Hope this helps.

--Ian

[TonyG614]

Ian,

Thanks for the tips.  I realize that with the right motivation the code can be recovered.  I'm just trying to understand the risk. 

Although no one at NI ever confirmed this, I got the impression that earlier versions of CVI were actually running as a C interpreter and the "EXE" was really just a compressed version of the source code.  More recent versions of CVI seem to have moved closer to a natively compiled app but still aren't all the way there (given that you need to install a huge runtime library to execute them).

I guess what I'm really asking for is an explanation of what's in a CVI 8.0 compiled EXE file.

[rolfk]

---

@tonyg 614 wrote:

Ian,

Thanks for the tips.  I realize that with the right motivation the code can be recovered.  I'm just trying to understand the risk. 

Although no one at NI ever confirmed this, I got the impression that earlier versions of CVI were actually running as a C interpreter and the "EXE" was really just a compressed version of the source code.  More recent versions of CVI seem to have moved closer to a natively compiled app but still aren't all the way there (given that you need to install a huge runtime library to execute them).

I guess what I'm really asking for is an explanation of what's in a CVI 8.0 compiled EXE file.

---

Your C interpreter speculations may have had some base with the first versions of LabWindows for DOS (but we talk here about 1990 period!!) but LabWindows CVI (since about 1993) always has been a real C compiler. I have never tried to disassemble a CVI program but did a few times with programs and DLLs created with Visual C and similar compilers and yes if you want to get at that information you can get it. CVI might be even a bit more difficult to disassemble since normal disassemblers might get ashtray by some of the startup magic in CVI.

In a CVI exe file are the various compiled object code modules just as in any other C compiler created application together with some runtime object code that is LabWindows CVI specific. A lot of the meat of work is then done in the cvirte.dll and various other external DLLs so yes most of what is in a CVI exe is actually the code you wrote yourself (and possible link libraries and standard C source code modules such as instrument drivers you added to your project).

Distributing an application created with CVI is not less safe than one created with any other standard C compiler without use of code obfuscating tools. The only real safe way is anyhow to create a single backup, lock it in a safe, throw away the key and delete any other code you might still have on any harddisk.

Rolf Kalbermatter

Message Edited by rolfk on 06-29-2007 11:01 AM