I have been asked to unprotect an RSLogix 5000 application by a client. Has anyone done this before? It is looking for protection keys but since the machine builder (who is out of business) did not give it to him initially. The RSLogix version is 11. Thanks.
This may be a dumb question (my best) but is it looking for the keys to run the software or have they protected the program itself. (IE logix 500 style).
I assume it is the first and the software protection for the RSLogix 5000 itself needs to be "purchased". Each copy of RSL needs a key to run it and then you can open all the programs with it you want.
If the software was purchased from RSI, there will be a record of the serial number and you will be able to get the key (probably after paying support) but if you did not get it, you will have to purchase the software and key.
Project Management: note make sure you have the software and all passwords for programs you requisition. And a back up strategy........or you get burned......
If it is the second, I am not sure, it has been a while since I used RSL5k and didn't know you could lock out, heard it was added ?
It is not a matter of RSLogix 5000 License.
With RSLogix 5k version 13 you can protect from editing an existing program. You, for maintenance purposes, can monitor the ladder or any other part of the code but you cannot edit it, unless you have the "key file" created during the protection.
i think your client has learned an expensive lesson on being stupid enough to buy a machine from someone who does this kind of thing.
A bit harsh Bob, there is not enough background info to make that call. Could be the builder was not payed and therefore did supply the key, and maybe now is out of business from not getting paid.
I did a job where I used source protection on a routine, I didn't want anyone modifying without seeing me, and before I had copied/backed up the files I had a hard drive failure. I was able to create a new key with the same text I had used originally. Sorry but this wont help if the builder had used some text that is not obvious.
I don't think it is harsh at all. The idea of accepting this type of nonsense on a piece of custom made machinery is just plain stupid in my book. I don't care what the supposed justification is.
Custom machine makers come and go. What the heck do you do to maintain your machine that has a secret password on the PLC code you do not know when the machine maker is gone??
I could understand if there was some legitimate trade secret involved that you might not want it spread all over town. In that case, as an end user I would certainly agree to a confidentiality agreement. But I cannot consider a case where I would have no way to maintain the machine if the OEM died off.
From what I can tell, the primary reason this is done is to generate revenue from service calls. If the end user cannot get at the code, there are many things that are very difficult to debug, and so you have to call in the service tech who has the password that opens up a lot of debugging info.
Well, between the PLC manufacturers and integrators, 80%
of what you need to know to maintain your machine is secret anyways. And nearly 100% of your typical PC software. And though I agree with you strongly on this point, I can't see where it's reasonable to expect someone who wrote a program for a closed system, with closed tools running on a closed OS to generously open their code, when the public tolerates this despicable behavior everywhere else. Closed source software sucks for maintainability in any of its many manifestations, but as long as people support it, they kinda deserve what they get. And you ain't seen nothing yet with "Digital Rights Management" top of the list for the closed source crowd. It's one thing when you don't receive your code. Pretty soon they'll lock up your data as well. There's only one way out, the OSS community will welcome you, when you've finally had enough.
In reply to Curt Wuollet - DRM offers the ability to impose a lot of restrictions which we are today not used to dealing with.
For example, with DRM, data files (e.g. back-ups of PLC programs) can be tied to specific computers (i.e., you can only open the program on a specific computer). WIth a DRM system, your supplier could provide you with copies of the PLC programs, but you can't open them until they send you a key (this would be independent of any actual password in the programming software). If
the contract said they don't get paid until they "deliver" the programs, then they can meet the contract terms without actually giving you anything useful.
If you have a soft logic or SCADA, or other PC based system, the vendor could tie the use of the application program to a specific PC. For example, they could ensure that you can only replace the PC with one from the original supplier. So for example, a SCADA supplier could provide you with a complete system which includes a standard (cheap) off the shelf PC, but if anything goes wrong with it, you have to buy your replacement hardware from them. This gives the supplier all the lock-in advantages of proprietary hardware without the cost of designing and building their own.
Shrink-wrap software vendors will likely stop "selling" software. They would only sell one year licenses under a service contract. If you don't renew your service contract, you can't run the software. They would also be able to lock the data files, so you can't switch to a competing vendor with a compatible file format (nor convert the files). Either you keep paying the original
vendor, or all your digitally stored work becomes inaccessible.
Another idea could be to give away the proprietary PLC programming software for no charge, but you must pay to unlock each PLC program on each subsequent PC it is copied to. That is, a sub-contractor would deliver a copy of the PLC program to you, but you must pay the PLC vendor to unlock it for you on each of your PCs. This would be a pay per use scheme that would let them extract more revenue from larger customers (or rather ones with more PLCs) while giving them a low entry cost. The PLC program developers would favour the use of this because it would cost them nothing (the end customer pays for everything after delivery). This could of course be combined with a service contract to fine tune the revenue extraction to the greatest possible degree.
Much of the above is technically feasible today, but is difficult and expensive to implement and so is not widely used (except for things like paid music downloads). DRM will be standard a feature in future versions of Windows, so software developers will be able to use it without much extra expense or effort. Updating the DRM system to patch holes in it will be Microsoft's job, so with regular updates (and your DRM'd data file may expire without regular updates) reverse engineering of file formats will be effectively impossible.
I have given a few simple examples, but I am sure that a few minutes of thought would turn up many other ways in which DRM could be used to control the use of the data. Essentially though, what it does is transfer the effective ownership of the *data* from the creator to the software vendor. This is a concept that is so different from what we have become used to, that many people will have a hard time grasping the extent of the implications. I expect that we will learn all the ways in which it can cause problems the hard way.
Yes, I would love to hear from any user who can say that this "innovation" will be good for them in any way. But they'll be waiting in line at midnight to buy the latest version of Windows and willingly lead the Trojan Horse to their data. This surrender of rights will be particularly bitter for those of us who have worked hard to make software FREE but are forced by dire necessity to use monopolyware in their jobs. It is unlikely that I will give Microsoft the rights to what is mine, but that which I do for the company will be subject and that's bad enough. And yes, if people grasp the implications they should be cutting up pillows and cooking tar for
delivery in Redmond. But I'm afraid, as usual, this will be like putting a frog in a pot of cold water and turning on the heat, by the time folks are ready to jump, it'll be all over. It proves that MS has the power over people to get away with anything. Scary, and it doesn't bode well for our freedom.
We have been asked to perform a simialar task and thus far have not been able to find a solution. I spent some time embedded with RA so some phone calls where made to people that may have information on this topic. The response is that there is no back door. I can believe that RA has not come up with a way in however hackers love this kind of challenge however I've been all over the web and haven't found a solution yet.
Is your program file view only or is the logic hidden? If you can see the logic can it not be replicated? In our case the logic is hidden.
I will stay away from the off-topic trail of discussion regarding protecting code.