"MCU break" services start at just under 1k$ and go up to a few k$ USD, the last time I checked. They're mostly based in the Far East (I'm not surprised at the author of this page) and while a lot of people may think "IP theft", they're very useful for right-to-repair, although at the higher end of the price range; if you have some old very expensive machinery to which the original company has long discontinued support or even no longer exists, the price doesn't seem so high anymore.
Functional expressions are not copyrightable. If I own a copy of the code you wrote, I am reasonably allowed to extract those purely functional expressions into my own work. Purely creative expressions are still protected by copyright. (This is why you cannot copyright an encryption key.)
When no “owner” exists, the licensing agreement is no longer valid. Copyright is a different issue. See above.
If the code is covered by patents, extracting it doesn't give you anything that reading the public patent wouldn't (if the patent was written as it should have been, to inform, and not obfuscated or ran through incomprehensible legal jargon).
And if it's a trade secret, then you relinquished it the moment you sold objects containing it. Though I realize DRM/anti-reverse engineering laws are trying to take away our right to examine how stuff works, they are absurdly immoral laws, and breaking them should never be described as "theft".
You shouldn't completely rely on the code you put out into the world in devices remaining secret. A sufficiently capable adversary will likely eventually get your data.
Whether you're talking about a $0.30 MCU with the lock e-fuse programmed, or a several-hundred-dollar (or more) SoC with triple-redundant power-management/security cores booting using unit-unique payload decryption keys burned into security fuses, the adversary might be able to get what you're trying to protect.
How paranoid you want to be about readout protection will vary depending on your goals. If you want to do a decent job blocking reverse engineering of a product to impeded clones being produced, the lock bit might do the trick.
Saw a design with battery / super capacitor and light sensor to deal with that. On light detect, kill power to volitile RAM and or wipe non volatile storage.
Cat n mouse game level up! Now it has to be done in the dark, or using a light wavelength invisible to the sensor.
or using a light wavelength invisible to the sensor.
...such as x-rays.
There are some highly secure (and expensive) cryptoprocessors which detect those too, but since security is their primary function, the effort is worth it. Otherwise you just end up spending more on protecting something of relatively little value that the cloners will reimplement in some other way anyway.
After some initial cliffs (e.g. higher-end crypto locked MCUs) at the end of the day security becomes an economic cat-and-mouse game. For cases where there's physical access to the devices at least.
I worked with a guy for a while doing high end security for buildings measured in 10's of K dollars per square foot. He was on a sort of forced retirement and had to have some work for a year or two gap before going on Social Security.
We had some amazing conversations about things like home security, say the value of a dog compared to fairly expensive systems, and the overall basic equation below as applied to threat scenarios:
Basically, when:
entry_cost < ((rewards / risks) + cost_of_sale)
...there is a chance that attempts to infringe will happen and be successful. When the risk/reward equation ends up being positive multiples of entry_cost valuation, you can count on infringement happening.
The whole game is to make that equation unfavorable and then stay ahead of all that as part of the normal product development and revisions over time, including new features, bug fixes, and the like. Obviously, strong customer relationships and value added can only strengthen the moat here. These basically increase that cost_of_sale term considerably.
Entry_cost is simply everything they need to do in order to infringe.
Rewards are a simple sales forecast, what's the revenue coming in going to look like, and why?
Risks get added up and weighted by percentage estimated likelihood to happen.
On this one, it's very similar to how sales opportunity is valued and rolled up into a forecast:
opp1 = $100k * 1 (gonna happen, done deal, no exceptions)
opp2 = $1M * 0.1 (high risk, many exceptions to overcome)
The two opps above are worth the same potential revenue! ...in terms of a forecast for that sales period, quarter, whatever. Sales teams that do not weigh their forecasts often under-perform and or show very turbulent performance relative to expected performance. Ideally, as opp2 is improved, sales exceptions removed, the degree of certainty improves, leading to more potential, real revenue in future forecasts.
Cost_of_sale is basically what it takes to do business and obtain that revenue.
That basic analysis formula has worked well in my experiences so far.
