Have you ever considered that most of the devices you own contain complex software, like your phone, laptop, cars, even washing and coffee machines? Software is increasingly present in everyday devices, industrial machines are more connected to the network and hardware architectures are becoming more complex, having an impact on the complexity of the software design as well. Rapidly stepping into a world of IoT, interconnected devices either for personal or industrial use, become as well more exposed to cyber threats and external attacks.
EURECOM’s Prof. Aurélien Francillon, expert in software security in embedded systems, will guide us through his project avatar² in collaboration with SIEMENS, with the goal to provide a framework for testing software in such devices in order to protect them from attacks.
Q. What is the motivation behind the avatar² project?
AF. All software systems inherently have “bugs” and vulnerabilities, which can lead to many security problems, exploiting software and taking over the system. There are multiple ways to avoid vulnerabilities and one way to do so is testing.
Now, during the last years there is more and more software presence in embedded systems. An embedded system is a computer system, made from a combination of hardware and software, that is used to perform a specific task. They are present everywhere, in your car, coffee machine, phone and of course your very computer. For example, a computer is made of around 20 different embedded systems. Also, there are more and more industrial machines that are connected to networks, including wireless networks.
Moreover, especially in the case of embedded systems, software becomes more complicated, written by different people, integrating different pieces of software. We already have a lot of critical embedded systems in automotive technology or in industrial control systems, but also personal systems like webcams/surveillance etc. These devices are getting more and more exposed to networks that contain an increasing amount of complicated software containing more vulnerabilities. In this context, with avatar² we are aiming to provide a framework for testing those embedded systems.
Q. How did avatar² begin and which are your main collaborators?
AF. Avatar² was first funded by a project we had with Google. Later, we collaborated with SIEMENS and particularly with a team that specialises in testing software for embedded systems, considering them as black boxes. This team performs security testing for many SIEMENS devices, usually without using the documentation of the products. This process is called external penetration testing, where they try to find security problems of a device by thinking and acting like an actual hacker or external attacker. SIEMENS was interested in these tools to be developed, because they can be used to validate and improve the security of their products. In fact, large companies like SIEMENS often have several tests performed by different teams. Some tests are performed within development teams as so-called white box testing, and other tests are often executed by external consultants as black box testing (or red team). Combining both approaches allows to have more comprehensive testing of the targeted systems. On our side at EURECOM, we drive extensive research and development to provide the tools that are generic and are in particular useful on SIEMENS’ devices or research projects. We also have collaborators from outside EURECOM; for instance, Marius Muench, one of our alumni, who is now a postdoc at Vrije Universiteit Amsterdam, continues extending, and using the framework. For example, he gave a talk at BlackHat conference on how to test Samsung smartphones “baseband” (Mobile modem software) using avatar².
Q. What is the core idea of the project?
AF. The core idea of avatar² is simple. When it comes to security testing for software vulnerabilities, the complexity is huge, especially when A) we do not know how the hardware of the device is actually functioning, which is pretty often the case in real life when dealing with no or limited access to documentation/source code etc. and when B) handling the testing of embedded systems where we have no or little control on how the software runs. Typically, while testing software we observe how the system is executing and try to find pieces of code that are not executed (dynamic testing), with the goal to reach the software’s limits and eventually getting it to misbehave. This is a brief description on how we are able to find “bugs” or if they are exploitable, vulnerabilities. However, in order to efficiently test the software of embedded systems, we need to be able to emulate the embedded device, which is an extremely difficult task as mentioned above. To tackle this technical barrier, avatar²’s goal is to create a framework in order to perform a type of an hybrid software execution, where the code is executed in an emulator but all the interactions with the real world are sent to the peripherals of the real device. For example, it is fairly easy to emulate the instructions of some code of a standard processor core (e.g., ARM Cortex-M), but it is not possible to emulate the whole system along with its peripherals. Therefore we use a generic emulator for emulating the instructions and the real system for components that cannot be replicated by pure emulation. In other words, we create a debugger link, connected between the PC that runs the emulator and the actual hardware.This is a fairly simple approach and it is really useful for analysing embedded devices and to be able to reverse engineer the software, to know what it is doing and which are the interesting parts to analyse.
We are working on this since several years, having multiple contributions, and it’s a topic that is getting a lot of traction. More and more people realise this problem, and they are using our framework. Because many different analysis are needed Avatar² has been designed since the beginning as an orchestrator of tools, to allow to use multiple tools for an embedded device analysis. For example, it is well integrated with the “record and replay” tool Panda (from New York University).
Another goal is to rehost the firmware, avoiding the hardware completely by building an emulator. This is a tedious task to perform manually and very difficult to fully automate. Such an automation is a quite active research field. With a fully rehosted system the testing can be performed without any hardware in the loop and therefore much faster. Avatar² can be used to identify peripherals behaviour and interactions and therefore help with this rehosting goal. There are many users outside of Eurecom, for example at UCSB, Florida university or TU Berlin. We have also established a research contract with the United States Air Force Research Laboratory, Information Directorate and Air Force Office of Scientific Research with whom we will continue working on this topic in parallel to our collaboration with SIEMENS.
Q. Could you share the idea behind the project name avatar²?
AF. Spawning from Hinduism, the term avatar is mostly translated with “incarnation” or “appearance”. Drawing from this, in the 2009 science fiction movie, people were projecting their minds on the “Avatar” bodies on this weird planet. In the film, we have the brain on one side and the body on the other. For our project the analogy is that we run the code of the embedded system inside a computer, constructing an emulator. It executes the code’s instructions one by one, transferring these accesses to the real devices. These pieces of software try to interact with the real world, e.g., by reading a value from a sensor, activating/opening a door, while connected to some external sensor. So, in the end, we do not have to emulate the real device, but only transfer the necessary information.
Q. What are the challenges to face in order to use avatar² for real products?
AF. Avatar² can live up to its full potential when there is a security purpose or a vulnerability problem with embedded devices. However, there are a lot of requirements for it to work efficiently. Currently, avatar² is working well for low-end embedded devices, for example devices that are not Linux embedded, but smaller microcontrollers. We mostly target ARM processors, but there are many other architectures. We also need to have access to the firmware to be able to emulate it, as well as having access to the debugging interface. For example, frequently devices which are not using ARM cores and lack a debug interface. This is not an inherent limitation, but more a development task, for example we just added MIPS support. More often than not, even if all the rest of the conditions are met, we cannot access the firmware.
The utter goal would be that companies would be able to use this software, in order to find problems in their products, being able to fix them before “bad” guys do so or even before the product gets released. Still, we must take into account that there is various business and real-world difficulties.
Another aspect where avatar² could be useful is regarding the “right to repair” your own devices, a hot topic nowadays. In fact, numerous physical goods have a lot of software in them, such as cars, washing machines, tractors etc. Today it is almost impossible to repair your own device since you do not really have access to the firmware from the manufacturer. This could lead to a complete lockout of the device due to software issues. But even if there is no such restriction, there is a difficulty to understand how the software actually works to be able to modify it. For this, avatar² could be a good way to make this easier, by automating a lot of complex tasks. Appropriately enough, there is a movement for having security certifications for all sorts of IoT and physical goods, in the US and in Europe. Tools like avatar² could take part in this context and help these security evaluations.
Q. What are the future directions of avatar²?
AF. In the future, we are going to continue working towards improving the system, especially to include more complicated use cases regarding Linux devices as well. We also want to improve the scope of avatar² and make it more used, find more use cases and promote it to industrial parties that are going to be interested in such approaches. For example, the US Air Force is leveraging avatar² in their research and testing environments. That is why they found us and why they want to support the development of avatar², which is an open source tool.
To conclude, the goal of avatar² is to be a versatile platform which can be used for many purposes on many different devices. We want to integrate various useful tools to provide a platform for testing embedded devices.
by Dora Matzakou for EURECOM
Welcome to avatar², the target orchestration framework with focus on dynamic analysis of embedded devices' firmware…
Playlists: '34c3' videos starting here / audio / related events Avatar² is an open source framework for dynamic…