User upgradable firmware

[MT]

Apparently, it is fairly cheap to have someone decap an MCU for you and read the data in there, no matter the fuses. Protecting your IP that way does not seem very productive. It is not a hurdle for any competitor or copy cats, but it is a hurdle for the guy wanting to tinker with his own hardware. That does not really work for me.

I find that naive. Fairly cheap is an understatement I think you have to pay at least $10000 to do this kind of job depending on the microcontroller.
You will not deter goverments or big companies or even medium companies, but those are probably not your real problem.
The real problem these days are the very small one or two person chinese companies that buy a western device and copy it over the weekend to bring out exact clones the next month on the market.

If it's a 2-person Chinese uoufit it will not cost $10K for a weekend. I've heard figures of a few hundred for most MCUs.
http://www.break-ic.com/index.asp

Well, so now there is no point in using flash security hardware? So will encryption do? The encrypted firmware still needs to be decrypted to be able to run on the MCU i presume?

The chinese hackers complains about dirty companies!

4:Reverse engineering is not a gold mine, with our vast client base around the world, we also had hard times when we failed with big investments on big projects, some new companies should bearly make their ends meet, so dirty companies are not uncommon in our trade, even the United States has dirty company. 6 years ago, we sent some projects to a US company which we knew each other for some years, when they failed with our projects, they did not refund the USD4000 downpayment, when the time comes to refund, they succumbed to the deadly sin -- Greed!

[Mr. Scram]

If it's a 2-person Chinese uoufit it will not cost $10K for a weekend. I've heard figures of a few hundred for most MCUs.
http://www.break-ic.com/index.asp

I have heard about similar numbers. If all it takes is what an average consumer easily has on his bank account and a few weeks patience, I can hardly imagine the trouble of development and added complexity is worth the hassle. Security theatre to fool yourself does not seem to be a productive route.

DRM that hampers paying customers, while not being a problem for organised opposition is not what I call a success. It makes sense to do it right or to not do it at all. Also, if FTDIgate teaches us anything, going after customers, even if they turn out to use fakes, is going to hurt you regardless.

Granted, there are a few different sides to this story and all have merit. I know of a few people who successfully deal with the problem by simply out-competing copycats by providing a better quality product and service and staying ahead of the curve by constant development. Admittedly, that is much easier to do with some products than others. The product being a critical application or in a niche helps.

Well, so now there is no point in using flash security hardware? So will encryption do? The encrypted firmware still needs to be decrypted to be able to run on the MCU i presume?

As far as I know, running code that is encrypted is not possible. You will either need to have the code stored unencrypted, or unencrypt it at runtime with an unencrypted key. Both the code or the key can be reverse engineered by the aforementioned method.

However, I stand to be corrected.

[MT]

As far as I know, running code that is encrypted is not possible. You will either need to have the code stored unencrypted, or unencrypt it at runtime with an unencrypted key. Both the code or the key can be reverse engineered by the aforementioned method.

However, I stand to be corrected.

Can ion beam and scanned electron microscopy technology penetrate a metal layer whos placed above flash/ram area?
(yes i know an extra metal layer is expensive)

[alm]

I would expect MCUs with encrypted flash (e.g. LPC3154) to protect the memory where the keys are stored. Yet break-ic lists the LPC3154 among the micros they can read. Maybe the caveat that it only works if the keys are not programmed? Or maybe they charge more for them? It would be pretty terrible design by NXP if reading the keys is just as easy as reading the flash. Might as well use your own decrypting bootloader.

[Kjelt]

If you do this you would not be able to use existing CDN infrastructure. Those services in their cheapest form serves static files with good TLS. Client certificate authentication is useable in CDN with PKI. If your server have metered traffic or less than ideal connection you will want to use CDN to ease the burden on your server.

I don't see your point, the firmware file is selfprotected (encrypted and hashed) so you can put it on a public forum if you like no-one is gonna be able to do something with it, no need for tls or other infrastructure, the microcontroller with its program is the only one able to do something with the file.

[Kjelt]

If it's a 2-person Chinese uoufit it will not cost $10K for a weekend. I've heard figures of a few hundred for most MCUs.
http://www.break-ic.com/index.asp 

That's scary and what scares me the most is that this site is still up and running on the open net and no-one takes it down, ridiculous.
If they can really do this for < $1000 than a lot of western companies are in deep trouble.
We have to wait for the next gen of microcontrollers that have onboard vaults that have the same kind of protection as tpm's, although I don't know silicon manufacturers that are building them which is even more scary.

[Mr. Scram]

That's scary and what scares me the most is that this site is still up and running on the open net and no-one takes it down, ridiculous.
If they can really do this for < $1000 than a lot of western companies are in deep trouble.
We have to wait for the next gen of microcontrollers that have onboard vaults that have the same kind of protection as tpm's, although I don't know silicon manufacturers that are building them which is even more scary.

Reverse engineering is not illegal. Doing a clean room design is not uncommon and has even been historically significant, as Phoenix sold their reverse engineered BIOS to several other companies,  but without it containing any original IP. That way they were successful, where others were sued into submission.

As often is the case, security through obscurity can provide an extra hurdle, but hardly adds any actual security.

https://en.wikipedia.org/wiki/Clean_room_design

[Kjelt]

Reverse engineering is not illegal. Doing a clean room design is not uncommon and has even been historically significant, as Phoenix sold their reverse engineered BIOS to several other companies,  but without it containing any original IP. That way they were successful, where others were sued into submission.
As often is the case, security through obscurity can provide an extra hurdle, but hardly adds any actual security.
https://en.wikipedia.org/wiki/Clean_room_design

That is different in that case that you should look at the system as a black box, what it does and then create your own black box with your own code that acts the same way.
In the case of the BIOS it was only allowed in court because the programmer that wrote the new BIOS did NOT have any knowledge of the source code of the IBM Bios, there was purposely built in  knowledge gap between the engineers that looked at the bios assembly code and the programming team for the new Bios, still it was on the edge of legality IMO.

But what my biggest problem is here is not that they reverse engineer and improve the code but just copy it and replace the company's name with their own name.
I have proof from my own company that this happens, we found products that were 1:1 copies of our product and we knew because one of the programmers left an easter egg in the code and that was still present in the copy  Still we could not make a courtcase out of it since it was a Chinese firm and they have different laws, we could however seize their products at the border of the EU (import restriction).
I have no problem with engineers that improve and create their own, but I have a big problem with copycats  because they ruin the company of the original R&D engineers, because invention and creation  costs a lot of money.

[Mr. Scram]

That is different in that case that you should look at the system as a black box, what it does and then create your own black box with your own code that acts the same way.
In the case of the BIOS it was only allowed in court because the programmer that wrote the new BIOS did NOT have any knowledge of the source code of the IBM Bios, there was purposely built in  knowledge gap between the engineers that looked at the bios assembly code and the programming team for the new Bios, still it was on the edge of legality IMO.

Note the link I posted. It describes a process in which a product is reverse engineered by looking at a competing product, creating a set of requirements based upon that work and then having a second team create your actual product. This method is purposefully designed to wash off any IP infringements and comply with the law. The process is not on the edge of legality, as it has been purposefully been designed to produce results that are in the clear.

I have no problem with engineers that improve and create their own, but I have a big problem with copycats  because they ruin the company of the original R&D engineers, because invention and creation  costs a lot of money.

Very true. Using other people's work in products without permission is and should be illegal, while reverse engineering in itself is not. Whatever the case, copycats are a reality and seem to always have been.

[Mr. Scram]

When I wrote the opening post of this thread, I had never seen a device of which the firmware could be upgraded using an SD Card. A lot of devices use similar set-ups, like using a USB drive, but never an actual card. After starting the thread, I came across a clip where Dave upgrades the firmware on his upcoming GW121 multimeter... using an SD Card. How cool is that? Great minds think alike, or something of that nature

Obviously, I wasn't the first to come up with the method. It's fun to see it applied regardless, and to see confirmed that it is a viable and fairly streamlined method.

[alank2]

My device mentioned in post #9 has up to 512K of EEPROM on board used for firmware.  It also allows you to program a configuration that can evaluate what it is connected to and make a decision as to which firmware to flash with, etc.