A product is reverse engineered by replicating its behavior and not by replicating its content. Reverse engineering has been a major part of my work for the past 40 years. Making a copy is not reverse-engineering. Reverse-engineering, in this context, is based on product behavior, and not on product content.

The one thing that people have to keep in mind, in the context of this "code-stealing" thread, is that cultural attitudes toward ownership of "intellectual property" (in quotes because it is differently defined under different circumstances) vary considerably throughout the world. In the "West" we have a fairly consistent underanding of what intellectual property is and what intellectual property rights are. In the remainder of the world, however, whether the intellectual property is the firmware in an iPod, or whether it's the formula for a life-saving pharmaceutical product, all bets are off as to who is justified in opening/examining/replicating such content.

No form of electronic protection for field-programmable devices has proven to be 100% effective. If a developer chooses to protect his content, be it a CD or a CPLD or a microcontroller, by invoking the on-chip protection for his code, he's saying that the door is locked. Perhaps there's a society within which it is considered appropriate and legal to enter a locked space and examine or remove the contents, and appropriate them for one's own use. I know of no such culture, however.

In cases where, perhaps due to actions of a disgruntled employee, or some other set of circumstances, backup copies of source code and documentation, etc, have been lost, leaving only a programmed and functional product for which someone has already been compensated, the situation is terribly complicated. I have been in situations where I felt I had to retain the sources and source documents to my work "until the check clears."

Cases where source code and documentation are lost within the organization are management problems and only through experience can management be taught that loss of a bit of time during development, time which would be consumed by generating proper documentation and proper backup of every work product, is a price worth paying in order to avoid catastrophic loss of work product when an employee quits, becomes ill, or is lost due to some other unforseeable event.

Laws have been written, which offer rightful owners of intellectual property the right to recover if someone acts illegally to violate the owner's rights to his intellectual property. They all require a reasonable level of effort be expended to protect that property and the exclusive rights to it. I doubt that any court would find in favor a reckless failure to prevent intrusion into a warehouse, resulting in property loss. Likewise, it's reasonable for a prototype to be electronically protected. Given that there will be protected MCU's or other devices on my test bench, I'd want to ensure that, no matter what happens, I have a safe and reliable way to recreate what could be lost or damaged on the test bench, even if the computer used to create the content was lost, stolen, or destroyed.

I'd reiterate, that the responsibility for safe maintenance of documentation and source code is a management issue, and should be handled by them to prevent circumstances within which "extracting" protected code from a programmed MCU would be needed or even just helpful. Sound practices and procedures are the best protection.

For those reasons, I think it's foolhardy for such discussions as have occurred regarding the "cracking" of whatever protections are available for proprietary firmware to occur in this forum.

RE