embedded software boot camp


Tuesday, February 17th, 2015 by Nigel Jones

There’s a fascinating story from Reuters (with a far more detailed report from Kaspersky) about how a very sophisticated hacking operation, presumably the NSA, has been targeting computers by reflashing the firmware of hard drives such that the attacker controls what is loaded at boot time. If you think this has shades of Stuxnet about it, then you aren’t alone.

Why am I posting this? Well I think in the embedded community there’s been a certain amount of nonchalance concerning malware attacks on firmware, aka Firmalware. I see a lot of shrugs – it’s firmware, so it’s not modifiable, or who wants to take control of X, or to attack it they will need the source code and so on. Well if you read the articles – and I strongly recommend you do, then you’ll read that the attacker almost certainly did get hold of the source code for the disk drives, that they exploited undocumented commands, that they reprogrammed the disk drive firmware and that they proceeded to take complete control of the victim’s computer.

So what’s this to do with you? Well I strongly urge you to consider the consequences of what would happen if an attacker took control of the gadget you are working on. For example, sitting on my desk right now is a USB dongle used to receive over the air digital TV broadcasts. It doesn’t sound like it’s a great avenue for exploitation. However, an attacker could easily do the following if they had control of this device.

  1. On broadcast (i.e. over the air) command, switch the dongle into acting like a USB drive. USB drives are a major source of malware infection.
  2. Again on broadcast command, force the dongle to tune to a specific frequency resulting in the user being exposed to whatever the attacker wishes them to.

Although I’m not exactly the paranoid type, it really doesn’t take much imagination to work out how legions of embedded devices could be made to do some rather nasty things to their users.

The bottom line. If you haven’t thought about what happens if an attacker gets control of your gadget then you aren’t doing your job. Some things to ponder:

  1. How secure is your source code?
  2. If you have a bootstrap loader, how secure is it?
  3. When you distribute new firmware for installation on your gadget, is it distributed in encrypted form?
  4. Even if it’s distributed in encrypted form, is it downloaded in encrypted form?
  5. How do you protect the encryption keys?
  6. Are you setting the lock bits correctly so as to at least make binary extraction more challenging. (However don’t get too cocky – see this site )

The list could go on – but I think you get the idea.

8 Responses to “Firmalware”

  1. Jeff Gros says:

    Hi Nigel,

    Good to see you posting again.

    I cannot yet comment on the equation group (I’ve listened to Steve Gibson’s synopsis on Security Now, but I have yet to read the 44 page Kaspersky report).

    On the state of security as an embedded developer, you bring up some good points.

    The way I see it there are two critical vectors of infection: system input, and firmware update/bootloader.

    I believe that system input should be able to be locked down. I always make a point to sanitize my inputs to prevent the dreaded buffer overrun, or similar attacks.

    However, firmware update is another beast altogether.

    Many chip manufacturers allow firmware reprogramming using a hardware bootloader. There is generally no protection in terms of stopping a reprogramming effort. Even if there is a password for accessing the existing image, usually the user can erase the device and then reprogram it without a password. Even if there is password protection, I have read about hardware level attacks (low voltage, etc), which may cause the CPU to incorrectly execute the required instructions to bypass protection. To my knowledge there is not a whole lot that can be done about this, but I doubt it is that much of an issue because it requires hardware access to the device.

    As far as firmware update / bootloader is concerned, I see this as the more likely vector between the two. As a developer, if you are in control of the firmware update (via some protocol such as serial, Ethernet, etc), then you can possibly implement some sort of authentication that the image is valid and not malicious. Even if the authentication is implemented correctly, the algorithm may grow obsolete over time.

    So what is the answer? IMHO, I think it comes down to which devices should allow firmware update and which should not. When I specify that firmware update should not be allowed, what I mean is that it should be impossible (micro is ROM based, not flash or something else reprogrammable). Manufacturers will not likely develop using ROM if given a choice. If they find a fimware bug after programming a batch of chips then they just have to throw them away. They won’t make this change unless consumers demand it.

    Remember the “Bad USB” exploit we were reading about within the last year? I don’t want or need a firmware update on a USB drive.

    I don’t want or need a firmware update for a harddrive.

    How about a home router? Manufacturers routinely release updates for their firmware to compensate for the latest exploits (assuming your router is relatively new anyways, otherwise, the manufacturer might lose interest if the device is no longer for sale). Being able to update the firmware also allows the installation of open source solutions.

    How about your insulin pump? Do you want your medical devices to allow firmware updates? Do you want them to allow wireless or ethernet access?

    Do you want firmware updates for your car? Or wireless / ethernet access for that matter? While my car does have firmware in it, at least it was purchased prior to this push to add bluetooth, wireless, etc. I don’t want to check facebook while driving! In my opinion this is getting out of control.

    Hackers have long been attacking juicy targets to steal user data. It has only been recently, because of the large publicity of the attacks (against Target, HomeDepot, Anthem, etc), that anything has been done about it. Without the publicity these companies would likely just cut their losses and chock it up to the cost of doing business. My hope is that the situation will slowly improve as more companies get egg on their face.

    Considering that most people don’t even know what embedded systems are, I’m not sure that companies which produce embedded devices are yet under the same pressure to plan for security from day one of development.



    • Nigel Jones says:

      A very thoughtful comment Jeff. Firmware updates are in general a convenience for the manufacturer. I don’t think any manufacturer will eschew the potential cost benefits of having firmware updates. I think the key is probably along the lines of Dan’s comment about digital signing.

  2. Dan says:


    I’m really glad to see you bring up security concerns in embedded products. As you know, I tend to get up on my soapbox about the topic of embedded security, due to the fact that there is so little of it!!

    Anyway, just wanted to chime in regarding item #3 on your points to ponder: It’s my belief that even more important than encrypted firmware updates is digitally-signed firmware updates. A digitally signed firmware update, while not encrypted (that is an orthogonal concept), guarantees beyond a doubt, that the firmware has originated from the vendor.

    Certain encryption modes (e.g. stream ciphers) and poor encryption implementations, unfortunately, can leave encrypted firmware updates vulnerable to tampering… but a digitally signed firmware update (which could be encrypted as well) ensures that the bits you get are exactly the bits the vendor supplied.

    Note that I’m not arguing against encryption, in fact I think it’s very important for many reasons. I’m simply saying that authenticating firmware updates with a digital signature is at least as important.

  3. Michael Barr says:

    Dan is too modest to mention it, but the Embedded Security Boot Camp (http://www.barrgroup.com/Embedded-Systems/Training-Courses/Embedded-Security-Boot-Camp) that he developed and teaches for Barr Group is an excellent way for embedded system designers to quickly become experts in this subject.

  4. Wally says:

    When using small micros that take firmware updates (small = 32K flash, and clocked at 1 .. 8 MHz) the constraints on digital signing or encryption become fearsome.

    Most digital hash algorithms are large (in code) and terrible for performance. Using small cheap fast hashes is not worth it as their security is terrible (or laughable). This creates a terrible dilemma about how to manage updates securely when you have little by way of the horsepower needed to do the job properly.

  5. Jon says:

    IMO, almost all firmware should require that a hardware switch be held down while an update is made.

    • Jon P says:


      That might work for some consumer devices, but it just isn’t practical for most industrial applications like electric power meters where there are millions of devices to be updated. There are also applications like satellites where it is physically impossible to push a button on the device.

      Jon P

Leave a Reply

You must be logged in to post a comment.