Subaru Outback Forums banner

21 - 40 of 63 Posts

·
Registered
2005 Outback 2.0XT, 2003 Audi TTq, 2000 Ducati M750
Joined
·
295 Posts
Maybe a silly comment, but the key in the pic is too far away from the ring compared to when its totally inserted in the ignition, could that be it? Maybe also dumb, but could you install all the parts into the car and try to go through the key-programming sequence separately? I assume you've given those ideas some thought, just some quick input. Overall this is amazing stuff, I've been side-glancing swapping to an automatic WRX gauge cluster for the center tach, I assume programming would be cake but don't know if it would physically fit; that's another thread though.
 

·
Registered
2005 Outback XT 2.5T
Joined
·
180 Posts
Discussion Starter #22
Maybe a silly comment, but the key in the pic is too far away from the ring compared to when its totally inserted in the ignition, could that be it?
Not dumb, and totally accurate. That said, I've tested with the immo antenna "loose" from the actual ignition barrel and therefore the key is "all over the place" relative to the antenna with good success.

Maybe also dumb, but could you install all the parts into the car and try to go through the key-programming sequence separately?
Also not dumb, this is actually the "obvious" solution, but I'm trying to avoid cutting up my wiring harness needlessly until I've identified all of the wires I actually need to tap into for all of this to work as expected.

Also, to be clear, this is ALL academic at this point. I have proven that I can clone the relevant memory on the EEPROMs of the BIU, ECM, and Combination Meter in isolation.

As such, I don't need to do a key-programming sequence, because all of the participants in the immobilizer circuit agree on the 2 keys I currently have programmed into the stock system.

What I'm hoping to do is gain a better understanding of how that handshake takes place. It looks like the BIU reads the key first, and validates with it's memory, then it validates with the ECM over either highspeed CANBUS or the dedicated serial lines. The BIU also verifies with the CM, which MUST happen over slow speed CANBUS, since there doesn't seem to be any other communication line between them.

I'm just hoping to intercept these communications, in hopes to understand it.

The "easy" way, would be to put a sniffer on SSM, and go to the dealer to have them program a new key for me, then I could reverse engineer the commands that get sent. But that'll be for another time ;)

I assume you've given those ideas some thought, just some quick input. Overall this is amazing stuff, I've been side-glancing swapping to an automatic WRX gauge cluster for the center tach, I assume programming would be cake but don't know if it would physically fit; that's another thread though.
Hopefully, what I'm learning would facilitate this.
 

·
Registered
2005 Outback XT 2.5T
Joined
·
180 Posts
Discussion Starter #23
I've identified the transceiver that's used in the BIU to read the key.

It's a Texas Instruments TMS3705 - TMS3705 LF Reader IC | TI.com

In reading through the documentation on creating a sample circuit I stumbled across this snippet.

Code:
The antenna is designed for a free air application. A parallel resistor of 15kOhm should be
connected to the antenna to reduce the quality factor. If the antenna is mounted on a keylock, the
antenna parameters have to be redefined.
This pretty clearly states that the circuitry in the BIU for driving the transceiver operation assumes that the immobilizer antenna is wrapped around a keylock. This no-doubt changes the characteristics of the circuit, and the sensitivity of the antenna.

I verified this by removing the immobilizer antenna completely from the ignition barrel in my car, putting a key "free air" in the immobilizer antenna, and putting another key in the ignition.

In this configuration, I get the same behavior as on my bench P1574.

So, I need to have the antenna around the lock barrel to work.

In fact.. I validated that even further, by taking my bench setup out to the garage, and plugging it into the antenna that's strapped around my ignition barrel, and lo-and-behold, it WORKS!

So.. I need to get a separate ignition, or pull my current one out, or simulate the mass of aluminum for my bench setup.

Notice the lack of the "Security" lamp! :)
 

·
Registered
2005 Outback 2.0XT, 2003 Audi TTq, 2000 Ducati M750
Joined
·
295 Posts
Thanks for the explanations, I'm glad I wasn't totally off-base, this is super-interesting stuff and love that this is by far the most teh hackz I've ever seen done with a car. This gif is way overdue:

 

·
Registered
1999 30th Anniversary Legacy Outback DOHC 2.5L 4EAT, 2008 Impreza WRX 2.5L 5MT, 2008 Impreza Wagon 2.5L 4EAT
Joined
·
1,221 Posts
This is absolutely amazing information and most of it is way over my head but it helps to understand why on the newer cars if you loose all of your key fobs the only option the dealer has is to ship these parts back to Japan to be reprogrammed. No doubt there are some folks out there that are smarter than your average DIY mechanic that can figure this stuff out but I am definitely not one of them.

Thanks for the insight.
 

·
Registered
2005 OBXT Limited, VF37, STI intake, 5MT
Joined
·
1,335 Posts
The required "deafening" resistor would make sense as the large slug of metal in the middle of the transceiver would act like a sort of "frequency sponge" in normal operation.

I wonder if the key-code write commands issued from a SSM3 would actually be some low-speed CANBUS commands and the read/write features are embedded into each module. Since the CANBUS system is essentially a "security though obscurity" system, I could see it being an easy command. Supposedly, the whole "flashing" procedure takes less than 30 mins from drop-off to pick up at a dealer. Normal ECU remaps take less than 20 mins, and that's a physical overwrite...
 

·
Registered
2005 wrx ej20y swap with HKS inlet/maf housing and downpipe
Joined
·
2 Posts
I just want to say thank you for looking into this and making this thread to document your progress, I was actually researching this exact topic last night since had read that the eeproms could be swapped, I thought to myself what if they can be reprogrammed and stumbled upon this thread.


I'm doing an ej20y swapped WRX at the moment and am getting finished with swapping the legacy harnesses over and at the point where I need to address this system to clone my matched immo system to my JDM ecu, already ordered the hardware cant wait for it to show up so i can pull the info off my eeproms and see if I can replicate your process!!!!
 

·
Registered
2005 Outback XT 2.5T
Joined
·
180 Posts
Discussion Starter #29
The required "deafening" resistor would make sense as the large slug of metal in the middle of the transceiver would act like a sort of "frequency sponge" in normal operation.
So, conceptually, I *think* I follow you. I'm a TOTAL n00b RE: electronics. You seem to know your stuff, I'm trying to design a circuit with that Teensy we exchanged messages about, and I've got a few low level hardware things to figure out (like level shifting, and having multiple voltage rails for the same circuit), once I get it roughly sorted, I'd love some feedback, assuming you know this better than I do.

I wonder if the key-code write commands issued from a SSM3 would actually be some low-speed CANBUS commands and the read/write features are embedded into each module. Since the CANBUS system is essentially a "security though obscurity" system, I could see it being an easy command. Supposedly, the whole "flashing" procedure takes less than 30 mins from drop-off to pick up at a dealer. Normal ECU remaps take less than 20 mins, and that's a physical overwrite...
So, I'm not really sure. What I know is that the SSM line goes into the BIU and ECM, but not the CM.

The most obvious way for this to work is that SSM issues the command, the MCU in the BIU and ECM in-system program their EEPROMs, and the BIU sends a low-speed CANBUS command to the CM to in-system program it's EEPROM(s).

Just a guess tho.

That said, reverse engineering the *programming* process is like step 200 in this process. I'd first like to determine the order of operations for a successful, and non-successful key authorization.

At the moment, I'm trying to figure out the nature of the dedicated immo signal between the BIU and ECM. It *looks* like it may be a dedicated serial protocol, since it comes from the pin, to a transistor, then directly to a digital pin of the MCU, on the BIU side anyway.

Fun stuff!
 

·
Registered
2005 Outback XT 2.5T
Joined
·
180 Posts
Discussion Starter #30
I'm doing an ej20y swapped WRX at the moment and am getting finished with swapping the legacy harnesses over and at the point where I need to address this system to clone my matched immo system to my JDM ecu, already ordered the hardware cant wait for it to show up so i can pull the info off my eeproms and see if I can replicate your process!!!!
Glad this research is proving useful to folks, and glad you're adventurous enough to take it on!

So, you purchased the Adafruit FT232H unit, and a chip clip?

I've since developed a better engineered reader/writer with an arduino, which I haven't documented very well AT ALL.

The FT232H unit will work fine, but my supporting docs/scripts are real rough, happy to walk you through it to make it work tho!
 

·
Registered
2005 wrx ej20y swap with HKS inlet/maf housing and downpipe
Joined
·
2 Posts
Glad this research is proving useful to folks, and glad you're adventurous enough to take it on!

So, you purchased the Adafruit FT232H unit, and a chip clip?

I've since developed a better engineered reader/writer with an arduino, which I haven't documented very well AT ALL.

The FT232H unit will work fine, but my supporting docs/scripts are real rough, happy to walk you through it to make it work tho!
I ordered a different eeprom reader/writer and I did get a chip clip, I want to see if another reader/writer will work as well, if it doesn't work I'll be getting the Adafruit FT232H.

Once my reader gets here I'm just gonna attempt to read and put it away for a little while until I'm ready as I still have some tidying of the wiring to take care of, for example I cannot communicate to the ecu via ecuflash through the obd2 port so I gotta trace the wires to see if there is a fault in the communication wiring and Im waiting on my legacy rear harness to get here so I can finish wiring the fuel system and tail lights, once I get that done and make sure my wiring is cimolete I'm gonna dig into the immobilizer.

I will definitely be asking questions if they arise.
 

·
Registered
2005 Outback XT 2.5T
Joined
·
180 Posts
Discussion Starter #32
I discovered this last night, while trying to trace the path for both the immo dedicated comms and SSM between the BIU and the ECM, in an attempt to work out what protocol they're using.

Specifically, I was hoping to find something like a K-Line Serial Link Interface IC, such as the MC33290.

What I found instead is even more interesting. Both comm lines are connected to the ECM through a transistor, and go to the same digital I/O pin of the MCU in the BIU.

I *think* this means two things.

  1. The BIU is using a single digital I/O pin for both comms. Meaning that at any given time, the wrong signal may be sent for either. Maybe they're at different transmission rates?
  2. It appears that the BIU can only *transmit* on both of those channels, and it is not meant to receive. So all SSM comms happen to the ECM
Anyone wanna check my logic? I'm not *at all* confident in my electrical knowledge..

 

Attachments

·
Registered
2005 Outback XT 2.5T
Joined
·
180 Posts
Discussion Starter #33
Making some additional progress.

Now that I have a bench setup which successfully reads the transponder key, I'm digging into setting up an arduino to log the various interactions over these busses.

  • SSM2
  • Dedicated Immobilizer Channel
  • CAN0 - High speed 500kbps
  • CAN1 - Low speed 125k bps (CM/BIU)
  • CAN2 - Low speed 125kbps (BIU, A/C controls)
I am successfully monitoring SSM2 (read only, not write yet), CAN0 and CAN1. Since this will ultimately replace my realtime logging solution, it also has an analog to digital chip with 4 inputs, one of which will be used for fuel pressure monitoring.

I can't seem to figure out the dedicated immobilizer channel tho. It *appears* to be a 10v signal, that is normally high, and drops to ~5v. I'm working on getting a voltage divider setup that will let me monitor it.

Making progress, still many more questions than answers tho!



 

·
Registered
2005 Outback XT 2.5T
Joined
·
180 Posts
Discussion Starter #34
I've made quite a lot of progress figuring out the immobilizer system, but for as many answers as I've gotten, I have generated more questions.

Some of the assumptions/constants I'm working with.
  • The immobilizer system can authenticate 4 keys
  • The BIU, the CM, and the ECM are all involved in authenticating a key and allowing it to start/run the car
  • The BIU is connected to the CM via a single low speed CANBUS
  • The BIU is connected to the ECM with a dedicated communication channel, as well as a high speed CANBUS
  • The transponder key uses a 4D62 chip, operating at 134.x khz, and is labeled as 80-bit
Some things I have discovered.
CANBUS BIU <-> CM Communication
On keysense, the BIU first authenticates a key against the values stored in the BIU. If the key is valid, the BIU will attempt to validate the authentication with the CM.

The BIU and CM transmit immobilizer related data via CAN IDs 16 and 17 where the BIU sends 16, and the CM sends 17. This communication happens each time keysense is cycled, but only happens once then is not repeated.

The communication is the same whether a key is present or not, and whether the key is authorized or not.

The communication *seems* to be a call and response, with the BIU initiating and the CM responding.

The BIU sends a 4 byte packet with ID 16, the first two bytes appear to be reserved, with the last two bytes containing the "payload". The CM sends a 6 byte packet with ID 17, the first two bytes and the fifth byte appear to be reserved, and the final (sixth) byte is a counter which continues after the handshake. Finally bytes 3 & 4 contain the "payload".

An example handshake;
Code:
16 - 0x02 0x01 0x00 0x00
17 - 0x02 0x01 0x00 0x00 0x01 0x(^+1)
16 - 0x02 0x04 0xe3 0x05
16 - 0x02 0x05 0x00 0x00
17 - 0x02 0x04 0xc4 0xad 0x01 0x(^+1)
16 - 0x02 0x06 0x00 0x00
17 - 0x02 0x05 0x00 0x00 0x00 0x(^+1)
The two byte payload is different on each handshake, and does not correlate in any obvious way with any of the keycodes stored in the BIU or ECM EEPROMs.

Dedicated BIU <-> ECM Communication.

The dedicated communication between the BIU and ECM is a 1200 baud standard (start bit, 8 data bits, 1 stop bit, no parity) serial line.

The BIU and ECM do not communicate over the dedicated immobilizer channel until after the ignition has been turned on. The BIU and ECM "handshake" exactly once to initialize the system, and never again. I.E. When battery power is disconnected, and reconnected, once a key has been successfully authenticated, and the ECM and BIU have completed their handshake, the dedicated immobilizer lines remain silent.

The ECM initiates the handshake by sending an 8 byte packet beginning with 0x07, 0x00 in the first two bytes. The rest of the bytes are unique for each handshake.

If the BIU has *not* authenticated a key (which would have happened on keysense, before this dedicated handshake), it will return a 9 byte packet beginning with 0x08, and ending with 0x30, 0x38. The ECM will respond in kind, and the handshake terminates. The handshake will initiate each time the ignition is turned on until a valid key is authenticated.

If the BIU has authenticated a key, it will respond with a 9 byte packet beginning with 0x08, 0x00 in the first two bytes. The rest of the bytes are unique for each handshake.

If the two unique payloads sent by the BIU and the ECM "match" (no idea what determines this yet), the remaining sequence is always the same. The BIU and ECM exchange 3 messages, with matching bytes, presumably completing the handshake.

Some example exchanges;
Successful Handshake:
Code:
0x07 0x00 0x46 0xe2 0xcd 0x98 0xeb 0x82 <-> 0x08 0x00 0x0b 0xf4 0x4c 0x54 0x25 0x00 0xcc
0x07 0x02 0x00 0x00 0x00 0x00 0x00 0x09 <-> 0x08 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x0a
0x07 0x09 0x00 0x00 0x00 0x00 0x00 0x10 <-> 0x08 0x09 0x00 0x00 0x00 0x00 0x00 0x00 0x11
0x07 0x02 0x00 0x00 0x00 0x00 0x00 0x09 <-> 0x08 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x0a
0x07 0x09 0x00 0x00 0x00 0x00 0x00 0x10 <-> 0x08 0x09 0x00 0x00 0x00 0x00 0x00 0x00 0x11
Handshake where the BIU rejects the initialization, due to an invalid key, or because the keycodes in the ECM and BIU do not match.
Code:
0x07 0x00 0xa2 0x67 0x75 0x0c 0x7a 0x0b <-> 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x30 0x38
0x07 0x01 0x00 0x00 0x00 0x00 0x00 0x08 <-> 0x08 0x01 0x00 0x00 0x00 0x00 0x00 0x30 0x39
Conclusions/Assertions
Stored and transmitted values
Given that the transponder chip in the key is an 80bit chip, the two byte sequences stored in the ECM and BIU must not be actual key values, but rather a hash or checksum used to validate the keys when they have been read.

Also, I don't see adequate storage space in both EEPROMs for 4 full "pairs" of two byte sequences, so it's also possible that there's even more munging going on.

Two things stand out about immobilizer related communications between the various computers.
  1. They are randomized
  2. The payload size is different for each (2 bytes for BIU<->CM, 5-6 bytes for BIU<->ECM)
This leads me to believe that the actual key codes are not transmitted via any of these communications, but rather a hash or checksum is handed back and forth.

I'm guessing that the full 80bit (10 bytes) value from the key is probably salted with some value (a checksum, or the current timer "tick" between CM and BIU?) then turned into a 2 byte hash (CRC?) before being transmitted between the various computers.

ECM "kill" instruction
I have not yet identified if there are any immobilizer related communications over the BIU<->ECM highspeed CANBUS yet. I am assuming that if any of the previous authentication steps fail, a message over the highspeed CANBUS is used to prevent the engine from starting, or running.

I believe this is the case because the dedicated immobilizer line remains completely quiet after the first handshake.

Next steps
I am now trying to find a way to actually read the transponder chip in the key. I believe that the values on that chip will literally be the "key" to whatever encryption scheme is being used, and without those values I won't be able to make progress.

I've been able to "snoop" the radio signal using a Proxmark3 RFID research device, but I haven't had any luck decoding that trace just yet.

I'm also going to try to determine which, if any of the highspeed CANBUS IDs are immobilizer related.
 

·
Registered
2000 & 2002 Outback Wagon EJ251/Auto + 2004 Outback LL Bean EZ30/Auto + 1996 Legacy Outback Wagon EJ22/5sp + 2008 Outback Wagon EJ253/Auto + 2004 Legacy Sedan 35th Anniv. EJ251/Auto (not OB) + 2005 O
Joined
·
131 Posts
@Ryan J. Geyer ... An incredible thread. Wish I was more up to speed on the electronics side of things. I just bought an 05 OBXT for cheap, but the previous owner had used the instrument cluster out of it to fix another car after it started running bad. I couldn't see any metal in the oil, so I bought it. I didn't realize what I was getting into. and so....... Obviously the immobilizer has it "immobilized".

Forgive my ignorance, but if I buy the cluster, BIU, and ECM from a donor car, will a locksmith be able to program the keys that fit my car now to the new parts? Or will I need to get the lock cylinders (and keys if available) from the donor car as well? I've searched the forum but can't seem to find the relevant info on anything other than "cloning" my original cluster. The nearest Subaru dealer is a long ways away and I would have to tow it back and forth to get it fixed as they don't do mobile repairs. It is looking increasingly like that is what I will have to do, but you might be my last chance at fixing this thing without that hassle.

Please help. Thanks.
 

·
Registered
2005 Outback XT 2.5T
Joined
·
180 Posts
Discussion Starter #38
Forgive my ignorance, but if I buy the cluster, BIU, and ECM from a donor car, will a locksmith be able to program the keys that fit my car now to the new parts? Or will I need to get the lock cylinders (and keys if available) from the donor car as well? I've searched the forum but can't seem to find the relevant info on anything other than "cloning" my original cluster. The nearest Subaru dealer is a long ways away and I would have to tow it back and forth to get it fixed as they don't do mobile repairs. It is looking increasingly like that is what I will have to do, but you might be my last chance at fixing this thing without that hassle.

Please help. Thanks.
You should ask around the locksmiths that are in your area. They will have varying methods for getting new keys to work with your car. The most common is to actually clone a working key onto a new one, so all they need is one piece of equipment that reads that original working key, and write the code onto a blank writeable key.

Some locksmiths *may* have the equipment to perform the key programming in the car, in which case you'd only need a replacement BIU, since the official Subaru select monitor programming method overwrites the BIU, the ECM, and the cluster to match the key(s) you have available.

So far, my research has gotten me as far as being able to clone all three of those components, and identify where the key codes are in the BIU and the ECM. The cluster, sadly is still a bit of a mystery. The same value(s) are not stored in the cluster, at least not without some obfuscation. When/if I figure that part out, I'll post it here and you'd be able to read the key codes from either the BIU or the ECM, transform them to the correct form (hash, or something, still haven't figured it out) and write them into the cluster.

So..

Long story short, your best option is buy a new cluster, and take it to the dealership. It's possible, but unlikely that a local locksmith would be able to do this as well.

If you're going to try to resolve it yourself, you're going to need the whole immobilizer suite. BIU, ECM, Cluster, and key(s). This can get pricy in a hurry.
 

·
Registered
Joined
·
10 Posts
Introduction:
This thread will be an attempt to distill the work that I've done to understand the immobilizer circuit in my 2005 OBXT.

My initial goal was to "clone" the ECM so that I could run either my stock ECM, or a JDM ECM which has the necessary hardware to run dual AVCS which my engine swap will require.

As I got deeper into it, I got more interested in actually understanding the entire system, and I'm well on my way.

You can read all of the discovery in my engine swap thread, from post 39, until about post 73. Of course, the actual findings will be documented here.

Organization of this thread:
The first five posts will contain the latest information about what I have discovered. They will be organized as such;

  1. This post, an introduction and overview
  2. Details on about the ECM
  3. Details about the BIU
  4. Details about the Combination Meter
  5. Placeholder for TBD content
I will regularly post new replies indicating an update, or just for discussion (please provide feedback, and ask questions!). However, the first 5 responses will always be the canonical, and up-to-date "truth" as discovered by my work.

Immobilizer system design and operation:
In order to effectively manipulate the immobilizer system, it's important to understand how it is designed and how it operates.

While actual details of the inner workings are hard to find, the factory service manual provides a fairly detailed, tho high level, description of the system.



From this, we learn that the BIU, the ECM, and the Combination Meter (gauge cluster) are all used in authenticating a transponder key. This is why when any one of these computers is changed, the key registration process must be completed, since the three systems will no longer be synchronized.

There are two communications between the BIU and the ECM. A high-speed (500Kbps) CAN network, and a dedicated immobilizer line.

There is one communication channel between the BIU and the Combination Meter. A low-speed (125Kbps) CAN network.

This is also shown in the factory service manual.



Answered Questions:
Remaining Unanswered Questions:
  • How to clone the combination meter EEPROM?
  • What size (in bytes) is a key code?
  • How can a new key code be added?
  • Are the key codes encrypted in some way?
  • Is there a "shared secret" which is used between all three computers when authenticating a key? An encryption key perhaps?
  • What protocol is the dedicated immobilizer line between the ECM and BIU?
  • How can a transponder key be "read" to get it's unique code?
  • Where is the key count stored in the ECM EEPROM?
  • Where would a 4th key code be stored in the ECM EEPROM?
  • What low speed CAN message(s) are sent from the BIU to the combination meter?
  • What dedicated message is sent from the BIU to the ECM?
  • What additional high speed CAN message(s) are sent from the BIU to the ECM?
  • What is the exact data organization of the BIU EEPROM?
  • Is it possible to enable/disable the immobilizer check in the BIU?
  • Is it possible to enable/disable OBD-II Mode 9 responses from a JDM ECU?
  • What command sequence does the SSM tool use to perform the key programming ritual?
  • What is the order of operations for validating a key?
    • Does it occur on keysense, on ignition on?
    • Which computer does the BIU validate with first, the Combination Meter, or the ECM?
    • Does the ECM validation happen over the dedicated immo communication line(s) as well as high speed CAN?
Common Tools:
In the process of reverse engineering this system, I used several tools, with varying effectiveness.

EEPROM Programming tools:
Reveltronics REVELPROG-IS.


This can read and write the BIU and ECM EEPROMs with proper settings. However, it can not read or write the ECM EEPROM in system, it must be desoldered from the board for this programmer to access it.

Adafruit FT232H
This can read and write the ECM EEPROM, both in system, and when it is desoldered from the ECM.

It can probably be made to read and write the BIU EEPROM, but I'm still working on code that properly supports this.

SOIC8 IC Test Clip
Not a programmer, per-say, but a necessary tool for reading and programming the EEPROM chips without desoldering them from the computer(s) they reside in.

The above link will likely die, and isn't the definitive source for shopping for such things. What you're looking for is something that looks like this.

hello my friend can you help me I have Subaru legacy 2015 problem security system . thanks
 
21 - 40 of 63 Posts
Top