gallia – An Extendable Pentesting Framework

gallia is an extendable pentesting framework with the focus on the automotive domain, developed by Fraunhofer AISEC under the Apache 2.0 license. The scope of the toolchain is conducting penetration tests from a single ECU up to whole cars. Currently, the main focus lies on the UDS interface but is not limited to it. Acting as a generic interface, the logging functionality implements reproducible tests and enables post-processing tasks. The following blog post introduces gallia's architecture, its plugin interface, and its intended use case. The post covers the interaction between its components and shows how gallia can be extended for other use cases.

The work on gallia was partly funded by the German Federal Ministry of Education and Research (BMBF) as part of the SecForCARs project (grant no. 16KIS0790). A short presentation and demo video are available on YouTube.

Disclaimer: Keep in mind that this project is intended for research and development usage only! Inappropriate usage might cause irreversible damage to the device under test. We do not take any responsibility for damage caused by the usage of this tool.




The following paragraphs gives a short overview over gallia and its architecture. At a glance, gallia is structured into several modules ensuring reproducible scans. gallia‘s modules provide interfaces where gallia can be extended by third party modules, called plugins. The basic idea of gallia is the concept of a so called ‘test run’.

Test runs

Since gallia is a general tool for software testing (with the focus on penetration testing), its architecture ensures reproducibility. Software tests can usually be divided into small self-contained test runs where each test run fulfills a particular purpose.
The basic idea of a test run is a corresponding artifacts dir where all relevant information is stored. The following information is always included in an artificats dir for a particular test run:
  • command line invocation,
  • process environment,
  • start of test,
  • end of test,
  • exit code, and
  • JSON formatted log file.
Optionally, a pcap file containing all relevant network traffic during the test can be created as well. The meta data is stored in a document using the JSON data format. An example testrun includes the following metadata.
In other words, the previous listing describes a successfully finished scan run. The command line invocation was gallia scan uds services –sessions 0x01 0x02 0x03. The start_time and end_time attributes are self-explanatory.

Software Architecture

Around the basic idea of performing self contained test runs, gallia is based on  a core component. The core component provides modules and interfaces for creating own tools that make use of gallia‘s features.
This core library can be extended with plugins. A gallia plugin consists of Python code loaded during startup. The plugin may be called by different gallia modules. Possible plugins are custom transport protocols, e.g. a special serial line, or support for switching UDS sessions for different OEMs. All possible entry points for plugins are documented on Github. The mentioned core component can be used with two approaches: the first approach is using the builtin CLI system for writing own scanners. By using the builtin CLI system own scanners are exposed as a gallia subcommand using the system shell. The second approach is using a standalone Python program by using gallia as a library. The differences are subtle and only relevant for the user interface. From a functional point of view there is no difference between both approaches. Digging more into the core component yields the following architecture for a certain UDS scanner module:

The core component is divided into multiple, logically separated blocks:

  • core: The software core provides basic functionality. Used by the scanner.
  • transports: Implementations of relevant network protocols, in this example UDS, DoIP, et cetera. The transports module can be extended via plugins.
  • automation: Modules that implement triggering power supplies enabling power cycles during a scan.

Use Case

At Fraunhofer AISEC gallia is used for conducting automotive penetration tests utilizing the UDS interface. As explained in the previous sections, gallia‘s architecture is not limited to automotive penetration tests, but can be used for every test where the presented test run concept makes a good match. Mentioning the UDS implementation, gallia e. g. supports endpoint enumeration of automotive ECUs. Automotive ECUs usually provide several so called UDS services which are available in different modes of operation, called UDS sessions. Each service provides specific endpoints.
gallia can be used to discover and enumerate the UDS service structure of multiple automotive ECUs. The available UDS scan techniques are explained on the documentation page.

Command Line Interface

The main user interface is the CLI. Every scanner is exposed as a command to the gallia command enabling scripting. Each command offers a help page which can be accessed via –help providing further information. The following video shows a UDS service scan.

Future Work

There are several areas of improvement for gallia. The idea of the framework is adoptable for different scenarios and the architecture of gallia is scalable. We are always open to ideas and contributions from the community. For future development, we want to work on the following topics:
  • Additional transports: Currently, there are only a few generic and UDS specific transports implemented. A few ideas for additional transports are: subprocess, ssh, http, …
  • Additional scanners: Currently there are only UDS specific scanners available. gallia could benefit from more general scanners that e. g. perform more different discovery scans. Examples are DLT or XCP which are used in automotive networks as well.
  • Split gallia into a core library and a collection of scanners: This would reduce dependencies for projects willing to use the test run concept.
Stefan Tatschner

Stefan Tatschner joined the Fraunhofer AISEC in 2015. His research focus is penetration and software testing in the automotive domain. Together with his college Tobias Specht, he maintains the gallia project.

Tobias Specht

Tobias Specht is an IT security researcher in the field of penetration testing and static code analysis with a focus on the embedded and automotive domain. He has been working at Fraunhofer AISEC since 2018 and has contributed to industry and research projects such as the gallia framework. Together with his colleague Stefan Tatschner, he is maintainer of the gallia project.

Most Popular

Never want to miss a post?

Please submit your e-mail address to be notified about new blog posts.
Bitte füllen Sie das Pflichtfeld aus.
Bitte füllen Sie das Pflichtfeld aus.
Bitte füllen Sie das Pflichtfeld aus.

* Mandatory

* Mandatory

By filling out the form you accept our privacy policy.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other Articles

Privacy By Design: Integrating Privacy into the Software Development Life Cycle

As data breaches and privacy violations continue to make headlines, it is evident that mere reactive measures are not enough to protect personal data. Therefore, behind every privacy-aware organization lies an established software engineering process that systematically includes privacy engineering activities. Such activities include the selection of privacy-enhancing technologies, the analysis of potential privacy threats, as well as the continuous re-evaluation of privacy risks at runtime.
In this blog post, we give an overview of some of these activities which help your organization to build and operate privacy-friendly software by design. In doing so, we focus on risk-based privacy engineering as the driver for »Privacy by Design«.

Read More »
Headerbild zum Blogartikel "Neue Studie zu Laser-basiertem Fehlerangriff auf XMSS" im Cybersecurityblog des Fraunhofer AISEC

Fraunhofer AISEC commissioned by the German Federal Office for Information Security (BSI): new study of laser-based fault attacks on XMSS

To ensure the security of embedded systems, the integrity and authenticity of the software must be verified, for example through signatures. However, targeted hardware attacks enable malware to be used to take over the system. What risks are modern cryptographic implementations exposed to? What countermeasures need to be taken? To answer these questions, Fraunhofer AISEC was commissioned by the German Federal Office for Information Security (BSI) to carry out a study of laser-based fault attacks on XMSS. The focus is on a hash-based, quantum-secure scheme for creating and verifying signatures based on the Winternitz One-Time-Signature (WOTS) scheme.

Read More »

Anomaly Detection with Quantum Machine Learning – Identifying Cybersecurity Issues in Datasets

Since the release of ChatGPT, the popularity of Machine Learning (ML) has grown immensely. Besides Natural Language Processing (NLP) anomaly detection is an important branch of data analysis whose goal is to identify observations or events that deviate from the rest of the data. At Fraunhofer AISEC, cybersecurity experts explore Quantum Machine Learning methods for anomaly detection. One approach is based on the classification of quantum matter while a second method uses a type of Quantum Support Vector Machine with a kernel that is calculated on a quantum computer. This blog post explains the fundamentals of anomaly detection and shows the two approaches being pursued by the Quantum Security Technologies group at Fraunhofer AISEC.

Read More »

Towards Automated Cloud Security Certification

Obtaining a cloud security certification requires a lot of preparation time, which mainly involves manual processes that are prone to error. In other words, several employees cannot perform their usual duties during an audit preparation. Our Clouditor tool aims to improve this process by making audit preparations more systematic and automatable. This makes it possible to continuously monitor cloud services and check their compliance with a cloud security catalog such as BSI C5[1], EUCS[2], or the CCM[3].

Read More »