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.
Metadata
tl;dr:
- FOSS: https://github.com/Fraunhofer-AISEC/gallia
- PyPI: https://pypi.org/projects/gallia
- documentation: https://fraunhofer-aisec.github.io/gallia/
- license: Apache 2.0
- maintainers: Stefan Tatschner (@rumpelsepp), Tobias Specht (@peckto)
Architecture
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.
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.
Authors
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.
Contact: Stefan.Tatschner@aisec.fraunhofer.de
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.
Contact: Tobias.Specht@aisec.fraunhofer.de
