Protecting RTEXE from hacking/reverse engineering

[Zyl]

Hi,

 

One of my customer is creating systems with high added value. These systems relies on a both CompactRIOs and deported computer code.

These systems will be deployed all around the world, and should be hardly protected against copy.

Concerning the computer code, they decided to use a dongle system to decrypt the exe each time this one is launched.

 

How to do something similar with the RTEXE on a compactRIO ? Is there a solution to encrypt an RTEXE ? Is it possible to remove VI's block diagrams in a RT EXE ? Is this solution sufficient to protect the code from reverse engineering ?

 

Any advice will be welcomed !

 

Thanks !

[Rolf Kalbermatter]

Hi,

 

One of my customer is creating systems with high added value. These systems relies on a both CompactRIOs and deported computer code.

These systems will be deployed all around the world, and should be hardly protected against copy.

Concerning the computer code, they decided to use a dongle system to decrypt the exe each time this one is launched.

 

How to do something similar with the RTEXE on a compactRIO ? Is there a solution to encrypt an RTEXE ? Is it possible to remove VI's block diagrams in a RT EXE ? Is this solution sufficient to protect the code from reverse engineering ?

 

Any advice will be welcomed !

 

Thanks !

 

Unless you explicitly tell the deployment engine to include the VI source code in the built executable (for remote debugging for instance) it will be completely removed and only the compiled machine code and connector pane resource will be included. As such it is quite a bit harder to hack than a normally compiled object code executable, since the executable code is placed into the binary file in a LabVIEW specific way, not how MSVC or GNUCC would normally do it. The machine code itself is of course machine code as that is the only way to allow the CPU to actually execute it, but if someone goes to the effort to hack that, the only measure to prevent that is to put your system in a steel safe together with any copies of your source code and dump it above the Mariana Trench, if you get my drift.

 

You can improve the obscurity a bit by renaming the VI names (and relinking the VI hierarchy) to some useless names, so that the VI names inside the deployed executable are just useless nonsense, but such a tool is not readily available and would have to be developed and then before each build invoked as a pre build step. The most simple way for that would be to load all top level VIs into memory and then recursively rename their subVIs to some random string and finally saving each of them. More advanced operations would require the use of semi documented VI server functions.

 

But even self extracting encrypted executables won't stop a determined hacker, but at most slow him (or her) down for a few hours. They do check for active debuggers before doing the extraction, but there are ways to get around that too.

[Jeffrey Habets]

I agree with Rolf, but just in case you need more, you might have a look at this dongle solution for LVRT from WireFlow: http://www.wireflow.se/products/wf2007

[Zyl]

Hi Rolf and Jeffrey !

Thank you very for responding that fast !

Indeed, if a hacker really wants to break the code, he will at the end find a way to do it. The idea behind my question was to know if there was anything that could be done easily and that can reassure my customer.

So I think I won't dive into Mariana Trench for this project (  ) but the dongle solution can be something nice ti have !

[smithd]

The dongle solution is probably better but this walks through a similar solution just using the information we can pull from the cRIO SW.

http://www.ni.com/example/30912/en/

note this hasn't been updated in ages so the concepts still work but there might be easier ways to get the data, like the system config tool -- for example if you yank out serial number and eth0's MAC address you could be decently sure you have a unique identifier for the cRIO.

 

You might also want to follow many of these steps, esp disabling the FTP or webdav server (step 9)

http://www.ni.com/white-paper/13272/en/#toc9