An Ethical Question

A

Thread Starter

Allen Nelson

Some time back, I figured out how to "hack" into a SLC with the "Access Denied" bit (S:1/14) bit set, as well as bypassing any passwords that the programmer may have set. For those not familiar with this feature, if the bit is set, the RSLogix software will not allow you to go online with the SLC, nor upload the program unless you have the same version of the code as is in the PLC. Allen-Bradley's intent with this bit is for OEMs to sell proprietary code without fear of it being copied (read: stolen), or the warranty voided because of software changes. It can also be used by a company to keep unauthorized users out of the SLC, but leave RSLogix installed on the PC. Rockwell publicly states that the only way to clear the bit without the original code, is to pull the battery, wiping the memory. They are wrong. It can be done (easily, if you know how) while the processor is up and running, without even stopping production. I've been tempted to publish the technique in some public forums (such as this one), but haven't for two reasons. The first is mercenary: why give away something that I can sell ;-); and the second is ethical: OEMs and SIs do have a right to keep their proprietary code secret. On the other hand, the technique is useful to a company who DOES own the rights to the software, but lost the copy that allows them online, or which suffers from an employee who accidentally or maliciously set the bit, and now cannot connect. I've considered selling a retrieval service to those companies who might need it (and if you do need it, contact me offline (Mailto:[email protected] (blatant plug, ;-) )), but the ethical dilemma is: HOW DO I TELL IF A COMPANY REALLY OWNS THE SLC CODE ? I feel morally bound, as a member of the community of integrators, not to steal someone's intellectual property, without at least an implied consent (such as the code to be found in this forum's PLC Archive). The "Access Denied" bit implies a negative consent. So, I would want any company that I perform this service for to prove that they SHOULD have the source code, either because they paid for it, or because they developed it themselves. But what constistutes proof ? How can I be sure, that I'm not ripping someone off. Or (for you open source proselytizers out there), am I wrong about the ethics? Does owning the functioning SLC automatically give the owner of the SLC the right of full and unfettered access to the code (provided they pay me to fetch it for them) ? Opinions? Allen Nelson
 
M
I'll bet that there's a SLC-500 OS revision in the works as I write this. I've never tried to prevent an end user from accessing a program that I've written. The apps that I've written tend to be one of a kind, so there's no point in protecting them from an intellectual property standpoint. I'd probably feel differently if my code had more mass market appeal. I've been torqued off when I've been provided with a piece of equipment that has had access to the PLC code protected in some manner from my prying eyes, particularly when the equipment didn't work as well as it should and some code tweaking might rectify the situation. The question is: Do you trust the owner / end user. If they're paying me for a product, I feel that they own it. ============================================= Mark Erdle The Boolean Embassy http://www.booleanembassy.org =============================================
 
L
NO! The writers of the code or the company that they work for "own" that code, proprietary or not. It is covered under the Copyright laws. In essence, under the laws of the US, anything that you right down, even if it is computer code that never leaves a processor, is automatically protected the same as if it was a registered copyright. Second, though not by much, is liability. If you mess with the code or even just access it and the machine frys, it isn't the fault of the manufacturer. It is your fault. That can be an expensive mistake, especially if it voids a warranty. If you want to sell your back-door, it is your business. Just beware of the reaction that Rockwell might have to your innovation. They may not like it, and they have attorneys on staff to deal with it. Then again, they just might buy it from you.
 
Allen, A program is the intellectual property of the company that authored it. If the company owns this then they should be smart enough to make several backups and keep them in a safe place in the event of an accidental lock or similar accident. Also the OEM that does this should not lock this until the final rev and the machine is tested and running. There is only one case that I can think of where a processor can be ethically unlocked since if it is their own program they have previous offline copies of the program and if they don't it isn't their property. This case would be an end user of a machine wants to upgrade or add to an existing machine and they go to contact the SI or OEM of the machine only to find out they have gone out of business. In this case something should be in the sales agreement of the machine that states in the event that the OEM goes out of business the intellectual property becomes property of the end user. Also there actually is NO workaround for the OEM lock if it is done correctly, the processors that you unlocked have been locked in a careless manner. It is recommended that the OEM protect the status file S2 with static protection selected in the data file properties. This will prevent the S:1/14 bit from being unlatched directly in any case. I hope this helps.
 
Allen, Since we live in a spineless society with relativistic ideas of morality, I am going to give you my perspective on your question . . . The "moral" answer is that you should get the permission of who ever owns the code prior to using it for any reason. I live by a quaint yet powerfully encompassing rule "Treat others like you would like to be treated". This is how this rule is worked out. The "Legal" answer is that anything published (including ladder logic resident in PLC memory) is immediately protected by US copyright laws and the theft of such copyrighted material is punishable by law. Unfortunately, this does nothing to protect the idea behind the code - that is what patents are for. Many companies are now specifying in purchase orders for systems with embedded code that "All software is being done *for hire*" . . . this effectively says that the code belongs to the purchaser of the system regardless of the creators desire to keep it proprietary. The "Realistic" answer is that it sounds like you have already made up your mind and you are looking for justification for your plans . . . . he who lives by the sword . . . .dies by the sword. We have had ample opportunity to scam on others code for a quick buck. These are typically low margin opportunities as there are lots of people willing to do this kind of work. Nothing brings out the creative juices as much as figuring out how to foil key disks, dongles, security bits, etc. We also realize that if they have no qualms about doing this with a former integrators equipment, they will not have much problem doing it with ours or delaying payment or . . . . We avoid clients (and potential employees) like that and pursue work with clients who have a high level of integrity and trust. In an effort to avoid this whole mess, if they pay us for the development, we always give the entire source code to the customer with no strings attached. My two cents worth. Ken Brown
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Allen Nelson <[email protected]> wrote: <SNIP> >HOW DO I TELL IF A COMPANY REALLY OWNS THE SLC CODE ? > >I feel morally bound, as a member of the community of integrators, not >to steal someone's intellectual property, without at least an implied >consent (such as the code to be found in this forum's PLC Archive). The >"Access Denied" bit implies a negative consent. So, I would want any >company that I perform this service for to prove that they SHOULD have the >source code, either because they paid for it, or because they developed it >themselves. But what constitutes proof ? How can I be sure, that I'm not >ripping someone off. Ideally the integrator is still around, and can be consulted. Another question though: If the original integrator is out of business, are you stealing from anyone by releasing it to the customer, even if the customer did not own the code? >Or (for you open source proselytizers out there), am I wrong about the >ethics? Does owning the functioning SLC automatically give the owner of >the SLC the right of full and unfettered access to the code (provided >they pay me to fetch it for them) ? No. If the author of the software did not assign the rights to someone else, then they do own it and it is not "right" to unlock it without their permission. I am fairly sure everyone here knows how I feel about proprietary protocols (Hi Dave!!) and code. However, just as I feel that it would be wrong for someone to blatently violate the GPL, I also feel it is wrong to violate the terms of any other software license. If you don't like the terms, get them changed before you accept the software. If you agree to the terms, you are bound by them. Another consideration: What will RSI think of your 'recovery' service? Opinions? Lots of them!!! --Joe Jansen
 
H

Hugh Scoggin

I don't see it as being significantly different that having a locksmith (manual or electronic) giving me access to my car or home. rgds, Hugh Scoggin TRW S&ITG
 
A

Anthony Kerstens

Just look at Napster. The situation is similar. Theoretically you are providing the means to allow others to violate copyright. Assess your own risk and make your own choice. I can't afford to tell you what to do. Anthony Kerstens P.Eng.
 
D
Allen, You must have a real problem with your conscience if you are willing to sell it as a service but won't give the info out! If you really had a problem with the ethical approach to this you wouldn't be trying to make money from it either! Dale
 
A
Actually, my conscience is quite at ease on this question, especially thanks to the comments I've received. What I've wanted to do is avoid a "Napster". It is a violation of copyright to send you a Metallica MP3 file, especially if I charge you for it. It is not a violation to send that file to Metallica (or their record label if they are the ones who own the copyright). Why they would want to pay me to do that is beside the point. (Actually, it IS a violation, since they explicitly state that "duplication...in any form...is a violation....", but if they were willing to pay me for it, they would certainly be willing to waive that protection. Sometimes analogies don't work 100%.) What I hadn't realized before was that there was an implied assumption buried in my question. I had been assuming that a potential client would be lying when they told me that they were the copyright holders to the code, and I was looking for a type of evidence to look for that would show that they weren't lying. This is why I've been close with the method, to where I haven' told colleagues how to do it, only that it can be done. However, I (naively, perhaps) generally trust people, unless proven otherwise, and have a desire to help them in any way I can. Business relationships are generally built on trust. Like the locksmith analogy, if someone is locked out of his house, and I know how to pick a lock, I'll open the door for him. But I first have to be sure that the guy actually has a right to enter that house before I let him in. So I'll borrow a line from SALT II: Trust, but verify. Have the client sign a affidavid that they own the software. Contact any vendor who's name appears on the panel or machinery that the SLC talks with. There is still an unanswered legal question, but one that I will have to consult a lawyer about. A registered copyright is usually valid for the life of the author. But we are dealing here with implied, unregistered copyrights. Do they become "public domain" after the 'death' of the company that authored them (i.e., when an OEM goes out of business, can you claim their source code (if you an get it)? I don't expect an answer from the List here (not that that's every stopped you guys before!) For the record, I don't expect to ever be able to sell this service. If someone has a SLC with the OEM lock on (which is rare - most people (myself included) don't bother to lock anyone out), they'll go to their local AB rep. If the AB rep can't help, they'll likely assume that they're stuck. Only a really intense search will find me (via this thread).
 
This thread subject is similar to those about politics and religion... I seldom "mix in!" However, you've hooked me. In my opinion, nay, experience... Legal ethics is an oxymoron. The litigation process is intended to fill, or keeps filled, the pockets of the 5th estate, ie, the legal beagles who are "looking out for their clients' best interests". Regards, Phil Corso, PE Trip-A-Larm Corp (Deerfield Beach, FL)
 
A

Anthony Kerstens

Another thought crossed my mind on this. On a previous thread there was a discussion about two-hand anti-tie down controls. In one of my responses I mentioned there was a Rockwell group providing redundant PLC configurations to satisfy the requirements of the press code. (That is, software cannot be "accidentally" modified.) What has been proposed in this thread _may_ threaten the security of that redundant PLC configuration and _possibly_ make the SLC unsuitable to meet press code requirements. Would a press code expert or anyone from Rockwell care to comment or offer insight on this particular point? Anthony Kerstens P.Eng.
 
J

Jeffrey D. Brandt

---------- Forwarded message ---------- From: "Jeffrey D. Brandt" <[email protected]> To: <[email protected]> Subject: Re: ENGR: An Ethical Question - community of integrators ><techie stuff snipped> > >I've considered selling a retrieval service to those companies who might >need it (and if you do need it, contact me offline >(Mailto:[email protected] (blatant plug, ;-) )), but the >ethical dilemma is: > >HOW DO I TELL IF A COMPANY REALLY OWNS THE SLC CODE ? > >I feel morally bound, as a member of the community of integrators, >not to steal someone's intellectual property, without at least an implied >consent (such as the code to be found in this forum's PLC Archive). The >"Access Denied" bit implies a negative consent. So, I would want any >company that I perform this service for to prove that they SHOULD have >the source code, >either because they paid for it, or because they developed it >themselves. >But what constitutes proof ? How can I be sure, that I'm not ripping >someone off. <<<>>>> First of all, you ask a leading question. "Community of integrators"??? Where do YOU work? When was the last time I saw two integrators trying not to harm each other in the eyes of the customer? Secondly, this mysterious person who has asked you to hack into a SLC is obviously on the wrong side of the ethical question already. Think about it: if he had the code, what would he need you for? Look at this from a purely practical matter. I once supplied GE 90 series controllers to an air compressor maker expressly for the 'Z' (fault) relay function. The code was locked out, HARD. Reason?: He didn't want anyone goofing up his air compressor during the warranty period. I hope you're ready to take on the liability of damage to warranted equipment when you change somebody else's code. Bottom line: If you hack into a SLC in the way you're describing, you ARE ripping somebody off. The real question is: who is the party that is really hurt by it. [let me get my flame proof suit on] Jeffrey D. Brandt
 
An Ethical issue. I have also been pondering this as I have also been sitting on this information for a few years now. Do I help or don't I? If you would like this service to be available to the public please respond to List. Allen Bradley once explained to me that this info is proprietary and that if a person was to published it they would incur their legal wrath. So, I can't publish it. But can I help a company that has been wronged by another? Maybe! Regards, Joseph D. [email protected]
 
A
> Allen Bradley once explained to me that this info is proprietary and that if > a person was to published it they would incur their legal wrath. Security by obfuscation? "Yeah, there's a big old security hole that we designed into our products so that WE can drive a truck through them. We'll just have to hope that no one publishes this info, or else we'll be screwed." There's a WONDERFUL idea. How about someone goes and posts the Top Secret Allen Bradley info to a USENET newsgroup from a terminal in a coffee shop in an airport somewhere, leaving no return address? No one to sue! Oh no! The chance of a secret getting out is proportional to the SQUARE of the people that know it... I do think that anyone trying to profit off of this bit of acquired knowledge is looking for trouble. The info has got to be out there, available to the public, or else can't be disclosed at all.
 
R
I would generally agree with this point of view EXCEPT: 1) most of the people that do this seem to be doing it for the express purpose of generating expensive field service calls 2) a lot of these field service calls result in no fix since the problem cannot be duplicated while the service guy is there 3) the warranty issue is 99% BS. If it worked right in the first place, you probably would not have to be hacking into it anyway. 4) what do you do with something like this when the OEM or integrator is gone? Best solution is not to allow this kind of thing in your plant except in extremely limited circumstances (if at all).
 
V
The question of code "ownership" is the real issue here. As a systems integrator, we sell a system, *including* *the* *code*. This means the customer owns the code. If I lock it out, preventing changes, I am in violation of my contract with my customer. Even though I wrote the code, I was paid by someone to do it. The payer (customer) is the rightful owner of the product of my work. My Opinions Only, Not My Employers. jfv John F. Vales Director of Technology Wes-Tech Automation Systems, Inc. [email protected]
 
A

Anthony Kerstens

As a note, this is not the case with everyone. There are out of the ordinary systems that for warranty agreement purposes restrict the end user from modifying the code. (oil rig equipment, etc.) Similarly, not all end-users are the owners of the equipment. Some situations involve equipment being run by a contract operator who leases the from the owner of the process. Anthony Kerstens P.Eng.
 
V
Touche, and point well-taken. If a flame was perceived, it was not intended. On the other hand, I've been the victim (more than once) of a third party locking out their code merely to force the end-user to pay, nasally or anally, for them to change it. As a systems integrator, I make a quote to my customer, am locked into a bid to integrate a machine made by manufacturer "X" into an automation system. Later, I learn that because company "X" did not get the integration contract, (on which they bid competitively against us) they locked down the code claiming "ownership". I'm now forced, or my customer is now forced, to pay exorbitant and usury fees to have company "X" unlock or otherwise work with me on the integration. This was the situation I had in mind when I replied.
 
A
It's not WHERE I work, but HOW I work (although the where is good too). If I'm on a job site with another integrator, I work with him to acheive our common goal - getting the project done, so we can get paid. If his PLC skills are weak, I'll offer to help (with his understanding that HE is still ultimately responsible for any errors on my part), just as I would hope that he would cover my weaknesses in things mechanical. Yeah, I've seen integrator pointing fingers (sometimes middle ones) at each other in front of customers. And trying to steal customers is usually fair game (just as Joseph, below, is trying to steal MY potential customers from MY thread ;-) ). But the "community of integrators" goes beyond that. Maybe it's just the Golden rule thing: "I won't delete one rung from the middle of your code while you're at lunch, if you don't delete rungs from mine" (no - I haven't seen that happen). The original reason I got in the SLC that I wasn't supposed to be in, was that my company had been contracted to perform Y2K testing on all their equipment. I had to verify proper date usage in the SLC, and asked for the source code. They didn't have it, of course. So I tried to go online, got balked, which thus became a "challenge". A few minutes later, I was in, did my date check (2 digit date was used, but not in a "non-compliant" way), and moved on. Later I learned what the purpose of the lock-out was, realized I had done a no-no, but since I had "looked, but not touched", I figured I was OK. But I got to thinking, "what if someone had asked me for the code, or if another client asked me to get code in their SLC?", what would I do? I want to help, but would it be right to do so? That's what I intended with this post. Seeing the direction the thread is heading, I fear I may have opened a can of worms. I just hope that they are only worms and not snakes.
 
Top