 But don't do it again good. So I am nothing face and this is talk about automotive networks Her overview. No, it's not Little overview of what the talk is going to be about Gonna give a little brief background about myself Give you some perspective about I get some idea of my perspective and you know, just give you an idea of where my You know the ideas that I'm that I'm coming up with may or may not be based on my strengths and weaknesses Give you a little idea of what how this could be relevant to you Depending on your level of interest in hacking an automobile There's some things that may be interesting to you even if you aren't interested in hacking an automobile just to learn about the operation and understand what's going on give a little bit background on the electronics and automobiles and then Large part will be about OBD2. It's on board diagnostics to that's a Standard used commonly today talk a little bit about common places that that's used the physical and data link layer Trying to adhere somewhat to the OSI model of networking Talk about some of the diagnostic modes that that specifies some products that implement it Now conclude with an introduction to some software I've been working on to implement these protocols and serves a platform for others to develop other applications So about the speaker, I'm educated in electrical and computer engineering My professional experience in hardware and software design But I'm also a Saturday afternoon mechanic. So I'm not afraid of grease or wrench, but I'm also not a mechanical engineer so the automotive Automotive engineering aspects are where aren't so much on my strengths, but My hope is to be able to put tools in the hands of those who are more able to make those types of Automotive engineering decisions and tinker with their vehicles and I'm also concerned about privacy and as you'll see there's a number of aspects of the Buses in the networks on the vehicle that could potentially have privacy implications So why why should you out there in the audience care? Well, the automotive maintenance monopoly is probably the big reason For for automobiles you can get service manuals that provide mechanical drawings with a great deal of accuracy for all the mechanical components in a Vehicle every bolt every nut all the torque specifications all that but for as far as electronics go Generally this the the best you can get is a wiring diagram that tells you where the wires in the vehicle go to hook up One box to another but each box is a black box. There's no schematics of the boards. There's no source code to the firmware You know, there's there's limited protocol specifications There's no way to really do the same thing you can do with an engine with the computer that controls the engine and particularly from my background, I think that that's very limiting because I'd like to be able to tinker around with that so A lot of this is more reverse engineering sort of try to gain that that knowledge from a vehicle There's also privacy implications even if you're not interested in tinkering with the vehicle There are things that a vehicle could potentially be recording with a lot of electronics on there could be Recording storing transmitting data about your driving about your vehicle and and also to make it about the driver of the vehicle And so, you know considering all these things a vehicle modern vehicles tend to be more into the control of a manufacturer than the owner and There's some barriers put in place to prevent you from being able to control that which Which a lot of people may eject to I personally do So automobile electronics what? Where did that come from? Well initially it started down so originally under the hood just controlling fuel injectors analog brakes traction control airbags You know performing some of the more advanced functions that were in a long time ago done by mechanical or electromechanical systems, but as federal requirements got more Got more strict and also as the systems got more complex the need was to make it more of a software type system with a Software control system. There's also user-visible Systems as a you know electronics becoming cheaper more use their use for climate control entertainment navigation communications and so on-board diagnostic standards OBD or OBD-1 Was an early standard by the federal government in the United States to standardize on some of these electronics But they didn't the standardization only went so far and it didn't actually require the manufacturers to standardize a particular implementation It just said certain functionality was required. So that led to a number of disparate implementations in the field so Every manufacturer had a different test box that you need to you need to get a specific one for a specific vehicle To perform the same functions So on-board diagnostics to Is a standard standardized an implementation that said not only do you have to do particular features? But you have to do them in a particular way so that you can have interoperable products where you can You can get a test box outside the vehicle to plug it into any vehicle and it will communicate with it And you can also get replacement parts for certain pieces in the vehicle Actually, I'm going to save questions to the end if that's right Oh Sorry, um, so OBD OBD one Was early 90s is when it was standardized or when it was required OBD two was mandated in 1996 And that's current in all vehicles nowadays There's sort of a little bit of slop in the in the time frame in which they they're implemented the The fellow government said vehicles starting in 96 have to have them But they don't actually have to be fully functional until 2000. They're in 1999. So there's some You know variants and what actually has been implemented and there's some discussion about what's the future for OBD three So I'll get to that a little bit in the future as well So so the current standard is OBD two it's standardized by SAE In the standard covers covers a physical connector all vehicles have to have one single the same single physical connector It covers a data link layer There's three options where any one via any vehicle has to have one of the three options And it's a standard network protocol that's right on top of all the data link layers it also standardized diagnostics by which there's certain procedures and Mechanisms required for diagnosing troubleshooting the vehicle Only the diagnostics that relate to emissions control systems by US federal law under EPA legislation are really required the scope of the the standard covers The ability to use this bus for other purposes So there's there's room in the standard to support You know standard common components and manufacturers specific components, but those are required by the federal law There's also many many packet formats and data types for diagnostic data again, there's a variety of them that only a few of them are specifically required but For manufacturers that want to don't want to duplicate efforts and have a separate diagnostic bus for all the things that are not required They can just use the same bus for all of their specific proprietary parts OBD two also specifies a mechanism to read and write the ECU memory ECU There's two term. There's two definitions for that acronym Originally a standard for engine control unit, but now it's often used to mean electronic control unit which can control things other than the engine such as any lock brakes or airbags or Climate control or any any of those black boxes could be a ECU and electronic control unit So since they have microcontrollers or more functional processors a memory you can read and write the memory with OBD message network messages, and there's also a security feature to allow particularly either proprietary or Hell or safety related features to be To be protected by a security feature that requires certain knowledge of the vehicle before you say reprogram your anal up brakes or Your any theft system on the vehicle And that's not required, but it is used by a number of manufacturers for for main for the theft control systems or any theft systems So common usage this is the scan tool is one of the very common uses of the diagnostic bus for the purposes as this name say diagnosing problems with the vehicle An ECU detects a fault condition some problem with the vehicle as you're operating it Say for example oxygen sensor detects a mixture too rich so The ECU it records a diagnostic trouble code. It's basically just a number that Explains more detail about what exactly is oxygen sensor to one bank, you know bank to had a problem And when the diagnostic trouble code is stored that causes a check engine line on the dashboard to illuminate Some DTCs can be minor and not cause that to happen But typically they cause a check engine light to illuminate so that the driver the vehicle knows his problem They take it to the mechanic the mechanic plugs in this scan tool device It retrieves a DTC. This is people hear a mechanic saying they read the codes back or they scan the codes This is the process that they're doing to determine what that number is and then use that to You know troubleshoot the problem So they fix a problem and then with that scan tool they can clear the DTC and cause the check engine line to Go off and do cars fixed another Common usage of OBD2 that's only becoming Put in use in the last couple years is a crash data recorder Now this is a function where the airbag control module senses the deployment or non deployment events event the deployment events Relate to when an airbag deploys Just the sensors detect the acceleration the vehicle and impact sensors and whatnot to determine that there's been a crash And it deploys the airbag to serve as purpose a non deployment event is an event that causes perhaps some but not all the sensors to To trigger so it doesn't actually deploy the airbag, but it's considered to be fairly significant So that information you can also be stored in the airbag controller The vehicle sensor data is stored in the airbag control module That's where the actual information is stored and it can store information from other sensors That are not part of that module including the vehicle speed engine speed Throttle position brake state the driver seat belt state whether it's engaged or not and Then this information can be read back from law enforcement Or mechanic or whatnot, you know after the crash for analysis Doesn't help in troubleshooting in a car because it's really just information about the crash So it's more for forensic analysis of an accident possibly in a legal setting So if the vehicle is repaired the airbag control module is just reset or replaced So I'm getting to the OB2 Network the physical layer specified by OBD2 Specifies three diagnostic buses. There's little mention in OB2 of other buses. I'll get to that in a bit but the the three main Buses are these these three here the PWM pulse with modulation a variable pulse with modulation and the ISO asynchronous serial the ISO bus is actually standardized by the ISO organization in Europe and that's commonly used by European cars and Japanese cars But the other two are actually detailed specified in OBD2 and any one of the Three buses is required on a vehicle and it's required to use that bus for all of the federally mandated Diagnostics and commonly manufacturers then extend that functionality to every other diagnostic capability they have because why Do what why add a second bus when you don't need to already have this one Some other buses they're common Elmobiles are the can bus the control area network That's a lot higher speed than the other buses on the matter factor of 10 or more and the can bus is typically used for real-time communication between between ECUs on a vehicle the whereas the diagnostic buses are used for Communicating off the vehicle to a scan tool or some other device plugged into the vehicle the can buses are often used for communication between the airbag controller and the Engine control unit at the while you're driving the vehicle in real time to update vehicle speed or other sensor readings or to control systems and Can is more used in higher-end automobiles nowadays, but its use is becoming It's becoming more and more prevalent. I think in the future. There's gonna be a lot more One more functionality available on the the can bus and other buses that are using many in the automobiles There's main factory proprietary There's the OBD one buses like I said that there's no standard implementations So there's a variety of buses that are used for the OBD one implementations and there's also buses before OBD one where manufacturers had substantial electronic control systems in a vehicle, but did not before there was federal requirements to have certain emissions control systems Ignosable from an off-board of controllers. So there's a variety of those and those are limited used from different manufacturers So the data link layer On the OBD2 and the ISO bus it's a They're all half duplex shared buses and they're all carry sense multiple access with non-destructive collisions So that I mean basically what that means is a priority in the header of the packet the The beginning of the packet which specifies the message type and addressing is Allocated in such a way that the higher priority messages Will win a contention on the bus So you don't actually have a destructive collision that causes both packets to retry only the lower priority packet will retry and this basically makes it such that if you have a bus with a lot of traffic on a lot of contention you won't You won't have zero data rate You'll have you'll still be able to have effective communication, but certainly the lower priority messages may get delayed or not sent at all The network layer is a standard standard across all three of the OBD2 buses the SAE specification and specifies addressing modes There's two different addressing modes of functional and physical the the functional mode is used for Addressing a component by by its function as a name that says And that's for the purposes of allowing many vehicle manufacturers to Have freedom in the topology of how they lay out their ECU's whether a manufacturer wants to have one or two or five ECUs in a vehicle They don't need to be concerned with functional addressing you can say You can ask a component You know which which component has the you know the sensors for the oxygen sensors And you don't need to care that the one manufacturer has one ECU that controls that and another manufacturer has five it You'll be able to talk to all of them. So That's some It's more to ease the ability of creating the off-board diagnostics Devices and the physical addressing is sort of a traditional network topology where Typical network addressing where every individual Physical ECU has its own address and either can be used for a vehicle, but certainly the functional can be done on on any vehicle Very much the same and physical is need specific knowledge of a particular vehicle And the network layer is also on packet formats There's also packet formats defined And they define things such as the diagnostic modes where you can run tests you can query sensors you can control outputs That's the main the purpose of the diagnostic classes from the point of view of a controller off the vehicle controlling the Systems on the vehicle and for diagnostics troubleshooting purposes So in these these various network formats, there's there's some data formats that are used to exchange information and This is done in a fairly efficient way to minimize the The or to maximize the utility of the low data rate buses There's sort of two Aspects to the defining a data format. One is the scaling limit offset table slot And that maps the data bits or bytes to a meaningful magnitude So basically it's what? You know assigned or unsigned number and the bit width and it goes even further to Define fixed point formats where for example an 8 bit value can represent minus 42 a 7.5 in in one half increments And the parameter reference number PRN is sort of the other half to that where It takes that it provides the the units and a label or description so a PRN would include something like a vehicle speed in miles per hour and then it would reference a slot that would Dictate how the magnitude is represented. So the the slot and the PRN are used to They're basically have to be off-board tables of when what packets supply which What types of value values? What's the slaughter PRN for values that come back from the vehicle so that? The vehicle can send back responses and efficiently the diagnostic modes variety diagnostic modes here and Like I've mentioned for requesting the sensor or diagnostic data you can you can ask an off-board device can query the vehicle for any particular sensor what the reading is or Diagnostic data, which is perhaps sensor input that's been Processed in some way or the results of an on-board test It's a freeze frame capability where certain Sensors can store their values at a particular time You can set triggers so that you can manually control when information is stored where If a certain threshold is reached on a particular sensor then store all these other sensors Also the freeze frame data is stored on some DTCs the diagnostic trouble codes when a particular error occurs Sometimes automatically sensors related to the sensor readings related to that error will be stored So a mechanic won't need to go reproduce the problem. He'll already have a bit more information about what we're wrong And as I mentioned before the scan the scandal example you can read and clear the DTCs The on-board monitoring and diagnostic tests there's a different there's continuously monitored non-continuously monitored systems which fairly self-explanatory one Just repeatedly runs as vehicles running and the other one is just sort of a one-shot deal You ask for the value ask for it to run it runs and gives you a value back And you can initiate the tests and read the results back from the tests and some of these tests are also run at particular times automatically and you can Read back the results of those automatically run tests Some other diagnostic modes available or reading vehicle information which includes the VIN calibration data memory check sounds And even more generally just reading and writing memory to the ECU's which can include Data parameters it can include code to the runs on the microcontroller that controls Whatever the ECU's function is so What types of existing products are out there? There's sort of a spectrum of the type of functionality and the sort of level of integration with the manufacturers in the products. There's the hardware Products that are basically just by a box and they go all the way to the the proprietary full interface type things that the manufacturers have Things to be at the dealer They're very functional. They have all sorts of they can do just about anything that you can do on those diagnostic bus control Just about anything, but they're typically in the tens of thousands of dollar range there's also devices that plug into a PC and Just provide basically a network interface to a PC and then the PC runs software that provides some functionality Often those are less functional. They're more general so they support some common subset across vehicles But they don't necessarily do every little feature of every vehicle out there And those usually convert some type of serial RS 232 or USB into the diagnostic buses There's also chips. So we're getting down more into the level. There's chips that provide some of these functionality Which really could be the basis for the devices and there's also a few designs for Real simple schematics or kind of hacks on the RS 232 TI 232 serial port They will communicate with the ISO interface on the ISO interface the bus again That's the bus that's defined by the ISO but SAE references it sort of as a consideration to the European and Japanese car manufacturers that tend to go with ISO as opposed to SAE standards and that data link layer is Looks roughly similar to what's a serial UR interface So just a physical physical layer conversion. You can actually plug a serial port on a PC into that So then with some of these devices that are just hardware that plug into a computer You need software and that certainly so there's numerous commercial and serial products Standard support is most common sort of the common subsets. I think that's the most number of vehicles But doesn't do all the features and new features of vehicles and some of them there are a few that are manufacturer specific And those are more commonly the commercial products And there's one notable free software project called free DAG That provides basically the basic scan tool operation diagnostic procedures It does not go into a calibration of vehicle specific things Nor does it really there is some support for diagnostics on some proprietary buses But there's not not too much support certainly not the the spectrum. It's available from shareware or certainly commercial software So open auto is a project that I've been working on And this is a bit of an overview of what that encompasses I've been working on some hardware designs Another variation on the RS232 to ISO bus interface To make use of some new chips that are fairly available now and fairly cheap It's somewhat of a Low-part count so easy to manufacture design or easy to put together I mean you could with two parts and samples from a couple manufacturers you could You know put that together by soldering 10 wires. So it's a pretty simple design I'm also working on a repurposed USB serial adapter. I'm basically taking a key span USB to RS232 interface and writing custom firmware that will Talk not only the ISO out of its out of its out of its RS232 connector Which would be fairly easy to do but also doing the VPW and PWM So that you can support all three of the OBD to diagnostic buses with them For the one device and that's that's not complete, but I've been working on that in the last two weeks So that's sort of in progress and software is a layer 2 and a layer 3 network stack and Some application software the the network stack Is in its early alpha stage Primarily of used to develop really only of used to developers There aren't just have test applications written no no scan tools or any diagnostic control, but It serves on as a basis. It could serve as a basis for writing such applications The approach taken by all the software packages that I've seen is to basically write one single monolithic application that talks all the way to the device to the user interface and one single single application and what I'm trying to my my sort of theory theory of operation for open auto is to provide the standard network stack type type of software where Each layer of the of the network is a separate piece of software is a separate library So that you can stack them up and you don't have to duplicate efforts when you want to write a new application You can build on top of whatever Standard layer that you're you're trying to work with and all the hardware and software designs are free software released under the GPL So the network stack Trying to go for a common API across networks Currently I'm working just with the ISO, but I'm planning to support VPW PWM and can at least initially and then Depending on what I can get access to as far as some of the other older buses You know, I hope to be able to support that at least to have an API that can Communicate with those if others would be interested in supporting that It communicates the OBD2 data link layer. There's one for all of the Well, there's one that corresponds to each of the physical layers. So as the physical layers are implemented, so will be the data link layers And then the network layer initially I'm concentrating on OBD2 because standards are available But manufacturer extensions should be easily added if that information can be reverse engineered or otherwise obtained And the applications these are these are not written these are these are just in the planning stages But certainly a scan tool will be like baseline type of device that is, you know, commonly done That's where but we'll just sort of prove out the the network stack And a network probe and logging tool be things like TCP dump and now just standard network diagnostic tools that are common in land networks But would be certainly useful an automotive network, too But the automotive network hasn't been really approached as far as a data network. It's more of a Thought of is sort of in a different frame of mind, but I don't think it needs to be so I think those tools on would be very useful so plan to get to those at some point that way sort of help in Determining some of these manufacturer proprietary extensions where you can explore an unidentified ECU's if there's some ECU that did never Responds to you when you do any of the standard communications, but if you You know if you just go through all the addresses and you can find that is there perhaps it can serve some function So they'll let you explore that and also explore unknown packet formats put a sniffer in between One of the manufacturers tools in the vehicle and log all the data and then use that to reverse engineer their protocol and then implement that in open auto Also some ideas for a high-level monitoring and control Where you can expand the diagnostics beyond the the minimal set for OBD to potentially have some type of Real-time logging that will just continually as you drive will tell you Tell you conditions that are not so severe to cause a DTC to be triggered, but potentially you can You know alert you to a great degraded operation of your vehicle before it gets to the point of component actually failing logging for, you know, whatever purposes if you want to For more diagnostics or if you want to tune your vehicle if you're trying to just determine performance data You want to generate logging over time to be a giving you a way to do that Everything's wise a configurable UI for a detailed dashboard where you take all your gauges out You put in an LCD and then each driver can have their own theme and you know have their own gauges displayed however They want they can have you know, someone can have just a speedometer and other people can add the output of our sensors If that's you know suits their driving style so That wraps up You know the onboard diagnostics and automotive networks So I guess I'll open it up for questions or comments The question was can you access the cam bus for the OB connector and yes, you can the SAE standard for that connector Also specifies a standard pinout and that pinout says Basically, if you have the ISO bus it has to be on this pin if you have the VPW bus has to be on this pin Peter Rowan bus on this pin and the can bus on this pin It doesn't have any other mention of what you would use a can for but it says if you have a can it should be on These pins so it should be there it should be in a standard place So since the can bus is standard you could potentially have a generic Sort of network layer there to communicate with whatever you can find on the end of that bus Other questions, yeah Sorry Was the question you can you add new devices onto that bus? Yeah, certainly the The open auto architecture is just a network stack that communicates on this bus So if you allocate the address for your ECU to be in the range not for the off-board scan tool But for on-board in the on-board range and you don't obviously collide with a an ECU that's there Which shouldn't be very hard because there's a Few hundred much. I think it's a seven bit number. It's about 128 Addresses and most vehicles have less than 10 ECU so there should be plenty of addresses to pick from but yeah It certainly could be possible to add an ECU to the vehicle and communicate on that bus Yeah sure If you had a rental car, I don't know there necessarily be a lot you could tell Depending on me and there could be some with on-star and some navigation systems There might be some proprietary ways you could look through the history of it One thing you would most likely be able to tell is with the crash data recorder in the airbags You could you wouldn't get a very detailed history But you could tell if there had been a non-deployment event Basically if someone was reckless driving almost to the point where the airbag deployed but not quite you could Read back those parameters, whatever is stored on that vehicle but other than that there's not not a lot of logging no other logging that I'm aware of is in the You know commonly used in the ECU is in a vehicle So there wouldn't be a whole lot of history available I guess but I'm certainly that could I could change with you know More navigation systems that would give you things like position and time Information and also Availability of more storage to be able to just log out. I'm not worried about you know using up storage space So the question I guess the question was how can you tell if there's some sort of remote transponder on a vehicle? those I Guess there's a number of obvious signs of that Certainly if it has on-star, that's a capability of on-star to be able to do that. I believe Ford has a similar System that's smaller navigation system that has some sort of a crash recovery feature That's not used for the asking for directions But in the event of an accident supposedly it can report your telemetry informations for rescue But those are the only ones that I'm aware of I mean There's certainly a number of ways that I could probably think of my half a dozen I thought my head of ways you could potentially set up set up a telemetry System on a vehicle, but I don't think there's no OBD2. There's no SAE standard for that type of system So it's really just you know up in the air could be implemented any number of different ways There's not a common besides the ones I mentioned of the on-star and whatever's Ford similar corollary system would be I don't know of any other commonly used systems that would do that I guess that reminds me of one more Just a little bit about sort of the privacy and the telemetry information is the so this OBD2 is the current standard for that's a federally mandated standard from the SAE for automotive diagnostics there's been some talk about what What will be OBD3 what will replace it and I haven't seen anything concrete I've seen a lot of sort of rumors and discussions and trade-jones, but I have seen the only concrete thing referring to this I've seen is on the California Air Resource Board, which is sort of where the EPA gets this direction for what eventually becomes a nationwide standard and They mentioned that there's going to be a feature or there's considering a feature that will make your vehicle inspections be much more convenient by continuously automatically reporting the state operational state of your vehicle to remote transponders such that only the vehicles that are performing under spec will be required for Required for an inspection. So certainly that could be on have all sorts of privacy implications if your vehicles all the time Or once a month is reporting its information to these beacons around your city around your town You know, it could be reporting more than just emissions control data It could be required, you know by the time OBD3 comes out It could require GPS in your car and it could have your coordinates certainly have to identify your vehicle and You know, I'm sure that someone will eventually find out how to decode that themselves And then you can just track people very easily with that That type of system Certainly yes, I mean you could yeah, you could do that You know, you could you can make a transponder that continually just reports. Yes, my vehicle is fine. Everything's perfect Just kind of get a record of what the the proper operational Messages and then just continually play back that forever and disconnect the the real transmitter So there's certainly a lot of flaws in that system And I'm not sure how much of any of that is being thought out because all I've seen Concretely about it from a third aid of surf sources is just a very Vague comment on the California Air Resource Board site So I'm our questions. Yep The question was the ECU stores the vehicle identification number. So what does that do for aftermarket? Mechanics that will swap ECUs for vehicles that have been damaged or need to be repaired That can cause a significant amount of problem might imagine I know I haven't seen anything with reference to the VIN, but I know there's a lot of lot of problems with odometers that With when you use a an ECU that has it because the odometer is in a lot of vehicles nowadays It's displayed on LCD and it's information stored in an ECU in memory somehow and so there are ways to reprogram them a single time or Certain procedures you have to go through to get them to be reprogrammed and I imagine they'd be similar for the VIN But I also imagine that it probably will be very difficult because I know that in other in other for more for anti-theft systems there's sometimes there's Pairing of certain electronic components where certain ECUs will only work with their their corollary ECU specifically the vehicle hydro the vehicle I drive the The the trouble getting we're putting a replacement engine because you have to put in a replacement ECU at the same time You put in a replacement engine Otherwise it just won't work Basically, you can't replace your engine or your ECU separately. You have to replace them both together Other questions Yeah, they can do on-star they can do all sorts of things remotely which makes it kind of scary They can they can read back just about anything from the vehicle. I mean they can start your vehicle remotely over the phone so it's actually had a discussion with on-star salesperson one time about the Some of the privacy and security of that and their best answer was well We have a policy and we train our people well, and I don't know any more than that So personally, I don't trust them very much because I doubt their policy is enough to really do anything in the in the face of something Something going wrong, and I really doubt that they have too much security on top of top of the system to make sure that it's it's hard to You know spoof and do bad things that question The question was on a blue tooth enabled vehicles nowadays is blue tooth available is the blue tooth on the can I'm not sure. I don't have any familiarity with those vehicles, but I would imagine in some fashion There's there's probably some interlocked there so that for example, if your your phone rings it can automatically mute your mute your stereo or You know perhaps they can do even more sinister things like You know make sure that the vehicle is operating in particular way or hang up your phone If your car is you know steered to a radical or something like that But I do think that the meeting the audio of a stereo when the phone rings is something that would be very likely done But I'm not sure I had us just speculation. I'm not Filling a lot Right. Yeah, the common was that there's a lot of us market stereos and In factory stereos have a line that's sort of a really output to be able to control this function But I think that's sort of a more of an old technology way to do it and the community came over the can bus with a message It would be I think the way things are going in the future And it's more of a sort of a shared network as opposed to a you know a one wire for every function You need you have you know pair of wires for a candle on your vehicle And that does everything you don't have to have you know dozens of wires going back and forth spidering all through the vehicle The question was how much code as far as quantity is in the ECU's and what type of processing is in it Certainly in say five to ten years ago 8-bit microcontrollers is very common and eight or 32 K of memory was very common I think modern vehicles are still used Some of them still use 8-bit microcontrollers for a number of functions some of the more enhanced ones And they also have um code that's you know, maybe 32 64 K and they also have a number of ECU's instead of having one ECU with You know 8 K of memory there's five ECUs in each one as 32 K of memory So they sort of parallel in that sense that there's multiple each serving separate functions Now the common was um average processors about 40 megahertz and one to two mega of storage It's just it's seven Yeah, the color was a newer versions of on star CDMA But I do believe that they do their data in band and their voice channel because the demo I saw when a they called up the The on-star representative and told them that they were locked they locked themselves out of the vehicle Since they're calling from the vehicle the on-star person said let me wait disconnect you for 10 seconds And I disconnected the doors unlocked and then they came back on the line reconnected the voice conversation so I believe that there's probably doing some type of um audio frequency shift keying through the The voice channel or some other type of modem through the voice channel of um of a cell phone The question was very good more about cryptography. Sorry was there more than that? Yeah, so the cryptography on the buses the only thing I know as far as any type of security features the security feature in the OBD2 and that's really just a challenge response type of It gives you a seed and you have to give it back the corresponding key and those are 16 bits each each way and that's that's the only security that I'm aware of that the vehicles do I think some of them also Have a security through obscurity where they have a checksum in an odd place and their memory map and they have an algorithm It's people don't know but it's not really a I doubt it's a cryptographic secure algorithm It's just an unknown algorithm So because I know a number of people that are reverse engineer different different ones So if you know the fewer vehicles that have a particular algorithm on it that sort of the less interest there is to to reverse engineer it and I mean, I know it's terribly effective But I think that there's very very crude and I mean it's hard to really even call what they do cryptography The question was what type of storage devices that they use eeprom is commonly used because they want to because you need to be able to Store small amounts of data, you know, you don't a flash memory wouldn't be sufficient because a DTC is two bytes You know some of the freeze frame data is just a few bytes So they need to be able to store those periodically and also You know share the memory with storing calibration data, which is only written once in the factory or whatnot So the E Electrically Erasable problems It's what they use their questions The question was if I consider writing it as an OBD device driver I'm not quite sure what the what you're asking, but I think that is basically what I'm doing Yeah, the the the question was Or the common was to have it as a kernel device driver I'm just like a network interface like other network interfaces in the vehicle and and yes I have considered that and that's sort of I see that as like a later step to what I'm doing now just because of the ability to develop it and and some of the Some of the common reasons why we want to do that for normally network interfaces isn't so much of a concern for open auto things like performance and some of the other integration with the other Utilities where you're not going to run why I suppose you could it would be I don't see what there wouldn't be a high priority to tunnel IP over OBD2 But potentially you could do that if you had something set up and now it might be an interesting thing to tell you Yes, it's actually something I've been thinking about too where you can have some sort of small device on a vehicle The talk so be it has an ether or something that you can connect through You know a computer in the back of your vehicle or tunnel it over 802 11 up to a service shop or something like that But yeah, I have considered that but I'd see that sort of as a later stage to just getting the driver stable because There's not a lot of benefit to doing at this point and just would complicate the development cycle other questions All right, thanks. That wraps it up. Thanks a lot