*33C3 preroll music*
Herald Angel: And without further to do, please welcome Guillaume and P1ckachu on
stage now. *applause*
Guillaume: Thank you. P1kachu: Okay. So hi everybody. Hi bingu.
So we are going to present what we've been doing lately with cars actually. So who
are we? My name is Stanislas Lejay "P1kachu". I'm an IT student in EPITA a
school in France and I'm part of EPITA's system and security laboratory the LSE.
I'm currently an intern at Quarkslab. I like a lot of stuff, like reverse
engineering, everything that is related to cars or mechanics and if there is
something stupid to do I shall already be doing it. And with me will be Guillaume
Heilles. Guillaume: Hello my name is Guillaume. I
work as at Quarkslab as a security engineer. I'm quite new to the security
field as I worked in the industry before. And I switched to the security field
because it's very fun and I like to reverse almost everything and I will give
a small talk about reversing a piece of hardware that you can find in an
automobile. P: So what is this talk about? This
talk will be in two different parts the first one is how to drift with any car.
And it's an introduction to how to automotive systems what you can do with them and what
we actually did with them. And the second part, which name is out to properly write
an amazon review, you'll see why just after, is OBD dongle. So analysis, reverse
engineering, stuff like this. So first part "drifting with any car". The idea is
that I'm a student, so I work at my school's lab, so I had to find a way to
explain why I was bringing different cars every day at my school's garage. So the
official goal was to look at our car works and what arise from this is what can I do
what can one do with a modern car system. The restriction I had was that since I'm a
student I'm poor so I don't have a lot of money and I don't have a lot of cars. So I
was actually taking my family's different cars and trying to analyze them. So I
wouldn't, I wasn't able to break anything or remove any parts from the car. So the
test subjects, what which cars was I playing with. I had five or six of them.
The first one for posterity, is mine actually. It's a 2006 Volkswagen Polo.
What is nice is that you can spend the whole day trying to find some messages on
your bus. If your car is too old there are no messages. So you can take the
oscilloscope and try to find them, you won't find them. Anyway, just before doing
anything try to think is the something I'm looking for ready in there. The second car
is my grandmother's car it's a Volkswagen Polo of 2013. And the last guy we'll talk
about is my mom's Fiat 500 convertible. It's from 2010. The dates are important
because the CAN bus I will talk about just after is quite recent in a way that
security on the CAN bus changes greatly from one year to another. So the CAN bus I
was playing with on this car was quite different from the 2013 Volkswagen Polo
for example. Okay, so talking with the car. So this is the introduction part, so
if people already know about what I'm going to talk about, but I want everybody
to be on the same first step. So first of all an ECU it stands for electronic
control unit and it's a small computer that you get all around your car. So there
are many of them. You can have at most 70 of them in very modern cars and take
control different parts of it. So you have the engine, the powertrain, the
transmission, ABS, stuff like this. And they talk to each other on what we call
the CAN bus. The CAN bus is a message based broadcast protocol. Messages are
mostly composed of two important things which are the arbitration ID which, I will
refer to ID from now on, they can be 11 or 29 bits long and you have data. Data is 8
bytes long on the standard that CAN message but they are on top protocols, I
can group messages together to get bigger lengths of data. What is interesting is
that it's a broadcast protocol, so the collision detection system is based on the
ID. The lower your ID the higher your priority. So very important CAN message
will have a very low IDs they will be sent from an ECU that are very low ID and less
important one will have a bigger arbitration ID. How do you talk to your
CAN bus without cutting any wire in the car? For this you see there is the OBD2
port so OBD stands for onboard diagnostic and is the vehicle self diagnostic and
reporting capability. When you are driving you have allowed a LED that start to blink
on your dashboard saying "ok something's wrong", you bring your car to your car
repair shop and the car repair guy will just plug itself to this port which is
located around the steering wheel often and query information using PIDs. So PID
is a parameter ID. It means "okay I want to have information about for example the
RPM or the speed or the fuel level something like this" and you can set or
reset diagnostic trouble codes a diagnostic trouble code means "ok
something is wrong with this part of the car" for example. Here is my setup. So
with just a Raspberry Pi, PiCAN 2 shield and a DV 9 to OBD 2 cable, I was able to
have a full linux that that can understand CAN messages and talk with the CAN bus. So
with that I could just communicate with my car without breaking anything, which is
quite nice. What does it look like? So in Python, I just import import can, so it's
a standard package, python-can, you create an interface, so it's socket CAN, so it's
like any kind of interface you just create a can0 interface and you can communicate
with your CAN bus. You create your message, so the data is here. What is
important is that the first byte tells how many bytes are important in the message.
You can have 8 bytes of data. The number of bytes processed will be this number, so
like there it says "ok, there are only 2 bytes of data that are interesting, just
discard the 5 of the ones.". Here, it asks for the first mode, so OBD have different
mode. The first mode says "Okay, I want the current value of what I'm looking for"
and 0x0c is RPM. So I want the current value of the RPM. If I put two there, it's
the second mode and it asks for the RPM when the last data trouble code was
actually set. You have different like that, but what interested me was "Okay
what is a current RPM?". You create your message, 0x7df is the classic ID for
diagnostic tools, so most ECUs will answer to OBD queries if you have this ID. On 29
bits, it depends on the car, on the Fiat 500, for example, it was this one. You
send your message, you get your answer and that's it. Okay, so this was the theory:
how do you talk, but how did I actually talk with my cars? So the first OBD answer
I was able to get was on my grandmother's Polo. It's quite a recent car, 2013, so
there was a gateway, a sort of firewall between the OBD2 port and the actual CAN
bus. So when I plugged myself to the CAN bus, I wouldn't receive anything unless I
send an OBD query. I would receive my answer but that's all. Else, the bus would
be completely silent. So here are some examples, so this is the one from just
before, how can I get the RPM, so this is the value of the RPM. Here, I can get the
engine coolant temperature, very important, so the idea is that it answers
83 and 83 is 131 degrees. The idea is that you are working with unsigned bytes, so if
you want to get a negative temperature, the standard tells you to subtract 40 from
your temperature. If you are outside of -40 or 215 degrees, you have other
problems than your coolant temperature. So, seems to work. Okay, nice. So,
displaying everything. This was to explain to my grandmother why I was stealing her
car for two weeks right now. So, with this, I'm able to get the RPM, the speed,
engine coolant temperature, always very important, throttle and accelerator pedal
pedal position and the elapsed time since engine started. So anyway, kind of
graphical, my grandmother understands, everybody's happy. Right, so right now I
can query standard OBD PIDs, I can have the RPM, speed, fuel level, anything you
would want to have on your dashboard, but if you want to get some probably more
interesting stuff, you have to go with the constructor-specific PIDs. For example,
the steering wheel position, brake and clutch pedal, gearbox status light or
blinkers are constructor-specific, so you have to break stuff to be able to find
them or are very good friends with manufacturer, which I haven't. Nice, we
can query stuff, mostly. Can we modify anything interesting from OBD? Because,
still, I don't want to mess with the car by cutting any wire. So first issue: what
protocol am I actually talking to? There are on-top protocols like with KWP, which
is Keyword Protocol 2000, Unified Diagnostic System is OTP, the volkswagen
version of ISO-TP, like really, and stuff like this. Which protocol am I talking to?
Okay, let's just brute-force by sending the classic introduction kind of message
and try to find for valid answer. With this on the 2013 Polo, I could speak UDS.
So UDS enables different kind of thing like resetting ECUs, which can be quite
interesting, query-specific PIDs, read DTC information, stuff like this. However,
nice stuff like dump the firmware, are only available through security session.
And security session on this car requires an authentication through a challenge
response kind of algorithm, so here is the example: I would start a diagnostic
session, UDS diagnostic session, first, then query for seed to get through the
security session, compute my answers, send it back, the cars compute its own answer,
compare and I would fail, because I would just send the feedback like, maybe they
didn't implement a real algorithm, you never know. But hey, okay, well done
Volkswagen, they did it quite well. Actually, the car has a four-byte seed,
which is different at each try. This is important to notice because on Guillaume's
car, it's a 2-byte seed, which is always the same. You have more than three seconds
required between each try and if you fail multiple time, it will just freeze for ten
minutes if you don't want to remove the battery, all that kind of complicated
stuff. So, how to break this? Brute-force? Way too long. Timing attack would be too
unstable because of the priority-kind of thing, because you can just get delayed by
other more important messages and so it will delay your timing attack. Disassemble
the car is out of the question, you know why, and get PCs from a repair shop is
tedious. You know, get an ECU, try to recreate the CAN bus around, stuff like
this, and I'm broke, so I don't have any money. Okay, so, my car, let's sum up, way
too old. My grandmother's car, bit too recent because of the Gateway, my family's car is
a Lancia Voyageur 2014, so even more recent, but it has Uconnect, so maybe for
another time. Who's left? Oh, mommy? So, my mom has a 2010 Fiat 500 convertible,
she loves it, so she doesn't like when I take it and she even more doesn't like when
I tried to do stuff with it. So one night I stole the key. *Laughter* Sorry. And I
tried to plug myself in and oh! It talks, it talks a lot. In four seconds, I was able
to get 2000 around message, so it's about 500 messages per second. There is no
gateway, so I have a lot of broadcasted message already. They are from few
different arbitration IDs, so a few different ECUs are actually talking on
this bus. When I'm in the car, I tried pressing random buttons and I see that the
data evolves, so the nice funny things to do is to try to understand what each
message mean. It's quite tricky with CAN dump, which is the standard Linux utils
which will just flood your stdout with CAN messages, but Python CAN monitor helps a
lot by grouping messages by arbitration ID. So here I'm in the Fiat 500 and I am
driving actually, and you can see the different arbitration ID there and the
data that is evolving. The two last one, which are way bigger, are the standard
OBD, meaning that okay, I have a priority that is way lower than the other kind of
messages. So, reversing a bit, what can we find? I found the speed, four time, the
values were quite different but quite close anyway, so was it at four different
time or at the for different wheels? And it was actually at the four different
wheels, because when I turned it would change drastically two values out of four.
I have the clutch pedal with respect to the accelerator am i accelerating while
depressing or pressing the clutch, the brake data are the doors closed which one
are closed is a contact on is the handbrake up or down and this one is quite
interesting because it would change every minute. Actually it's the time and date.
So it was 9:00 p.m. on the 24th May of 2017 meaning that they created an ECU
would which only job was to send the current time and date readable in
hexadecimal format on the CAN dump like this.
*laughter* But what that was I found it funny I've
weird sense of humor, anyway so this thing even masters this time to explain to my
mother what I'm doing with her car so this was a kind of capture was doing from my
school to my home like I was recording what I was doing in the car, recording at
the same time a CAN dump and displaying what I could display so I have the
handbrake, start and stop and engine is on okay it seems to be the doors are closed
hopefully okay. So this was quite fun to do actually. Okay what can we do with
that? Can we do something useful for humanity can we do maybe something a
little bit challenging or else it's absolutely not interesting? How can I at
least put something on my resume after that something I can be proud of? Yes or
we could try to do something completely stupid and that's what I was I mean to do.
So I created CANPad. The idea of CANPad is that with the steering wheel or brake and
an accelerator pedal you can drive any car in any video game. So.. *Laugher*
*Applause* So that's what I did. I take the CAN
messages from OBD sensor and back pass it to a piece on CAN and client and float
them through libuinput to be able to create a virtual gamepad and plays it in
V-Drift. So V-drift is an open-source racing game that allows one to play on
Linux through at least libuinput. So this is a start and stop button that I use
as a toggle to send data and here I'm driving with my mum's car, a car in a
video game. *driving noise*
So I have the steering wheel the handbrake all every pedals is quite it's quite hard
to drive right now. *laughter*
And my official goal is to drift. So at first I have to learn how to drive at all.
It was actually quite nice when I managed to do anything at all. So you can see that
data is only like 16 bytes long and *music*
*applause* That's the best drift I was able to do on
this game. So I was actually quite disappointed right now. So features and
limitation of this. So the features is what I was explaining right now. But the
limitation are that the engine needs to be running because else I don't have the
assisted direction which makes the wheel quite hard to turn. Also on a real car if
you really see steering wheel it will by itself try to match the car direction
which I don't have so I would just spend all my time turning the wheel. And the
control simplicity going through libuinput limits it to V-Drift because no
other Linux game recognized my virtual gamepad as a real one. So I was quite sad
and but I really wanted to drift. Oh wait I created another version which is CANpad
v2. CANpad v2 I just understood that on the real game pad game box - Xbox, Xbox
gamepad. If I plug the Xbox gamepad and don't touch anything no inputs will be
sent. On the other hand if I put a PS4 gamepad and don't touch anything it will
flood the status of every button all the time so what I would do is take the Xbox
controller put it on the table and hijack its port to send data instead of it. So I
would have a real, a real plugged-in controller that is recognized by nicer
games like V-Drift, like DiRT and I could send inputs by my, myself. I change this
few stuff like the gas pedal because I had to flow in the real world to flow in the
game which was quite fuel consuming, the steering wheel rotation was adjusted so
that it matches, it matches rally cars like if I turn it 180 degrees it will turn
all the way in the game so quite nice, and I found the direct command to query and
break in the in the video. In the next video you'll see that when I turn abruptly
in the game and I release at the same time the brake the wheel will take a little bit
of time before stopping to turn because I have a small delay. But now I have the
real input so it's way easier. so: demonstration. So, some sensors:
*soundtrack* Start and Stop *soundtrack* I just wanted the music. So, anyway, as you
can see it's way easier to play because of the steering wheel which was adjusted it's
way nicer to drift in it. I can do the crane drift
*applause**soundtrack* my brothers were very fond of this. My
mother was only thinking about her tires right now
*audience laughing* *soundtrack*
Anyway. Sorry. I'll give you the title of the song later if you want. So I can now
drift with my front-wheel drive car in any kind of video game which is almost quite
very nice. So possible upgrades - yes there're always upgrades: I could get the
gearbox tattoos to put the car on the lift and try to put it in manual which would a
be a bit more life... life kind and create a better gamepad so that I'm able
to race on my Micro- windows because right now it's only on Linux. Okay this was fun
but it was actually consuming a lot of gas for nursing. So with Guillaume we try to
find a way to reduce gas consumption and that's what he will - he is going to talk
to you about right now. Guillaume?
Guillaume: Thank you, Stan. *Applause*
So, Stan had a little problem about the gas consumption and the friend of us told
us about this little nitro OPD dongle which is supposed to save fuel. It's sold
on Amazon and the reviews are quite good so we said "ok, strange but ok" let's try
it. First of all just a reminder about the - what is an OBD2 dongle? An OBD2 dongle
is a small device that you plug into the OBD2 port of your car. Any recent car has
an OBD2 port you can find it by googling the model of your car and OBD2 port and
you will find a picture of it and the interesting thing is that you just have to
pull the panel to access to your OBD2 port and it's very cool because we don't have
to take anything apart or whatever. So, just buy the thing on Amazon, pull the
panel and put it there. That's all. So, this dongle is supposed to save fuel by
reprogramming the main ECU - the engine ECU of your car. And this is done for
quite some times: This is known as a chip tuning and you can find it on internet. It
works pretty well it will break your warranty, but the very interesting
thing about this dongle is that you will not break your warranty because, if you
remove it you will go back to factory settings and this is very new. So, it
works on any car, well any recent car and well it seems to work really well. Ok so
why did we reverse engineer this dongle? Because it just an amazing piece of
hardware. If you think about it: it works on any car and it also reprograms any car
so it must contain all authentication codes. Stan explained the challenge and
response mechanisms so this one must contain all of them. It will also contain
the reprogramming software for any car of any manufacturer and this is also just
amazing and I just wanted to have a look at this and it is able to adapt itself to
the way you are driving for a few kilometers then it will reprogram your
engine and I say wow there must be a very smart algorithm inside this very small
piece of hardware and I just wanted to have a look at this software. As I said
also - it also modifies the RAM of your engine and I was not aware of anything
that will be able to do that because from the things I know about chip tuning it
will change the flash of your ECU. That's why the warranty is broken but not this
one, not this one. And this is just amazing. I just wanted to have a look at
the source code while the binary. Ok so. The first thing about reverse engineering
such a piece of hardware is monitoring the CAN signals to see if it's talking and
what he - what it is doing exactly if it's opening security sessions or not. Well,
all this stuff. So, here you see in my car. There is the OBD2 port right there
and I used the same configuration as Stan to record the CAN messages which is a
Raspberry Pi here and the PI CAN2 shield and well just for fun a picoscope to
check the signals and a computer to - to monitor this. The thing is you just have
one OBD2 port in a car and - here - and you cannot plug at the same time the
dongle like - like this and the wires for the Raspberry Pi. So we took
apart the dongle and after a bit of reversing the PCBs we found the can lines
and ground and we just soldered three wires on it. And with using this approach
you can reverse the messages sent on the bus. The interesting thing is that as you
are plugged directly on the dongle you will monitor exactly what the
dongle is doing and what he's seeing. Just for reference you just have three wires to
put in a car to hijack or to communicate on the CAN bus. Those are CAN high, CAN
low and the ground and that's basically all you need to connect to a CAN bus. Just
for reference: you can find on today's cars you can find many many CAN buses in
in the different parts of the car. So the OBD2 port is just more accessible but it's
basically another CAN bus just like another one. Okay. So, we did two
measurements: one with basically no OBD dongle plugged in and there is a one with
the OBD dongle plugged in. Stan explained in the first part of the presentation that
every CAN message is sent by an ECU and the identifier of the ECU is called the
message ID and the lower it is the higher priority is. Here you are the most - you
have the most prior - you have the message with the - the biggest priority and here
with the lowest priority and you see here the - the content of the messages. The
thing is, if you look at the lists of the message IDs - here - and the list of the
of the message IDs - here - you can see: it's the same list. Basically it means
that no other ECU was talking on the bus when we plugged the OBD - the Nitro OBD2
dongle. So, it means that the dongle basically doesn't speak at all on the CAN
bus. And that's too bad because we say how is it possible that it works if it's not
talking on the CAN bus? Okay. Is it over, is it just not working? Well not really. The
dongle is advertised as working after 120 kilometres. It will just listen silently
to the way you are driving, then reprogram your engine after this small amounts of
kilometres. So it was still possible that the dongle was not sending anything during
the first kilometers. And - but we couldn't just monitor the CAN bus during
such a big period of time and so we needed another approach and we chose to reverse
the PCB. If you take the dongle apart, you can see two PCBs. The first one here is
just connected on the OBD 2 port and the other one seems to contain, well,
something. Okay, so this is a picture of the first one. As you can see, there is no
components on it at all. It's just routing the CAN wires from there to the second
board. So okay, let's go on, and the second one is more interesting. On the
front side, you can see, well, a few components, but there are not so many. You
have a voltage regulator here, 7805, you have a push-button, this diode is part of
the voltage regulation and that's pretty much all you have here. And three LEDs,
you have three LEDs, okay. On the back side, you can see, here there is the
footprints of a very small microcontroller, and here is a picture
before dissoldering it. And the interesting thing is that there is
absolutely no reference on this device, as if the manufacturer took a special care to
hide what was inside. And this is not so common because usually you can find a
reference in a chip. Also, there is no CAN transceiver on this device, yeah, it's
strange. What is a CAN transceiver? A CAN transceiver is a piece of hardware to
translate the signals from the CPU, which are basically UARTs, into CAN signals
which, are CAN high, CAN low, this is a differential pair. But this device is not
just about adapting the signals and electric conversion. It's also about real-
time monitoring and checking. Stan explained before that in each frame, you
got a CRC and an error bit. And if there is a transmission error on a frame, any
CAN transfer has the duty to assert the fault in real-time, so it just has a few
microseconds to compute the CRC in real- time and say "Okay, no you just have to
discard this frame". Basically, two tasks for this one: electrical signal conversion
and checking in real-time. Okay, so you have no CAN communication, no CAN
transceiver, okay, it smells weird. A few guys told us "yeah but maybe it's possible
to do that in software because, you see, those are just signals and maybe with an
IDC and so on you can do that in software." I put a link, if you are
interested, here, for Stack Overflow discussion, which is very interesting and
a few guys say "ok, yes, it's possible to do that in full software, so you basically
don't need a CAN transceiver". The thing, is as the CAN transceiver has to react in
a real-time, you have to have a very fast CPU to do that in real-time. And the guys
on Stack Overflow say "Ok, it's possible, but at a very low speed like 10 kilobits
per seconds or something like this." But on a real CAN bus on a real car, the speed
is more like 500,000 bits per second, so it's not the same order of magnitude. And
then, some of the guys say "Okay, maybe there is some CAN transceiver inside this
chip", and I say "okay, yes, it's just a small A Super8 chip, there is nothing
there, just a small microcontroller ", but, just to be sure and because we like
to decap chips, *laughing* I asked my intern to do that because, you know, there are toxic
fumes and things like that. So here is Stan in my garden and, well, it was pretty
- it was the first time I did that, and Stan also, and the thing is, it's pretty
easy to do that, but if you want to do it, just be careful because it is very
dangerous stuff. You can buy it on the internet, it's very cheap, and, what do
you need? You need cooking plates, here, to produce some heat, crème brûlée, or
just the ceramic plate. You pour the sulfuric acid in it, you wait for it to be
hot enough and that's all, basically. Just throw your chip in it and you're done.
Just wait 10 minutes and that's all. So again, if you want to do it, just do it
because it's fun, but use protections because it's very dangerous. Okay, well,
here is the results. I put a real CAN transceiver here, and this is the chip you
have in the nitro OBD 2 dongle. Some of you, you will recognize the basic
structure of a small microcontroller. Here, you have the CPU logic, here you
have the memory banks and some glue logic there. And that's pretty much all you have
there. The interesting thing is that, this does not fit into this. So definitely,
there is no CAN transceiver in the Nitro OBD 2 dongle. The other thing I would like
to show is if you look at this, we said before that the Nitro OBD 2 had to contain
a database for all authentication algorithms. All the way to reprogram any
car on the market and so on. And this is all the flash you have inside. I was
expecting at least a big chip of flash, but there is nothing here. So basically,
it just looks like a tiny microcontroller, like an Arduino or something like this.
But I really wanted to know what chip it, was so we have a game at the office, it
was looking for Waldo, and because the chip manufacturer like to write chip
reference inside their chip, and, well, there is something here. If you look at
the chip, the big magnification power, you will see this and this is the chip
reference. Unfortunately, I could not find any reference on the internet about this
chip. I asked a few friends on Twitter and so on, but nobody could find it, which
means, well, I don't know, this is not a big chip, very well-known. If you know
what it is, just tell me, send a mail or whatever and take the microphone during
the question answer session, it will be nice. So, just to sum up this part, this
dongle is very nice but there is no CAN communication, does not contain any CAN
transceiver, it has not enough CPU power to emulate a CAN transceiver in full
software, and the most important thing is that it has no flash in it to contain the
database, you know, to reprogram any engine and so on. But the links are
blinking very well, so, yeah. If you really want to reprogram your car, use
something else. Thank you. *Applause* I would like to invite all of you, if you
are interested in car hacking, to try and put some OBD cable into your car because
it's very easy. You just have to pull a panel to get access to your OBD port. You
will just need a Raspberry Pi, CAN shield and a cable and that's pretty much all you
need. Just a few words: so you don't need to take anything apart, so it's pretty
easy, you can do many interesting things just by using the OBD2 port of your car,
like fuzzing and so on. But please be careful, you can hurt yourself or break
your engine if it's running, so if you do some fuzzing, please stop the engine
before. P1kachu: Because as you saw at the
beginning, I was actually recording CAN data or querying stuff while I was
driving, which was the stupidest thing I did from the hole analysis. I was able to
disengage ABS by fuzzing, too - stuff like this - because they have some systems that
if they receive too many invalid kind of messages, they will just shut off, so I
was able to disengage stuff like this, so, yeah, if you are doing stuff like this,
just don't drive while doing it, for example. That's the kind of stupid mistake
you do when - or disable the airbags. Guillaume: That's very important.
P: You never know. G: Well, thank you again, and, yeah, if
you want to speak with us, you're more than welcome. Thank you!
*applause* Herald Angel: Thank you deep guys, I could
normally skip the car hacking talks. This time it was really amusing and I'm happy
that I didn't do that. We have a lot of time for questions, if you want to line
up, there's one over there or two of there, one over here and one over there.
Are there questions from the audience? Signal angel?
Signal Angel: So, people on the stream are wondering where they can find your
software and whether you contributed any signals you found to the open DBC project
that is collecting signals from the CAN bus.
P: I haven't really heard about this - yet. So right now, not that much, but I
will take a look at this after this. Sorry
Herald Angel: Mic 1. Q: I was wondering you try to reverse
engineer to get into the secure mode so that you can access all the issues. You
want to... we reverse engineer this challenge/response authentication.
P: Yes. Q: Why does he not try to reverse engineer
the diagnostic software that is used by the dealers?
P: Because this infringe, we call this valise, like luggage, and it costs if I
recall correctly about 5,000 Euros by car manufacturer. So we went to a garage and
asked the guy "Can you lend us your valise?" and he just laughed at us because
no he didn't wanted to but there are some partnership you can have. [There] is a
group of manufacturers that offer that kind of information if you pay every month
a very huge sum of money. Q: [...] pay 6 Euros and can be used for
an hour. P: I haven't heard of it I just saw a big
numbers and I told myself, okay, I find another way.
Herald Angel: Microphon 3. Q: A great presentation. Thank you very
much. I was just wondering, how much more work is needed to actually control your
car with an Xbox controller? *Laughter* *Applause*
P: I was asked this question before. Not that much *Laughter* if you find the right
guys with the right amount of knowledge. The idea that you'll get, of course. You
have to find a way to control the car from the CAN bus which is not something that
easily done. Because for all I know right, now the CAN bus I was only used for
broadcasting information not really using this information for real-time data. We
actually tried to find some way to know how the ECU's interact with each other
with Young's car. So the idea was that we go to a field, I am on the passenger seat,
and he would just tell me "okay try to find the ABS ECU I will brake very hard"
so he was driving fast breaking. I was just checking which ECU would actually
send something different and after we've tried to recreate some messages,
but without a lot of luck. So from the CAN bus I don't think
that's quite possible. But they did it. Nissan did it like two months ago with the
GTRC. They created a Nissan GTR that is actually controlled by a gamepad
controller. But they have a full robot in it just controlling the steering wheel and
pedal so it's quite easy when you have money. *Laughter*
Herald Angel: Microphone 2 in the back, please
Q: Okay, hi nice talk. Thank you. First of all don't play around with the Airbags
please. I tried to reverse engineer my old Mitsubishi - I'm a passionate Mitsubishi
driver - please don't try mine. You get hurt, really. So my real question is: Did
you try to reverse engineer cars with an older bus then OBD, ever? Because mine is
from the 90s. P: Yeah, No I didn't because I had my and
full already with the with OBD. To be honest before this analysis I hadn't
touched any kind of bus or any kind of car systems ever. So I was really discovering
everything from scratch. So I just focused on the OBD port and the CAN bus and stuff
like this. But I know there are a lot of different stuff Valasek and Miller already
did different kind of attacks on the Jeep for example of the Prius with different
buses. So I ought to be looking at them but right now no I didn't do anything else
from the OBD or CAN bus. Herald Angel: Is there another question
from the internet? Okay otherwise mic 1. Q: Sorry, just one sentence. I guess
because of the Mitsubishi stuff you've mentioned the car your parents or so I
guess we should talk about the Lancer. Okay?
P: Okay. *laughter* Herald Angel: Mic 1.
Q: Thank you. There are some other buses like EtherCAT or Flex Ray in other car
manufacturers. What about hacking them? So you also said, you already said that maybe
you will try it in the future? P: Well quite the same answer also. I read
the car CAN books, so I just have a few a little grasp of other kind of protocols
and other stuff like this. Right now I didn't do anything. I am planning on
trying different new buses but right now just the - I haven't touched them I can't
answer and more honestly than this - I don't know. G: The other thing is that on the OBD 2
port you just have access to the CAN bus and as far as I remember the Flex bus is
internal and dedicated to high speed buses. So it's not as easy to plug
yourself onto this bus because you have to open your car and take things
apart and stuff like this. But it's definitely interesting to look at it also.
P: Sorry. Herald Angel: Okay, another question from
the 3, please. Q: Oh it's 4. Okay, so just a little
hint. OBD2 is actually just half of the fun so you should definitely remove your
car radio and check if there's a CAN bus behind that I know for BMW have it and
there of course it's much easier to control of all of the fancy buttons that
you have in your car. Like window and wipers and all that stuff because that's
completely unencrypted and so can simply listen on this and also send your own
commands. P: Okay, so, check the other CAN bus in
the car, right? Q: Yeah it's I mean it's maybe the car
radio, because you don't have to cut anything just plug it off, take an adaptor
and put your own bias on that. P: Thank you. Maybe another talk.
Herald Angel: And yet we have one question from the internet now and then the 1.
Signal Angel: So there's a person from the darknet who would like to leak you
original diagnostic software for that kind of hardware and the person wants to know
whether you would be interested in that? P: I haven't heard the end of the sentence
but the beginning. Signal Angel: Would you be interested in a
software leak of original diagnostic software? *laughter* Actually you don't have to
answer that because the person is outside but if you want to say something you can.
P: *Coughing* You have my Twitter. Herald Angel: Yeah question please.
Q: First thank you for your very inspiring speech luckily or unfortunately I don't
own a car myself otherwise... Well, what I wanted to say was, you now have your hands
on a few Volkswagens. If you could choose a car yourself what brand would you like
to monitor. P: Ah, to monitor. Actually, what I wanted
but I haven't taken the time right now, was to play with the Lancer, the big mother's
bus, because it has UConnect and as far as I remember it was one of the attack
vectors Miller and Valasek used in the past, so I think I would go with the one with
full features everywhere and remove parts to be able to get to the fun stuff. So I
would take one with a lot of electronics, not too much, because it's expensive, but
at least a bit of electronics, so that I could remove stuff and do interesting and
nice stuff. Herald Angel: Thank you okay and another
one over there. Q: Hi thank you and I enjoyed your talk. I
think I read you already online or I read something about doing that what what you
have done. It's really fun just a few correction to the last part - the
transceiver does not do any error correction it's just a transceiver. And
there are chips actually available which have a cortex m0 and D transceiver on chip
for few bucks. P: Okay.
Q: So those chips exist and are used in automotive and just for your fun for next
year: choose the right car just depending that question from that girl. There are
car manufacturers who can do networking and who can do and your... let's say you
are candy with the right brands. Like the Italian.
P: Thank you very much. I have way more information that when I started this talk
which isn't much what I expected at first. Herald Angel: I would say final question
Mic 1. Q: Very small question but did you
consider lifting the front wheels instead of starting the engine to make it steer
easy. Yes I put it on parpar - the block of cement you find - but it's not the
easiest part. What would be easier what was done was to put cardboard under the
wheels to make it easier with a little bit of oil to turn but here to be able to play
without the engine turned on and with assistic direction. Kind of putting the
car on a car lift would be the safest way. Because just putting the front wheels I
wouldn't see anything from the windscreen which would be a bit disappointing.
*laughter* And yes I indeed I plan to put it on a car lift soon.
Herald Angel: Anyone who didn't get the chance to pass the question on stage, I'm sure that
the speaker's can be approached next to it. Thank you again for being here and
drift on. P: Thank you very much.
G: Thank you.
*Applause*
*34C3 postroll music*
subtitles created by c3subtitles.de in the year 2020. Join, and help us!