 Hello, everyone. My name is Marcelo Sacachin. Today, I'm going to be talking about chupacarbara. It is an open source do-it-yourself tool for interacting with automotive CAN bus. Just a quick disclaimer, this presentation is based solely on my opinion. It has nothing to do with my employer. And keep in mind, if you attempt to do the things that I'm covering here, you might potentially damage your vehicle. And keep in mind, if you damage your vehicle, malfunctions may or may not incur in safety issues for you and others. So be careful if you attempt doing stuff here. I cannot accept the risks. OK, a little bit about me. I'm a security engineer. I do secure development lifecycle. I work close with the DAV teams on my daily basis to make sure they write secure code and applications. I try to do a lot of automation with Python. And we're going to surprise, surprise the chupacarbara that I develop very uses Python a lot. And my first exposure to CAN, to the CAN protocol, was a while ago when I was a secured software engineer. And I developed some industrial control software. And we know that a lot of PLCs rely on the CAN Open protocol for communication. I also like building stuff with single-border open source hardware, such as BeagleBone and Raspberry Pi. And one of the cool things that I built was some coding bots. So I could teach my kids learning Python. And this is what brought me here. Because when I tried first to do some CAN hacking, I researched it. And CANTAC was the most known tool for doing that. And because of, but it was sold out on a lot of vendors. And they even mentioned it was because of DEF CON. It was really interesting. And then I remember that one of those bots that I built for my kids, I used the BeagleBone Blue, which had embedded CAN controller and the transceiver on it. And I thought considering options. And I said, well, why not try doing that using a BeagleBone Blue rather than waiting longer to be able to buy the CAN TAC? So this presentation is about how to use BeagleBone Blue socket CAN and Python CAN to interact with the CAN bus on your vehicle, more specifically to the ODB2 CAN bus. At the end, I will bring some research I have ongoing. It's still ongoing, no solid results, but trying to connect to ECUs directly. It is possible, but it's still an ongoing work. And I plan to make it interesting for both newcomers like me that are attempting car hacking for the first time. So the ChupaCarbara is easy enough to build and plug into your car and start doing stuff. But it could be very useful for more experienced hackers as well, because since it's a single board computer, you could easily extend it to different applications or use cases that you might have when you're doing your hacking. So all the ChupaCarbara code is available on GitHub. So if you're an expert, chances are that all you need to know from these presentations is this URL, so you can take a look on the code. And also, on GitHub, I share a link to a Hexter IO tutorial that I wrote with a very detailed step-by-step instruction so you can build a ChupaCarbara device exactly to the one that we are going to cover in today. And I hope I'm going to share the mistakes that I made when I was attempting to do it for the first time. And hopefully, it will help others when trying to do that. And with a device is enough to build, potentially, we can engage more people on attempting car hacking and growing the community. So this is the device. It's basically a beagle bone, as you can see here, with some add-ons. So basically, I connected a USB cellular mode in here on the USB jack. I connect a DC jack here so I get power from the ODB2 port on my car. And of course, I will need an ODB connector to connect it to my car. And here, this is the can port on the beagle bone blue. So all you need to do is to connect a JSTSH cable here. And then on the back, you connect it to your ODB2 extension cable. Of course, you can wire it directly to the back of the device. We can also see that I use a battery. It's completely optional. But you can use it even if you're, let's say, you are building a car tracking application. So and even after your car batteries die, using the battery, your beagle bone will be still alive. And you can still track the GPS coordinates with this GPS module here and potentially recover your car if that is your goal. So I use it very simple material. So I use a plastic plate like this to put all the pieces together, some rubber bands, but you can build it differently. Again, all the instructions are on the Hexter IO article. And all you need to do is to put all those pieces together so you have a functioning beagle bone to plug to your ODB2 port on your car. So and also you don't need to add all those parts together. I would say if all you need to want to do is to just use a socket can to run some can, exchange some can messages with your car, all you need to do is, of course, the beagle bone blue. And a connector like this, the name is JSTSH connector. You connect it to one end to the beagle bone, and then you can use solid hookup wires like this to connect it to this connector and then the other end directly to the ODB ports to your car if you want to keep things simple. Or you can just build it using the ODB2 extension like this. OK, so once you build your device, what does it do? So the idea here is to create a connection between your can bus from inside your vehicle to the outside world. So from my perspective, I can assume that most of the manufacturers create a threat modeling of their can bus system, assuming that they are going to be isolated from the outside world. So of course, you would need physical access to the car, but the idea here is to create an easy way so you can exfiltrate data from your car to the can bus. And the beagle bone blue makes it very convenient because it's really easy to connect the GPS module that I showed before. And on the top of that, it already has the embedded Wi-Fi access point and interface. So you can connect it directly or connect it to your Wi-Fi network and access the internet. Or as I showed, you could use a cellular molding like this to the USB port. And even if your car drives away and goes out of the range of your Wi-Fi network, you still have communication to your vehicle. And you would be able to potentially send can message to your car remotely. And one other cool thing about doing it using a single board computer, you can easily expand it to some other different applications. You can, for instance, create a geofence application. You want to maybe disable your car if it goes too far or maybe you want to track it back. You can, for instance, plug USB cameras and microphones. So if you want to capture audio, you can even use a servos because the beagle bone blue is a robotic application. So you can plug servos here on those rails and perform some physical actions inside your car if you need it. You can even try to robotify your car. Let's put that way. So this is what it does. And once we run the Chupa Carbure inside your car, you're going to see on your local terminal, I'm assuming you SSH to your beagle bone. And you're going to see once you run the Python script, you're going to see on your terminal what we have on the left. By default, we start monitoring your vehicle speed from the old DB2 port, the RPM, and the temperature. And we'll also start sending all that information along with the GPS coordinates to a Flask application running on AWS. The code, the source code for the Flask application is also available on the GitHub repo. So as I mentioned by default, it will send only vehicle speeds, temperature, and RPM. But if you want to use other old DB2 PID from your old DB2 port, I created this convenience CSV file that if on the left column here on the enable disabled column, you just set 0 and 1 to the old DB2 PIDs that you want to enable or disable. So as you can see here, this is one example. And all you need to do is customize it, and then you should be able to monitor other information from the old DB2 port other than the speed, temperature, and temperature. OK, so how do you connect a beagle bone to your old DB2 port? As I mentioned before, you have the CAN connector here. You use the JST connector to plug it here. And then all you need to do is to go to the female old DB2 port on your car and connect the CAN high and CAN low pins to the pin 6 and 14 respectively on your old DB2 port on your car. And it brings me to the first mistake I made. Keep in mind that this schematic, these pin numbers, are related to the female old DB2 port. So initially, what I tried to do, as you can see here on this picture, I connected the JST connector to the beagle bone, and I used some hookup cables. And I cut a cable like this. And for convenience, I would connect my beagle bone hookup wires to a male old DB2 connector. And keep in mind, if you do that, the numbers 1 to 8 will be mirrored because the female connects front to front to the male and female connects like this. So the eighth pin here on the female is actually the third pin here on the male. So keep those things in mind. This is a mistake that I made. And I believe I want to just prevent you to waste some time doing troubleshooting those things. And other mistakes that I did, and it could potentially help you when attempting this. So use a multimeter is your friend. I would be able to easily catch up that mistake if you use a multimeter and make sure you have some voltage on the pins that you wanna tap in. And by the way on my car, the pins 3 and 11 that I connected by mistake initially, they don't have any voltage there because they don't do anything. So with a multimeter, you would be able to catch issues like this. Another mistake that I did was when I saw Ken dump, I assume a TCP dump. So it's a sniffer, right? Sniffing traffic, so they should be similar. They are in some extent. However, Ken bus is not Ethernet. You need that minimum two nodes on the bus so you can potentially transmit and sniff some traffic. So initially, I enabled the Ken interface on my big old one. It started Ken dump on one terminal. I started doing Ken sand on the other and I didn't see anything and I didn't know why. The reason is because you need two nodes so you have a minimum, so you have a Ken. But even before doing that, what I would recommend is to play a little bit with V-Ken first. It's very easy to install V-Ken on a Ubuntu Linux, for instance, and then you can do the Ken sand and Ken dump and monitor the messages and understand how it works before even attempting to a real physical Ken. Another common issue that I had to face is you have to know the bit rate. So if you wanna Ken bus to work properly and for my vehicle, by default, it uses 500K balled rate and yours might be different, so keep that in mind. So this is a suggestion. So if you wanna make sure your Chupa-Carbora is working and you understand a little bit how Ken works, create a Ken bus breadboard like this. It's really simple. You just use some jump wires to hook your JST connectors to a breadboard. The only thing you need to know is I'm using blue for Ken high here and white for Ken low. The only thing that you need to know is you need a 120 ohms resistor at each end connecting the Ken high and Ken low rails. It's gonna be very helpful because then you can plug two big old bonds, for instance, and exchange some Ken messages between each other with Ken dump. Another useful thing that I would recommend not necessarily, but it might be helpful is to cut a extension cable like this. So if things are not working properly, for instance, my first, I bought a very simple device like this. It's a scan tool that supports Canon ODB2. It's very cheap and it was working and I didn't know why my big old bond wasn't working properly. So I created this, I cut this cable and hook it one through 16, all the pins on my breadboard rails. And then I was able to connect it, this device to this extension and the extension to the car. And then here on the picture with the zoom, I could hook the JST connector to this breadboard and then start Ken dump there. And for instance, use this device to retrieve the VIN number. And then I would see the exactly messages that it was exchanging and understand what could be wrong on my big old bond that I wasn't getting right. And in my case, what I didn't know at the time was this. I was expecting to plug the big old bond to the ODB2 port, start Ken dump. And I was expecting to see a lot of traffic there. But what I noticed is that my ODB2 port was silent. It was just listening to, because it was segmentated to the other Ken buses on the car. So it was just waiting for some specific Ken messages to reply to it. And this is exactly what happened. This is when I sniffed the comments from this device here, that was the Ken message I saw. And then in using the Ken dump on the Ken zero from the big old bond, I saw the request and the response with my VIN number there. So, all right, so let's say you're confident enough, you understand how to play with Ken bus using a big old bond. And now you wanna, and you built your two car bro device and you wanna run it on your vehicle. So my suggestion would be play a little bit first with a socket gun and make sure everything is working. So just try different bit rates. For instance, here on this, I'm trying the 500K, which is what worked for my car, enable the Ken zero interface and open another terminal with Ken dump. And on a different terminal, you send the request VIN message. And by the way, all those messages, including this request VIN is available on the CSV worksheet that I have available on GitHub. So you can try different stuff there. Once you know, once you see the request and the response, you know that your two car bro and your big old bond is able to properly use socket scan in your car. And then if you wanna test the GPS module, you would recommend using this TIO comment. By default, it uses the serial port TTY02 with both rates, 4,800. There's a specific one that I use it. All the parts are listed on the Haxter IO article and I point to vendors that supply them. So, and when you start the TIO comment, you're gonna see a lot of GPS synthesis flowing around. And wait a little bit for the module to find a GPS satellite. And once you get some GPRMC sentences, similarly to this one that I have on screen, you can use a online decoder just like this RL.SC. It's really cool, by the way. You just need to provide the GPRMC and it will plot your exact locations on a map. For cellular connection, so for connection, all you need to do is to make sure you have internet connection from your big old bond, either by using Wi-Fi network or a cellular LTE modem, which is what I did. I use it the hologram vendor because it's very Python friendly. The documentation is really good. So it was really easy to install it and get it working on my big old bone. Again, all the documentation is available on my Haxter IO article. And at the end of the day, all you need to do is to ping a public server on the internet and make sure you have internet connection. So the data that your Chupacarbra is capturing can be exfiltrated to a server. And once you know everything is working properly, it is time for you to clone the repo, go to the Chupacarbra folder and play around a little bit with the CSV files and enable and disable the ODB2 PIDs that you are interested in and then just run the Python script. And by the way, it's all Python 3-basic. I don't think it works with Python 2, right? And if everything goes well, we are gonna see all the ODB2 PIDs that were enabled being displayed on the screen. And also, if you have an internet connection, by default, it's gonna be exfiltrated to this public AWS Flask app that I have running by the folder script points to that. If you wanna create your own, just use the code available on this server or on this GitHub repo. And then you can customize it, run in a different cloud environment and customize it any way you want. Okay, let me run a quick demo video here. So we have an idea how the Chupacarbra works. So this is the device. I'm gonna plug into the ODB2 port from my car. The engine is on, already running. Yeah, so I'm just showing where is the ODB2 port on my vehicle. It's usually some close to the steering wheel. And then I'm gonna put it on the dashboard because I'm gonna monitor it from outside the vehicle. This is something that is really convenient compared to the other solutions because you have the embedded Wi-Fi access point on the Eagle bone. You can just connect to it and run Chupacarbra from there. This is what you would get on your terminal if everything goes well. And then you can monitor your car. Of course, if it goes out of range, it will won't work. But you can monitor your ODB2 data from outside the car. Let me, and now I have a test from inside the car. Here is I'm running the same test from inside the car. But the cool thing here is I'm going, I perform a lap around the course and I'm monitoring the GPS data. So it's exfiltrating using the cellular network to the AWS server that I had running, right? And you're gonna freeze the video exactly where the coordinates was exfiltrated. Then when I got home, I just visited the public AWS Flask application and I saw all the GPRMC sentences available there and I could plot them on the map. So if I was away from the vehicle, I would be able to track it wherever it was. And if you plot all the, and it will all GPS will also give you the speed. And if you plot all the coordinates that are available in the application, you would have an idea from where the vehicle was traveling. So I performed a course around a few blocks and this is what they show here. All right, so this is how the device work, right? So it is able to exfiltrate ODB2 and GPS data. But what's next? And this is a currently work. I have only preliminary results, but probably the next thing that you wanna do is to go beyond of the ODB2 CAN bus and actually tap into a real CAN bus for your vehicle. And you can do it using the exactly same device. So what they've been doing so far, so rather than reverse engineering every wire inside and disassembling my dashboard that would be an insane hard work to do, you can alternatively go to your dealership and get a book like this, a supplemental, electric supplemental manual and it will give you a lot of detailed information about all the cables, where all the electronic components from your vehicles are located in the connections between them. So for instance, really close to my steering wheel on my vehicle, I have this E-Tax ECU that is also located pretty close to the ODB2 connector. So I thought, okay, let me connect those two CAN buses that are segmented from my vehicle and then I can monitor everything. And that was my goal. So knowing where the ECU is helps a lot. And here is a picture of the vehicle. So to get physical access to that specific ECU, all we needed to do was to remove a couple of plastic covers from my vehicle. And that was it. I could see the ECU from the bottom of the driving seat. And also the electronic supplemental will give you detailed information about the ECUs on your car. So for this one specifically, if you look to the picture on the left, on the bottom, I have this C411 connector. And if you go deep on the manual, you're gonna notice then on the diagram on the right, on the top, you would know that the C411 connector is actually connected to a CAN drive. And the pins eight and nine are connected respectively to CAN low and high to another component. They call ECM on this vehicle. And not only that, you know, you have the wiring colors used for those cables. So I know that the CAN high on pin nine is VR, which is brown cable. And the CAN low on pin eight is a Y, a yellow cable. So looking carefully to inside my dashboard, I was able to find this ETOX ECU with this specific connector. And you can see the brown and yellow cable on pins eight and nine. And also close to the arrow that I put, you can see the ODB2 port on the top. So again, so what I needed to do, all I needed to do is to use a hookup wire like this. This is not the actual CAN cable, it's just a hookup wire that I manually twisted myself. Oh, this is another common mistake. Make sure you either use a real CAN cable or if you're using hookup wires like me, make sure they are not too long because they might not function well. And you can try to manually twist them to mimic what a real CAN cable with the physical properties of a real CAN cable. But back to this, be aware that by bridging those segmented CAN buses on your car, you might damage your electronic components on your car and in core and safety issues for you and for others. So be sure you know what you're doing and be careful. Okay, so once I got a good physical connection with those pins, I used a multimeter to make sure I had good wiring. On this specific ECU, when I have the ignition off, it gives me 1.13 volts, but when I turn the ignition on, you, I get the expected 2.5 volts. Another mistake that I did, if you, I recommend turning on the engine because you would very quick kill your battery. I did that, don't make the mistakes that I did. Okay, so now that I know with the multimeter that I have a good physical connection with the ECU, I connected the other end of the hookup wires directly to the back of the beagle bone with the other, with the existing CAN high and CAN low cables that I wires that I had to the ODB2. And that's all I needed to do. And then by doing that, as opposed to the initial results that I had only with the can, the ODB2 can, now if I run a CAN dump from the Chupacarbon device, now I see a lot of traffic between this ETAC CCU that I connected and the other electronic device ECM from my vehicle. I can tell, I can guess it's the engine and this other ECU communicating and exchanging information through the CAN bus. All right, so that's what I, where I got so far. What I'm planning to do, that's what I'm trying to do right now is to reverse engineering some of those messages. For instance, I'm trying to use a CAN dump to save the traffic, to dump the traffic to a local file, do something on the vehicle, for instance, opening and closing the power window and then using CAN player, try to replay the traffic and try to open and close the window just by replaying the messages. The problem is I wasn't so successful doing that so far and every time I try that, I get a beautiful and shining service engine light on my vehicle and I might break my vehicle at some point. And not only that, maybe I'm not even connected to the right CAN bus that I should be tapping into if I wanna open and close the window. So I have a lot of work to do that yet. But what tells me I'm on the right path is when I do CAN sniffer, unfortunately, because it's a very busy CAN bus, it's still very polluted to me to tell exactly what's going on when I open and close the window, but I see something go, some action there, some different, some new messages showing up when I'm doing those actions. So I still don't know what's going on, but that's what I'm trying to do. Get some interesting CAN messages so I can replay that then later. So since I wasn't able to get the, for instance, the opening and closing window yet, let's assume the message that I wanna do remote execution on my car is the retrieved VIN message, right? Which is the one I'm highlighting here with the CAN send comment. So my goal is to create a kind of RPC where I have a new endpoint on the Flask application running on the cloud that I would be able to send any CAN message that I wanted to be executed remotely on the car. Of course, I had to URL encode the hashtag here so I could send a post to this URL to my Flask application and get it available. And in order to do that, here's a oversimplified version of the changes that would be needed on the current Supercarb implementation. Yeah, and by the way, once I get it working, I will update the code and make it available, but if community guys, if you feel free to fork the code and or even submit requests, I would be very excited if people would start doing that actually. But the idea here is to do what I showed before, submitting messages remotely to create this kind of reverse HTTP command and control, I would create on the server application a queue and two new endpoints, say getting post endpoint on this RPC endpoint. And whenever you send a post message with the CAN message, it would add to the queue. And then on the GET request, you would pop a CAN message from the queue and potentially, and then you execute it on the client. So the changes on the client, the chupacarber.py would be basically hitting the RPC Flask application with the GET request. It would give you a keyword can message that you submitted and then it would send it to the bus and execute on your car. Of course, this is a very oversimplified version just to illustrate you would need to add some error catches here, some logic, and even you would need to parse the JSON data to put your can message together. But that's the idea. So this is one suggestion, this is what I'm going for. But again, it's a Python code on a open source hardware platform. Feel free to do whatever you wanna do with it, right? And the takeaways here from this presentation is again, I wanna build a open source hardware and software platform that could be useful for newcomers that are attempting this for the first time, but also for more experienced guys that see a need for a single board computer running on a car where they could remotely do some stuff there. Currently, I only, the code that I have on GitHub only do GPS and ODB2 can messages, data's exfiltration, but I has just showed I plan to expand it in the future. Yeah, so let's use it guys, I'm open to feedback. Let's grow the community and let's have fun. Oh, one thing I would like to thank my friend Robert from Autobone AI, he helped me a lot with all his knowledge on AutoMagic if you can with issues that I have, troubleshooting things and attempt different approaches. So thank you Robert, it was really appreciated. And that's all I have guys. So again, all the information that you need to build the ShupaCarbara is available on GitHub. And if you have any questions, suggestions, hit me on social media. I would be very happy to see people using the device and if people have the same issue that I have trying to buy other open source tools because they were sold out. Let's make Big O-Bone sold out. I'm gonna measure the success of this presentation based on whether or not we can sold out all the Big O-Bone blues next year because everybody will be trying to hack their cars using this open source platform. So again, thank you guys. I'm open for questions. Reach out to me either on social media on the Q and A session.