Protecting Firmware Code

Status
Not open for further replies.
Y

yeahtuna

Well-known member
Some questions...
How safe is firmware code? Can it be downloaded or copied from the device itself? Are there any strategies for releasing firmware updates (teensy 2.0) without releasing the firmware hex?

I've invested a significant amount of time developing some firmware code and it's quite troubling to me at how easy it would be for someone to steal it.

Regards,
Rob
 
The ATmega32U4 in the Teensy 2 is a low-cost processor. The built-in protection mechanisms are more the sort of lock you find on a low-cost filing cabinet than the sort you find in a jewelry store safe.

Search for "lock bits" or protection in the [FONT=Arial, Helvetica, sans-serif]ATmega32U4 datasheet.[/FONT]
[FONT=Arial, Helvetica, sans-serif]
[/FONT]Unless the firmware updates occur in a protected environment, a determined attacker can spy on the updating process and get your code.

It's not easy to know what the right balance is between investing in new features and investing in anti-tamper measures. For small companies with new products, it's hard enough to get the product to market without the added burden of engineering industrial-strength anti-tamper measures. But until the product is successful, there isn't much incentive to steal it.

Maybe the fuse bits would be a good start? Maybe giving up on the notion of customer firmware updates and potting the electronics would be a good next step?

Beyond that you're starting to look at security ICs, key management, battery-backed key storage with tamper switches, processors with built-in encryption features, custom board designs, special packaging, etc.

Hope this helps,
John

 
Thanks for the info, I will look into it. I guess not releasing firmware updates in the best plan. Unfortunately my coding invariably has bugs that need to be fixed.
 
Some companies use removable CPUs in socket headers for that reason. I.e. the chips get flashed in factory and then sent out to field, no in-flied flashing.

Downside is higher cost of board and limitation on what chips you can use as a MCU.
 
AVRs have a code protect fuse setting. Code can't be read (without extreme means). New code erases and re flashes, replacing old code.
In-field reflashing has to be simple for user, normally.
 
All Teensy2's have the AVR lock bits set. The bootloader implements a write-only protocol, so there's no way to read back the code, unless your own program provides that functionality. The bootloader also has a feature where all flash memory is automatically erased upon the first block written after the USB has enumerated. If you don't load any new code, it's possible to reboot without any changes, but as soon as you attempt to change even 1 block, the whole chip is erased, as a security feature to prevent patching attacks.

This protection is only as good as Atmel's hardware and lock bits. I personally do not know of any weaknesses, and I follow most AVR stuff online and I've never seen any credible info about any weakness. I have heard rumors that some companies can break it for a substantial fee, but even there, I've never seen these rumors actually backed up with any info of where to buy this service (a.k.a. "shut up and take my money"). It may be true, but then again I've also heard rumors of some semiconductor manufacturers spreading misinformation about their competitor's chips. If I ever do find a company offering such a service for a fee I can afford, I'll probably program a couple chips with dummy code and send them, just to confirm if they're really able to do it. Even if I can't afford the fee, if anyone ever shows me someone actually offering this service and ready to accept real money, I'll certainly remember that!

In field upgrades are much harder to protect. Using Teensy Loader, it is necessary to distribute the .hex file. The binary data is transmitted on the USB cable, so encrypting only the file would be superficial protection. I have sometimes considered creating a "secure bootloader", which could accept encrypted upgrades. I believe Atmel at one time published an app note, as I recall on a non-USB chip and using 3DES. The idea is pretty much the same, the bootloader would receive the encrypted data and decrypt it on-chip using a private key stored permanently in the bootloader. I never actually worked on this product, partly because selling bootloader software isn't a direction I want to take PJRC, and also partly because I've never heard a serious request (as in, willing to fund this software development with up-front payment).

Even with such a bootloader, the protection would only be as strong as Atmel's hardware lock bits.

It's also worth mentioning Teensy3 does NOT set the chip's hardware locks by default.
 
pictographer said:
Here's a talk entitled, "Extracting keys from FPGAs, OTP Tokens and Door Locks [30c3]".

Reversing a PIC starts around 23:30. The rest of the talk will blow your mind if you're not already familiar with Side Channel Attacks.
Click to expand...
Exact! Some company in china also uses to reverse engineering the chip by connecting to some kind of logic analyzer, it depends of what your chip it's doing. For cheap microcontrollers it's also easy create a brand new code by observing circuit and functionalities of the code. A couple of years ago I got a PLA repaired from the manifacturer on a Audio Interface that uses the reverse engineering capabilities of a chinese company to replicate the chip because they lost hex and source in a fire accident and worked, also the cost was acceptable (around 300US) so they must have some kind of well experimented method.:rolleyes:
 
pictographer said:
The rest of the talk will blow your mind if you're not already familiar with Side Channel Attacks.
Click to expand...

The whole talk blew my mind. Simply amazing to see what kinds of attacks people have dreamed up and how some very bad decisions by designers/managers/etc. led to poor cryptography solutions. As I see it, once the device is physically in the hands of an attacker, chances are slim to none that a determined adversary will not crack it over time.

Think of the $$$ that the motion picture industry invested in encryption for DVDs, Bluray discs, and the whole signal chain between the content provider and the TV set. Yet, over time, all of these standards have been cracked by determined folk who look long and hard for weaknesses.
 
Constantin wrote:
> Yet, over time, all of these standards have been cracked by determined folk who look long and hard for weaknesses.

There are lots of different TV encryption schemes. Some of them have been cracked, but several others have NOT been cracked yet.

Maybe people download the keys from internet and can watch television, but this is not cracking.
If you have a legitimate TV decoder with a legitimate subscription and (via a modified receiver) upload your received and decoded keys to the internet so others can use your keys to see the TV program (with another modified receiver), this is not cracking. This is key sharing.

And what concerns DVD and Blueray: The only reason why they could be cracked is that they have SEVERE design errors.

And concerning the video on Youtube posted by pictographer:
This is off-topic here.
You may be able to get the AES encryption key from a door lock system by a side channel attack.
But you can NOT read the entire firmware of a microprocessor with a side channel attack.

So this video has nothing to do with the original question.
You can NOT extract the program code of a Teensy with a side channel attack.

And even if you put acid on a chip and see the entire structure of the microprocessor under a microscope you can NOT read the program code stored in the flash memory under the microsocpe. If a memory cell is holding the charge of a "1" or a "0" is invisible.


Coming back to the original question:

Paul wrote:
> It's also worth mentioning Teensy3 does NOT set the chip's hardware locks by default.

How is the code running in the Teensy 3.2 protected and if it is not, is there a way to do this ?
I searched the entire MK20DX256 document and could not find anything about a lock bit.
 
Last edited:
I saw the word NECRO the other day - and that thread was just over 6 months old?

Indeed the acid exposed an ASIC where the physical bit's could be read by someone as a project for a Master's degree ? - it then continued to show on a modern device where that wasn't perhaps possible in the same way, but instead the acid exposed the FUSE bits used for locking and reset them rendering the locks reset and that chip was then vulnerable. The locks on AVR are fuse bits, but not the cortex ARM chips AFAIK.

Unknown if that applies ... the point was given the facilities and the determination to try any weakness if not in planning then in shipped hardware may be found and exploited. Is that video the one that showed every pin on a Teensy being wired to a pin on a PS2 controller contact with wire wrap wire to catch or control the device and hack it? Maybe it was in the 'suggested links' on that youtube video or a short search into areas unsupported on this forum but exposed in a whole dedicated WiKi with a step by step guide.

Anyhow - if you look at more recent threads you'll find where Paul exposed a way to change the lock bit on the T_3.2 family in the past couple of months. Not sure if I dropped it on the WikKi coming thread as it was a useful point for the newer Teensy, not sure if the same bit works on the T_3.6/3.5 - that would be a worthy note for the WiKi and for the a test on the newest Teensys.

INDEED: I did dutifully put that link in this post: Wiki-Coming-Please-link-worthy-posts
 
Hello

Yes I read the answer from Paul in the thread you have linked:
https://forum.pjrc.com/threads/34427-Does-Teensy-lock-the-flash-memory

But I don't understand it.

The Teensy has as fuse bit that can be written only once in the life time of the processor ?
And then I never can make a firmware upgrade once it is locked ?
If this is so, then I think this is not a good chip design.
Or did I understand that wrong ?


The question is if it is possible to prevent that anybody can READ the flash memory and so steal my code.
But why does this bring the danger to "brick" the Teensy ?
And it does not make sense to me why the EEPROM must be erased for that.


I have worked before with another board (FEZ Panda unsing NXP's LPC2387 micro controller) which simply allowed to read protect the flash memory.
There were no negative side effects.
You just entered a command in the bootloader ('P' for 'protect') and the bootloader said 'Deployment is protected'.
But this did not prevent further firmware uploads nor did that bring the danger to brick the processor.

I don't understand why in the Teensy this is so complicated.

I think an explanation with more details about the internal workings of the Teensy Loader would be very helpfull.
 
Teensy is complicated by a 1800 page manual for the T_3.2 processor and that goes up to something like 2,600+ pages for the T_3.6 processor and another ~2000 pages for the T_3.5 processor - all with subtle difference :(

That thread was only half of what I saw I realized after I read it through again. There is a more recent thread where the details and process are spelled out, but if will take more of a search than I did. And then it should be posted on the WiKi coming thread.

That post details for changing a byte in CORES that is written on each upload. Cortex doesn't have fuses - but setting the now included in Teensy/CORES EEPROM bit value requires a flash erase to gain access to the flash, thus making it readable only after it is blanked. It is not permanent - reprogramming is possible - after a blanking flash.

Here is the July,2016 commit change with details: github.com/PaulStoffregen/cores/commit
And the Thread Post: Setting-flash-security-byte?
 
Last edited:
We're working with the chip as designed by Freescale (now NXP). You can find documentation in the reference manual. Look at section 28.34.3 on pages 577-578.

Seems likely Freescale has some customers who wish to program the chip once and prevent anyone (even themselves) from ever changing the code after their product ships. It's pretty easy to imagine large corporate customers making safety critical products that control powerful machines might want to be certain firmware that's been tested and passed certain certifications can't ever be changed.

But whatever the reasons, Freescale made the chip this way. Originally I designed the bootloader to disallow any changes to these settings. Now it allows much more flexibility, but still tries to prevent this setting that forever locks the chip.

You may not like the fact that this feature exists in the silicon. But it does, and it's Freescale's design. Several other non-Freescale chips on the market have also started including a similar feature, to forever lock the chip and disallow erase or reprogramming. It's obviously a feature semiconductor manufacturers are providing. I don't personally like it, and obviously you don't either. But it's out of my control. Somehow I suspect semiconductor giants like NXP/Freescale are doing this because it's been requested by huge customers and they probably won't be moved by our opinions for development boards.
 
Hi Elmue, apologies if you had got this sorted already but don't forget the Teeny ICs offer multiple layers of protection. So the code in Pauls github link just protects against code extraction, it doesn't attempt to protect against writes since it's designed to allow firmware updateing. The gotcha is that part of the hardware design to prevent people even trying to probe the thing means that entering programing mode wipes the memory. Which if somebody is trying to get a programmer/debugger onto your product is what you want to happen but does mean we need to be careful of how that button is treated inside a product protected in this way.

The unit will not be truly bricked since you can still load firmware onto it, as long as the user has some method to do that.

Going full armour is not supported by any code that Paul has written that I'm aware of, and that's what can turn the device into 'write once, buy a new one later' thing. What people have done with that mode is setup some form of unlock code themselves that allows them to go through some form of authentication process to unlock the bits for an update. Critical thing is that you have to have put this code in there in the first place, and the only way to test it is by locking a Teensy... And you then need to ensure that code is both really robust (so it works if somebody bricks things some other way) but doesn't expose an attack interface all of it's own (allowing a brute force attack for example).

Some micros also offer a true 'single use only' bit that physically burns out wires that will really lock things down. Unsure if the Teensy offers such a thing beyond the locations that store the MAC address.
 
Thanks for your answers.

I just want to understand how the bootloader is working.

I suppose the following:
When I press the button on the Teensy 3.2 the tiny chip takes over control.
It shuts down the main processor and creates it's own USB interface.
It receives the firmware via USB and over some pins it injects the firmware into the main processor.
Then it reboots the main processor and goes to sleep.

Is that correct ?

The firmware in the second chip has been written by Paul?
Is it open source?
Counterfeit boards do not have this bootloader chip from Paul and so will not work with the Arduino IDE?
 
my understanding is
upon program button press
- bootloader chip takes control
- copies bootloader program into ram of main chip
- starts bootloader which
-- presents itself to PC as HID
-- receives hexfile from PC
-- erases flash
-- stores decoded hexfile in flash
-- receives reset from PC and starts new program

bootloader chip program is not open source.

Counterfeit boards are possible, if someone takes the task to program the bootloader chip
However, the product Teensy is registered trademark
As far as see, Arduino is only the software vehicle to 'ease' programming.
At the moment I use my own eclipse neon IDE with downloader derived from PJRC published software.
Others use other SW development IDEs.
 
Elmue said:
I suppose the following:
When I press the button on the Teensy 3.2 the tiny chip takes over control.
It shuts down the main processor and creates it's own USB interface.
It receives the firmware via USB and over some pins it injects the firmware into the main processor.
Then it reboots the main processor and goes to sleep.

Is that correct ?
Click to expand...

I believe so.

Elmue said:
The firmware in the second chip has been written by Paul?
Click to expand...

Yes.

Elmue said:
Is it open source?
Click to expand...

No.

Elmue said:
Counterfeit boards do not have this bootloader chip from Paul and so will not work with the Arduino IDE?
Click to expand...

Well you can buy the bootloader chip (either MKL04 or MKL02 depending on whether you want a larger chip that is easier to solder, or a smaller chip), and make your own Teensy: http://www.pjrc.com/store/ic_mkl02.html.

If you want to make your own Teensy with the MKL04 bootloader chip, you can start with this PCB design: https://www.oshpark.com/shared_projects/d3J03Zeb.
 
Last edited:
Elmue said:
The firmware in the second chip has been written by Paul?
Is it open source?
Counterfeit boards do not have this bootloader chip from Paul and so will not work with the Arduino IDE?
Click to expand...

I am sort-of curious what are you really asking? It is easy to read it many different ways, like?

Can I build a Teensy without paying PJRC for their work?

or, if I develop a new product for the Teensy, can someone easily duplicate the processor chip and cheat both PJRC as well as myself?

or, is the Teensy approach the only approach to make an Arm processor compatible with Arduino? Which I am sure you obviously know is not the case as there are several other boards out their, including some by Arduino (Due, M0, ...), plus others like Feather from Adafruit, plus...

Again just sort of curious...
 
Thanks again for your anwers.

Kurt:
I'am not interested to cheat anybody.
Paul is doing a great work and the Teensy is woth it's price.

But I have made very bad experiences in the past with other boards.
I have written software for a FEZ Panda II board from GHI Electronics which my company is using in multiple clients in multiple countries.
I started that project when the FEZ Panda II had just appeared on the market.

Then 2 years have passed and the stupid idiots from GHI Electronics took that board from the market without any exlpanation or excuse and without a replacement.
The processor is still sold, so there is no obvious reason for such a ridiculous short life time.

Also several of the Arduino boards are not sold anymore.
Stangely the oldest board (the UNO) has a longer life than it's successors although it is quite useslees due to the slow clock and the very few RAM.

So now I'am pissed off because I did a huge software development for a board that does not exist anymore.

I don't know when Paul will take the Teensy 3.2 from the market but I hope that it will be available for many many years.

For the future I don't want to do more development in vain and so I thought to create my own board with the processor of the Teensy.
But if my development still depends on Paul's bootloader chip I don't gain anything with that.

If he will stop selling the bootloader chip some day I will be in the same situation as when he stops selling the Teensy.
 
Last edited:
First, I believe we have a pretty good history of keeping Teensy available and continuously in stock. Teensy 3.2 is very popular, so of course we're going to keep making it for quite some time.

In the unlikely event Teensy suddenly vanishes, you could still get the MK20 chip from NXP/Freescale. All the software I've written is fully stand-alone (no internet access) and will continue to work. You would have to adapt to using some other tools, like P&E Micro, to get your hex file onto the chip. Or you could make a programming adaptor from any MKL02 chip or Teensy you may have (or remaining stock at the many distributors who sell Teensy). That would be inconvenient. As far as risks go, I'd say this one is pretty low (probably among the lowest in this entire market), and there are paths to adapt.... but ultimately it's your decision.
 
Paul once noted when he saw the programmer/bootloader chip previously in use with a supply threat he stocked up to support future production. In parallel he moved to the newer chip that will have longer term availability - as well as the added features that perfectly support the T_3.6/3.5 with code that wouldn't fit in the older chip - in a chip that had the smaller footprint that let the T_3.6 be what it is ... while already working to use the processor on the T_3.6 before it was available.

Nothing good in this world is guaranteed - but change is. Indications are Paul seems to be dedicated to finding the sweet spot on pricing and expanding and supporting the Teensy universe to fill what would be a void without the Teensy, with the T_3.2 cheaper than a redboard [avr clone] and more powerful and cheaper than the best from Arduino folks - with software ability enhanced more than both. He developed a 'secret sauce' that makes that work well and has kept cloner's from polluting it or compromising that.

I'm not sure what hit the GFI folks - I did the KS for the mbed mBuino they still sell - but their related products just vanished - stuff happens - even apple was nearly bankrupt back a couple of decades ...
 
Status
Not open for further replies.
Back
Top