Ladder Logic Total Source Protection (security)

How do I keep someone from uploading my program from a PLC and Downloading it into another PLC running an Identical machine? Specifically, RS LOGIX 5000 on a 5555. I have the source protection enabled so that the routines cannot be accessed with LOGIX software.

Is there also a way they can upload from the PLC and crack my source protection or more to the point, am I wasting my time attempting to secure this?

Is there a way to generate a random number in the 5555 processor?

Thanks in advance for any input.

Dan
_________________________________________________________

Locks only keep honest people honest. You make a better lock, you can always find a better lock picker.

Locks only keep honest people honest. You make a better lock, you can always find a better lock picker.

Click to expand...

You said it. I don't try.

I can tell you that your plans are one way to guarantee that you will never sell me one of your products. Fix it so that I don't purchase the program when I buy the machine, and I get 1/2 of a machine (no program access). That is like buying a car without being able to also buy a repair manual. What if Ford had said, "Sorry, our engine computer trouble codes are secret. We can't give you those, even though you just paid $25,000 for the car". You think I wouldn't go elsewhere?

Unless I have complete control over the machine, I WILL pass on to the next highest bidder. Who knows where YOU will be when I need help. You may leave, move to another company, retire, or die, and then I would be stuck with a worthless piece of junk. That won't happen to me, at least not for the second time. You have your right to protect your program, and I have my right not ever to buy it.

ddobson

I agree with you one hundred percent. I would never buy one either. Then again I never thought my customer was going to sell all the prints to my machine. I was dropped from an overseas bid and I came to find out that someone bought a copy of my machine. The corruption in the company that I am in a contract with leads to believe they also sold a program that they don't yet have. I have never done this to a customer before. But my inexperience with international business has led me to this end. If they want to try and sell my machine they can write their own code.

It is my sincere hope to never have to do it again.

I am a big advocate of having a single site license agreement that must be signed by a fairly high level individual in the customer's company before I turn over final documentation and programming. I include notice of this requirement in my proposals.

This certainly doesn't gaurantee compliance, but it puts everyone on notice that proprietary information is involved and they are violating a contract if they copy improperly. That has always worked for me. The real crooks can't be stopped, but they are thankfully few and far between.

I know of one major European vendor of high-speed wrappers that does use CLX source protection. Some (but certainly not all) of their routines are encrypted so that their rivals can't see how they achieve their speeds. Some of customers' techs actually like the fact that parts of the code is a "black box" as far as they're concerned; the operators now have to maintain/recalibrate the machines as opposed to leaning on the techs. to "fix" jams/crashes
by tweaking code.

As to your second point; you can see where the word "random" is not one that A-B would be keen on associating with its products but you can achieve what you want by using the CST timestamp. Try byte-swapping, multiple BTD-ing, MVM-ing (using some bytes as source and the other bytes as mask). If your program uses push buttons as inputs then try measuring the time for which they're pressed as the basis for a random number.

Randon number generation in logix 5555

Thanks Tom.

I appreciate the feedback.

On a brighter note I think I have found away for my customer to operate his machine while making his competitor's machine in operable.

My random number is going to be generated by adding 3 analog inputs from the last piece of material processed after the counter expires and saving that value to compare to a DINT that only I can give them from a key that generates to their display. I'll be onsite for a few months anyway to make sure this code is "fool proof."

Nostalgia

Does anyone remember when those old guys used to say, "I forgot more than you know." I finally realize what they meant. I completely forgot about...

"If your program uses push buttons as inputs then try measuring the time for which they're pressed as the basis for a random number."

It so simple but yet beautiful.

NOP thanks for the trip down memory lane.

Dan

______________________________________________________________

Vampires beware, I had a lot of garlic last night and I am about to have a brain-****. Silent But Deadly.

DDobson,

This is what we do for our OEM customers:

Our programming software creates two files. One is the .hex file that is downloaded to the PLC. the other is a .lad file. This is your program file. I am not certain what or how the two way loading is done by other PLC manufacturers. All we provide with our controllers is one way download to the PLC. No password is required to protect your intellectual property. Many of our OEM customers appreciate the fact that a controls manufacturer understands and supports protection for their intellectual property.

The .lad file remains in your possession, so you have complete control who you decide to give your code to.

Should our customers decide to burn the EPROM, then you eliminate the ability to download a different program to the controller. From an OEM point of view, this eliminates the ability to tamper with existing code by writing over it. Once development is complete, many of our OEM customers burn their EPROMs, creating a permanent file. If any changes need to be made later on, all they have to do is send out a new programmed EPROM to their customer. The customer changes it out and they are up and running. No service call required.

Even if someone has our programming software, the best they can do is monitor the PLC through the table.

In providing this setup, the biggest disadvantage is to the end user, who is familiar with PLCs and wants to make changes to the system without contacting the OEM. Another disadvantage that we hvae experienced is when someone is buying an old piece of machinery with our controller on it, but no documentation is included, so they would want to upload the code. Can't be done.

So, just in case your wondering, there is at least one company that is concerned with the time you spent devloping your code.

Hope this helps.

God Bless,

Stephen,

Every little bit helps. Thanks for the you time spent creating your post.

You know I might start doing this to all my machines while they are in warranty status.

At least then I have a little control over how the parts can be damaged!

Thanks again.

GE Fanuc uses a similay 'sheme' they call an 'OEM Lock' it stores an encripted version of the code in the processor. The 'only' way to change this type of code is to use a backup of the code that was made before the OEM Lock was turned on.

DDobson,

I think you may have misunderstood. This is for our brand of PLCs only. I don't believe that you have that capability with the Allen Bradley units.

There are others that offer different levels of lock out, but not specifically what we do with our ePLCs.

Just to add my tuppence worth...

Whenever I write code for a customer I let them have the code lock, stock and barrel. I find that if I do this a) the customer is happier because they have all the documentation and b) I still get called to service machines and breakdowns etc anyway because generally their own engineers don't want to "mess" with someone elses code.

Protecting your code is important in some circumstances but I've also seen it abused whereby the code author can charge whatever amount he wants in order to do code changes as he is the only one who can make mods. This can lead to an unhappy customer who feels almost as if they are being blackmailed.

I would guess that if someone can steal your code and understand it fully, then the chances are they would be capable of writing the code themselves if they needed to anyway.

I've seen too many customers left in the mire by OEM's who have set passwords etc on machines and then gone bust or the engineer who has designed the system has left the company. This leaves the customer stranded and generally, not a happy bunny...

As I said, just my tuppence worth...

BTW, for S7 PLC's you can convert your code to source and then use KNOW_HOW_PROTECT to 'lock' the programming blocks. Its not foolproof but discourages your average 'tinkerer'...

Another method that can be used when working with S7s is to encode the actual serial number of the CPU into the code so that it only works with that CPU (the CPU part number and serial number can be read with certain SFCs). The code that reads the ser# could be know-how protected, while leaving the rest of the code wide open for troubleshooting.

Of course, it would be fairly easy to hack, but it would prevent the casual user from simply uploading the code and installing it in other machines.

S7Guy said:

Another method that can be used when working with S7s is to encode the actual serial number of the CPU into the code so that it only works with that CPU (the CPU part number and serial number can be read with certain SFCs). The code that reads the ser# could be know-how protected, while leaving the rest of the code wide open for troubleshooting.

Of course, it would be fairly easy to hack, but it would prevent the casual user from simply uploading the code and installing it in other machines.

Click to expand...

S7Guy, if you read the serial number and it wasn't correct, how would you then stop the code from operating though?

Curious because your idea sounds like a belter...