So, thank you all of you for being here today with us. We're gonna talk about, um, a
car hacking topic. Uh, let's go fast because I think we made 20 slides. Let's see. So, yeah.
Who are we? I'm Javier Vázquez. I'm a hardware security specialist. I work at Code White, a
German company. We pawn stuff. I'm from Cádiz, Spain. I guess you can figure it out already.
I'm sort of dark stuff. And yeah, I reverse engineer stuff, blah blah blah. I like cake when
it's not dry and barbecues. I mean, who doesn't like barbecues? So. Uh, so, hi everyone. I'm
Hendrik Ferdinand Nötscher. Uh, Ferdi for short. I also work at Code White in southern Germany.
Uh, among many things, I also like barbecues of course and lasers. Like, lasers are fun, right?
So, uh, we have to decide between doing stuff with lasers and car hacking. And, I don't know.
Maybe you can imagine what we're going for, so. Car hacking status. What's going on? So, yeah, uh,
besides remote stuff, like yeah, focus is on the canvas because data, blah blah. Replay attacks,
like yeah, you can record and then replay like such awesome stuff. Uh, yeah, so, uh, so, yeah, uh,
stuff like yeah some researchers also found remote exploits like uh slashing wheel tires and
stuff but yeah. Real hardware tech. Yeah it's like hardware stuff so and there are also some
really awesome tools to help understand the UDS protocol but is there anything else? So
yeah chip tuning is like uh it's own thing but it has a lot of common with car hacking
actually. It is car hacking. And uh there's ECU's being cloned uh G keys being dumped and data
being manipulated to get more horsepower or yeah that sort of stuff. Yeah also uh in the
internal data manipulation uh chip tuners uh often enable for example writing over OBD which is
disabled. That's actually quite a hack. I mean you need to bypass checks on RSA signatures. So
that's a cool topic. And yeah we also have a lot of things to do with chip tuners. We also
know OEM diagnostics right? They can do also fancy stuff. So yeah what's the secret? Uh yeah
my hat fell down. So UDS is not only protocol like really. There's also tunneling protocol which
is the canvas version of the keyword protocol 2000 which was used on all cars over KLAN. And
both offer a series of services uh SIDs which are like actually quite interesting but people
don't care that much about them. And yeah using these services you can get a lot of fancy
information. Even memdumps. Wanna explain that? So yeah. Uh let's compare the UDS and tp
2.0 very quick. So for tp 2.0 you actually have to negotiate a channel where the communication
will happen between the set tester and the module. So let me see yeah uh first we have a response
like 200 is always the common base of the configuration. It's a prefix you can use for a
channel negotiation request and like you can see the different fields split up and on the
bottom one you can see the response which is 200 plus the the target address and then you can
communicate. So yeah and then you have like the transmission. Transmission is just like the ID
which is the can ID you have the frame counter the frame type the and then like data blah blah
blah blah we will share the slides so don't worry if you're not getting it this fast. Then UDS
the only difference between UDS and TP is that you don't need to negotiate a channel you just
like broadcast you have your type of frames the first by this length and the type of frame but in
the end the data that's in the payload is what matters that's the SIDs the firmware whatever so
they are pretty similar they are both transport protocols actually. And just to make a
if it's somewhat visible uh that's the difference between TP KWP and UDS there's just like some
services are like divided into more small services like on UDS we have communication control on
KWP you have for example start com stop com disable normal message all that is handled by a
single SID on UDS you have four on KWP which is standing protocol so that's the only
difference on a protocol level.
So I here will shortly list a couple of interesting services so the first one is security access
which is which is uh the way you authenticate the tester against the ECU right so the security
access will unlock different levels of functionality it's like a challenge response then
there's read memory by address uh you give it an offset and it will return the contents and often
but not always uh requires security access uh read and write data by ID is like for for example for
the VIN the vehicle identification number um you give it parameters retrieve the data uh
request upload is like from the ECU's perspective so don't confuse the name it's like to retrieve
the firmware from the ECU and routine control allows us to start like custom routines for
example erasing the flash uh triggering all sorts of stuff like uh.
Like uh there are some fancy routines uh we found in some vehicles well ECUs actually in the
vehicles uh name it uh Bosch uh that would allow you to retrieve the the boot keys in EDC 17 and
MED 17 so basically you just trigger the routine you get the key and then you can unlock the
boot lock mode. Uh so yeah why all this stuff? Because cam badger. So yeah glitchers gonna
glitch. So let's take a look at the hardware overview. Uh it's uh an embed deltas that's
PC 1768 or PC Espresso. It has external RAM 128 kilobyte to speed things up. Two DV9 for uh
can, two debug headers, SD card, uh ECU power controlled by a MOSFET. We have UART we'll see
later why. Four GPIOs if you wanna add fancy LEDs and it runs in three different modes.
Stand alone, USP which is a CDC device, USP over serial or network. And yeah it can be powered with uh
power on and off. It's uh it's uh it's uh it's uh it's uh it's uh it's uh it's uh it's uh it's uh it's
a ah it's uh it's a gaming devices. It's a gaming device. Uh it has a power and has a blinky LED.
So that's really fancy and it's really cheap to make. It's under 25 bucks. Yeah. And we made it
like easy to solder so there's it's really easy to set up. So the firmware consider it a proof
of concept. Ok? Uh the actions are always handled by the cam badger itself so it doesn't really
require a laptop or computer whatever to perform any logic it's all implemented in the firmware.
Like UDS2 2.0 parsing, RAW can log in to stop it. We only have HD 20MB. It's uh it's uh really
uh just as a start uh we have a man in the middle mode, we have the emulator mode and we
also mentioned that you can have 3 different modes of uh operation. That is stand alone mode
without anything attached, uh UART mode where you get a CDC device on your computer and
connect with your terminal and then there's Ethernet mode which we will, I will go on to
that, don't worry but it's for use with the cam batches server so you can have multiple cam
batches in parallel. So fancy stuff. So uh just a quick overview on the protocol analysis,
so yeah many SIDs are already included in the firmware, it's just a switch case so adding
support for additional ones is really a piece of cake. It's extremely verbose, it parser, it
parses the SIDs and the parameters. Uh everything is done by the cam batcher firmware so no need
for PC, just the serial parser, you need a terminal and everything is stored in the
SD of the cam batcher so you can retrieve it later. And works with UDS and TP 2.0. So yeah
for the interactive session, the interactive session is uh interactive so it doesn't require
scripting and it allows you to perform actions on the go. I don't know if you guys saw before
we were starting the presentation I popped a termite and I was doing some stuff, that's
actually the the interactive session. So you start a diagnostic session, you start a
session and then you can think what's your ne- what your next move is gonna be. You don't need
like to write a script or anything, you can just try stuff, see what happens, change something,
try again, like with no rush. And there are built in scanners for SID parameters so for
example if you wanna go and check if there's any hidden type of diagnostic session or you wanna
see what offsets are readable by read memory by address or whatever you wanna check, there are
some built in scanners for that to make things easy and fast.
Uh let's talk a little bit about the man in the mill mode. It's also as I mentioned already
mention uh all implemented in pure firmware. So on the right hand you can see the original
traffic on the top and the man in the middle traffic on the bottom where the payload has been
changed. And on the left brackets you can see that there's no delay added. So it's pretty fast
and we tested a lot with like 30 or 40 rules. And basically the way it works is that you can
directly it will match any incoming packet on either port against your set of rules on the SD
card and it will like do basic operations like dropping frames, uh doing math operations or
substituting simple bytes. Uh yeah. So um we thought we could make it even easier to use a
cam badger. So we wanted to have cam badgers talking over internet so maybe they could exchange some data, you know,
uh to each other or just to have multiple ones running in parallel and this is why we had the
cam badger server. Uh it's written in python and here is a small snapshot it's actually not
themed but uh it looks different now. So on the left hand you can see the connected nodes and
this is where you will switch between different cam badgers. And uh the GUI was really inspired a
lot by burp suit so you can you have everything in one place and you can exchange data between
different modules like the logger for example send a frame from the logger to the replay tab or
create a rule for that. Uh yeah. So security access hijack. Why? So yeah we were talking about
security access and it's now starting to be more known uh so yeah uh just the test authenticating
itself against ACU. So but you need to know obviously the algorithm being used and the key
being used. Since it's random uh you need to know the key is being used and the key is being
used. Uh you cannot brute force it. I mean the the challenge is gonna change every time and
after three failed uh authentication attempts the ACU locks down for 10 minutes to 30 minutes. So
no brute force in there. What's the other solution? Hijacking security access. So you just
need a tool that uh is able to authenticate. You don't need to care about what the tool does. It
just needs to be able to authenticate. So for that for example we bought a cheap uh clone interface
for example. So you don't need to care about what the tool does. It just needs to be able to
authenticate for tuning the cars and every time we want to have access to something like
dunno the restricted diagnostics mode for example or reading some offsets that are not
standard we just hijack the security access and yeah. Then we have security access without
caring about that. So how does it work? The combat gear gets into a transparent mode uh
breach mode so it waits for the security access to happen. If the security access is not
succeeds it will disconnect the external tool and then it will take over the session and give
you a nice menu with a lot of stuff to do. So, yeah let's try the demo. We are running a
little bit bad on time but why not. Let's try the demo. So let's fire up our super Windows
XP. Yeah. Because why not. Ehhhhh. So let's try the demo. So let's try the demo. So let's
see. Ahh yeah. We all love waiting right? Yeah. Okay so in the meantime let's although
VMware do its thing, we're gonna do the demo in a while. Let's let up the, because we're not
that good on time. So yeah. Let's travel to the future on the next slide. So yeah. So we
hopefully we survived the demo. So what else can the Kanbatge do? So another thing we
can do, another fancy thing is dumping the TP and UDS transfers. We are, which are used for
firmware updates. So let's say a vehicle gets an over the air update so that will be
encrypted, signed, blah blah blah blah blah. But then it needs to distribute the firmware
updates over the network to the different modules. So it does that over the Kan. Most of
the time. Not every time. So if it goes that way and it decides not to use encryption,
which I, we have found some manufacturers do. Then the Kanbatge can just like, you know,
grab the whole transfer and dump the, the data. So basically dump the firmware that was being
updated. It can also spoof OBD2 data through the one in the middle and an emulator. The emulator is
like some other fancy stuff we will explain later. And yeah. You can use GPIO pins for boot
loading. Uh for tricord you know. Like some people call it zero day, it's just on the data
sheet. We call it like a function. And yeah. It can manipulate GPS signals via UDS. So
it can do that with the third pins. So why did we mention GPS? Hmm. Well many of you guys might
know those uh kind of donwels that give you rewards or um allow you to track vehicles for
example from insurance companies and they turn your safe driving into savings. Hmm. Let's
play a game. So the thing with these donwels is that they implicitly trust the data that is
coming from the car. It's requesting data over like diagnosis protocols and also they're
dependent on GPS so they do have some cross validation or some features that require that and
by spoofing the OBD data you can have your own driving habits. Uh yeah well and maybe if you
look spoof your location too it's going to be more money for you. Uh so that's one of the
features. So here we have an android radio that's not a stock radio. So basically running an
android app uh connecting to a bluetooth dongle that is plugged to the car. And you can see
that there's like stuff going on, RPMs going up and down. But the car is not really turned
on. Hmm. And now you can see that we stop the cam badger. The data will stop
changing. Yeah and there you see the feature you can just control it with a button.
You don't need to do anything. So yeah that was emulator we were talking about. So how
does emulator work? So just uh set up a file inside the cam badger and tell it to broadcast
every 10 milliseconds whatever I request. Which is a request for a PID. Which is the data
used uh by these insurance dongles. So it just keeps on making those requests as long as you
want it to. It could be like 2 hours. Uh log in, log in, log in, log in, log in, log in, log in,
log in. All the data that will be used for the emulation which is actually real driving. I
mean you just uh like go around in circles for 1 hour, log in the data. Then you create the
emulators. Once you create the emulator you got the data. Then you use the cam badger to
create the emulation data. So the cam badger will look on which SIDs were used, which PIDs
were used. Uh and just like ask you from which one do you want to create the emulation data. So
the way that the emulation data is stored in the cam badger because like we said earlier
everything is running inside the cam badger. No computer needed for this. Just press a button.
So we created a header that has the IDs, uh the protocol used, uh the SID, the PID and then
the start offset and end offset. So that's sort of a look up table. And then it maps
everything else in the RAM. So whenever it gets a frame, I mean on every single frame it gets, it
will check the contents of that frame against the whole emulation data. If it finds uh data
that can be used for that uh SID for that frame then it will provide the emulation data. If it
does not it will just forward the request straight forward. So the dongle uh the insurance
dongle really doesn't know if there's anything in between. It's getting all the stuff. And
yeah. It's uh it's uh it's a store using timestamps. So uh it's uh it's uh it's a store
using timestamps. So to get stuff real uh it will only check for the data uh change the data
when it actually changes. So to keep the emulat- yeah what a genius. So uh the thing is
that it will to reduce the size of the emulation files it will only log the changes uh using the
timestamp. And yeah. When there's nothing left then it just starts over. So yeah. Now we're
gonna do the demo. Uh so yeah. Uh let's do the demo now. Hopefully the uh so we'll be
having a workshop. Unfortunately it's already uh sold out sort of. But uh we're gonna release all
the code and schematics on Github their GPL. Um you're also welcome to go hack this stuff. It
doesn't have that much dependencies and if you're like an embedded coder anyway it will be really
easy to get set up for you. So.
So yeah. Okay. Yeah all fancy Windows XP machine doesn't want to work because why not. So
let's show something else instead. Uh we hope you guys will like it. So how much time do we
have left? Okay we have something. So are we connected to the cambutcher? Yeah let's actually
check it out. So. That's the cambutcher USB interface. So right now we have a um a Bosch EDC17
uh ECU connected. It's from a Volkswagen Passat so let's have some fun with it. Just to quickly
show you how it works. So yeah. Let's start the accession so you tell it your own ID, you tell it
the ECU ID. So yeah. We got UDS uh so let's just start the uh the uh. Uh. Um uh. Uh yeah. And uh.
established. So then you say okay I want to read memory because I just want dumps. So yeah
let's try to read memory. So you tell it the offset. You tell it I want to read ff bytes.
Whoops. We got an error. Service not supported in active session. Okay so let's see. Yeah I
don't really know what sessions are there so let's scan for session types. There we go. So we
have like different session types that can be uh initialized. 1 and 3 are standard. 40 and 4f
are not. Yeah I'll cheat a little bit because I already know it's 4f okay. So let's try 4f. So
let's switch to a custom one. Let's go for 4f. So it's established correctly. Okay let's try
to read again. So yeah read. The same thing. Yeah sure. And ff. So let's try to read again. So
damn it now security access required. Okay so yeah again we already reversed that ECU. We
already have security access so let's cheat again. Uh okay so yeah we're. Oh that was well it
worked. Awesome. So yeah. Level 3. So yeah. So yeah security access granted. Okay let's see
if it's true. Let's try again. So read memory by address. Let's try yeah blah blah blah. So
let's try ff. Yeah so this time it worked. So and we got a lot of fancy ASCII stuff. So that's
sort of the way the KanBadger works. Like you can like uh you know interactively interactively
try stuff. You don't need to script. You can like okay let's see if this works. It doesn't.
Okay let's try something else. So it speeds up things a lot. And yeah so let's like quickly
because we need to get out already.
Uh blah blah blah blah blah blah blah blah blah blah. So yeah. I've talked a lot already.
So yeah. Uh as I mentioned earlier code and schematics are GPL will be published on GitHub
like give us one or two weeks to clean it up a little bit. But uh we're gonna tweet about it as
well. So you might want to get our Twitter handle. Um so yeah we are very thankful for you
having us here. Um also we'd like to thank you guys for being here today. We're very happy to
have you guys on the Code White which have given us a lot of support and trust. Uh time
especially. And of course our family and friends who've been supporting all the way down even
if we run out of coffee. Yeah thanks to everyone for being here today with us. And I hope
we everyone and just DEF CON.