CAN I haz car secret plz?
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Vidal, Javier Vazquez
Noelscher, Ferdinand
The CAN bus is really mainstream, and every now and then there are new tools coming out to deal with it. Everyone wants to control vehicles and already knows that you can make the horn honk by replaying that frame you captured. But is this all that there is on this topic? Reversing OEM and third party tools, capturing firmware update files on the fly, and hijacking Security Sessions on a bus are just a few examples of things that can be done as well. For this and more, we will introduce to you the CanBadger! It's not just a logger, neither an injector. It's a reversing tool for vehicles that allows you to interact in realtime with individual components, scan a bus using several protocols (yup, UDS is not the only one) and perform a series of tests that no other tool offers. The CanBadger is where the real fun begins when dealing with a vehicle, and you can build it under $60USD! If you are already done with replaying frames on the CAN bus and want to learn how that fancy chip-tuning tool deals with your car, or simply want to get Security Access to your vehicle without caring about the security key or algorithm, we are waiting for you! Bio: Javier Vazquez Vidal is passionate about technology and specializes in hardware and embedded systems security. He studied Electromechanics and Telecommunications, developing a passion for electronics and technology since his youth. He has been part of several projects that involved well-known hardware, but his first public work was presented at DEF CON 21, the ECU tool. He developed the CHT, a tool to take over the CAN network, and had some fun with the ‘paella country’ smart meters. He is currently working as a Product Security Engineer at Code White GmbH, and has worked at companies such as Tesla, Daimler, Airbus Military and Visteon. Ferdinand Noelscher is an information security researcher from Germany. He has been working in Information Security for several years now. Ferdinand is very passionate about Offensive Security research and has been working on numerous embedded security projects, and some lasers too. Furthermore, he gave a training together with Javier at hardwear.io. He is currently a Security Researcher at Code White.
 So thank you all of you for being here today with us. We're gonna talk about some um card hacking topic. And let's go fast because I think we made 20 slides. Let's see. So yeah, who are we? I'm Javier Batkev. I'm a hardware security specialist. I work at Code Wide, a German company with on stuff. I'm from Cadiz, 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 alive. I'm barbecues. I mean who doesn't like barbecues? So. Uh so hi everyone. I'm Hendrik Fettin at Nurture. Uh Ferdi for short. I also work at Code Wide in southern Germany. Uh among many things I also like barbecues of course. And lasers. Like lasers are fun right? So uh we had to decide between doing stuff with lasers and card hacking. And I don't know. Maybe you can imagine what we went for. So. Card 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 like. Yeah some researchers also found remote exploits like uh slashing wheel tires and stuff but yeah. 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. So yeah chip tuning is like uh it's own thing but it has a lot of common with card hacking actually. It is card hacking. And uh there's ECUs being cloned. Uh keys being dumped and data being manipulated to get more horsepower or yeah that's our stuff. Yeah also uh in the internal data manipulation uh chip tuners often enable for example writing over OBD which is disabled. That's actually quite a hack. I mean you need to bypass checks and so I would say signatures. So that's a cool topic. And yeah we all 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 the 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 of uh 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 mem dumps. Want to explain that? So yeah uh let's compare the UDS and TP2.0 very quick. So for TP2.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 channel negotiation request. And like you can see the different fields well up. And in the bottom one you can see the response which is 200 plus the target address. And then you can communicate. 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 uh and then like data blah blah blah blah. We will share the slide 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. Uh they first by this the 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 uh 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 sample start com, stop com, disable normal message. All that is handled by a single SID on UDS. You have for on KWP which is done in protocol. So that's the only difference on a protocol level. So here we will shortly list a couple of interesting services. So the first one is security access 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. You give it an offset and it will return the contents. And often but not always requires security access. Uh read and write data by ID is like for for example for getting 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 to start like custom routines for example erasing the flash, uh triggering all sorts of stuff. Like there are some fancy routines. Uh we found in some vehicles. Well ECU's actually not vehicles. Uh name it uh Bosch. Uh that would allow you to retrieve the uh the boot keys in EDC 17 and MD 17. So basically you just trigger the routine, you get the key and then you can unlock the boot load mode. Uh oh so yeah why all this stuff? Because Kan badger. So yeah glitchers gonna glitch. So let's take a look at the hardware overview. Uh it's an M-Bed LPC 17 68 or PC Espresso. It has external RAM 120 kilobyte to speed things up. 2db 9 for uh Kan 2db back headers, SD card, ECU power controlled by a MOSFET. We have UART, we'll see later why. 4 GPIOs if you wanna add fancy LEDs. And it runs in three different modes. A standalone USB which is a CDC device, USB over serial or network. And yeah it can be powered with 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 this it's really easy to set up. So the firmware considerate the proof of concept. Okay uh the actions are always handled by the Kan 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 UDS, CP 2.0, browsing, rock, hand logging. Uh just as a start. We have a man in the middle mode with the emulator mode. And we also mentioned that you can have three different modes of operation. That is standalone 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 uh we'll go into that. Don't worry but it's for use with the Kan badger server so you can have multiple Kan badgers in parallel. Yeah so fancy stuff. Yeah. 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 piece of cake. It's extremely verbose. It parses the SIDs and the parameters. Uh everything is done by the Kan badger firmware so no need for PC. Just the serial part so you need a terminal. And everything is stored in the SD of the Kan badger. 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 that termite and I was doing some stuff. That's actually the uh the interactive session. So you start uh diagnostic session and then you can think what's your next 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 they are built in scanners for SID parameters. So for some point if you wanna go and check if there's any hidden type of diagnostic session. Or do 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 middle mode. It's also as I mentioned already mentioned uh all the 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 it out with like 30 or 40 rules. And basically 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 the camcabacher. So we wanted to have camcabacher stocking over evanette so maybe they could exchange some data uh to each other or just to have multiple ones running in parallel. And this is why we had the camcabacher 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 canvaders. And uh the GUI was really inspired a lot by Burp Suits. 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 uh test the 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 cannot brute force it. I mean the the challenge is gonna change every time. And after three failed uh authentication items the ACU locks down for ten minutes to thirty minutes. So no brute forcing there. What's the other solution? Hijacking security access. So you just need a tool that 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 clone interface for tuning the cars and every time we want to have access to something like I don't know that 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 combator gets into a transparent mode uh bridge mode so it waits for the security access to happen. If the security access 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're 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? Uh yeah we all love waiting right? Yeah. Okay so in the meantime let's although being aware do it sing 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 combator do? So another fancy thing is dumping the TP and UDS transfers. We are which are used for finger updates. So let's say a vehicle gets an over the air update so that will be encrypted, signed 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 can. Most of the time. Not every time. So if it goes that way and it decides not to use encryption which uh we have found some manufacturers do. Then the combator can just like grab the whole transfer and dump the data. So basically dump the firmware that was being updated. It can also spoof OBD2 data through the band in the middle and then the emulator. The emulator is like some other fancy stuff. We will explain later. And yeah you can use GPIO pins for boot loading for tricord you know like some people call it zero day. It's just on the datasheet. We call it like a function. And yeah it can manipulate GPS signals via your pins. So why do we mention GPS? Hmm. Well many of you guys might know those uh kind of donalds 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 donalds 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 spoof your location too it's gonna be more money for you. Uh 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 camberger. 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 set up a file inside the camberger's D and tell it to broadcast every 10 milliseconds whatever a request which is a request for a PID which is the data used by these insurance dongles. So it just keeps on making those requests as long as you want it to. You could be like two hours uh logging all the data that will be used for the emulation which is actually real driving. I mean you just like go around in circles for one hour logging the data then you create the emulators. Once you create the emulator you got the data then you use the camberger to create the emulation data. So the camberger 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 storing the camberger because like we said earlier everything is running inside the camberger. No computer needed for this. Just press a button. So we created a header that has the IDs, the protocol used, uh the SID, the PID and then the start off set and end off set. So that's sort of a lookup 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 out of stuff. And yeah it's uh it's a story using time stamps 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 emulation yeah what 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 using the time stamp. Um yeah when there's nothing left then it just starts over it. So yeah now we'll 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 the stuff. It doesn't have that much dependencies and if you're like in a better corner anyway it will be really easy to get set up for you. 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 COMBAT? Yeah let's actually. So that's the COMBAT USB interface. So right now we have um and Bosch EDC 17 uh ECU connected. It's from Apple's back in Passat. So let's have some fun with it just to quickly show you how it works. So yeah let's just start that session. So you tell it your own ID, you tell it the ECU ID. So yeah we got UDS session established. So then you say okay I wanna 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 wanna read FF bytes. Whoops. We got an error. Service not supported in the update session. Okay so let's see. Yeah I don't really know what sessions are there. So let's just come for session types. There we go. So we have like different session types that can be uh initialized one and three 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 dammit now security access required. Okay so yeah again we already reversed the 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 three. So yeah. So yeah security access wanted. Okay let's see if it's true. Let's try again. So read memory by address. Let's try blah blah blah. And 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 Kanbager 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. Blah 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 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 in Go Stefkorn.
 So thank you all of you for being here today with us. We're gonna talk about some um  card hacking topic. And let's go fast because I think we made 20 slides. Let's see. So yeah,  who are we? I'm Javier Batkev. I'm a hardware security specialist. I work at Code  Wide, a German company with on stuff. I'm from Cadiz, 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 alive. I'm barbecues. I mean who doesn't like barbecues? So.  Uh so hi everyone. I'm Hendrik Fettin at Nurture. Uh Ferdi for short. I also work at Code  Wide in southern Germany. Uh among many things I also like barbecues of course. And lasers.  Like lasers are fun right? So uh we had to decide between doing stuff with lasers and  card hacking. And I don't know. Maybe you can imagine what we went for. So. Card 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 like. Yeah some researchers also found remote exploits like uh slashing  wheel tires and stuff but yeah. 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. So yeah chip tuning is like uh it's own thing but it has a lot of common with card  hacking actually. It is card hacking. And uh there's ECUs being cloned. Uh keys being  dumped and data being manipulated to get more horsepower or yeah that's our stuff. Yeah  also uh in the internal data manipulation uh chip tuners often enable for example writing  over OBD which is disabled. That's actually quite a hack. I mean you need to bypass checks  and so I would say signatures. So that's a cool topic. And yeah we all 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 the 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 of uh 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 mem dumps. Want to explain that? So yeah uh let's compare the UDS and TP2.0  very quick. So for TP2.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 channel negotiation request. And like you can see the  different fields well up. And in the bottom one you can see the response which is 200 plus  the target address. And then you can communicate. 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 uh and then like data blah blah blah blah. We will share the slide 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. Uh  they first by this the 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 uh 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 sample start com, stop com, disable normal message. All that is handled by a single SID on  UDS. You have for on KWP which is done in protocol. So that's the only difference on a  protocol level. So here we will shortly list a couple of interesting services. So the first  one is security access 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. You give it an offset and it will return the  contents. And often but not always requires security access. Uh read and write data by ID is  like for for example for getting 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  to start like custom routines for example erasing the flash, uh triggering all sorts of stuff.  Like there are some fancy routines. Uh we found in some vehicles. Well ECU's actually not  vehicles. Uh name it uh Bosch. Uh that would allow you to retrieve the uh the boot keys in  EDC 17 and MD 17. So basically you just trigger the routine, you get the key and then you can  unlock the boot load mode. Uh oh so yeah why all this stuff? Because Kan badger. So yeah  glitchers gonna glitch. So let's take a look at the hardware overview. Uh it's an M-Bed LPC 17  68 or PC Espresso. It has external RAM 120 kilobyte to speed things up. 2db 9 for uh Kan  2db back headers, SD card, ECU power controlled by a MOSFET. We have UART, we'll see later why.  4 GPIOs if you wanna add fancy LEDs. And it runs in three different modes. A standalone USB  which is a CDC device, USB over serial or network. And yeah it can be powered with 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 this it's really easy to set up. So the firmware  considerate the proof of concept. Okay uh the actions are always handled by the Kan 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 UDS, CP 2.0, browsing, rock, hand logging. Uh just as a  start. We have a man in the middle mode with the emulator mode. And we also mentioned that you  can have three different modes of operation. That is standalone 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 uh we'll go into that. Don't worry but it's for use with  the Kan badger server so you can have multiple Kan badgers in parallel. Yeah so fancy stuff.  Yeah. 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 piece of cake. It's extremely verbose. It parses the SIDs and the parameters. Uh  everything is done by the Kan badger firmware so no need for PC. Just the serial part so you  need a terminal. And everything is stored in the SD of the Kan badger. 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 that termite and I was doing some stuff. That's actually the uh the interactive session.  So you start uh diagnostic session and then you can think what's your next 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 they are built in scanners for SID  parameters. So for some point if you wanna go and check if there's any hidden type of diagnostic  session. Or do 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 middle mode. It's also as I mentioned already  mentioned uh all the 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 it out with like 30 or 40 rules. And basically 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 the camcabacher. So we wanted to  have camcabacher stocking over evanette so maybe they could exchange some data uh to each other  or just to have multiple ones running in parallel. And this is why we had the camcabacher  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 canvaders. And uh the GUI was really inspired a lot by Burp  Suits. 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 uh test the 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 cannot brute force it. I mean the the challenge is  gonna change every time. And after three failed uh authentication items the ACU locks down for  ten minutes to thirty minutes. So no brute forcing there. What's the other solution?  Hijacking security access. So you just need a tool that 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 clone interface for tuning the cars and every time we want to  have access to something like I don't know that 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 combator gets  into a transparent mode uh bridge mode so it waits for the security access to happen. If the  security access 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're  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? Uh yeah we all love waiting right? Yeah. Okay so in the  meantime let's although being aware do it sing 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 combator do? So  another fancy thing is dumping the TP and UDS transfers. We are which are used for finger  updates. So let's say a vehicle gets an over the air update so that will be encrypted, signed  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 can. Most of the time. Not every time. So if it  goes that way and it decides not to use encryption which uh we have found some manufacturers do.  Then the combator can just like grab the whole transfer and dump the data. So basically dump  the firmware that was being updated. It can also spoof OBD2 data through the band in the  middle and then the emulator. The emulator is like some other fancy stuff. We will explain  later. And yeah you can use GPIO pins for boot loading for tricord you know like some people  call it zero day. It's just on the datasheet. We call it like a function. And yeah it can  manipulate GPS signals via your pins. So why do we mention GPS? Hmm. Well many of you guys  might know those uh kind of donalds 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 donalds 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  spoof your location too it's gonna be more money for you. Uh 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  camberger. 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 set up a file inside the camberger's  D and tell it to broadcast every 10 milliseconds whatever a request which is a request for a  PID which is the data used by these insurance dongles. So it just keeps on making those  requests as long as you want it to. You could be like two hours uh logging all the data that  will be used for the emulation which is actually real driving. I mean you just like go around  in circles for one hour logging the data then you create the emulators. Once you create the  emulator you got the data then you use the camberger to create the emulation data. So the  camberger 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  storing the camberger because like we said earlier everything is running inside the camberger.  No computer needed for this. Just press a button. So we created a header that has the IDs, the  protocol used, uh the SID, the PID and then the start off set and end off set. So that's sort of a  lookup 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  out of stuff. And yeah it's uh it's a story using time stamps 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 emulation  yeah what 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 using the time stamp. Um yeah when there's nothing left then  it just starts over it. So yeah now we'll 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 the stuff. It doesn't have that much dependencies and if you're like in a  better corner anyway it will be really easy to get set up for you. 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 COMBAT? Yeah let's actually. So that's the COMBAT  USB interface. So right now we have um and Bosch EDC 17 uh ECU connected. It's from Apple's  back in Passat. So let's have some fun with it just to quickly show you how it works. So  yeah let's just start that session. So you tell it your own ID, you tell it the ECU ID. So  yeah we got UDS session established. So then you say okay I wanna 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 wanna  read FF bytes. Whoops. We got an error. Service not supported in the update session. Okay so  let's see. Yeah I don't really know what sessions are there. So let's just come for session  types. There we go. So we have like different session types that can be uh initialized one and  three 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  dammit now security access required. Okay so yeah again we already reversed the 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 three. So yeah. So yeah security access wanted. Okay let's see  if it's true. Let's try again. So read memory by address. Let's try blah blah blah. And 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 Kanbager 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. Blah 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 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 in Go Stefkorn.
DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_0_155.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_156_3707.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_3708_5891.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_5892_6467.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_6468_7547.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_7548_9239.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_9240_12671.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_12672_13955.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_13956_18887.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_18888_18971.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_18972_19067.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_19068_19199.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_19200_19343.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_19344_21479.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_21480_23267.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_23268_23555.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_23556_23603.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_23604_27491.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_27492_27635.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_27636_27779.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_27780_27851.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_27852_28175.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_28176_28283.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_28284_28907.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_28908_29543.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_29544_32543.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_32544_32651.png DEF_CON_24_-_Javier_Vazquez_Vidal__Ferdinand_Noelscher_-_CAN_i_haz_car_secret_plz_gx35otoHQgw_32652_33903.png