How to disconnect the tracking telemetry on the 5th gen 4Runner

You should call and opt-out FIRST, as this is legal opt-out. This way if DCM is somehow re-connected, you are not back into Peeping Toyota land.

 

Calling in and opting-out/disconnecting your system but leaving the fuse in is what I did.

The microphone I believe is the same in Bluetooth and CarPlay.

I called in while I was waiting for the tire pressure machine at Costco so it isn't a huge timesink at least in my singular experience. (which clearly can be extrapolated to everyone /s)

 

Great advice, thanks!

 

it's been over 2 weeks since I traded in my Raptor and I can still unlock and start it via the Ford mobile app on my phone

 

Note: originally, between this post and Old Red’s heroic post #436, there was a “spirited exchange” between myself and a user named 2coco. He asserted, in a very convoluted and condescending way, that our 4Runners could be hacked through the radio even if the DCM was disabled. That they could be hacked, re-programmed, and disabled. It was very disheartening. Then Old Red showed up and dispelled a lot of the notions that 2coco had been spouting. In response 2coco deleted all his posts. Afterwards I considered deleting my half of the exchange, because those posts don’t make much sense without 2coco’s. But I decided to leave them to give context to Old Red’s post which I consider authoritative and valuable. Cheers.

Perhaps you’re thinking of a different post. The resistor used by the guy in the post I referred to didn’t look like the slab you pictured above. It looked like this.


And here it is on a fakra adapter. No soldering.


Perhaps if you want to contribute meaningfully to this discussion you could provide detailed specs for the components you recommend, and what to do with them in a simple step by step way. Maybe even provide a link or two. Because just spraying us laypeople with a bunch of jargon may convince us that you’re erudite, but it doesn’t help us at all.

 

I’m no expert, but based on this photo of the antenna connectors on the DCM, the adapters you pictured won’t fit. Am I correct?

 

Too funny, but be very careful not to actually do so as you can be criminally liable for anything bad happening as the result (e.g., starting it in enclosed space and killing someone).

 

We are getting into targeted attacks/surveillance situation, so your opsec has to be on entirely different level to withstand that. Disabling DSM is about avoiding mass corporate for-profit surveillance.

I recall BlackHat presentation by someone correlating TPMS signals with cell modems and then tracking down someone working undercover to their house, because they were changing (Faraday bag) phones they use after going over state lines. Fascinating stuff.

 

These are the antenna connectors that plug into the DCM. They don’t look like the one that you suggested.

 

@2coco i have a couple of more things to say.

You have accused me a couple of times of not knowing what I’m talking about. I don’t pretend to. But in spite of the jargon you’re throwing around, you haven’t convinced me you know what you’re talking about.

The dummy load I posted a picture of in post 431 you insisted was a cap. It is in fact a dummy load. The part number is on the bag. Look.

In post 432 you posted this photo.

I naturally inferred that you think that this component is required. Now, choose whichever analogous jargon you prefer, but this looks like a plug


and these look like sockets.


Also notice that none of the 4Runner’s DCM antenna connectors are “claret violet” in color, nor do any of them match the fakra D profile.


It’s all very confusing, the way you’ve put it. I can’t tell if you know what you’re talking about or not. I know you know something I don’t know, but I don’t know if it’s relative to the discussion or not.

I suspect you first became miffed at me because I described your posts as “spraying jargon.” Look. This is a car forum. Most of us aren’t in the telecommunications field. But we’re not idiots either. We know enough about car electrical to do what most car guys need to do. Add a few lights, maybe an extra usb port, add a second battery. A winch. We know how to use a test light and a meter. Some of us might even know Ohm’s law. And then you chime in with this:

“Mostly it's useful for one thing, which is listening to DRM (Digital Radio Mondiale) HF signals using an IC-7300 and a PC; the IF mode is the only way to get the 10kHz-wide digital signal to the software, since the filter can only open up to 3.6kHz wide in USB-D mode.

As a digital medium, DRM (Digital Radio Mondiale) can transmit other data besides the audio channels (datacasting) — as well as RDS-type metadata or program-associated data asDigital Audio Broadcasting (DAB) does. DRM services can be operated in many different network configurations, from a traditional AMone-service one-transmitter model to a multi-service (up to four) multi-transmitter model, either as a single-frequency network (SFN) or multi-frequency network (MFN). Hybrid operation, where the same transmitter delivers both analogue and DRM services simultaneously is also possible

DRM incorporates technology known as Emergency Warning Features that can override other programming and activates radios which are in standby in order to receive emergency broadcasts.”
​

And then accuse us of not pulling our weight if we don’t look up all of those terms in order to decipher your post. Excuse me, but you’re being a little tone deaf regarding your audience.

 

Thanks. 2 questions.
1. Do the various fakra configurations (per the chart above) differ in ways other than the shape and color of the shell? If the answer is no, and o have to remove or modify the shell, does it matter which one I get?

2. Couldn’t I get these and just plug it in and add dummy loads? Seems like less to shave off.


https://www.pasternack.com/sma-female-fakra-plug-rg174au-cable-assembly-pe39345z-p.aspx

 

If I read your translation correctly, you are saying that the car can be bricked by the radio even if the DCM has been disabled. Is that correct?

 

Interesting. I made a similar perusal of the wiring diagram this afternoon. I know the radio talks to the multipurpose display (between the gauges) to display which media is being played. But that was all I was aware of.

 

Wow...

This thread has gone from a normal conversation of getting your data/privacy back to certain new people needing a generous dose of haldol.

@2coco, I'm looking at you. Stop listening to BS videos on Youtube and actually go read and educate yourself on these systems before regurgitating nonsense all over. Critical thinking...

On a more informative note, @Captain Spalding, yes the OEM head unit does talk with the multi-information display in the cluster. It only broadcasts the current source, compass heading, and when navigation is active, turn directions. This is on a separate local CAN bus that only exists between your instrument cluster and radio. Your cluster in turn sends it the average MPG and trip information. Your OEM radio can't "brick your car" even if you disable the DCM because there is no programming in it to do so. It is also connected to the Gateway ECU which allows connection to the OBD2 diagnostic port. The gateway in turn further filters the messages to other buses and ECUs.

While you can get FAKRA style coaxial connectors to potentially work with these terminals for the antennas, they are not FAKRA made by Amphenol, so they may not give a perfect mating connection. All FAKRA connectors are essentially shielded coaxial cables. The colors just denote the different keying of the connector so you can't mix and match plugs. The ones on the DCM are a proprietary design by Sumitomo, and are a bit different.

Just so people don't get wrapped around the the axle, here's some real factual information:

Your vehicle's CAN bus or controller access network is a common data bus that all ECUs talk on. You also have direct line, LIN, and AVC-LAN in your vehicle depending on the system. CAN is a broadcast based network, and is fault tolerant. ECUs are only programmed to listen TO and FOR specific messages broadcast by specific ECUs. For instance, your engine control module broadcasts engine RPM to every ECU on the bus, but that message is only received if the intended ECU is programmed to receive it via the specific ID, control field, and more specifically the intended data bytes. For RPM, an example would be the instrument cluster. Your TPMS ECU will not even receive this information because A) it is not programmed for it, and B) it doesn't need it. The ECUs in your vehicle do not "listen to any device connected to it". In order for the ECUs to talk to any "other" connected device, it needs to either be UDS (Unified Diagnostic Services) protocol, or a manufacturer specific diagnostic system (Toyota TIS). The OEM head units in these vehicles only broadcast 5-6 message IDs (Model year dependent/if it is JBL vs Standard, etc) and none are related to anything in the drive train. The higher priority messages have lower number IDs, and I can tell you with 100% fact anything coming from the radio has low priority and a higher ID. Even the DCM only broadcasts 6 IDs, and half of them are remote frames requesting data like vehicle speed, fuel level (for that annoying low fuel pop-up warning) or for a fault code to display in the head unit under messages. Some just let other ECUs know that it is present. Two frames are only broadcast when the DCM detects a collision, and that is to the instrument cluster to turn on the hazard lights automatically, and to the head unit/NAV to get GPS location for first responders ONLY if the DCM safety connect is still active and not opted out (it will trigger the hazards regardless, just not send the GPS location).

This is coming from someone who has worked with almost all the ECUs in the 5th generation and has actually mapped the CAN bus and 90% of the messages present in these vehicles.

For those models with the JBL head units and remote start from the App, this comes from communication between the DCM telematics transceiver and the Smart Key ECU. Why only certain models, I haven't figured that out yet. It might be a firmware difference in either module, but I haven't found it yet.

So to put it plain, in order to remotely "brick" your vehicle, you would have to simultaneously send a constantly updating packet of data on (insert whatever tin foil hat device they can think of) to CAN, LIN, and via direct lines simultaneously (all of which have a different bus speeds, data formats, etc) to your Engine Control, Smart Key ECU, Immobilizer, Main Body ECU, and ABS ECU, none of which are programmed to received a message of that nature. Yes, I'm sure our 2010 design based head units have most cutting edge technology that can do this no problem when someone magically snaps their fingers.

 

Thanks Red.

 

Anytime.

I certainly don't know everything, but I do try to be the voice of reason. There seems to be more and more new accounts being created lately with some truly wacky posts with nonsensical info.

My 4Runner never came with a DCM, but I can understand the desire to yank that thing out and keep insurance companies from freely getting private data.

EDIT: It appears 2coco received the boot from either the moderators or admin. Good riddance.

 

Just as an FYI pleas see my addendum to my post.

 

Now, for anyone but Hamas leadership and maybe Boeing whistle-blower that is sufficient explanation. However, there are couple assumptions baked into this that require further understanding for the kinds of people I listed.

Miller & Valasek were able to hack Jeep and take over controls using cell connection that was part of the head unit. They were able to string a set of attacks to push updated firmware that allowed them to send arbitrary CAN BUS code, effectively allowing them to to take over all ECU system.

What all of this means? Remotely hacking a vehicle over infotainment have been done in the past. It is not categorically impossible. Any drive-by system, like throttle-by-wire can be hijacked this way.

Now, to highlight assumptions that may not be true.

OEM head unit does not broadcast other messages for as long as its firmware isn't altered. This is not impossible, as firmware isn't signed and there isn't root of trust that would prevent unauthorized firmware from running on it.

You are assuming that Gateway ECU does filtering of all messages, and not just ones coming from OBD port. I am not sure this is true.

You are assuming that ECU and other critical systems are on a separate bus. I am fairly certain they are not on a 4Runner. More so, with car thieves opening and starting cars via lamp control module we know there isn't much isolation implemented by Toyota.

 

Even though it does sound kind of paranoid, taking external control of vehicle functions not really beyond the realm of possibility. In fact, the poor security design of these systems (in general) is obvious low-hanging fruit for anyone looking to cause a mass ruckus.

Which is why I wonder if removing the headunit or replacing with aftermarket is a foolproof way to sever the connection to outside networks.

 

I'm not denying it can't be done, as you said, it is not categorically impossible. That said, it is not as simple as the previous poster who's responses have since been deleted stated. There was some rambling about Sirius XM, dish satellite receivers, bluetooth garbage. Some real needs a "padded room timeout" style commentary.

I'll go through your points one by one so that it isn't a jumbled paragraph response.

First, I can't speak to how other manufacturers update their software OTA (over the air). Jeep may be different from Chevy, Toyota, Honda, etc. but as more manufacturers move to Automotive Grade Linux (AGL, runs the new full screen instrument clusters in the Tundra, Tacoma, and the newer head units in those models), they will likely share a core program that is merely reskinned.

I can tell you firmware for Toyota head units (Entune 2.0, 3.0 systems) are signed, that's why it will only accept certain updates for certain head unit models, and why it has to come from Toyota's servers. OTA updates require a seed key generated from the vehicle itself to access the update if updating OTA. You can download the file (Toyota allowed this for the older Entune 2.0, but I haven't check in a while if still possible) from their site, but again this is on the secure TIS server (again not impervious to hacking, but compromising that isn't something that would go unnoticed). Within the firmware package, the software is checksummed at multiple levels (even for how crappy it is as a user interface) which hampers any attempted tampering. This is partially in place to protect the hardware. That firmware also contains coding for several microcontrollers within that radio, some are master over other chips, and some require constant communication between each other with checksummed values to run processes. Again, pretty hard to blanket hack when Toyota likes to switch up which microprocessor models it goes with depending on manufacturing region/date of manufacture/year of manufacture.

Secondly, everything you are saying is an assumption, without evidence to back any of it up. I have mapped the Gateway ECU both on the bench and in a 2020MY+ while connected to everything. Only certain messages are passed between buses. It isn't a free for all. Can you inject messages on a CAN Bus, absolutely. You need some hardware and custom code to do it, and access to a bus that is constantly hot. You also have to negate the issue of collisions on the bus by transmitting with whatever you are sending. If that occurs, the message is ignored, an error is flagged in a process, and the original "unhacked message" is immediately retransmitted from the OEM ECU. Again, an ECU has to already be programmed to accept a specific message ID, match the corresponding control field, and data bytes. You can't just send random crap. In our 4Runners, when the security system is armed, the CAN bus is inactive, and will only wake up in selected circumstances, when it receives input from key ECUs on a triggered event. Even then, most ECUs, and higher level functions (Engine control, Radio, Smart key) remain offline until they receive power (Accessory, Ignition, or otherwise) or a sequence of events in a specific timing/pattern. Very few ECUs remain "hot" when the vehicle is powered off.

In regards to the whole headlight hacking, I will admit that is a sh*t security flaw, and manufacturers have known about his vulnerability for along time. All manufacturers suffer this because all use the BOSCH standard protocol originally developed in the 1980's whether or not it is CAN 1.0 or CAN 2.0/FIFO. I can't defend that. Some manufacturers have implemented features to prevent this like requiring a combination of signals from multiple components for a single response, or by separating systems on different buses where communication between each is filtered by a gateway ECU. There's some interesting reading out there regarding why this is an issue and what is/can be done to fix it.

For our concerns as 4Runner owners, the headlight hack does not apply. There is only one spot on the 5th generation 4Runner where the CAN bus is outside of the cabin, and it isn't the headlights. For all our security I won't state the location on the vehicle. Even if that spot were to be accessed, that BUS is not hot until the vehicle is powered on, and only 1 ECU is programmed to accept a single message from that system. That's it.

Finally, I am not assuming anything when I say the the DCM is on a separate bus. I know because I have actually looked at the technical documentation provided by Toyota. Please see below:

The 2010-19MY Limited trims had a DCM that did not have a CAN bus connection, so there is no interface between it and any of the drivetrain systems. It was essentially a crash detection emergency response box that had a GPS and cellular signal. It was a first generation system




The 2020-24MY DCM have a CAN bus connection that is isolated to Bus 3 which the radio is also on. BUS 5 is all the ADAS systems, and BUS 2 is essentially the 2010-19MY system separated from all the new stuff that was added in the 2020MY+ refresh. The messages passed on BUS 3 are DTC fault codes that are directed TO the DCM from the other buses, and output to the radio/NAV. As stated prior, there is a separate local bus between the radio and instrument cluster for Source, NAV, compass, etc. (I added this in red so that it was all on a nice single diagram for folks). The main data connection between the head unit and DCM is actually a USB bus (it is over this which map updates, firmware updates to the radio occur, and the fault codes are given to the radio to alert you in the messages section. This allows faster transmission between the two vs CAN.) This USB bus is the black plastic connector that @Captain Spalding included in one of his photos of the antenna connectors. That USB plug doesn't even interface with the radio itself but rather the NAV ECU below it for updating MAPS and Dynamic navigation.




If you feel all concerned about your radio being hacked (Which has no basis in reality, hardware, or the software in your car), call and opt out of the connected services, and unplug the black plastic USB bus connector going to the telematics ECU. PROBLEM SOLVED. There's healthy concern for data privacy, and then there's unfounded paranoia. Let's get back to the healthy discussion regarding the concern for data privacy.

 

Thanks again for that, Old Red. The time you put into it is much appreciated. I’ll have to read through it more than once to really absorb it.

 

I'll echo that!

 

I appreciate the effort you put into your detailed response, but I am not sure why you keep ignoring Miller & Valasek work I brought up as evidence. Once they gained access to a device that had ability to broadcast messages to CAN Bus they simply spammed at max transmit rate. As CAN is a real-time system with non-existent endpoint authentication, there is absolutely no protections against such misbehavior by a malicious actor. The retransmit behavior you mentioning is an error-checking mechanism, not an integrity or authentication one and the workaround is to send more messages.

It is not paranoia, as in "this is impossible", it is paranoia as in "nobody who can pull off such attack would waste all that effort to go after you". As I mentioned in my previous response, if you are Hamas leader driving recent 4Runner somewhere, I'd seriously consider pulling out radio, DSM, and disconnecting Sirius radio antenna. But then again, even pagers could be fatal to these people.

Just to restate, remote attack via DSM is a state-level difficulty attack that is going to cost millions in research and expertise and a few FISA Court orders to Toyota to pull it off. More so, there is no money in doing this, as such criminals are not going to attempt to do that. You want to disconnect DSM to prevent Toyota from snooping on you and reselling your data to data brokers.

 

I have read Miller & Valasek multiple times. Each time I read through research or an article like that I learn something new. Stuff like this takes multiple passes to comprehend, and even then it still requires more learning.

You are correct in regards to your description of CAN and that there is no endpoint authentication when a message is sent on and pulled from the BUS. It is a fault tolerant bus, without CONSTANT endpoint authentication and designed that way so that modules from a manufacturer can be added or removed based on vehicle configuration/trim/features. That said, there is endpoint authentication in that you have to be able to send the exact message that an ECU is programmed to receive (ID, DLC, Data field), but once that message is received from the bus and loaded into the CAN buffer and passed to the microcontroller(s) in the ECU, they determine if it is valid or not based on the ID, DLC, Data field, and wether or not the data field values match up with the internal programming logic.

For example, and ECM will only validate a CAN message saying engine stop if it sees other criteria from other messages or inputs telling it that X number of conditions are true. A great example would be in our ECMs with select shift. I could inject a message into the CAN bus telling my ECU to shift the transmission into reverse when going 70 mph. The message will be received, and the ECM will reject it because other conditions required for the program logic to == true are not met. There are multiple redundancies that would need to be defeated in order to do this, and some of those conditions are not data but physical direct line inputs that can't be altered remotely.

Unfortunately you are referencing a document as evidence and citing it out of context. If you actually read through the entire paper and go through the process to broadcast on CAN for the Jeep, it required completely reworking multiple binary files, update commands, etc for the U-connect system and months of reverse engineering the software in a decompiler on top of having to reverse engineer and rewrite code in that module to access the entire vehicles CAN bus and messages. i.e. not simple in any aspect

Only after completely changing the entire CAN register within the microcontroller did they have any remote success in sending messages after connecting to the vehicle. It's not simply gain access and inject random messaging to disrupt the bus. You also fail to recognize that the vehicle did not respond to any of this unless is was going 5-10mph or under. Only then could they get systems to go offline temporarily. They had more of a risk bricking the head unit than the vehicle.



Most ECUs have built in protection to prevent UDS commands unless it is actually in service mode. Did blaring vulnerabilities exist in FCAs U connect software, absolutely. Were they patched, yes. Does this have anything to do with the discussion here? No.

I won't even go into the fact that the software required to do some of this costs thousands of dollars, plus the equipment they used in their study which was even more. I don't think people are going to "sell their plasma" multiple times to buy equipment like this as the authors stated they did in their paper (which IMO says a lot about the quality and funding of this research).






The authors even contradict themselves in the conclusion by saying no modifications were required to perform a remote attack. Completely reworking the firmware of a module to respond to your commands is a modification. The only conclusion one can quickly draw from this paper is to not buy an FCA/Stellantis product, but then again one doesn't need a study to figure that one out.

Sprint has never been the bastion of security either.

Yes, the statements from you above are. Having illogical pervasive and unwarranted distrust and suspicion of others that involves interpreting their motives as malicious is DSM-5 textbook paranoia. No one is out to get you, no one cares enough to hack your car.

You even state there is no money in doing any of this, and criminals won't attempt this because it is too much work. You then pivot to some FISA court/State-level conspiracy. I don't understand what point you are trying to prove here, other than trying to scare people into an emotional response that is not based in reality instead of critically thinking and responding logically to this issue.

This does not help validate your argument. It accomplishes quite the opposite and is low brow. This has nothing to do with a sensible discussion on data privacy. I would urge you to tread lightly with statements like this as the moderators here run a tight ship (as they should). If you want to make comments, discuss politics, or anything other than 4Runner stuff, that is your right, but do it elsewhere.


People need to stop taking emotionally charged material at face value and having knee jerk responses. THINK analytically and slow it down folks.

 

I am not sure if you are confusing me with 2coco, let me assure you I am not. Non-technical part of your responses make no sense to me, as I don't see anything in my posts deserving such hostile response.

For the record, I personally met both Miller and Valasek at a conference where they presented this work, I am very familiar with what and how they accomplished what is documented in the paper I linked. My decision to disconnect DCM on my 4Runner was partially motivated by their work. While possible, it is highly unlikely that I misunderstood infosec aspect of their work as I have done similar research outside of the automotive field. To me, the novelty of their work was successfully exploiting otherwise unaltered Jeep remotely (exploit code was all loaded without access to the vehicle and not via OTA update channels) and not well-known techniques they used to take over various embedded systems to accomplish this. In this way, wide scale adoption of Automotive Grade Linux may not be as beneficial as it would appear - as doing so widens applicability of any discovered exploit. Additionally, Miller and Valasek previously done similar hacks to a Prius, so these issues are not limited to Stellantis products.

While discussion of attacks on vehicles is fascinating to me, you are correct in your point that it is off-topic in this discussion. As such, this will be the last post on this subject from me.

 

What do I need to disconnect to get my 4Runner to stop controlling the weather and those space lasers?

 

That, My friend, will be covered in a completely different thread in the coming future....