RSS Feed

Embedded Systems Blog

Could Ransomware Go Embedded?

May 23rd, 2017 No comments

Could Ransomware Go Embedded?

For criminal hackers, ransomware has become increasingly popular. Ransomware locks a PC or encrypts its data and ask for a ransom to be paid to the hackers to unlock the PC or decrypt the data.

To which extent are embedded systems vulnerable to similar attacks? How realistic is it that firmware update mechanisms are used by hackers to install foreign code? Although loading malicious code to deeply embedded systems might seem far-fetched, some of the Snowden documents have shown that this already happened to the firmware in disk drives. Also, the well-documented Jeep Cherokee attack in 2015 that allowed a remote operator to almost entirely remote control the vehicle shook the industry. A wake-up call?

The Challenges

For hackers, the challenging part is that even though there has been a development to use more off-the-shelf hardware reference designs and software, most Embedded Systems platforms are still different from each other. Different microcontrollers require different code, so that ransomware has to be tailor-made for a specific microcontroller. The bootloader mechanisms in place are also different which means hackers need to find exploits for every one they are trying to attack.

A hacker’s task would be to write an exploit that manages to replace the entire original code and includes an own, password-protected, bootloader. With payment of the ransom, the hacker would share details on how to use his bootloader. There would of course always be the risk that this feature was not tested well enough by the hacker and a restore was not possible at all. It can be assumed that far more effort would have gone into generating the exploit and replacement code than the unlocking and restoring procedure.

Note that many microcontrollers have a built-in on-chip bootloader that cannot be erased or disabled, so if such a bootloader is usable in a device, a device with ransomware could be re-programmed on-site by the manufacturer or a technician. However, that might still be impractical or expensive if, for example, a very large number of devices were affected and/or the devices were at very remote locations.

A theoretical Example

To pick a specific application example, let’s have a look at an elevator / lift system: It consists of multiple microcontroller systems that are interconnected for example by CAN or CANopen and let us further assume they also feature a CAN/CANopen based bootloader mechanism.

A hacker installing ransomware replacing the existing bootloader with their own would need to

  1. get access to the system (either physical by installing a sniffer or remotely through a hacked PC that is connected to the system)
  2. know which microcontrollers are used
  3. know how the CAN/CANopen bootloader mechanism works (with some CANopen profiles, some details about it are standardized)

This information might be stored on multiple PCs: with the manufacturers, distributors, technicians or operators of the system. If one or multiple of those get hacked, an attacker might have all this information readily available. Note that the risk of a rogue or disgruntled employee with inside knowledge is often underestimated. The information above will typically be accessible by many people.

With this information, a hacker would be able to generate and load his own ransomware loader replacing the original code in all devices, which would disable the system. Now buttons, displays and controls would all stop working and every affected device / microcontroller would require a restore of its original firmware. If the affected devices still have an on-chip bootloader and if it can be activated, then a technician could manually update all affected devices. For large elevator systems with 20 or more floors and multiple shafts this task alone could take days.

How likely is such an attack?

The sophistication level required for the attack described above is quite high. Not only does it require “traditional” hacker knowledge but also in-depth knowledge of embedded systems. At this time it might be unattractive to most hackers as there are possibly still many “easier” targets out there. However, with enough resources thrown at the task, a determined hacker group could achieve the tasks listed above.

What are possible counter measures?

The most basic pre-requisite for an attack as described here is the knowledge about the specific microcontroller and bootloader mechanism used. This information can be obtained by either monitoring/tracing the CAN/CANopen communication during the firmware update process or by access to a computer that has this information stored. Protecting these in the first place has the highest priority.

The designer has to make sure that the firmware update process is not easy to reengineer just by monitoring the CAN/CANopen communication of a firmware update procedure. Things that we can often learn just by monitoring a firmware reprogramming cycle:

  1. How is the bootloader activated? Often the activation happens through a specific read/write sequence.
    Counter measure: Only allow authorized partners to activate the bootloader, best by using encryption such as CANcrypt or at least a challenge/response mechanism that is not repetitive.
  2. What file format is used? “.hex” or binary versions of it can easily be recognized.
    Counter measure: Use encryption or authentication methods to prohibit that “any” code can be loaded by your own bootloader.
  3. What CRC is used? Often a standard-CRC stored at end of the file or loadable memory.
    Counter measure: If file format doesn’t use encryption, at least encrypt the CRC or better use a cryptographic hash function instead of a plain CRC.

These counter measures are fall-back safeguards to protect the system if a higher security level has failed before. A hacker should not get bootloader access to a deeply embedded system in the first place. Ensure that all remote-access options to the bootloader level are well-secured.

Impressions from the Embedded World 2015

March 2nd, 2015 No comments

With about 900 exhibitors the Embedded World reached a size where it is impossible to “see it all”. Yes, you can still walk by all booths in a day, but you might easily miss hidden highlights. It was quite obvious that IoT – the Internet of Things – is a current hype. To me this is quite astonishing as already some 10+ years ago we built an “Embedded Internet Demo” – at that time based on a Philips 8051 with a dial-up modem connected. The main difference between now and then is that now smart phones are widely spread and we are “always online” and now can access our embedded devices “at any time”. Among the visitors one could recognize a lot of skepticism for what exactly we really need the IoT, other then it being hip and cool to be able to control “everything” with our smart phone.

An unusual approach to get remote access to embedded applications was shown by Raisonance ( – they have a miniature NFC or Bluetooth module that connect to the JTAG/SWD debug port of an application. So it can be added to any application with debug port, sometimes even without the need to re-compile the code, if you have the knowledge where in memory the variables are that you want to have remote access to. A great tool to get started with IoT without requiring a re-design of existing hardware.

At the CiA (CAN in Automation) booth a CAN FD demo integrated devices and tools from multiple vendors. CAN FD (Flexible Data) allows higher bit rates and longer contents (up to 64 bytes) of the data frame. Especially bootloader applications and other software update features benefit from the higher data throughput. For such applications it seems to be possible to increase the effective data throughout 8 fold easily, potentially even more.

We at ESAcademy further enhanced our portfolio of CANopen Diag products. There is now a second hardware, based on PEAK’s mini Display, that offers a subset of the diagnostic features provided at a price point of well below 1000 Euro. The CANopen Test Machine System part of the CANopen Diag now allows to create tests based on MS Visio graphs. The transitions in a state diagram can be used to transmit or receive a CAN/CANopen message or to influence/set/test/query variables or timers. More details and examples will be published shortly.

Micro CANopen Source Code V6.11 released

May 10th, 2013 No comments

Today we released a new version of our Micro CANopen source code. Updates and changes made include requirements from the latest CANopen conformance test as well as updates to the CiA 447 specific examples. Besides two bug fixes, the changes are:

Device switch themselves automatically to pre-operational when they detect a loss of a heartbeat that they are consuming. In the past this was application code specific, but as the conformance test requires it, we moved this function into the stack. In CiA 447 this is only done for the loss of the gateway’s heartbeat. Reaction to other heartbeat losses remains application code specific.

For CiA 447 devices, the shut down sequence is now also initiated if a gateway is not present. As before, devices wait for the next wake-up message before they try to communicate again.

Micro CANopen customers with a current maintenance and support contract may download this latest version from our servers as described on the delivery note for each product.

MicroCANopen Plus 5.50 Available

October 2nd, 2010 Comments off

MicroCANopen Plus and MicroCANopen Plus Add-in Manager have been updated. The highlights in the new version of the embedded CANopen stack are:

  • More clarity and easier maintenance in user-configurable files by dividing call back functions into multiple files
  • More flexibility by adding many more data call backs for SDO accesses
  • Framework support to guard Object Dictionary entries with auto-generated minimum and maximum values from EDS/DCF file

Customers with ongoing maintenance agreement with us are entitled to a free upgrade. In this case, please download the new version from

using the activation code(s). For those projects using auto-generated code, also update CANopen Architect EDS to the latest version.

The process to update embedded firmware libraries that become part of a bigger project can be complicated. For that reason, we have developed tools and to ease this on-time task.

Contact us if you are interested in obtaining or need assistance in performing the update.

From Embedded World: “Debugging” Power Consumption

March 5th, 2010 No comments

A few years back, Al Gore was speaking at the Embedded Systems Conference. His key note also included the call upon us engineers to do more to ensure that embedded systems use less power. With the billions of microcontrollers out there, all the milliwatts that we can potentially save in each one do add-up. Although many microcontroller manufacturers already offer multiple power saving options on their devices, it is not always easy to get exact values. Any change in clock rate, also on any of the peripherals, immediately has an affect on the overall power consumption. But how much do we really save by reducing the clock to a communication peripheral?

This year, one of the Embedded Awards given out every year at the Embedded World is for a product that helps engineers with measuring the power consumption of their system dynamically. The PowerScale by Hitex not only allows measuring a system’s current power consumption – it makes that information available via an API so that debuggers can include the information into the trace recording or other displays.

This allows engineers to easily determine which code areas have an impact on the overall power consumption. The power-saving effect of reducing clock rates or disabling unused peripherals becomes immediately visibile.

Various adapter probes including a USB and Power-over-Ethernet Probe are available to allow for an easy connection of the up to four channels to the target hardware.