Jump to content

Protecting RTEXE from hacking/reverse engineering


Zyl

Recommended Posts

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 !

Link to post

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. :D

 

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.

Link to post

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 (  :shifty: ) but the dongle solution can be something nice ti have !

Link to post

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

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By usmanf
      Does any one have an idea on how to password encrypt an Excel file (or csv) in LabVIEW or zip up the excel file/csv and add a password to it that way? I need to be able to add a simple encryption to confidential patient data files after they are created and be able open them to read later by the same program.   I've tried using OpenG to add a password protection to a Zip file but when I try to add a string variable to the password connector it says password (none) so it makes me feel like I'm doing this wrong.    I couldn't really find any similar documentation or tutorials on creating a csv or excel file then zipping up the file and adding a password to the zip with OpenG though I read about the function on the Labview forums.   A few other things over I've tried recently:   I think a solution would be to use some sort of property/ invoke node with ActiveX like I've attempted to do in the picture below but I can't find anything that explains exactly how property and invoke nodes work with ActiveX to achieve what I wanted, and I was hoping someone would have a tutorial that a LabVIEW beginner like me could use.    Something else that I looked at was adding a "blowfish" encryption to encrypt the data but seemed extremely complicated and all I need is a simple password encryption.   Finally I tried using an add on called AES crypto but I felt that the encryption methods that were featured in the add on were limiting. For patient names they would be at different lengths and in the example programs it showed that if a string was shorter than 128 bits then it would't be able to encrypt the string. Which is an issue if the patient has even a regular length name.   If you have any thoughts or find anything useful let me know.   Thanks,  From a beginner usmanf
    • By Igor Titov
      Hello everybody!
      During a few last years I received multiple appeals to release AES library that I developed in 2011 into open-source. So, I've just done exactly this: https://github.com/IgorTitov/LabVIEW-Advanced-Encryption-Standard
      I released it under MIT license (which means that there are no restrictions whatsoever). No VI passwords, no uglification.
      LabVIEWishly Yours,
      Igor Titov.
    • By Alvaro Espínola
      Does anyone have any vi of overcurrent protection? for substations? simulation only.  
    • By OlivierL
      ShaunR's recent topic on Security reminded me of a situation we explored in the summer and need to revisit at some point. We were looking for a method to protect the communication with a cRIO.
       
      The situation is that we need to communicate between a cRIO and a host on an unsecured network (manufacturing environment.) We concluded that we needed some form of encryption as well as a standard login mechanism but identified that having a single symmetrical key would not provide enough protection (for various reasons and specific use cases.)
       
      Therefore, we looked into SSL and LabVIEW Web Services because it already includes that library and all the security features that we need. We figured out that it would definitely offer the protection required but that would mean rewriting most of existing code to use Web Service instead or establish some for of communication through a new Web Service. Considering the amount of unknown and risks associated with modifying our code, we looked into an alternative and came up with the following scheme:
       

       
      In short, we would use a Web Service for the initial login and create a new symmetrical key which would be passed to the host and to the main application on the target (cRIO) and would be used to encrypt/decrypt all data during the session. This way, we could still program all of our code in LabVIEW and easily download/deploy the services and applications to the Target using NI standard tools but benefit from proper security and only have to add fairly simple wrappers to some sections of our existing code.
       
      I wonder if anyone else has already gone down that route to add protection to an existing application. Would you suggest a different implementation method or an easier path to a similar result? Is there some obvious pitfalls in this approach that we do not see?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.