 So my name is Eric Evanczyk, I work on cars. I work for a company now called Faraday Future. We're making a new electric vehicle. I get to say that we're hiring, which is something I've never got to say in my life before. So if you're someone who's into cars, wants to do like firmware kind of stuff on cars, reach out after we can chat about that. The other thing that I've done is build this little open source can tool called CanTact. Basically the way that this came along is I was giving a talk on CanBus just in general at TourCon, which is a great conference that happens in San Diego every year. I was like, yeah, there's a bunch of tools available. Most of them are a couple hundred bucks or whatever. There's some open source ones, but no one really makes them anymore. Someone was like, oh, well, you should build one and so I did. This talk isn't really about this tool, it kind of is, but it's more about something called Socket Can. We'll talk about Socket Can, which applies to a lot of different tools, both commercial and open source, what it is, how it works, and how you can use it to develop CanBus applications for whatever you want to do with cars. So what is Socket Can? Basically, if you've ever dealt with, is anyone here like a Linux user in general? Are you mostly Windows? Okay, so we got a good amount of Linux users. OSX, anybody? Couple, okay. You guys might know what's going on a little bit, and then Windows, you have no idea what's going on, but I'm sorry. You can run a VM, you can run a VM. So what happens with this is, if you've ever used Linux network devices before, you have the network driver, which is sitting real low in the kernel, deals with the actual hardware. In this case, that's replaced with the Can controller. Then on the left, we have the Socket Can version. On the right, we have the traditional version. We'll start with the traditional way of doing it. So Can controller, you stick a driver on top of that, such as a character device driver for the SL Can devices we'll talk about. Then on top of that, you can stick a protocol interface, and then the application that you actually write goes in the very end. You can take a picture of this, or literally go to Wikipedia, which I ripped it off of. Yeah, sorry. But on the left-hand side, you have the Socket Can version. The way this works is your ethernet hardware or whatever Wi-Fi card, whatever it is, replaced with a Can controller, and then Socket Can jumps in and takes over from the network device driver level up, and it actually merges back with how you'd normally deal with Sockets and Linux at the socket layer, which means that we can write code that looks a lot like network socket code, but it's actually going to talk Can. And then in your application, you make those calls, just like you would with any other socket. And you're probably familiar with something like this if you've ever dealt with Sockets ever, or devices on Linux at all. This is kind of washed out, I'm sorry, but this is me running IFconfig for a VCan device, which is a virtual Can bus device we'll talk about. And it shows up just like any other network device you'd see. It has, the one weird thing with it is the hardware address comes up as just a whole bunch of zeros for some weird reason. And it has everything you'd expect. Some of those numbers don't work, but a lot of them do. Received packets, transmitted packets, all that kind of stuff. So once you have this device and you've set it up and it's actually a network device, in C, you literally do everything you'd expect to do with Sockets. So has anyone done socket code in C before? Got a couple hands. So like, you call the function, you get a file descriptor back. The difference being where normally you would specify like I want an Inet socket and I want it to be, or UDP datagram and I want these flags. This will get you a Can socket, that is a raw Can socket, which means you get direct access. There's also a mode called BCM, which is meant to deal with queuing and it's meant to take the work off of the user space application and do more of it in the kernel space. I haven't worked with it too much. It supports kind of odd, it seems, but it's getting there. So once you have that socket, you can do everything you'd expect. You can call IO control to set up, you know, in some cases bit rates, but at the very least, set the address of it. You can bind to it and then you can do reads and writes and you can set socket options to block or not block or time out, all those things. You can also do all of this from Python, but specifically Python three. For whatever reason, socket.pf can socket.socket.socra are not defined in Python two. I'm not quite sure why, but in Python three it works great. You can create a new socket and call all the same functions. It's just an interface. So this is, you know, that's how you go from Can to Sockets is you're just working with them. You fill up a buffer rather than sending a normal IP, like a TCP IP or UDP buffer, you populate a Can frame struct and you say, hey, send this Can frame struct or read me in a Can frame struct, just like you would with TCP or UDP. Now, if you don't have any Can devices though, a lot of you will have one of these sweet things now, but it doesn't plug into your computer. So let's say you want to play around with Can on your computer and, you know, create a device that's, it's not a real device, but it'll let you send and receive messages and play around with all the tools with no hardware. So it's free. That's the biggest benefit. It's also useful for like simulating stuff and just testing out tools. You can actually do this pseudo IP link add vCan zero of type vCan. That will create you a new virtual Can device. Once you have the device, you can just do ifconfig vCan up and sure enough, you get a Can device. Again, it's not gonna send any frames out on the wire. It's just virtual, but you can use all the tools. You can send stuff around. You can write. It's quite useful for developing tools because let's say you have a client and a server. You can develop both of them to use Socket Can. Use this to test it without actually dealing with hardware and then write whatever you need to deal with the hardware later. I may have done that once or twice. So it's kinda handy. Now, if you want a real device, there's a few things you can do. One is this SL Can. So this stands for Serial Line Can. And it supports this pretty old protocol that some company came up with a while ago that basically takes Can frames and encodes them over serial data like UART or RS232. You can actually buy something that does this from, for example, Peek or GridConnect. They sell a tool that is canned to RS232 and it spits out ASCII. It's really not that efficient because, for example, the byte FF becomes the two bytes, the character F and the character F again. But it's well supported and it works out of the box. So that's why this CanTech thing ended up using this protocol rather than something more efficient. It's just, it works. The bad news is that serial is very slow. Typical bot rates are gonna get off of RS232 or UART, it's gonna be 115, 200 bits per second. Can can go up to one megabit per second that we usually see it used at 500 kbps. Can FD is another thing that I'm not gonna talk about, but there actually is starting to be Linux support for it. So yeah, that's a problem, right? We have one order of magnitude of a jump. The good news is that it turns out that the bit rate doesn't actually matter when you're dealing with a USB to serial device. That bit rate that you set is only to tell the device, okay, please talk serial at whatever rate. So in the case of the CanTech, if you tell this thing I wanna do 9600 BOD, it will ignore you and instead just continue talking as fast as it possibly can over USB. It's kind of a common misconception. People figure, oh, well USB serial devices must be limited to whatever, 115, 200, but no, they can go a lot faster. Specifically, if you're interested in it, it's a 64-byte endpoint for USB, so you can basically do really fast transfers as long as they're 64 bytes or less. So you can use this, there's a type on this slide, but you can use this command to bring up a serial line device. So anything that speaks this standard protocol will interface by running this command. So it's SL-CAN-D, which is the serial line Can daemon. Dash O tells it that when you start it up, you want to send the open command, which is just capital O and a, it actually all uses a carriage return rather than a new line, or yeah, carriage return rather than new line for whatever reason. Dash C tells it whenever you close SL-CAN-D, you want to send the close command, you give it the path to your device, dev, TTY, ACM, whatever, then the name of the device that you wanna actually create. So in this case, it would connect to something like this and create a Can zero device. Here's the typo, you would then call i-f-config, Can not v-can, zero, up, and that would bring the device up, and now you have access to it over the socket interface. Now, if you're a developer who deals with Unix sockets, that might be of interest to you, might be like, great, I can do Can now, that's cool. If you're not, you're probably thinking, well, okay, what's the point? Like, I don't write code for that anyway. And the main reason you'd wanna do this is there's a whole bunch of tools you get for free. This is a list of some of them. And we'll show them now because I don't have that many slides, I figured it would be better to actually show you this working and how it works. So if I switch to VM mode, and if it actually works, oh, that is interesting, that is not what I want at all. I have no idea what that is. This is why you test out the projector before you start your talk, just for future reference. Nope, that's me changing my screensaver. No, I took that picture, it's a good one. Thank you. Here we are, arrangement. Let's see, where's mirror? It's not gonna let me mirror. Awesome. What we're gonna do then is we're just gonna take my VM because you guys are probably bored of me playing around with display settings. Is that, there it is. Apparently it's off to the left of my screen. Hey, please don't be terrible resolution. All right, now I have to look this way. So, first thing we're gonna talk about, and I'm gonna do this all on VCAN devices, just because this is all stuff you can try at home with no hardware, which is kind of fun. First thing we'll do is, actually, let's do Tmux, let's do, it'll be equals, cool. So I have two terminals here, hopefully, it comes out legible. Projectors and VMs are always trying. So, first thing you're probably gonna wanna do if you're ever on a CAN system is dump a whole bunch of stuff, so let's do that. So, CAN dump VCAN zero. What this is gonna do is start dumping messages, and there actually are active messages right now flying around. We'll look at that more later, but it's gonna give you a trace of the CAN bus, it's just gonna give you every message printed out with a few different options that are quite useful. So, if you want time stamps, you can do TA for absolute time stamps. That's the number of seconds since the Unix epoch that your CAN message arrived, which is probably not the most useful number. But TD is a very useful one, it will tell you the delta time, so time in between messages. And that would be CAN dump, pretty simple, but let's keep CAN dump running. We'll kill off that stuff running in the background, cool. So it stopped, we'll start it again so you can see. You wanna send some arbitrary CAN frames, that's another useful thing to do. We're gonna use CAN send format for this is CAN send, CAN ID, number sign, and some bytes, one, one, A, A, B, B, C, C, whatever. And that, oh, no it's not, the CAN zero for the device. And that'll let us send CAN frames. So if we're connected to a real car right now, we're literally sending CAN frames on the bus. It's pretty simple if you wanna just fuzz out some frames and see what happens. Another pretty useful thing you can do is logging. So I actually took a log by using CAN dump with the dash L flag, which will log to a file. And the nice thing about this is I can now play it back. So this might be a little hard to read. What I'm doing here is using CAN player, which is a playback tool, and I'm saying send the messages that were on CAN one whenever you received them to the device CAN zero and repeat this infinitely using this log file. And so that's what lets us just generate a whole boatload of frames that are kinda useful. There's another tool if you wanna generate useless frames called CAN gen. And that will literally just spit out random data. There's a whole bunch of different flags you can set for different types of data, but the CAN zero. You can use this very useful if you wanna load up a bus to like 90% and see what happens. You can say I want message zero to be going on at really, really fast speeds that I can test to see if my diagnostic stuff that's on really high IDs still work. One example of using it, but here it's just spitting out crap. So these are all like, you know, simple CAN interfacing tools. Now we'll talk about some actually pretty useful ones. The first one is CAN sniffer. And CAN sniffer is sort of unlike any other tool that I've really seen for CAN. It basically lets you be CAN zero. Basically lets you just take a look at what's going on. Is it, I've killed off all of my messages in a sec. We'll start that log up again, and we will do here, kill that. CAN sniffer, V CAN zero. This is gonna show you everything going on in the bus. You see a bunch of messages at the top. After a couple seconds, a lot of them go away, and we only have one left. And the reason being, this is the only frame where anything is changing. Everything else, it's just we're getting the same frame, the same data over and over and over again. And that's not exciting, because who cares? When you're reverse engineering CAN buses though, it's quite useful to be able to see what's changing. For example, you wanna know where the pedal position signal is on the bus. So you plug in, and you start pushing the pedal, and you wanna see that value change. This gets even better if you do use the, ah, what's the flag? Oop, nope, it's definitely not dash dash help for it. There is a flag for color. It's dash C, great. So now we can actually see what's changing, and it shows you exactly what byte is changing. It shows you it in ASCII as well, and increments like that. If you plug this into real systems, it's quite useful because all the cruft that just repeats itself over and over and over again goes away, and you actually get to see the live data. So that's CAN sniffer. It has a whole bunch of other options. This is a quick demo. Depending on what you're trying to do, CAN sniffer might have something useful. The last thing I really wanna demo, and then this is basically just about showing you tools and having you ask questions about them. The last tool I'll show off is Wireshark, which some of you have probably used for not CAN purposes. It's a pretty popular tool. You may have heard of it. Wireshark supports CAN, and most people don't know this. It supports it out of the box. It does a pretty good job of it too. If you just wanna record CAN frames, everything that I've been doing is now recorded in this Wireshark trace. I can scroll through, I can pause it, I can save a pcap file. You can write filters like CAN.id is greater than 0x100. It'll filter them. If you're working with CAN open, which is a protocol mostly used in ICS systems, not so much cars, so industrial stuff, SCADA, you can actually do CAN open dot and filter by a lot of different things that CAN open uses. I'm not sure if anyone's interested in that part of CAN, but those options are there. And it's a useful tool for looking at buses. It can deal with very large amounts of data. It's used to dealing with network packets. And yeah, it's kind of a nice thing to run the background and just be able to save a trace of what you're doing. So all this stuff, it's pretty low level tools. It's more meant for the development end, but it makes it pretty easy to then write your own software using CAN. And if you do see right now when you do network devices or any kind of socket stuff, extending that to CAN has just become, okay, I'll call it with the right flags, and that's about it. So that's pretty much my really quick tour of socket CAN. At this point, questions or tool demos that you wanna specifically see probably make the most sense because we should tailor this to what you want and not just keep talking about random tools. So is there any questions for anyone about socket CAN or devices or really anything CAN related? I'll try to answer. Oh, what is CAN? I figured people in here knew a bit about cars and CAN bus. I may have just gone way the hell over everybody's head. I hope I didn't. Has anyone gone to none of the car hacking stuff yet? Everyone's gone to something, right? Good, you scared me. I didn't realize that, okay, good. Are there any other questions about socket CAN or CAN in general? Yeah, so this device that I built, it's basically I was like, hey, I should build an open source hardware thing. So I did. This is using the STM32F0, which is remarkably similar to the microcontroller on this guy. Slightly different package. Cool thing about it is it can do USB and CAN at the same time. So this is essentially a USB connector, microcontroller, CAN transceiver, and some jumpers. Reason being, if you've ever dealt with DB9 cables, they come in two different formats. The really expensive ones come with the right pinout. The cheap ones from China come with the wrong pinout. So this lets you select between both those pinouts. I say the right pinout because it was actually set by CAN in automation like 20 years back and for some reason they don't conform to it. It also has a little termination resistor. So if you're just testing like two of these or this and one other device, you can terminate the bus. Otherwise, nothing works. So it's used to be able to jump or select that. And yeah, DB9 connector on the end. Yeah, it was just mostly just to say, hey, I wanna put together something, make it open source. github.com slash link layer has all the firmware, hardware design, everything you would need to put one of these together yourself. You can, if you want, you can print your own board and build it. contact.io, c-a-n-t-a-c-t is the actual website. I'm not allowed to get selly, so I'm just gonna stop right there. You can go learn more on that website. But yeah, the main goal was let's build an open source one and the information's out there now for anybody here to go out and build a USB to CAN tool that speaks socket can. Any other thoughts, questions, ramblings? I'll take anything really. This was meant to be kind of quick and introductory. Not aftermarket, I've heard of some OEMs, but not with this. It's a really divided world, the automotive one. OEMs, for example, work with the most expensive tools out there that cost more than everyone's badge for registration here combined times 10. Stuff like that. You were talking like five figures before, you can get even a single CAN channel plus the software, plus the support, plus, plus. The tuning guys I'm guessing are more into cheaper things and they need to get that out there, so that could be interesting. But it's a pretty closed community from what I've seen. They don't wanna talk about much. I don't know if you work in that. Yeah, okay. It would be interesting, we should talk, yeah. Because some people figure out secrets about how to make your cargo faster and they want to not tell you that because they can make money off of selling that option. And that's a business model, I guess. The automotive companies, of course, they're most interested in making your car as emissions-friendly as possible nowadays. So that's why the aftermarket guys can have some fun. We don't care about emissions now, let's just go for performance and then suddenly your car behaves very differently. Any other stuff? Yeah. Sorry, what was that? So, oh, okay. So if you wanna figure out what ECUs are talking to each other, the question was how do you figure out interactions between them? Oh, if you wanna simulate an EC, okay. So, it's hard. CAN is a totally multiplex, or sorry, multi-master bus and everything is sent to everybody. It's broadcast. So every message that's sent out could be received by every controller for all you know and you have no idea really how they act. The way you would find out is you get the DBC file, which is a CAN database from the manufacturer, which actually will say here are all of the nodes in the network, here is all the messages that every single one of them receives. The only problem is the manufacturer is not going to give that to you. Yeah, they're not gonna give it to you. They'll make it available if you care to go down that road. So yeah, they just don't want you to know or they figure they can make money off keeping that information secret and selling it. So really the best way to figure out interactions between controllers is by trial and error nowadays. It's sort of, it sounds unfortunate, but it's true. If you disconnect a controller from a CAN bus, a whole bunch of messages disappear, so you know where those were coming from at least. You can also do things like fuzzing. Fuzzing in a real car can be kind of dangerous. I have a little story. I was talking about this at another conference. There was somebody from Continental in the audience and he was like, don't tell people to fuzz CAN. I said, okay, why not? He said, well, I'm not gonna give you any details, but you can actually destroy an engine by fuzzing the CAN bus while it's running. Oh, it's like I've seen it happen. I was like, oh, that sounds really bad. So you can do fuzzing, but that gets to be somewhat problematic. You can actually potentially mess things up. In simulating, if you're doing V-CAN simulations, the easiest way to do it is you treat the V-CAN interface like a CAN bus and you just make everybody connect to it. So you can also use it for piping messages around. I've seen at least one script that took messages from a real CAN interface, moved them to V-CAN, doing some filtering and some reassignment of IDs, and then moved them back to a different CAN interface. So that way, what often happens is you buy something from an OEM, it only supports CAN ID 100 and 101, and they wanna charge you like 10 grand to change it to 102 and 104 or whatever. So you put a device in the middle and you make it do that translation for you because it's cheaper. For stuff like that, V-CAN can be pretty useful. But in terms of actually knowing who's talking to who, unfortunately, CAN is pretty good at hiding that from you. It takes a lot of other stuff available though. Yep, sure, so this is raw CAN, this is just the messages. This'll do anything except CAN FD. For those higher level protocols, 1939 OBD2, Unified Diagnostic Services, which is ISO 14229, I think, somebody? Yeah, I got it. For those, you're gonna need some higher level software. There is support for, all right, add to backup. CAN supports eight bytes per message. That's a little limiting if you're trying to send, let's say, a firmware update, eight bytes at a time. So there's a protocol on top of that called ISOTP, and I forget the ISO number. 15.765-2, I'm bad with numbers. So that is the protocol it's used to basically say, I wanna send 10 kilobytes over CAN. How do I string it all together? It'll do that. Then on top of that are the actual services for UDS. That middle part, which is called ISOTP, if you don't wanna remember that number that Rob yelled out, that is actually implemented in kernel space, but it's not included with the kernel and it's really hard to build. It's a lot of butts, I'm afraid. It would be really nice if it worked, but it doesn't. So one thing I'm working on are some new open source software tools for doing the higher level protocols, but socket CAN itself is very raw. Give it eight bytes, a data length code, and a message ID, and it will send a frame. That's about it. That's a silence. Are we good? You can find me after and ask me about anything, really. I'll be around here for a little while, but thanks a lot for listening about socket CAN. Hopefully it was of some interest and you can play around with it.