Hey guys, I'm new here, so sorry if this post would be better fit under a different forum. Just let me know and I can repost it elsewhere. I've got a real doozy here, so get ready for a story. I'll tell you guys exactly as it happened so there's good documentation of this specific failure; anyone not interested in reading a book, the TL;DR will cover it in less detail. TL;DR: An improperly remanufactured HMI has managed to write its original vehicle's immobilizer identifier to 4 other modules on this 2014 Cadillac SRX Luxury 3.6L V6 FLX FLEX FI, and according to numerous sources it will only continue to spread. Once it reaches a module that is integral to the immobilizer system, the vehicle will become a no-start. I need to find a way to either manually put the correct identifiers back into these 4 modules or find a way to properly virginize them. I'm planning to buy the Xhorse Multi-Prog programmer to attempt this; if any of you have other tools you recommend over this one, please let me know. I'm completely new to this, so basically any tips you guys have are much appreciated. Has anyone here ever run into this issue before? First off, I'm a professional mechanic. I specialize in electrical diagnostics and get a very high volume of vehicles, therefore I get the chance to see some real weird shit; this is no exception. It started as a simple parasitic draw on a 2014 Cadillac SRX Luxury 3.6L V6 FLX FLEX FI. I diagnosed it and found the Human Machine Interface Control Module was causing the parasitic draw. Once the part was delivered, I installed it, programmed it using SPS2 and an MDI2, ran it through the set up procedure using SPS2 and an MDI2, then scanned it for DTCs. I found DTC B3902:00 was set in the HMI, indicating the remanufactured unit I had installed was not fully virginized during remanufacturing. After cycling the key a few times, I rescanned the vehicle and found that DTC B3902 had now been set in the Instrument Panel Cluster, Electronic Brake Control Module, and the Climate Control module, as well as the HMI. This DTC is for Incorrect Immobilizer Identifier Received. General Motors official work-flow for this fault is to reprogram the module, then run the vehicle through an immobilizer relearn; if the DTC still returns, then the module must be replaced. I followed these instructions, but found that the DTC was still active. Once I saw this, I called AC Delco's Diagnostic Hotline. I found that this exact issue has been documented, and never has a happy ending. In very rare cases on Global-A vehicles, when a used module is installed into a new vehicle while still containing the previous vehicle's security identifiers, the replacement modules' incorrect security identifiers can propagate, being rewritten to other modules on the networks. ACDelco has only seen this happen a couple dozen times, but it is a confirmed issue. In every case, all of the vehicles modules eventually relearned the incorrect security identifier, and the only fix is to replace every affected module at once, i.e. every module connected to the gateway. Once the incorrect identifier spreads to any of the modules integral to the antitheft system, the vehicle will also no longer be able to start. I was told to immediately remove the HMI from the vehicle to prevent further modules from being affected, to install a brand new one, and then after programming the HMI, to perform another immobilizer relearn on the vehicle. Thankfully, in my case it had only spread to 3 others so far. I ordered a properly remanufactured HMI through GM and followed their instructions, but found the B3902 was still set in the IPC, EBCM, and HVAC. The only solution I was given by AC Delco was to replace all 3 modules with new ones. I decided to take the vehicle for a test drive to see if any new DTCs would set; rather than finding new DTCs, I found that the Inflatable Restraint Sensing and Diagnostic Module was now setting B3902 as well. No other DTCs are present in the vehicle. The incorrect security identifier is still managing to continue propagation to other modules despite the HMI being replaced; absolute worst case scenario. I reached out to a couple of my contacts that deal with programming issues on a large scale, and they also said they have seen this happen to Global-A vehicles. Much like AC Delco's reports, every time they had seen this issue, all modules in-network with the Gateway had already been affected. One of my contacts said that he had fixed these issues in the past by removing the MCUs from each module's PCB's, virginizing them, reinstalling them, then reprogramming all modules on the vehicle. Sadly he said that these jobs were all far too time consuming and not something he would be interested in ever touching again, so im still on my own. I know all of this sounds crazy if you've never heard of it happening before, but I've had numerous independent sources confirm it as a known, extremely rare failure. Every single one agreed that it shouldn't be possible, but it is. My next step from what I can tell needs to be purchasing a programmer that will let me manually edit the bin file. From there I seem to have 3 options that I can think of. Figure out what hexadecimal bytes contain the immobilizer/environment identifier, determine the vehicle's correct identifier from an unaffected module, and write the correct data into the affected modules. Find a way to properly virginize the modules, likely requiring me to purchase the virgin .bin files and write them to the affected modules. The obvious one that I'm trying to avoid, replace all affected modules. If anyone here can come up with better options, I'm open to them. I'm planning to buy the Xhorse Multi-Prog Programmer here shortly so I can get started with this soon; if anyone here has a better tool they recommend over this, please let me know. Once I get the bin files I'll be sure to post them here. Has anyone here personally dealt with Global A B3902 propagation like this, or successfully corrected/virginized affected IPC, EBCM, HVAC, or SDM modules?

Hi, "incorrect immobiliser identifier" you will get this DTC whenever you install a used module that's on the GM vehicle's secured system, for example, a used BCM, IPC, EBCM, etc. This happens because the used module's immobiliser security code differs from the vehicle you're repairing. To program the correct immobiliser identifier code for the vehicle you're repairing onto a used module, you need to use GM SPS or DPS to remove and reprogram the vehicle keys. Also, to remove and program the vehicle keys, all modules on the GM vehicle's secured system must have the same PIN and VIN stored in them. More information is listed in this article.

Incorrect Immobilizer Identifier Propagating to All Nodes In-Network With the Gateway

Hot

Followers

Solved by Troy

Thursday at 01:45 PM2 days

Go to solution

Unhappy_Node

+Contributor

GM Service Provider

15 posts
4 Badges
3 Reputation

Joined:
2 days ago

My Feedbacks

0% My Rating

Unhappy_Node's Rank Progress

Current Rank

Lv. 2

Next Rank

109 / 185

View All 4 Badges

Rare

15 hours ago15 hr

Author
Contributor

#26

Well, ACDelco has been outdone, once again. I followed Troy's article on how to correct the B3902, and they have since all cleared and not returned.

In SPS2, I first ran the BCM Set-Up procedure. It has you do all of the usual stuff, such as reprogramming the TPMS sensors, etc.

After that I ran the Immobilizer Relearn procedure. Once it was complete, I cleared all DTCs and rescanned to find none had returned. I test drove the vehicle for about 20 minutes, cycled the key a few times, and so far not a single DTC has returned.

This solution is honestly pretty interesting. It shows that ACDelco's description of the failure is analogous, at best. They described the failure as the used module propagating its incorrect security immobilizer into the other modules on the network, but I'd argue that's not the case. The fact that Performing a BCM Set-Up procedure prior to the Immobilizer Relearn changed the Immobilizer relearn procedures outcome, to me, could only really mean one thing: the used module somehow corrupted a piece of the BCMs NVM, which was causing the Identifier challenges sent out by the BCM to be corrupted. Again, this is only based on assumption, but if the BCM Set-Up procedure were to clear the particular part of the NVM that was corrupted by the used module, this hypothesis would fit rather well. Taking it a step further, I'd be interested to find out why this failure occurs so rarely. Could it be that it only occurs if the used module's immobilizer identifier is mostly identical to the identifier of the vehicle it is being installed into? If all but a few bits of the used modules identifier were matching and the BCMs checksum falsely verified it, it could allow the incorrect immobilizer identifier to pass into the BCMs ram, which is then mirrored to the BCMs NVM during key-off timeout. This also just so happens to match what my contacts were describing in regard to the "propagation" spreading further only during key cycles, since that is when the BCM sends out these identifier challenges and reviews each module's response. The issue may very well be caused by the BCMs corruption, not corruption of the Nodes setting the B3902. This is really-Y making me wish I got a dump of the BCM before running these procedures.

Alright, now this is actually pretty funny. Before posting this update, I decided to research if what I just described is even possible, or if I was just going off my rocker. Funny enough, it absolutely is possible. I went down a bit of a rabbit hole (hence the late update) and was able to find documentation of this exact checksum failure. I sadly wasn't able to find any information saying that these specific erroneous packets can cause NVM corruption, but generally speaking, bad can-bus data screwing up modules is far from an abnormality. I included the PDF I found describing this checksum failure, but incase you guys dont wanna download and read through it all, here's the important stuff:

"Classical CAN has a known Cyclic Redundancy Check (CRC) weakness. More specifically, in Classical CAN a pair of bit errors in a frame generating/eliminating stuff conditions may reduce the Hamming Distance (HD) to 2. This means that a receiving node may accept a frame and give a positive acknowledge even if this frame has two bit flips. This case was first reported in a paper by Bosch for the ISO task force on CAN (1989) and first published in the SAE paper 900699 by Unruh et al. It is also explained in 1999, “Multi-Bit Error Vulnerabilities in the Controller Area Network Protocol”, a thesis paper by Eushian Tran at the Carnegie Mellon University"

"Root cause for the CRC issue

The receiving node compares the calculated and received CRC bit sequence to decide if a frame can be accepted or not, i.e. if it was received correctly or not. The CRC result is reliable if the CRC-algorithm is applied exactly to the same number of bits (frame length) on sender and receiver side. In this case, the term Hamming Distance can be used. A Hamming Distance of n expresses that frames with up to n-1 falsified bits are detected by the CRC-algorithm as erroneous. The CRC algorithm may or may not detect frames with n or more falsified bits as erroneous. If the receiving node applies the CRC-algorithm to a different number of bits (less or more) than the transmitting node, the result of the CRC-algorithm has to be regarded as corrupted. This means that a corrupted frame could lead to a positive CRC result too. it is possible that the frame format checking at the end of the frame (CRC delimiter and later) does not detect this shift, because the shift is very small compared to the duration of an arbitration phase bit time."

can-newsletter.pdf