Destroying the firmware if fuse bits are reset

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. For the past few days I've been looking around for cons and pros for encrypting the AVR firmware with AES, XTEA, XOR etc. Seems like everyone agrees there's little to no point in that since megas can have their lock fuses reset for few hundred $. So, I'm quite likely missing something here, but is it possible to simply implement check in bootloader which reads lock bits and if they're reset simply flash entire chip with 0xFF? Auto-destruct if you will.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How would that work for the "hacker"? All they need do is change the lock state then power up the chip held in _RESET and then perform ISP to extract the image. The "destruct" code need never get a chance to run.

 

Face it, AVRs are NOT secure chips, if you value your firmware more than the $500 it costs to break in then don't use an AVR or use one in such a way that it is reliant on some "mechanism" that cannot be so easily broken. However whatever you have in the AVR to control and interact with some external "secure unit" will be visible so it needs to be done in such a way that even seeing that it is still secure - that could be quite a challenge.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
All they need do is change the lock state then power up the chip held in _RESET and then perform ISP to extract the image.

 

Ah, there's the gotcha. I knew there was something...

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, generally speaking: If something seems too good/simple/whatever to be true/possible/relevant/whatever then it probably is.

 

And since prices on a market works on supply, demand and perceived customer value, but not so much on on actual manufacturing cost, the pricing you see on secure memories (in or out of microcontrollers) are substantially higher than on non-secure ones.

 

If it was that easy someone would have done it, and it would have spread, and there would be no place for the silicon sellers to pull the prices they do for secure devices when a $1 AVR would suffice.

 

So.. It was too good to be true/possible.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One scenario may be good enough. I am not sure what microcontroller you have in mind, but Mega328PB and all Xmegas have unique serial number.

 

Have your application read this serial number, and compare with a value written in flash.

 

The production steps would be:

  • have your bootloader read the serial number
  • automatically change your code with the new serial number (you may obfuscate it by doing some simple math, shifts, CRC, encryption etc
  • compile
  • update the firmware

 

Now, in order to make it difficult,  move parts of your firmware from here to there so a disassembly from one device would look very different than from another device. If you are the owner, have this aspect known only by you.

 

I see two ways stolen firmware being used:

1. just blindly copy the hex from flash and use it for a cloned product - in this case the solution would be effective

2. copy the hex, disassemble it and figure out how the serial number is used.

 

Would it work ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@angelu: Your scheme requires one build for every produced device, which is possible but awkward. Never mind the possible need for sending out an update to a device "in the field" - if this is needed then the procedure is becoming a nightmare. Add the possibility that your "obfuscation" measures might introduce bugs.

 

The potential costs might well be higher than investing in a secure controller.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

angelu wrote:
(you may obfuscate it by doing some simple math, shifts, CRC, encryption etc
The problem with anything like this is that the $500 will always get someone into a copy of the code and the dedicated hacker can reverse engineer anything it may be doing, however complex you try to make it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

@angelu: Your scheme requires one build for every produced device, which is possible but awkward. Never mind the possible need for sending out an update to a device "in the field" - if this is needed then the procedure is becoming a nightmare. Add the possibility that your "obfuscation" measures might introduce bugs.

 

The potential costs might well be higher than investing in a secure controller.

 

Indeed, I am talking about hundreds of devices which all require single flash which works on all devices, so the proposed solution isn't acceptable. I know this might not be the best place to ask, but does the same problem (cheap unlocking) plague ARM chips (STM32Fx)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If you *really* need secure (and when most people say they do, they actually don't)* then use a secure microcontroller.

 

*most people seriously over-estimate how much their firmware is worth.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
then use a secure microcontroller.
+1

Brian Fairchild wrote:
people seriously over-estimate
+10

 

The fact is that simply by monitoring the inputs and outputs of a typical AVR MCU application it's usually pretty easy to monitor and then replicate behaviour while what is inside remains a "black box".

 

But these micros that use the charge on the gate of a "lock" transistor to disable their programming /read back mechanisms are generally always going to be "crackable" by those who are determined. I think the technique involves using a laser to change the state of the charge on the gate of a specific transistor or something (after removing the covering plastic with hydrofluoric acid) so, no, only micros deliberately designed for security are really secure.

 

Atmel do provide some chips to aid in secure designs but if you google "Atmel secure microcontroller" all the links from Google to atmel.com are now dead so presumably you need to find the new home for this stuff on the Microchip site?

 

EDIT: perhaps here (so some bits of atmel.com still work): http://www.atmel.com/products/se...

 

EDIT2: expect that it seems that all the links from there lead to the same "service not available" I was seeing before :-(

Last Edited: Wed. Aug 16, 2017 - 12:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure if this would work, but you could set the programming pins to outputs so they're driven high or low, thus disabling the programmer from connecting to it - why might it not work? Well I don't know off the top of my head but if the device you're using can be connected via it's programming interface while being held in reset then it doesn't matter what state you're application puts the programming pins into... 

 

Assuming your device can't be connected while being held in reset, a hacker could still use HVPP to get into your device however if you're working in high enough quantities, you could have the markings on your microcontrollers removed. This way the hacker would have to guess what the device is and which pins to use for HVPP, and if he/ she gets the wrong pins the first time round then it's likely they'll fry the device anyway.

 

Disclaimer I haven't looked into this at all so there might be some fundamental reason this simply wouldn't work, I've just stumbled across this thread and thought 'what if...' :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:

...the hacker would have to guess what the device is and which pins to use for HVPP...

 

On an AVR, HVPP goes in on the /reset pin and that pin is easy to find with a multimeter.

 

Other manufacturers have standard pinouts and it's normally quite easy to work out what chip family you have in front of you from the location of the power pins which themselves are easy to identify.

 

I Someone who knows a number of families can normally identify the chip in front of them within 10 minutes.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

Last Edited: Wed. Aug 16, 2017 - 07:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
On an AVR, HVPP goes in on the /reset pin and that pin is easy to find with a multimeter.

Easy with a package with visible leads/ pins and the reset signal trace on an exposed layer so you can see where it goes (probe straight to the pin or where ever the signal trace goes) but not so much with a QFN or BGA (or some other package without visible pins) with the reset signal trace buried in an internal layer ;)

 

But quite right;

Brian Fairchild wrote:
Someone who knows a number of families can normally identify the chip in front of them within 10 minutes.

so perhaps not such a good idea...

Last Edited: Wed. Aug 16, 2017 - 07:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The whole thing becomes very much like virus writers and anti-virus writers. If there's money (or enough thrill) in it the virus writers will find a new way to get through, the anti-virus writers gets isolated specimen in a couple of days or weeks, devises an anti-virus and the process repeats..

 

Similar with protecting your firmware. If your firmware have a perceived value that is high enough, the crackers will find a way to get through  your (not so) clever arrangements. The value they see is the value they can sell a clone for times the number of clones they can sell. Since clones are can be sold at a very low price compared to the original thing, a relatively large effort/cost might be put into the cracking'n'cloning.

 

Example: The Saelae Logic analyzers. Cost for the original thing: $600. Clone: roughly $50.

 

Aside, re SaleaeNot that it should be that hard to clone. Just opened my, real-thing, Saleae Logic 16 and nothing is obfuscated, disguised or so. A Xilinx FPGA and a bit of other stuff for the USB etc. So they get one real Saleae and downloads the software. FPGA bitfile (its "firmware") comes from PC, presumably, at startup. Just tap the USB to get it. Then clone the hardware. Design into a somewhat less fancy housing (a much less fancy housing, actually!). Sell for a tenth of the cost of the real thing and you have 99% of the hobbyist market. And probably a substantial part of the semi-pro/small-pro market as well. MEanwhile the Saleae folks are crying, looking at the thousands of hours that went into the firmware (bitfile) and the host application. If Saleae decides it is worth it to stay in the market, then the cloners will just continue laughing all the way to the bank - they get software and firmware updates for free. Occasionally the makers of the "original thing" changes their design, perhaps obfuscates things etc and the cloners are a number of weeks behind again until they've cracked the new thing. Just like the virus makers and hunters.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Locks only keep out the honest people...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use smd parts on the board then flood it with black hard resin at top and bottom side. Or put the board inside a small metal box then fill with hard resin maybe better.
It can be frustating to just try to looks what's inside.
.
MG

I don't know why I'm still doing this hobby

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another reason to switch to ARM??

 

From Microchip.com - SAM 4s:

 

  • Safety and Security — Integrated best-in-class hardware code protection:
    • Prevents access to on-chip memory to protect your intellectual property (IP).
    • Supports secure device reconditioning (chip erase) for reprogramming.
    • A unique 128-bit ID and scrambled external bus interface ensure software confidentiality while the hardware cyclic redundancy check (CRC) checks memory integrity.