[Ryan J. Geyer]

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:

• How to clone the ECM EEPROM?
• How to clone the BIU EEPROM?
• Rough data organization of the BIU EEPROM.

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.

 

[Ryan J. Geyer]

How to clone:
The ECM stores all of it's immobilizer data on a single EEPROM.

The EEPROM is labeled as L56R, and is a 2056Kbit microwire serial EEPROM, with a 16 bit organization, resulting in 128 Byte capacity.

Here is a datasheet of a compatible EEPROM. A more common part number would be 93L56R.

In order to clone the ECM (with respect to the immobilizer) you'll need to read this EEPROM from your stock ECM, then write the contents to whatever ECM you wish to use in it's place.

You can use the Revelprog IS introduced in the "common tools" section of the first post in this thread to read/write the EEPROM, however you'll need to desolder the EEPROM from the ECM in order to do so.

The recommended method is to use the FT232H board, and the SOIC8 test clip to read and write the EEPROM(s) while they're still in-system on the ECM(s). This will be the method discussed below.

EEPROM Location:
When looking at the ECM, face up, with the connectors at the bottom, you'll find the EEPROM at the top left corner of the PCB.

EEPROM contents:
Here is the contents of a stock, USDM EEPROM with all the immobilizer data in it. I've sanitized this data so that it doesn't show my actual key codes, or VIN.

           0000  0001  0002  0003  0004  0005  0006  0007  0008  0009  000a  000b  000c  000d  000e  000f
0000000    cdab  0000  01ef  0000  4523  0000  cdab  0000  01ef  0000  4523  0000  cdab  0000  01ef  0000
0000010    4523  0000  0001  0000  0001  0000  0001  0000  5334  4234  3650  4337  3531  ff34  ffff  ffff
0000020    00ff  5334  4234  3650  4337  3531  ff34  ffff  ffff  00ff  5334  4234  3650  4337  3531  ff34
0000030    ffff  ffff  00ff  ffff  ffff  ffff  0300  0000  0080  0080  0080  0080  0080  0080  0080  0080
0000040    0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080
0000050    0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080
0000060    0080  0080  0080  0080  09ae  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080
0000070    0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0080  0000  0000  0000  0000  0000

Here's what we observe.

• All crucial values are repeated 3x.
  • Key #1 is found at addresses 0000, 0006, and 000c
  • Key #2 is found at addresses 0002, 0008, and 000e
  • Key #3 is found at addresses 0004, 000a, and 0010
  • The VIN number is found in address ranges 0018 through 001f (and half of 0020), 0021 through 0028 (and half of 0029), and 002a through 0031 (and half of 0032).
• I believe that 0036 contains the key count, which is currently 3
• 0064 contains an interesting value. I'm not sure what it is, but could be a checksum or encryption key.

Flashing Software:
I've written some python scripts for reading and writing the EEPROM on the ECM, using the Adafruit FT323H breakout board.

It needs significantly more documentation, but you can find it here.

Wiring Diagram:
You'll need to connect the FT232H breakout board to your SOIC8 test clip thusly.

FT232H <-> CLIP
+5v        8
Gnd        5
D0         2
D1         3
D2         4
D3         1

Reading:
Once you've got everything hooked up correctly, connect the SOIC8 test clip to the EEPROM in your stock ECM, then run..

python eeprom-read.py

That will produce a file named 93x56-dump-<timestamp>.bin which should be the contents of your EEPROM.

Writing:
Then, you can swap the SOIC8 test clip to the EEPROM of the ECM you want to clone to, and run..

python eeprom-write.py 93x56-dump-<timstamp>.bin

You may want to verify the the successful write by re-reading the EEPROM, and comparing the files.

Communication with BIU:
Unanswered

CAN:
Unanswered

Dedicated line:
Unanswered

 

[jwrezz]

Subscribing!

Sent from my V35-ThinQ using Tapatalk

 

[Ryan J. Geyer]

Updated the overview post to include some detail on the overall system, and some additional required tools.

Added a preliminary ECM post, likely to get heavily edited with time.

@l88m22vette. It looks like the tool you got doesn't include anything we can easily reuse, sadly. Did it claim to support Subarus? I didn't see any mention of that in the docs. You'll have to buy the FT232H breakout board, and a test clip.

Let me know if you need more info (probably, I got distracted while writing this and rushed it a bit toward the end).

 

[l88m22vette]

I had seen that Subaru was mentioned, I've heard about the CTK100 mentioned a few times as working on the OBXT but of course had to try another instead

I know next to nothing about the actual hardware and process for building and programming something like this, and I don't know hex in any capacity. I'll get the SOIC8 so I don't have to mess with soldiering, but could you give a quick parts list and how-to? I do have a teensy 2.0 and powered USB cable, if that helps.

 

[l88m22vette]

Well, its time to bump this thread. @Ryan J. Geyer and I have been working on getting this to work for my setup, he's answered a hundred of my questions and had to basically help someone who knew almost nothing about what it took to make this happen, I just copied what he did so I am completely grateful for all of this. I knew how to solder, I had a Teensy 2.0 sitting around from an older project that never happened, and I had to buy the SOIC8 clip and jumper wires; were I to do it again I'd get the Teensy with the solderless pins, or just get an Arduino Uno (which saves like 1 step). Here is what I, a total electronics noob, had to do to build a clip to read and write the immobilizer chip on our ECU.

Ryan provided me with this schematic, it is simplified to without the clip but gives the basic idea. There is some prep work to do once you have all the parts, with the biggest being that you need to make sure all the wires, pins, and clip contacts are aligned correctly. One thing to note, I used brown instead of black for the ground, for no reason other that I ruined the black jumper I had; my camera also kind of sucks so I'm sorry if the pics are a bit blurry.

Here is the immo chip, IC405, which I put a yellow dot of paint on. Notice the small white triangle (arrow) on the upper left pin, that is the "1" pin. Pins 1-5 and 8 are used, 5 is power and 8 is ground.

V
1 | | 5
2 | | 6
3 | | 7
4 | | 8

Thanks to Ryan J. Geyer for this pic, the basic overview of connecting a Teensy 2.0 to the immo chip pins.

First I got the soldering stuff I needed - torch w/tip, solder, flux, and I used the piece of wire to apply a tiny bit of flux so I didn't coat the Teensy when it melted. I used the tweezers to bend the pins a bit so that when they heated up the flux flowed into the hole on the Teensy board, I used the tip of the soldering torch and just dabbed a bit of solder in there and it got sucked right in. I then trimmed off the excess pin ends and cleaned up with some rubbing alcohol and a cotton swab.

Here is the SOIC8 clip, that plugs onto a SOIC board, then the jumper wires soldered to the Teensy attach to the other side. The red wire on the clip's ribbon wire is pin 1, that orients to pin 1 on the SOIC board and the blue wire on the Teensy. Once everything was connected I had to plug in the USB cable and verify the Teensy, then I used Ryan's instructions* to do a test-read from the JDM Spec-B ECU that's left over from my engine swap. Well, wouldn't you know it, it worked! The plan is to read my USDM ECU's immo code and try to write it to the EJ20X ECU I was using last spring, as long as that works I'll be able to swap between ECUs without a locksmith and take full advantage of dual-AVCS...I'll update if/when that's a success.

*I'll wait for Ryan to post up all the specifics and links, he did the real work so I'll defer to the OP to provide all the juicy details :7:

 

[l88m22vette]

Good news bump, it worked, the car runs! :jester:

 

[dennisinsc]

You have waaaaaay more patience than I do.

 

[l88m22vette]

Nope, just cheap and nerdy!

 

[joe r]

So can we purchase this from you and make extra keys for our cars?


joe r

 

[l88m22vette]

It doesn't program keys, it just clones the immo code to the ECU so the entire CAN system doesn't need to be reflashed. The body integrated unit (BIU) is the center of the system and handles key coding, when the immo is reprogrammed the steering angle sensor reads the RFID code on the key and logs that key identity; the code on the ECU's IC405 chip is also part of that check. When you insert a key the sensor compares it to the programmed codes, if the key and all the other parts of the CAN system check out the security light on the dash stops flashing and the system is ready to start the car.

 

[joe r]

So this would turn off the coded key feature and I could use any cut key then?


joe r

 

[l88m22vette]

No, it has absolutely no control of or effect on keys or key programming, and it doesn't alter the immobilizer system in any way, it only changes the code on the ECU's chip.

 

[Ryan J. Geyer]

It's been a while since I posted, but I have made a few good breakthroughs.

I need to update the post(s) above, but it seems that there is a 43200 minute limit on editing posts? I don't suppose a moderator could tweak that for me?

At any rate, I have successfully cloned the combination meter, in addition to the body integration unit, and the engine control module. I also have that full set of computers setup and talking to one another on my bench, so I can start to really track all of the comms between them in an effort to understand it a bit better.

I've also designed a single circuit, based on an arduino nano which will in-system read and write all of the EEPROMs involved in the immobilizer system. You can find it here. It needs some more documentation and updates, which I'll get to next week hopefully.

More to come when I can edit my own posts, otherwise I may have to break this out to some other place, like reviving my blog.

 

[RoughDiamond]

@eagleeye, this man needs assistance!
@Ryan J. Geyer this is great stuff, as always. Any thoughts on a CANBUS interface for read/write? I figured the actual initialization sequence might be harder to crack without an SSM3 to eavesdrop on the comm lines...

 

[eagleeye]

I need to update the post(s) above, but it seems that there is a 43200 minute limit on editing posts? I don't suppose a moderator could tweak that for me?
.

30 day cut off for regular members,

which seems to be designed to create stability, and I don't think that can be fixed.

although moderators can alter older posts if "need be", ... I mean like you are freaking out about something you posted 30 days ago.

 

[Ryan J. Geyer]

30 day cut off for regular members,

which seems to be designed to create stability, and I don't think that can be fixed.

although moderators can alter older posts if "need be", ... I mean like you are freaking out about something you posted 30 days ago.

Thanks for the explanation.

I'm not freaking out exactly, just assumed I'd be able to go back and edit my posts so that this was more like a document/sticky. I have like 3 posts after my original that contain no real content, because I was going to build them out.

Not a *huge* deal, I can publish it on a website and link back here if it's a hassle to tweak the thread

 

[eagleeye]

Thanks for the explanation.

I'm not freaking out exactly, just assumed I'd be able to go back and edit my posts so that this was more like a document/sticky. I have like 3 posts after my original that contain no real content, because I was going to build them out.

Not a *huge* deal, I can publish it on a website and link back here if it's a hassle to tweak the thread

now they are gone from view, ...so not screen hogging a otherwise insightful thread.

 

[Ryan J. Geyer]

@Ryan J. Geyer this is great stuff, as always. Any thoughts on a CANBUS interface for read/write? I figured the actual initialization sequence might be harder to crack without an SSM3 to eavesdrop on the comm lines...

Bit of a spoiler alert, but.. Yes.. I've got a Teensy 3.6 which has two CAN controllers on it, and I'm going to add a 3rd so I can monitor all of the CAN lines. It will ultimately replace the Raspberry Pi solution I started to build.

I started to do my research. (https://forum.pjrc.com/threads/55282-Multi-network-and-sensor-automotive-datalogging).

What I didn't mention in that thread is that I'll also be monitoring the dedicated immobilizer digital signals between the BIU and ECM, since the Teensy has ample I/O for it.

Just gotta get my bench setup working completely!

 

[Ryan J. Geyer]

I have successfully cloned all 3 portions of the immobilizer system. The BIU, ECM, and CM (Combination Meter, or gauge cluster). I know this, because if I put all three foreign modules into my car, and put in the key, there are no IMMO related codes, and the security lamp is not lit.

I'm trying to reproduce the whole thing on my test bench so that I can do some more digging, like monitoring all of the CANBUS networks, and the dedicated IMMO serial connection between the BIU and the ECM.

I have it totally wired out, and it appears to be working almost 100%. EXCEPT, I can't seem to get the BIU to successfully communicate with the transponder key, and I simply can not figure out why. I get a P1574 (key communication failure) even though everything else seems correct.

I really need to get past this hurdle in order to be able to "record" a successful handshake, but I'm struggling with it.

My best guess at the moment is either that the circuit is tuned to a certain wire length for the antenna, and/or the actual orientation of the key to the immo antenna is VERY precise.

That said some tests in the car (where it works) reveal that I can move the immo antenna around quite a lot and get a successful result.