Protecting your firmware. What is legal/illegal?

Thread Starter

BertPAab

Joined Aug 16, 2021
2
We're worried about a particular customer copying the firmware in one of our products. We are adding a DS18B20 temperature sensor to the design because each unit has a unique 64 bit code that enables us to detect when a copy of our hardware has been made.

We can easily prevent the copy from working but other possibilities exist. We could allow copies to work for a certain amount of time or a certain amount of operations. The question is how legal would it be to allow the copiers to produce a volume of copies before the product stops working?

The copiers would end up with a number of unhappy customers which would likely result in the copiers having to replace them with original products purchased from us. On the other hand this could result in a legal challenge of us having entrapped the copiers.

I would like to question the audience here about their feelings and knowledge,
 

DickCappels

Joined Aug 21, 2008
10,153
Not having studied it, I do not think the infringer would have a legal leg to stand on. If the infringer wants quality firmware there is nothing to stop them from paying to have it done right or licensing it from a legitimate source.

Consider if someone breaks into your home and steals a faulty piece of equipment, do they have any right to force you to have it repaired?
 

olphart

Joined Sep 22, 2012
114
Hmmm, I wonder what build makes that an issue? I don't remember a microcontroller that doesn't have robust code access protection. I'm a fan of by the time they access, disassemble and interpret, they'd have "black box" written it twice.
 

Ian0

Joined Aug 7, 2020
9,667
I heard an apocryphal tale about a British company who made fruit-machines (one-arm bandits) who were having trouble with copying. They added what looked like a via on the pcb but was just a hole. The microprocessor checked for the presence of a connection, and if it was connected changed the average payout from 95% to 105%. (This was back in the day when microprocessors had their code in external ROMs)
 

Ya’akov

Joined Jan 27, 2019
9,068
This is a question for an attorney not an engineer. The law is based on precedent and the logic of it is internal. You can reason out how things should be but unlike in engineering that doesn’t mean they are that way.

I wouldn’t call a lawyer to design a product nor an engineer to give legal opinions. If there is a chance of liability, consult an authority.
 

Deleted member 115935

Joined Dec 31, 1969
0
I can say that I have made many products that have a hook into a fixed / unique / one time programable device,
to stop this exact kind of "low cost duplication"
As far as I understand, the real manufacturer puts the constraint in the purchase agreement, no copying permitted,
and thats it.

Thinking about your phone,
each and every one of them has a unique IMEI, which allows locking

But just to highlight ,Im not legal,
 

sagor

Joined Mar 10, 2019
903
I'm not a lawyer, but I would never produce something that if copied, works for a little while then stops. You will be blamed for some form of sabotage. If you design your system such that any copy does not work at all, that is probably a "safer" way to do it. The copied devices just never work, and the customer has to return them to whoever supplied it. That way, I see no liability on your end.
Also, when you sell the system, you must clearly state that using any "copied" devices voids the warranty and all liability for your company.
You can then license your work to other companies to produce "legal" copies so you can keep an eye on it.
But like others say, best to copy protect your work if possible, so it cannot be easily copied.
 

Deleted member 115935

Joined Dec 31, 1969
0
As an aside,
once worked on a secure chip.

it had an auto destruct system built into it, literaly destruct if some one tried to take lid off to reverse engineer the silicon.
 

Thread Starter

BertPAab

Joined Aug 16, 2021
2
Hmmm, I wonder what build makes that an issue? I don't remember a microcontroller that doesn't have robust code access protection. I'm a fan of by the time they access, disassemble and interpret, they'd have "black box" written it twice.
There are a number of companies advertising services on the internet to "unprotect" various micros, unfortunately including the one we are using in this product.
 

DickCappels

Joined Aug 21, 2008
10,153
If your concern is about a current customer and you hope that after an unsuccessful attempt at copying your firmware they will continue to buy from you, you might find it wise to do as little damage to them and their business as possible. After all they are your partner in a sense.
 

click_here

Joined Sep 22, 2020
548
I'd say that if you put in a problem in your design for your competition, you have also put in a problem for your customers.

You need to talk to a patient lawyer and protecting your IP that way. Also using T/Cs as someone suggested will help.

Your product should always be the best the customer can buy.

Imagine if your competitor started using the fact that your product stopped working after x months as a way of promoting their own product... They could turn the thing you came up with to protect you against you.

The best way to out do your competition is through constant innovation and better ideas.

Accept that people will copy good designs and keep evolving your product to be better.

The real problem will be if your competitor starts out innovating you
 

JohnInTX

Joined Jun 26, 2012
4,787
If your concern is about a current customer and you hope that after an unsuccessful attempt at copying your firmware they will continue to buy from you, you might find it wise to do as little damage to them and their business as possible. After all they are your partner in a sense.
Dick, with respect, I disagree. The test for continuing business should not be did they fail in copying the firmware. They failed the test for trying to do it in the first place for the purpose of cutting out the TS's company and eliminating the revenue that TS expected from the deal that presumably determined their pricing to the customer. If it is really true that they attempted to steal the code, they have indicated that they can't be trusted. Even if they failed and keep buying, will they pay the invoices? In my 40+ years of business, I've encountered a few of those outfits and, without belaboring the details, if they would attempt to steal the code, that's an ender. You can construct contracts ad-nauseam to protect yourself from unscrupulous operators but those are expensive to write and even more expensive to enforce. Better to deal with trustworthy operators - maybe sell your product to them long enough to develop another customer.

Without knowing the specifics of TS"s deal with the customer, I'd advise a visit with an attorney skilled in IP and software copyright issues. Bring all the paperwork.

Just my .02 Been there.
Good luck!
 

JohnInTX

Joined Jun 26, 2012
4,787
To add on another level.. We had a case where we were pretty sure that a customer had cracked a codeset on a 16F84 which at the time was a target as it was used in cards to validate satellite TV subscriptions. Exploring the vendors of such cracks we found that they required 2 chips to verify. Ours were socketed. They would mess with the supply voltage and clocks until the code protection would fail but the ROM would still read. If they had 2 matches, they would conclude that their reads were valid and that was the code image.

I can't say for sure but the suspected copied stuff stopped after we:
  • Introduced new features (the LED flashes twice as fast - WOW!) to prompt an update.
  • Separated the code functions into individual files - within the confines of the PIC architecture.
  • Dynamically created a linker file to link those files in random order until we had a couple of hundred builds, functionally identical but different .HEX i.e. no simple verify.
  • Programmed sequential chips with a randomly selected build.
  • Later, we increased the shuffling by using macros that did equivalent source operations in different orders e.g. load A first vs. load B first and in a different byte order.
If the processor allows reading its program memory, you can include a copyright statement e.g. 'Copyright XYX corp 2020 all rights reserved bla bla..' then include an encrypted copy of the same statement in the code space. Log the CRC and test for it on power up. If they've deleted the plaintext, the code won't run. It sound stupid but I did this once in the program in discrete EPROM days and included a deliberately undocumented error code for a license-built product. Sure enough, after awhile, we got a call from them wondering what the error code meant... Kicked it up to legal.

Something to think about.
 
Last edited:

JohnInTX

Joined Jun 26, 2012
4,787
NXP Semiconductors P89V51RB2/RC2/RD2 8-bit microcontrollers with 80C51 core

6.10 Security bit
The Security Bit protects against software piracy and prevents the contents of the flash from being read by unauthorized parties in Parallel Programmer mode. It also protects against code corruption resulting from accidental erasing and programming to the internal flash memory.
When the Security Bit is activated all parallel programming commands except for Chip-Erase are ignored (thus the device cannot be read). However, ISP reading, writing, or erasing of the user’s code can still be performed if the serial number and length has not been programmed. Therefore, when a user requests to program the Security Bit, the programmer should prompt the user and program a serial number into the device.
Did you do all of that?
Or is the problem that you provided the program image to them for manufacturing?

Either way, if they have your producible design and are really stealing it your options may be limited to whatever legal actions you can bring, afford,etc. or whatever wrench you can throw into the works.
 
Last edited:

BertPeter

Joined Jun 19, 2020
3
Did you do all of that?
Or is the problem that you provided the program image to them for manufacturing?

Either way, if they have your producible design and are really stealing it your options may be limited to whatever legal actions you can bring, afford,etc. or whatever wrench you can throw into the works.
Hi,

Yes, we set the code protection bits but there are a number of companies that have figured out how to defeat the protection. For example see: https://www.icunlock-mcucrack.com/ic-unlock/lpc11-lpc12-lpc13-lpc17-lpc2-p87-nxp-unlock/
 
Interesting. I built a science project and I wanted to make sure the batteries were good when it came time for me to demo it. I made a sliding copper contact activated by the turning of a screw.
It was grade school. Incidently, won grand prize in every grade school science fair I entered.
 
Top