ControlLogix Sourde Protection

Hi, all. New to the forum. I spent some time reading some past threads about Source Protection in ControlLogix. Seems to be some differing opinions on its use and credibility. This is of great interest to me. A little history.

I have been writing programs for the same type machinery (which I do not build) for 20 years. I have had competitors upload my programs and then use them to control machines made by the same manufacturer I work for and other manufacturers. This has cost my employer several projects and plenty of revenue.

I am now attempting to prevent this from happening again. But there is one thing about the Source Protection I can not find a solid answer to...

Is it possible, legally or illegally, to "crack" the Source Protection in ControlLogix? I have had several people tell me the Source Protection was a "joke" and was easily defeated with export/import. This was tested and was determined to be a myth. The code was present, but encrypted. Is there a way to get around the encryption? Is there a "back door", intentional or not, left by RSI? RSI, Microsoft, Autodesk, and many other "software" companies go to great lengths to prevent the illegal copying and use of their software. Originally designed and coded PLC logic is no different (in my opinion). But I see no way to protect my company's investment in developing the code other than a means provided by the manufacturer. That, at least for now, leaves me with the Source Protection from RSI. So does it work? Is it really secure?

Thanks,

South

There is only one thruth when it comes to code protection: anything can be decrypted, given enough time and resources. The question that matters is: is it worthwhile. It can be that the decryprion takes so long that the result is no longer of any value for the 'hacker' or that the effort outweighs by far the revenue. Then it is worth to encrypt.

In other words: if the encryption is strong enough, then it is worthwhile to protect your source. The only source who knows in your case is Rockwell.

Kind regards,

I don't beleive that the source protection encryption in ControlLogix is "easy" to circumvent. I personally have not encrypted anything on a PLC. It just gets the valid customer mad and does little to discourage the dishonest person.

jkerekes said:

I don't beleive that the source protection encryption in ControlLogix is "easy" to circumvent. I personally have not encrypted anything on a PLC. It just gets the valid customer mad and does little to discourage the dishonest person.

Click to expand...

I know this will become a "touchy" subject if it is allowed to continue, but do you have anything on which to base your belief that it is not easy to circumvent?
My end users have no issue with the locking of AOI's to this point, and I see no reason why thry will in the future. I always offer to show them the source code so they can see what is in it and explain why I protect it and most understand completely.
If it is not easy to circumvent it does more than discourage the dishonest person, it prevents them from stealing code.

South

It can and has been circumvented, not by the average schmuck like SLC processors but don't think of it as impenetrable.

That being said if you have known instances of competitors using your code verbatim its time to contact a lawyer not install encryption. If they are just poaching your ideas and integrating them into their code welcome to the software business 90% of it is someone poaching someone else's idea for profit.

Kick-It-Up said:

It can and has been circumvented, not by the average schmuck like SLC processors but don't think of it as impenetrable.

Click to expand...

Thanks. Obviously I would like to know how long it took, what means were used, etc. but won't ask. I see where that is not allowed on this site. But knowing that it has happened means doing things a little differently.

That being said if you have known instances of competitors using your code verbatim its time to contact a lawyer not install encryption. If they are just poaching your ideas and integrating them into their code welcome to the software business 90% of it is someone poaching someone else's idea for profit.

Click to expand...

Verbatim, but merged some subroutines so it "looks" different. They did change a few things here and there due to differences in the machine, but the code I wrote was the code they used, down to the same addresses (SLC500), symbols, and descriptions. The problem with lawyers getting involved is that if it ends up in court, interpretation is everything. Without someone who knows PLC programming, techniques, standards, etc. it would be difficult to prove copying if anything in the program had changed. My experience with copyright laws are that it had better be an "exact" copy or it becomes nearly impossible to prove.

Thanks, again for the info.

South

I think the encryption in CLX is good enough. Certainly better that PLC5, SLC500. We're not protecting military secrets here. Do have them trying to decrypt it will certainly be a waste of their time. Are you only going to do this with AOIs? Makes customer debugging much harder.

As I understand it, routine source protection uses ordinary Windows encryption, starting with a hash generated by the keyphrase in the *.SK file.

The only time I've heard about a ControlLogix project even offering to be decrypted is when the file was sent to RA and run through a cracking routine. This was presented to the customer as a "we might be able to crack your encryption if the password was weak, but we're going to need quite a lot of legal proof that you have rights to the code". That customer rapidly skulked off.

I have never heard of an end user, OEM, or system integrator in North America or elsewhere successfully cracking Routine Source Protection.

That's not to say it's not possible; I was just an RA field engineer, not a developer.

I agree with K-I-U; while passwords in the PLC/SLC family were almost trivial to defeat, in the Logix family there are no backdoors or obvious workarounds.

Southner,

if you are writing code for a company (Machines r us) and they sell a machine with your code to an end user (ford for example), then the end user owns the code and all its propritary information (depending on the wording of the contract). Food for thought. A former company had a legal battle similar to this.

regards,
james

jkerekes said:

I think the encryption in CLX is good enough. Certainly better that PLC5, SLC500. We're not protecting military secrets here. Do have them trying to decrypt it will certainly be a waste of their time. Are you only going to do this with AOIs? Makes customer debugging much harder.

Click to expand...

Yes, only with AOI's. Troubleshooting is no more difficult than any other function in the program. Just as RSI will not allow access to the internals of the S-Curve function, there is no access to functions which I write. My AOI's are documented, tested, and I can support them if an issue arises. So far no complaints.

South

Ken Roach said:

As I understand it, routine source protection uses ordinary Windows encryption, starting with a hash generated by the keyphrase in the *.SK file.

The only time I've heard about a ControlLogix project even offering to be decrypted is when the file was sent to RA and run through a cracking routine. This was presented to the customer as a "we might be able to crack your encryption if the password was weak, but we're going to need quite a lot of legal proof that you have rights to the code".

Click to expand...

Thanks, Ken. I was just offered the same thing from RA, and was then told what all I needed to provide to prove it was mine, which included signing statements which made me negligible if it were not my program.

South

James Mcquade said:

Southner,

if you are writing code for a company (Machines r us) and they sell a machine with your code to an end user (ford for example), then the end user owns the code and all its propritary information (depending on the wording of the contract). Food for thought. A former company had a legal battle similar to this.

regards,
james

Click to expand...

No, sir. Our programs are coptrighted and the end user is granted a single, non-exclusive user license. That is defined in the contract which they sign. Oterwise it would not be worth the time, money and effort to develop the routines and control we develop and provide to our customers.

Programming can be done as "work for hire" in which case all rights belong to the entity purchasing the program.

South

Southner said:

Verbatim, but merged some subroutines so it "looks" different. They did change a few things here and there due to differences in the machine, but the code I wrote was the code they used, down to the same addresses (SLC500), symbols, and descriptions.

Click to expand...

If they had your descriptions, then they did not just upload your code from a machine in the field, someone handed them a copy of your original development file.

If you protect the source of your AOI, that will not prevent them from reusing it, only from modifying it.

Brownhat said:

If they had your descriptions, then they did not just upload your code from a machine in the field, someone handed them a copy of your original development file.

Click to expand...

Or they re-entered them from a printout. There were lawsuits, ownership changes, and all kinds of issues over the equipment, so I do not know exactly how they acquired the program.

If you protect the source of your AOI, that will not prevent them from reusing it, only from modifying it.

Click to expand...

Correct. I have another means of verifying the program is "legit" before allowing the AOI's to execute.

South

Boy, you sure have some great customers!