Let's go and get started. We are going to talk about how your car isn't. My name is BitBang.
There's also some who call me Tim. I am a largely recovered software developer. I spent most
of my career writing embedded systems for planes and the types of planes that you fly from
the ground and cars. Somewhere along the way I've become a hardware guy. Still not quite
sure how that happened but people keep asking me questions about hardware and I know the
answer apparently. So I've been doing that a lot recently and I still get a bit twitchy
around certain aircraft. I'm N2. In meat space most people call me Mitch. I am also a
recovering software developer. I'm not quite as recovered as Tim is but get in there. I've
had a passion for embedded development for a long time but for many years I was
paying the bills doing web dev. It's a lot more fun breaking stuff. So that's what I do now
full time. So this is your car. This is what it looks like now. There aren't things like
carburetors. You don't replace your jets and tweak your idle screws to tune your car anymore.
You do it a little bit differently these days. So I'm going to go ahead and get started. So I'm
ORP system. Your car is actually a network. A bunch of different components connected over
typically other types of buses that we'll talk about later. And actually with that again your
car isn't a network it's a whole bunch of networks. There's a bunch of stuff on there like a can,
ethernet, Wi-Fi, Bluetooth, over radio, wirelessorener where tire pressure sensors. We'll be putting
another radio on there for autonomous driving called a DSRC radio. If you don't know what that is, just look at
I just see attack surface. So they're just networks. We've been protecting and working on
networks for dozens of years now. We know how to do that. No, not quite. These are not the
networks you're used to. So there's a bunch of standard techniques that used to be employed
and are still employed for standard like TCP IP networks that don't work on CAN bus for a
variety of reasons, which we will talk about now. So CAN bus has a tiny payload. It's 8 bytes
in a packet. Now there are standards like ISO TP that allows you to send more traffic on the
CAN bus, but CAN bus is also slow. About 500 kilobits per second is typical in a car. And
there's a lot of data on a CAN bus. So if you hook into a CAN bus, we have our
demo out in the car hacking village. You can hook into the bus, see the traffic. There's a lot of
stuff going on there. And making it longer and making it take longer to process isn't always an
option. Your processors on a lot of these ECUs are eight 16-bit micros with I can count the
flash and RAM on my fingers in kilobytes. Very, very small processors. It also makes things
like authentication. A lot of these things are also very safety critical, very time
sensitively safety critical. So you add a bunch of overheads, you add a bunch of
overhead to do authentication, add a bunch of overhead to do your encryption, all of a sudden
you can't hit your timing requirements for safety anymore. You also have the question of
protecting the keys. We actually give cars to people. I don't know how many of you realize
this, but everybody who owns a car owns a car. And they have access to all of these things that
are in the car. And if you're going to ship the key with the car, it's only a matter of time
until somebody rips it out of there. Traditional networks use things like IPs and
firewalls. They tend not to work quite so well in a CAN bus network. If you have any sort of
message passing ability, lots of the time the messages which are normally passed in the course
of normal operation can be used against you. So on most vehicles, there's some sort of diagnostic
methodology where you can actually pulse the ABS modulator to bleed brakes. That's a normally
allowed message. So it gets through a firewall. And if you have any sort of message passing
through the CAN bus, it's a firewall. On the CAN bus, there is no way to determine what node on
the bus is sending a network. So once the message gets on the network, it's indistinguishable from
any other node's messages. So if the message can ever appear on the bus, it's basically forced to
be treated as valid. So what about intrusion detection systems? Something a little bit smarter
than a firewall is able to say something like, you know, you're a driver, you're going to get a
call. Hey, you know, we're trying to bleed the brakes and we're going 70 miles an hour down the
interstate. This probably shouldn't be happening. And while I'm not denying that this could be a
part of the solution, what do you do? I mean, you can't just disable the ABS module because you
kind of need that. You can't just pull over to the side of the road because that might not be a
safe thing to do at the moment. So there's a question, so you have this IDS that alerts you,
which is great, but what do you do about that? And what do you do with that alert? It's like a
check engine. You're going to take it to the mechanic in three months and, you know, see what's up
with that. So what can we do? Segregating networks is a great first step. You can't hack or influence
what you can't talk to. So if you have dedicated buses for just talking between the power
steering and I don't even know what needs to talk to the power steering most of the time, usually the
power steering is for speed-related messages, there's a lot less attack service on the bus. So if
you can't talk to your brake module from the head unit, then no one who gets into the head unit from
some sort of Internet connection can apply your brakes in the middle of, like, driving. Good
things. Having some sort of internal sanity checking on each module, so I'm going 70 miles an hour
down the highway, maybe now is not the right time to try and bleed the brakes. Some of these we're
starting to see in modules, not as much as we might hope. For all of these, like, it's just a part of a
broader solution. The end solution is probably getting rid of CAN altogether, but eventually maybe.
That's going to take a while.
So what does it mean to hack a car? Is this car hacking? This is actually more expensive than a lot of
forms of car hacking that we're going to talk about. Those things probably cost 20, 30 bucks a piece.
I mean, that's a lot of money going into that Audi there. Axes aren't cheap. No, they are not.
So hacking a car, what does it mean? That depends on who you're talking to, who's doing the hacking,
what systems are in scope for the hacking that you're doing, what are your goals? Are you trying,
you know, like, for the modern community, like, they're trying to get into the ECU and do some
performance tuning. That's the hacking that they're doing. There's nothing malicious about it.
They just want their car to go a little bit faster. There's plenty of other things that we're
going to talk about, too, in a couple slides. So hacking a car can mean a lot of different things.
Like Mitch alluded to earlier, a lot of stuff that we found is diagnostics that are left enabled on
ECUs that can be enabled at times that would be somewhat inconvenient for the driver, like the
brake bleeding at 70 miles an hour. Sending CAN messages to control the vehicle, doing
enough reverse engineering on the CAN bus to figure out what different messages do. Taking over
the infotainment system via the Internet or SMS, this is kind of getting more into your, you know,
more standard Wi-Fi type hacking, where this is just a infotainment system. It's a full-fledged
operating system. It's, you know, Windows CE, QNX, Android, running Wi-Fi, running Bluetooth. This
is a lot of attack surface, a lot of what's very quickly becoming very well-known attack
surface. And, by the way, these are also almost always connected to the CAN bus. Now, the
segregation is actually happening. We're seeing it happen in the real world that the infotainment,
which used to maybe be on every CAN bus, is now only on a couple of CAN buses. And, you know, the
infotainment system is on a couple of them, which is great, you know, especially isolating it
from the safety-critical systems is something that we're seeing happening now. So now you still
have to pivot off something in order, because there are things that are connected to both CAN
buses. You've got to find a device that's also vulnerable to compromise to pivot then onto the
bus that you want to get to. And, I mean, GPS, a lot of the cars have built-in microphones for
your cell phone, using the TPMS sensors that all have a unique ID to track a vehicle. Yeah, lots
of other concerns as well. And all these different types of hackers, these different goals in
mind are going to employ various of these and other attack methods. Something that's useful to
know when you start actually looking at hacking cars is that the OEMs, so, like, Ford and
Nissan and Volkswagen, they don't make cars. They put their cars on the road, and they don't
put them together. So they subcontract construction of pretty much every assembly in the
vehicle. So the primary subcontractors are called Tier 1s. Tier 1s employ Tier 2s who employ
Tier 3s, many levels deep sometimes. When you're dealing with security requirements, there's some
high-level requirements that the OEMs specify when they're designing the car. This must be secure.
Who knows?
knows if those actually get implemented down the line. Some of this stuff is really hard to
verify experimentally. As we mentioned, the relationship between OEMs and their Tier 1s and
their Tier 2s and their Tier 3s isn't always necessarily a completely healthy, open and
honest one. Which in some ways makes sense. These Tier 1s are working with more than one OEM.
They have their secret sauce that makes their stuff better. So they put on their marketing
glossies. So they don't necessarily want to just give the OEM complete access to all of their
source code, all of their information, because they could lose out on competitive advantage
that way. So that's the question. What exactly do you do about that? There's a lot of
project manager chicken being played. Yes. I'm going to go to the next question.
So who's doing the hacking? As I mentioned, modders. They want to add cool features. They want to
make their car go faster. They want to turn their LEDs blue instead of yellow in their car. All
those very vitally safety critical features in there. Security professionals. I hack on cars, too.
To protect and against what? What's actually important? Where should the focus be put? And how
do we address some of these fairly complex issues that face the automotive industry? I'm going to
go to the next question. Expedition engineers. Code execution. Like I said, these are often very,
very small micros. They're not running an operating system. There's no data execution
prevention. There's no ASLR. If you find a buffer overflow, you stick your cell code on the
stack, overwrite program counter, and jump to it. It's back to the 90s in terms of security, because
these small processors that are in use just don't have these features. There is no operating system
in use to add these features. So I'm going to go to the next question. I'm going to go to the next question.
Organized crime. This is actually the one that kind of, so what keeps me up at night isn't so much,
you know, hacker, you know, Fast and Furious 8 hacker taking over the world and crashing all the
cars into each other all the time. It's more targeted stuff. Targeted assassination. One of the
saving graces of the automotive industry is that there is so much difference in a car. There's
different, every car has different ECUs. Even between model years, when you find out on a 2012 focus,
there's a lot of difference. So I think that the hack that you have out there might be different,
at least in some critical ways, from a 2013 focus. So the hack that hacks all the cars just isn't
going to happen because of that difference. But the hack that hacks one car is a lot more in
reach. And of course, nation state level stuff that I'm not going to get into. In terms of
organized crime, larger crime ranks are starting to figure out, oh, I can actually use like relay
attacks to do a remote replay, not replay, relay attack against most keyless entry dongles and
steal cars that way. It's actually pretty easy. I think there was a good talk on it last year at
Def Con? I'm not sure. Yesterday. I missed that one. So how are, you know, targets and
all these various people hacking into cars.
There's a lot of different interfaces
you can actually get into.
So all of these are networked at this point.
Your OnStar uses like a 4G AT&T connection
that's always on.
The Uconnect system is on Sprint.
I don't actually know off the top of my head
what other cell networks the other OEMs use,
but most modern infotainment systems
will be connected to a 4G network somehow.
There's much lower level like debug interfaces.
So you've got JTAG and SWD interfaces.
If you can actually take the time
to pull a module out of the car and tear it apart.
If you have an active debug peripheral,
you can dump whatever from where you want most of the time.
Even if you don't have a debug peripheral,
there's other buses you can attack.
If you want to reverse engineer
the operation of subcomponents,
you've got SPI, I2C, and UARTs,
which are commonly used to talk between modules
on the same board.
Firmware updates are less secure than you might hope.
I don't think I've yet encountered a submodule
other than head units that use code signing
or anything like that.
I don't think there's any sort of decent integrity checking.
There's lots of different radios on your cars.
So even like your FM radio,
just listening to FM,
if you take a look at your head unit,
it'll display station names and track names.
That's done with a system called RDS,
the radio data system.
In addition to just displaying short strings of text like that,
there's an entire subsystem
for distributing traffic messages.
So it'll actually update,
on my car at least,
that's the method used to add accident indicators
on the navigation system.
And if you get really dedicated,
you can start decapping chips
to try and break into hardware security modules.
So general analysis is a lot of fun too.
Yes, it is.
And car hacking doesn't have to be all that expensive.
The CanTact, Canable are what?
If you want to build your own Canable,
I built them in like 15 quantity
for I think it was eight bucks each.
That's pretty cheap.
So the Canable and CanTact
are a open source hardware CAN adapter
built around a small STM32 microcontroller.
The default firmware exposes it just as a UART
using a standard CAN protocol.
And they're really basic hardware,
but they work really well.
Yeah.
I have a bunch now.
You can do a software-defined radio.
These are obviously a little bit more expensive,
but still pretty reasonable.
Like a Blade RF or Lime SGR is three, four hundred bucks.
Do a whole bunch of different types
of wireless hacking with those.
In addition to your standard on Wi-Fi,
your laptop has a Wi-Fi chip on it,
just use Wireshark.
And for the more esoteric ones like your TPMS sensors
or TPMS and the SCR works really well for that.
There's also the Yardstick One and the Pandwa RF,
which are slightly less capable than SDR like the Blade RF,
but still definitely quite useful.
Like the Yardstick One was used in the Roll Jam attack
against your car's key fob.
Which is a very interesting attack.
They're less capable, but they're a lot easier to use.
Yeah, that too.
If you want to use SDRs,
the most common way of interfacing with them
is with something like GNU Radio Companion,
which is a very complex flowchart-based radio setup tool.
The Yardstick One and Pandwa RF are all in hardware.
So it's configurable, and it does multiple modulation types,
and encodings.
But you set the hardware up, and you just do the data transfer.
It's much simpler to use.
And also the...
Is that my question?
Yeah, the can tag you were talking about,
is that like a USB to can?
Yeah.
So you're saying those are actually cheap to make?
I'm seeing the ones for sale for like $3.95 or $2.95.
All the commercial ones are way overpriced.
If you want to pay Vector, they're all overpriced.
Yeah, if you want to pay Vector,
and you don't have that much money,
then go right ahead.
But you really don't have to.
So where do you find the can tags?
So the can tag, I think the website is cantag.io.
I'm not sure.
If you Google it, you'll find it.
It's a unique project.
If you Google cannibal,
you will get Google auto-correcting it to cannibal,
and that's not what you want.
But if you actually tell it to search in verbatim mode,
you'll find the right project.
They're based on the same schematic.
So cantag was a project from Eric Evanczyk,
who writes for Hackaday.
It's literally just a microcontroller
that has a crystal on the side
and a CAN transceiver.
It's super basic.
The one thing you don't get in this sort of hardware
is any sort of galvanic isolation.
So some of the more expensive CAN adapters
will actually protect your PC
from high voltages
that they're going to get
or the CAN bus might experience
if something goes wrong.
These are just directly connected.
I've never had a situation where that's important,
but it's something to be aware of.
Still, a cantag and a USB hub is a lot cheaper
than anything you buy from Vector.
Yes.
I also have the CANCAT.
That's a tool we've developed in-house.
It's an Arduino Dewey with a CAN shield on it,
open source.
If you want to see a demo,
we have it at our car hacking lab
in the car hacking village.
Slightly more expensive than the CANtactor CANable,
but it also has two CAN transceivers on it.
So you can do...
CANCAT supports what we call CAN in the middle mode
where you can isolate a device,
basically use the two CAN transceivers
as a pass-through.
And you can also do filtering
or modification of messages
or block a certain method
or whatever you want to do to screw with it.
It's also really nice since CAN doesn't have a source IP address
or source address as part of the packet.
If you don't know which device is set
for sending a message,
you can use that to isolate a specific device
and then see which messages
that device is actually sending.
Otherwise the CAN bus is just nothing but
messages going back and forth
and no idea where they're even originating from.
Makena M2
is a Kickstarter project.
I think everybody said they're going to start shipping
in a couple of weeks.
I don't recall.
Yeah, it's going to start shipping in a couple of weeks.
It's also based on the Arduino Dewey
and after our CANCAT firmware runs on it.
Same deal, you get two CAN transceivers.
You also get
what else do you get on it?
It does 12-volt I.O.
It has
a single-wire CAN,
also called GMLAN.
It's used for lots of the lower-speed communications
in GM vehicles.
It does K-Line.
It does LIN.
Basically, if it's a protocol that a car speaks
that isn't automotive Ethernet,
it'll do that.
Does it do J1950?
I think it does J1950.
Yeah.
A whole bunch of stuff.
Especially if you have an older car you're hacking on.
Modern cars mostly just have CAN
and the single-wire CAN
if it's a GM vehicle.
If you're hacking anything before about 2008 though,
the Makena's awesome for that
because it has all of these older protocols
that aren't in so much use anymore.
But we're using those older vehicles.
It's a great tool for that.
And what's the fun in giving a talk
if you don't actually introduce something new?
So over the past couple weeks
I put something together we're calling CANFLY.
It's based on the ESP32.
Has anyone heard of the ESP32?
It's an IOT
targeted module.
It's got inbuilt Wi-Fi
and Bluetooth.
It does both Bluetooth Classic,
Bluetooth Low Energy.
It has a CAN transceiver on it,
thankfully.
It has two 200 MHz processors.
It's a little bit of a weird architecture
but the tooling is a lot better
than it was a few years ago.
So you can actually run
a modern GCC on it
which is great.
No crappy proprietary compilers.
The way the CANFLY uses the hardware
is it exposes a Wi-Fi access point
which you connect to
and then you
at the moment, the only protocol
that supports is the Metasploit Hardware Bridge
because that seemed like an interesting
place to start.
The Metasploit Hardware Bridge
is fairly new.
If you see Craig Smith around
he's put a lot of work into it.
Soon we're working on adding
you're working on adding support
for our existing tooling for CANCAT
and I'm working on
putting together a socket
CAN adapter so you can use it
with whatever socket CAN stuff
in Linux you might want.
But the main advantage of this
is that it's really cheap.
So being an IoT targeted module
the ESP32
you can buy it for $7.50
from AliExpress
or several other Chinese sites.
And then all you need
in addition to that
is a CAN transceiver
which you can find for as little as $1.50
on the checkout board
with all the bypass caps you need.
So this is what the hardware looks like.
It's not terribly impressive
because it's really simple.
All you have is the
ESP32 module
you've got the CAN transceiver
hanging out in the middle of the screen
and then I have it hooked up to an OBD2
connector.
The only other thing you need for this
is a 5-volt power source.
Do you have anything you wanted to say?
You usually
supplied over a micro USB cable
on most of the ESP32 breakout boards.
Yeah, for most of my testing
so far I've just plugged it into
a USB power bank and let it be.
At some point in the near future
we're going to put together
probably a separate breakout board
that you can plug it into
and actually power it from your car.
It's a really simple voltage regulator.
So the demo
is not particularly impressive
because it's just a screencast
of using Metasploit.
I was originally going to try
and put together a live demo
on something in the car hacking village
but I didn't want to risk
Wi-Fi at DEF CON
over that much distance.
It's not a good idea.
So here we just launched Metasploit.
We're going to actually
start using the Metasploit
hardware bridge client.
We'll configure it to connect
to the 192.168.4.1
router access point this is exposing.
Set up the port
connect with run
and we have a session
with the CAN fly.
The CAN fly is exposing
just one CAN bus at the moment.
If we need two in the future
we can probably attach
something via SPI.
Now I'm going to run
one of the standard Metasploit
hardware bridge payloads.
This is just something
that scrapes out a bunch of
vehicle info over OBD2.
So it lists all the bunch
of OBD2 PIDs
you can fetch
via standard commands.
It grabbed them.
We got the VIN.
We got the calibration ID
which is one of the standard
parameters on an OBD2
diagnostic connection.
And we have an ECU name.
So this is all running on a 3PO
our mobile car hacking lab.
So some of it looks a little bit weird.
Engine temp is negative 40 C.
There's no engine.
There's no engine temperature sensors.
It looks a lot more normal
on other things.
The engine light being off
is a little bit weird.
I think I might have
a few more bugs to fix.
Being so new
the Metasploit code
is still a little rough.
So I actually have my own
branch right now.
I need to get some fixes
pushed upstream.
But soon.
So let me touch a little bit
on what you need.
But here's a slide with all of that.
You need the ESP32 dev board.
You need a CAN transceiver.
This CAN transceiver
actually if you can find it
get the 232 not the 230.
There's basically just one fewer pin
you have to mess around with
to get the 232 working.
Just make sure if you do get
a CAN transceiver
the ESP32 is a 3.3 volt part
and most CAN transceivers
that I've seen are 5 volt parts.
Just make sure that you get a 3.3
If you just pick up a random CAN transceiver
it's probably going to be a 5 volt part.
So make sure you get a 3.3 volt transceiver.
You need a 5 volt power source
There's usually a voltage regulator
on the ESP32 dev board
to step down from 5 to 3 volts
to power the micro.
Wire and possibly a soldering iron.
And the total cost of all this
assuming you already have a soldering iron
on a power source is less than 10 bucks.
So the firmware for this
uses an IOT framework
called Mongoose OS
It's absolutely miserable
from a security perspective
so when you spin it up
don't run a port scan
like it's terrifying
how many ports it has on there.
Yeah don't do that.
It also crashes.
Yeah it does.
You actually compile the source
at the moment by
it's like compilation as a service
I think their goal was to
enable people to
compile firmware
without downloading a toolchain
so you post your source code
to the cloud
and it gives you a zip back
we're going to be rewriting this soon
so it doesn't use this firmware
it's not good
but it is simple
so the entire firmware runs 250 lines of C
it's pretty straight forward
as C goes
I wrote most of the query string
code at 3am without beer
so it's probably not
it's anything but bullet proof
but it works
it works
as soon as we get some time
this will be rewritten
to not depend on the cloud
looks like we are significantly earlier
than I thought we would be
Does anyone have questions?
Yeah what about
other software
stuff that's out there
that's cheaper than the car spy
software
that does the same thing
build loops of
so like the
vehicle spy
I don't do a whole lot with GUIs
but there are a few
open source projects
working on that
do you remember any of the names
Savvy can is a good one
this is the one I was thinking of
pick up Craig Smith's car hackers handbook
seriously for real
I need to start getting a commission from him
because it's an awesome book
Have you guys looked at any of the
monitoring products
like Verizon or Progressive
putting into their cars
saying oh we can make sure
we'll prove you're a safe driver
but they're putting these products in there
and I'm going to go out on a limb
and guess they have not been fully vetted
as far as security
so if you stay here
Corey Thune is giving the next talk
he's the guy who did the Progressive
dongle hack 3-4 years ago
so yes
these things are
not
my insurance company offers them
and my car does not have one
I'll put it that way
you can shut down cars
with those things installed
and you can get on the CAN bus
which on the CAN bus
you can do whatever you want to do
Are they only targeting at OBD2
or OCS?
Whatever CAN
you want to run it on
so I've been connecting it
to the OBD2 port
out of convenience
if you have like
some under hood CAN line
or something that you want to connect to
it would work for that too
Elevators often run CAN
whatever you can tap into
Do you guys have any experience
with J2534?
I've used it
I'm a bit familiar with it
it's just a windows
API pass through layer to get on
whatever bus you're using to flash
which
in modern vehicles is almost always going to be CAN
So you mentioned
CAN is an old
protocol
that's going to be phased out eventually
We hope
We only hope
So that's what I want more information on
what's the next step
what's going to
sunset CAN
what's that going to take?
For higher speed stuff
or latency critical stuff
automotive ethernet is starting to get rolled out
it's actually kind of an interesting physical layer
because it still uses two
wire pairs
but it runs at
gigabit speeds over it
it has
it's noise robust enough
that it actually works in cars
and you get all the benefits
of a ethernet
system
The car hacking
village badges actually have a
TGA 1100
automotive ethernet transceiver
on them
It's interesting because it's
purely point to point
much like gigabit ethernet
there's no way to passively
tap it in the middle
so you actually need to
to explain why
the way the
it's a full duplex protocol
you can talk and listen at the same time
and the way that works
this gross oversimplification
you send messages
and you subtract whatever you're sending
from what you see on the bus
so
you
if you try and
tap it in the middle
you can't tell what's being sent
because either side might have
sent that energy
so you have a lot more security
in that sense
there's no
question
what node something came from
yeah
So CAN FD is a protocol
which is
it was finally actually finished
standardization this year
I think
it's much like CAN
it's somewhat
compatible with traditional CAN
devices on the same bus
it expands the data payload
to 64 bytes
instead of 8
so you can fit a lot more
in a message
and it's also 8 times faster
to send the same number
of messages through
And also FlexRay
FlexRay is something
I actually haven't worked with a whole lot
but it's a bus designed for
time critical communications
it uses a bunch of complicated
time slot management techniques
so there's actually like a synchronous
clock
and each module on the bus
gets a slot within the bus
to talk
yeah
Anybody else?
Cool
Alright
Thank you very much