[00:00.000 --> 00:10.800] So, hello everybody, today I'm going to talk about something I've been hacking on for quite [00:10.800 --> 00:16.760] some time now and it is called GALIA and it is an extendable pen testing framework mainly [00:16.760 --> 00:19.720] in the automotive domain. [00:19.720 --> 00:26.240] My talk is structured like this, it is divided into four parts, I will start with some metadata [00:26.240 --> 00:31.560] about me and the project, then I will give you an overview of the status quo, I will [00:31.560 --> 00:38.040] conclude with an outlook and I hope we have some time for a little short demo. [00:38.040 --> 00:42.700] So that's me, on the left hand side you see my avatar and you might have spotted me on [00:42.700 --> 00:51.160] GitHub, I'm Stefan and I'm a security researcher and I'm the maintainer of GALIA. [00:51.160 --> 00:57.800] So what is GALIA, GALIA stems from the SACFORCAS project, it was a research project and we [00:57.800 --> 00:59.600] received some funding. [00:59.600 --> 01:05.920] On the YouTube link you can see a little demo we prepared last year, GALIA is implemented [01:05.920 --> 01:12.920] in the Python programming language and we support the latest version minus one that is currently [01:12.920 --> 01:20.200] the 3.10 release, it is free software and it is available on GitHub, it is licensed on [01:20.200 --> 01:27.160] Apache 2 and we have two maintainers, the second maintainer hides in the audience, if [01:27.160 --> 01:33.240] you have questions we have been around here for some time and it aims to be a modular [01:33.240 --> 01:36.320] tool for automotive penetration tests. [01:36.320 --> 01:43.320] So what is this, according to Wikipedia a penetration test is an authorized simulated [01:43.320 --> 01:49.520] cyber attack on a computer system performed to evaluate the security of the system and [01:49.520 --> 01:56.400] that basically means we connect our computer to a car or an automotive ECU and we send [01:56.400 --> 02:02.640] some data and we keep on sending data until it breaks and hopefully it breaks and then [02:02.640 --> 02:10.800] we try to figure out what we did in order to break it and after such tests the lab usually [02:10.800 --> 02:16.240] looks like this. [02:16.240 --> 02:20.200] What are the challenges to actually achieve this? [02:20.200 --> 02:25.880] The reason why GALIA exists is that we were doing some penetration testing and we needed [02:25.880 --> 02:32.720] a protocol stack for this and in the automotive domain there is usually the UDS protocol that [02:32.720 --> 02:40.840] stands for unified diagnostic services and you can think of it as the HTTP of automotive [02:40.840 --> 02:47.520] with the difference that UDS is stateful in contrast to a stateless protocol. [02:47.520 --> 02:53.240] Of course we need post processing which means machine readable logs in order to analyze [02:53.240 --> 03:00.440] data, everything needs to be reproducible, we solve this by a defined directory structure [03:00.440 --> 03:07.400] for artifacts and of course the automotive guys are very, very creative in implementing [03:07.400 --> 03:15.120] network protocols that means if you do expect an answer, the ECU doesn't answer, if you [03:15.120 --> 03:20.160] expect no answer, the ECU does answer and that's quite a challenge and that's why we [03:20.160 --> 03:25.640] decided to write our own protocol stack. [03:25.640 --> 03:32.400] Since the automotive industry loves proprietary software and we do want to release the core [03:32.400 --> 03:39.720] of GALIA, we created a plugin interface where we maintain our own proprietary plugins in [03:39.720 --> 03:46.240] our own infrastructure which plugs nicely into the GitHub code and of course we need [03:46.240 --> 03:53.080] the whole software stack to achieve these goals. [03:53.080 --> 04:02.000] We did write a whole implementation of the UDS stack and the status quo is like this. [04:02.000 --> 04:08.920] Here you plug it into the OBD port of your vehicle, OBD stands for onboard diagnosis [04:08.920 --> 04:14.480] and several ECUs might be exposed on that port and you can use GALIA to discover this [04:14.480 --> 04:16.360] whole tree. [04:16.360 --> 04:24.040] For example, there might be three ECUs available and each ECU has different modes of operation. [04:24.040 --> 04:31.200] These are called UDS sessions, GALIA can also discover these and each session might also [04:31.200 --> 04:35.360] provide different UDS services. [04:35.360 --> 04:43.600] What a UDS service does is up to the manufacturer of the ECU, it can be getting parameters, [04:43.600 --> 04:51.920] it might be setting parameters, it might even be software updating, the UDS standard defines [04:51.920 --> 05:01.920] just some basic facts what this actually is and it could be everything basically. [05:01.920 --> 05:07.640] GALIA comes as a CLI tool and you can think of it as the end map for cars. [05:07.640 --> 05:15.400] We provide some ready to use scanning modules, for example the discovery I already showed [05:15.400 --> 05:21.600] and there are also modules to investigate these modules further. [05:21.600 --> 05:29.720] We have an UDS stack including DOIP or ISOTP, these are little transport protocols beneath [05:29.720 --> 05:40.120] UDS since UDS is on the application layer, DOIP for example is on top of TCP, ISOTP is [05:40.120 --> 05:46.240] on top of the CAN bus and you can use all these setups. [05:46.240 --> 05:53.040] The next one is that we are able to do some automation if you are testing some ECU on [05:53.040 --> 06:01.360] its own, you can power cycle it during a scan, we power cycle the whole setup before [06:01.360 --> 06:06.800] each scan and so on and of course we have machine readable logging which comes as JSON [06:06.800 --> 06:15.000] logging and SQL logging, the SQL module is quite interesting since it can be used to [06:15.000 --> 06:23.320] query logging information across different or multiple ECUs and for development we offer [06:23.320 --> 06:26.320] a virtual ECU module. [06:26.320 --> 06:31.920] The core concept of GALIA is a test run, it is basically the invocation on the command [06:31.920 --> 06:39.560] line until it finishes and it always creates a directory structure which is always the [06:39.560 --> 06:47.920] same in which contains some artifacts which can be used for scripting or similar and the [06:47.920 --> 06:54.560] artifacts they always contain log files, always contains pcap files and it might contain [06:54.560 --> 06:58.040] some something else. [06:58.040 --> 07:03.040] The software is basically structured like this, there is a core module which can be [07:03.040 --> 07:12.840] extended via plugins and you can build standalone modules or you can integrate into the CLI [07:12.840 --> 07:13.840] system. [07:13.840 --> 07:19.360] Basically, the architecture is like this, the main entry point is the scanner on top [07:19.360 --> 07:26.280] which contains a module for optionally controlling power supplies and it contains an abstraction [07:26.280 --> 07:32.200] module for an ECU which uses the whole UDS protocol stack and the protocol stack also [07:32.200 --> 07:35.880] can be extended via plugins. [07:35.880 --> 07:41.480] These plugins might look like this, this is a hello world module, basically you create [07:41.480 --> 07:48.480] a class in Python, you need to implement the main method which could be basically anything [07:48.480 --> 07:56.080] and then you plug it into an entry point and that's basically it. [07:56.080 --> 08:03.000] For random facts, we use poetry for dependency management and in order to maintain a modern [08:03.000 --> 08:08.360] Python code base async IO and async await is used everywhere, it is fully typed, it [08:08.360 --> 08:19.000] passes mypy strict, it is extendable as mentioned via the Python entry point API and for configuring [08:19.000 --> 08:27.520] the protocol stack, we use some URL strings which are verified by the pedantic module. [08:27.520 --> 08:34.760] Yesterday there was a great talk about the pedantic module if you are interested in this. [08:34.760 --> 08:39.240] So let's give some little outlook. [08:39.240 --> 08:44.840] Of course, we need more power supplies, we need more transport modules, we need also [08:44.840 --> 08:51.320] more scanner modules and also to we need extending the scope, we need more plugins, scanning [08:51.320 --> 08:56.560] techniques and so on and of course more breakage and more memes and more testing. [08:56.560 --> 09:02.800] And we need more packages, currently there is a package for the Arch Linux distribution, [09:02.800 --> 09:11.800] we have a AUR package and it is included in the NixOS distribution in the unstable branch. [09:11.800 --> 09:15.440] And if you are a package maintainer and if you are interested in this, just create a [09:15.440 --> 09:22.240] package, file a ticket on Github and we would like to include this in the readme file. [09:22.240 --> 09:28.240] I will conclude with a short demo, it can be downloaded on this link but I brought it [09:28.240 --> 09:44.600] here and I will play it. [09:44.600 --> 09:49.600] What we can see here is a T-Mark session with two tabs. [09:49.600 --> 09:55.200] On the first tab, we will start a virtual ECU which is a testing device we will run [09:55.200 --> 10:03.800] Gaelia against and on the second tab, we have the command line invocation, here we have [10:03.800 --> 10:09.920] the configuration of the network stack, we have a transport module called TCP lines which [10:09.920 --> 10:18.240] basically sends ASCII strings as TCP, on top of TCP, we use this for debugging and testing, [10:18.240 --> 10:24.880] we have an Artifox where all the logging is placed and we try to discover what actual [10:24.880 --> 10:29.800] UDS services this ECU exposes. [10:29.800 --> 10:38.040] When you start it, it starts Dumbcap which records all the network traffic, then Gaelia [10:38.040 --> 10:43.920] synchronizes with the ECU which means it sends a test a present packet that is something [10:43.920 --> 10:49.480] like a ping message and when the Pong arrives, the scanner starts and it iterates over the [10:49.480 --> 11:00.920] ECU and in this example, we have found a mode of operation, this session hex 52 and several [11:00.920 --> 11:09.640] services are exposed in this session which can be exposed, which can be scanned further [11:09.640 --> 11:16.760] with other scanning modules. [11:16.760 --> 11:22.320] Now I have finished with my talk, thank you very much for your attention and if there [11:22.320 --> 11:26.160] are any questions, I will be happy to answer them. [11:26.160 --> 11:31.560] Yes, thank you Stefan. [11:31.560 --> 11:46.920] So we have sometimes four questions here, yeah. [11:46.920 --> 11:47.920] Hi, thank you for the talk. [11:47.920 --> 11:55.240] Can you say anything about fuzzing or memory scan, what you did there? [11:55.240 --> 12:03.040] We have some very basic fuzzer, it is included in the GitHub code, it is a PDU fuzzing, [12:03.040 --> 12:10.240] but it just generates random data and you don't have any feedback loop for this since [12:10.240 --> 12:16.680] this is quite complicated to implement for a car in a generic manner. [12:16.680 --> 12:21.920] Internally we have some more sophisticated fuzzing modules but we are not allowed to [12:21.920 --> 12:26.400] publish them because of the NDA stuff, unfortunately. [12:26.400 --> 12:35.320] For the memory scan, there are a few services, blah, blah, blah, by memory address, we have [12:35.320 --> 12:42.240] discovery modules for this published on GitHub, but they actually discover endpoints and that [12:42.240 --> 12:46.680] is basically it. [12:46.680 --> 12:52.680] So I have done a lot of testing and reverse engineering and you need a matrix of tests [12:52.680 --> 12:56.160] of what you are testing against and the thing. [12:56.160 --> 13:03.080] So I was just wondering for fits and giggles, is this virtual CPU sufficient to actually [13:03.080 --> 13:10.560] plug it into the bus and actually run the car? [13:10.560 --> 13:19.400] Because then it would be accurate enough to be able to be tested as a real world MCU. [13:19.400 --> 13:27.560] I hope I did understand the question correctly, but our virtual ECU module offers a possibility [13:27.560 --> 13:36.880] to clone ECUs so we can just record traffic and store this in the database and it just [13:36.880 --> 13:44.360] answers what it has seen recently, but it does not cover any state. [13:44.360 --> 13:53.680] The idea was that the virtual CPU is actually sufficient to replace the ECU in the car and [13:53.680 --> 14:01.960] run, drive the car and that would give the enough accuracy of the ECU to be able to be [14:01.960 --> 14:02.960] tested. [14:02.960 --> 14:11.480] Maybe it's a bit too much, but that's not in the scope of Gator, I feel. [14:11.480 --> 14:14.800] Okay, thank you, Stefan. [14:14.800 --> 14:21.920] Thank you for listening and feel free to ask questions outside full speaker there. [14:21.920 --> 14:22.920] Thank you. [14:22.920 --> 14:39.400] You are welcome.