While working with a customer on a recent RSLogix 5000 project (now called Studio 5000), there was a need to protect some proprietary source code. In this particular case, DMC had developed a custom Add-On Instruction (AOI) to be used within the project that contained some unique logic that the client wished to protect. This is incredibly easy to do. Rockwell provides an easy tool for this that comes prepackaged with RSLogix.
Since protecting intellectual property or touchy algorithms while opening up some of the code for modification or troubleshooting is pretty common, I thought I'd share some of the info I found and provide a few easy steps to locking down your code. Incidentally, while I'll walk you through configuring an AOI for source protection, you can use the same approach to protect routines as well.
Note that all of the information below can be found in various forms in two useful documents published by Rockwell Automation that I would highly recommend you download for reference:
Enabling Source Protection
Out of the box, source code protection is not enabled in RSLogix 5000. So if you have never used it, chances are good that its never been activated. To check, open up the project you are working on and look under Tools >> Security. If you don't see an option for "Configure Source Protection," then you will need to enable it.
I would assume that you really only need to make a quick registry change, but its even easier than that as Rockwell provides a free tool you can download and run to take care of it for you. Allen Bradley provides some good instructions for the process that outline the different methods for different revs of RSLogix in
Logix5000 Controllers Security. In my case, using rev 20, I needed to download Allen Bradley's Source Protection Tool. To find it, I started at their
software download page and searched RSLogix Downloads. You should see it listed as "RSLogix 5000 Source Protection Tool." This is a quick download. After running, restart RSLogix and you should see a new option under Tools >> Security: Configure Source Protection.
Ok, after enabling, you can choose your newly available option and you will now be prompted to specify a Source Key File location. Go ahead and choose a location. If you don't have a source key file in the specified directory, you will be asked if you would like to create one. This source key file will contain your keys for any protection you establish. This file can be moved from computer to computer, or it can be built locally by adding the keys you create. Go ahead and create a new one; once you've done so, you're ready to lock down your code.
Protecting an AOI
For a quick demo, I created a new project with a single Routine called 'MyRoutine' and a single AOI, 'MyAddOnInstruction.' Once you open up Source Protection Configuration from Tools >> Security, you will see that your programs and Add-On Instructions will be available. You can configure different keys and settings for each program and AOI, but lets just walk through configuration of 'MyAddOnInstruction.' Take a look and notice that there are currently no Source Keys defined.
Select your AOI you would like to protect and choose "Protect." A Source Key dialog will open allowing you to select or create a source key to apply to your selected component (in this case, our AOI). I'm going to create a new one, "MyKey" and name it DMC. If you choose not to show the key (characters will not be shown on the screen) you will need to confirm the key a second time. I prefer to just see what I'm typing. You can also define a Source Key Name. This is really just a friendly name to associate with your key (think of user name::password, key name::key) that will be shown in the Source Protection Dialog to protect your key from prying eyes.
The checkbox in this dialog is worth discussing in a little more detail. You have two choices for the level of protection you are enabling. Leaving this checkbox unchecked will completely lock and hide the code source code from anyone without the key. Any one viewing the project (or any project containing this AOI) without the key will not be able to view, access, or edit the source code for the instruction. Selecting the checkbox will allow a user to view, but not to modify the source code, in effect making it read only. Of course with either selection, if you have the key, you have full access.
It should be noted that in addition to protecting any sensitive code, this can also be used as a method of source or version control and can be a great way to prevent unauthorized or unintended edits to sections of source code that have been validated or released.
Getting back to our walkthrough, let's go ahead and leave the checkbox unchecked and select OK. This will bring us back to the Source Protection Configuration dialog again, but you will now see that the key "DMC" has been added to our AOI and it is not selected as viewable for anyone without the key.
We're done here. Choose "Close" to exit the dialog and take a look at your project tree. You shouldn't notice any changes. You can still expand and see both Tags and Logic for the AOI we just protected. However, to see what it looks like to someone without the key, I'm going to save the project, exit RSLogix, and delete my key file. Now, after reopening the project we can see that I am not able to expand the AOI - there is no access to the Tags or Logic for the instruction.
If we dig a little deeper and open up the Source Protection Configuration dialog again, we will see that 'MyAddOnInstruction' is protected and has an unknown source key. Selecting the AOI and choosing "Protect" will bring us back to the Apply Source Key dialog. Attempting to apply a new source key other than the one we already created for this instruction will give an error and will not allow us to unlock it. However, I luckily grabbed a screenshot of the earlier showing me that I used the key 'MyKey.' Sure enough, entering this key will unlock the AOI and allow access to the source code again.
It is also worth taking the time here to export our AOI. Normally, an exported AOI will be saved in human readable text in an XML type format (try it!). However, when source protection has been enabled, this exported file is encrypted.
Before I wrap this up, I want to get back to one more point. I touched upon this earlier, but its worth mentioning that there are many reasons one may want to use Source Protection within their project. In addition to protecting proprietary code, it can also be a useful method of source control. A good example may be a custom motor implementation in a large project. Once development and testing has been completed on the instruction or routine, the code could be locked by the creator to prevent any accidental changes by others. By locking and then exporting to a library, other developers can then use the instruction and be guaranteed that the source code has not been modified.
This, combined with the version information available for each AOI and routine, can be a great way to manage a shared library of reusable code. DMC strives to make code as reusable as possible as a means to decrease development time (and cost), increase reliability, and provide for scalability and modularity. Combining this with versioning software such as SVN provides for an easy way to maintain a library for all our engineers to share.
Finally, a quick disclaimer about security. I personally haven’t delved into how encrypted or hidden this method of source code protection is, but it will probably serve for the majority of purposes. In the case of extremely valuable intellectual property, I would always strongly recommend consulting with experts before trusting that this is bullet proof. DMC has acquired a wealth of experience in the past few years protecting valuable information and has the experts available should this be the case.
