Wow. Thats all I can think of right now... is wow.
LK I expected a little more from you.
Matrix: The starmobile is a unit that sits on the obd2 port, its a date recorder and gateway for the starscan or wireless deal. Its has no more power then a snap-on scantool.
Karh4ck3r: Based on your comments and assumptions I have to assume that regardless of what IT Security expereince you have; You have little understanding of the CAN and microcontrollers used in the chrysler vehicles.
I found some things that were kinda funny to me and I have a minute so I'll elaborate on some things:
For people who understand the CANbus better than I, "Is there anything within the CANbus design that would prevent any module on the CANbus from sending data (spoofing) as if it came from another module?" If your answer is "No" then be afraid, be very afraid.
There is actually a security system in place for important things. Its a seed and key return system that is almost a minimum of 16bits or 65535 combonations with a time delay of 5 seconds between tries (its actually 2 tries then a 10 second delay, then a set max attempts before a longer delay 120 tries to a 20min delay or so). This is only for important things like the door unlock command or panic mode. Everything else is considered unimportant and harmless.
What does this mean? This means that an attacker who can successfully inject code into the hands free module can begin sending data on the CANbus that can wreak havoc with all the other modules on that bus.
This is so far from reality that I have to now assume that you have never programmed for a state-machine or rtos microcontroller. There is a long answer to this but I'm not that patient to try and explain it, you get the cliff notes version... Chrysler can network is a very large state machine, where every normal message is always being sent at a specific timed interval. In this way the bus load is never much less or much greater then its load at any given point in time. This means that inside every micro holds variable to be sent of the bus in ram, its data is updated however often but its transmission of the bus is a constant interval (say 10-500ms). This means module A can only ever send ID:500 DLC: 2 Data1: XX Data2: YY. Where XXYY is some relevant vehicle data, like a fule level, or configuration message. A 'hack' (as someone who considers themselves and actual hacker I use that term loosely) to the HFM or Radio+HFM can not start sending user specified data onto the bus b/c it has no function to do so. Perhaps you could alter some data that the module is prepared to send, but in the actual scheme of things, I doubt it. More on that later. Super short answer is not going to happen.
Am I a crazy paranoid person? No, I am an IT professional with 21 years of industry experience, the last 8 of which have been specialized in information security.
No, your not crazy. Just misinformed.
Is this just science fiction?
You're getting there. Comparing a 'hack' or any modification to the vehicle's data/bus to a cellphone hack is really reaching. The HFM does nothing more then route the voice transmision of a call throught the cars stereo and mic, and store contact/address data. It would be FULLY possible to inject data into the address book even over the vehicles speakers.... Maybe you could even use some crazy ascii chars or spoofing/slamming function that crashes/freezes the HFM. But not do any damage to the vehicle or comprimise data on the bus. Besides, there is security in place for this too, Chrylser's HFM does not openly solicite itself as a bluetooth node nor does it accept data (like a cellphone does) unless it receives it from a known phone. It only 'knows' a phone after completing a phone pairing op. So.... MAYBE you could make a module that spoofs phone paring, and MAYBE you could distract someone long enough to pair your module to thier car, and MAYBE... Just MAYBE then you could freeze up thier HFM or make the phone book have naughty entries or something.
So, I believe this forum may have an interest in knowing if the HFM is secure.
Prepare to be bored out of your mind. Even if you are a really smart cat and figure out the can data by logging it, (Look around here to see how well thats going, and some of these guys are pretty smart) you'd be ultimately be very disappointed.
If you are driving one day and your CD ejects and your radio tunes to a different station, you might want to look around you.
Uh... You're kidding right? Aside from the horrible range that chrysler's bluetooth has.... eh nevermind. I'm not being aggresive or anything, but you have very little understanding of how this whole system works.
And you are 100% correct. There is no security layer on the CAN bus. It does base it's security on the closed network / trusted nodes mentality.
Really Lk..... Come on. He's no where near 100, maybe 20% at best.

See above for a little info on the identification these modules share. See, regardless of what the original posted suggests, Chrysler did think a little about security. The fact that CANC is isoloated from B isolated from D is, well, physical security is the best form of security. Next you have the fact that very very few people have figured out much of the bus on thier own by logging it. People who don't have to log it, well lets say have other things in mind. So protection by confusion. Then you have the the seed and key, ie one module asks for a seed, the other gives him one, then requesting module then sends a matching key, if its legit the auth was complete. In the case of door locks I believe I've seen 3 byte seeds and keys, that I believe rarely repeat. Thats 16,777,215 possible combonations for you just to once unlock the door.... Not sure how this would even be helpfull since you need the key in ingition and access to CAN-C... good luck.
There's software out there for sniffing bluetooth traffic, and decoding the link key that secures these connections.
See above, closed to unknown attempts. I did a little bluetooth programming for a project awhile back, didn't really like the fault tollerance and message balancing so I never got into it too much. Can't really go further without really a few things. Not gonna happen today. Already typing a novel.
All Flash updates are done over Bluetooth. I believe that the init of the update is done over CAN Bus, but the actual firmware data flows out in the open air waves...
I find this a little odd, but I could understand if it were the case. The HFM has a very small amount of resources devoted to CAN. It would probably be fasted to load via rf. I can promise you these are not open air waves. The same seed and key return is done at the very least on the can init side. But most likely also on the rf side.
One other point of entry into the system is the SKREEM module. It is also a wireless interface device that resides on the CAN bus. It handles not only the validation of your key by way of rfid, but is also responsible for listening for the lock / unlock / panic / trunk pop signals from your key...
Arg... The SKREEM doesn't work like that. Inside each key is a little philips chip, battery, and antenna. The way it works is that when a key is learned to the car a rather large chunk of data is downloaded into the key. A data table. When you press the key for a learned vehicle the chip sends packet containing the ID, Command, and Security packets. A total of 32-64 BYTES of data. Cool thing is, when you are in a parking lot of Chrylser cars and press your button, they all wake up their SKREEM. It checks the ID of the incoming packet. If it does not match an ID (4 bytes i think, maybe

that is known to that vehicle, nothing will happen. Now, if it does match and the command is ok (lets say unlock doors) it will then check out the data that was recieved for the security packet. This is all done on the die of a matching philips chip. If its OK, then the SKREEM sends a packet to the cluster asking for unlock, the cluster starts seed and key then bla bla bla we're back to where we started. If you can find a flaw in that system you would be a multimillionaire. I am not saying its impossible. But its so unlikely that its pretty stupid to worry about.
By the way, Tire monitoring is not just LX, its all of dcx's line. Manditory for 08. All new models or models with refreshes since 04 have it now.
linuxkidd catch the right point when talking about the Screem module. It is a weak point in the network .
Actually its the or the second strongest point on the network. But uh.... good guess ? It might loose out to the FCM, but I'd guess they are equally secure.
I wish there is no "Air Bag deploy code"
There is not. Its federal law that there can be no magic remote trigger of the air bag system.
he will have to try up to 256 different codes to get the car to disarm and unlock
Thats a 1 byte code (0x00 to 0xFF). I'd be willing to bet 00 doesn't ever come up so 255 is way more likely. Like I stated before, Chrylser's systems are never less the 2 bytes and always have a time to retry limit. No getting around it. I saw one instance where the time set and based off a charged capcitor, so one start they charge it then let it drain through a huge resistor, like 1M or so. So even if you pulled the power and restart you still need to wait the time for it to discharge before trying again. That was a long time ago though, I think now they force a delay on start before the module will allow any attempts
That could explain why they have chosen a Fault tolerant bus.
No... The FT bus was a bad idea and they are moving away from it. No one seemed to realize that it would make modules exclusive of either bus (sometimes a fuel pump module might be can-c or can-b perhaps). It wont change today, but its pretty soon. FT is for physical errors like a wire came out from its connector and one 1 bus line of its differential pair was still intact. Its just a special transceiver and termination method.
So thats all I have. Sorry if I offended anyone but like I said, I was some funny stuff. Had to fix it. Woot, I now have the record for longest message on canhack! And I didnt proof read any of it.,
Lates, Its sushi time!