This talk is not only about security, but about hacking and video games. Many video games are about driving cars, whether it is for racing, or heisting and escaping the police. In this talk, we will explain how the user experience could actually be improved by connecting a car to a video game and turning it into a game controller.
We will discuss about these connected systems, how car components interact with one another, the different protocols, or anything that came to us during this journey.
However there was one important constraint during all that experience: no car could be dismantled nor modified. The main goal of this analysis was to try doing something out of the data which could be freely recovered while plugging itself to the OBD-II port of a car. As mentioned, this resulted in the possibility of controlling a video game car through the real car, like a simulator, without the need of modifying anything in the car itself.
Unfortunately, this requires a lot of gasoline to have the engine powered on and run. Moreover, gasoline is really expensive in France. So we looked for a way to reduce that cost. We actually found a nice device on the Internet to optimize the amount of gasoline used by the engine. Apparently, it works by connecting to the OBD-II port and reconfigures the engine’s ECU. We looked into that to understand what was actually going on… and try to reduce the cost of the drifting.
The following points will be mentioned during the presentation: ECUs CAN bus OBD-II (DTCs/PIDs) On-top-of-CAN protocols UDS (Diagnostic/Security session) Reverse engineering: the meanings of CAN messages Using a real car as a simulator, for poories Minor details about how to create a custom game controller OBD dongle reverse engineering