Immobilizer Reverse Engineering (2005 OBXT, probably other year/models)
121 - 140 of 180 Posts
I've given up and ordered a programmer, additionally one of my friends has an outback of the same generation and is willing to let me pull the rom info from his, I'm going to put together a scanner to read key codes and then scoop his info, and assuming I can successfully reprogram mine, I should be able to get enough data to clear up some of ambiguous information about how data is stored in the ROMs. Unfortunately I don't have any way of monitoring the data lines real time so I can't find out what commands are sent for key programming. I'll check back in with my findings in a week or two!
I read through the entire thread, and I think I understand just enough to know what questions I need to ask to try this on my out-of-service subaru, maybe not. I just replaced the valve cover gasket on my toyota matrix so I'm feeling ready to start fixing the Soobie.
I've got a 2008 Outback Limited 2.5L 4AT (EJ253)
I'm trying to clone my ECM immobilizer data to swap my existing ECM with a salvaged one I got (I suspect the ghost I've been chasing is actually a bad ECM).
My existing ECM has an S93C86 | BD VG2 | 5520 EEPROM
The replacement has an S93C86 | BD VGX | 2201 EEPROM
I have an Arduino Uno I use to unbrick 3D printers, I found Ryan's sketch of the Uno Circuit
github.com
and I have it wired up with breadboard pins to an SOIC8 clip so I can move it between my two boards
and I found the Hexdump.exe
QUESTION ONE: Is the Uno drawing referenced above the correct pin arrangement still?
QUESTION TWO: Is the Subaru_immo sketch working as is for my ECM EEPROM or will I need to change anything?
QUESTION THREE: How the heck do you use the sketch to read or write to the EEPROM chip?
QUESTION FOUR: How the heck do you use the hexdump exe?
With my 3d printers I compile and upload the sketch, the UNO is used for in circuit serial programming of boards with nothing stored in EEPROM so not exactly the same as here... any advice would be super welcome, even willing to pay a bit if someone could walk me through it live.
I've got a 2008 Outback Limited 2.5L 4AT (EJ253)
I'm trying to clone my ECM immobilizer data to swap my existing ECM with a salvaged one I got (I suspect the ghost I've been chasing is actually a bad ECM).
My existing ECM has an S93C86 | BD VG2 | 5520 EEPROM
The replacement has an S93C86 | BD VGX | 2201 EEPROM
I have an Arduino Uno I use to unbrick 3D printers, I found Ryan's sketch of the Uno Circuit
sketch_subaru_immo/Uno_bb.png at b2869735725af325cfd06e8dcd1a7fa0109d8f10 · rgeyer/sketch_subaru_immo
An Arduino sketch for reading and writing EEPROMs that are part of a Subaru Immobilizer system. - sketch_subaru_immo/Uno_bb.png at b2869735725af325cfd06e8dcd1a7fa0109d8f10 · rgeyer/sketch_subaru_immo
github.com
and I have it wired up with breadboard pins to an SOIC8 clip so I can move it between my two boards
and I found the Hexdump.exe
QUESTION ONE: Is the Uno drawing referenced above the correct pin arrangement still?
QUESTION TWO: Is the Subaru_immo sketch working as is for my ECM EEPROM or will I need to change anything?
QUESTION THREE: How the heck do you use the sketch to read or write to the EEPROM chip?
QUESTION FOUR: How the heck do you use the hexdump exe?
With my 3d printers I compile and upload the sketch, the UNO is used for in circuit serial programming of boards with nothing stored in EEPROM so not exactly the same as here... any advice would be super welcome, even willing to pay a bit if someone could walk me through it live.
Hahaha. Shoot me.
I got the programmer, got the immobilizer code.
But it still won't work. Seems like you need a registered key to program new keys?!
![507378]()
![507379]()
![507380]()
UPDATE:
Ok.So Ive confirmed that you need a valid key to program new keys, you can't start from scratch.
HOWEVER. I have learned something important. Bytes 38-39/78-79 (counting up from 00) are the hexadecimal representation of your Security ID. I changed mine to 3039 and the code 12345 works! So, here is my plan now: (and at this point its just stubbornness, Im past the point where it would have been easier to tow to the dealership and pay for all new parts)
Give a friend with a running car some beer.
Rip all his EEPROM data.
Use his programming code to program one of my keys to his car.
Rip all his EEPROM data again, flash the original EEPROM data back.
Burn his EEPROM data to my components.
Use the key I programmed into his car to program the other keys for my car.
I should have a much better idea of how the rest of the data on the EEPROMs is formatted at that point.
What I would really like to do is get my hands on a brand new, unprogrammed set of components and look at whats on their EEPROMs. the SSM can tell that a unit has been previously programmed and wont let you remarry used components.
I got the programmer, got the immobilizer code.
But it still won't work. Seems like you need a registered key to program new keys?!
UPDATE:
Ok.So Ive confirmed that you need a valid key to program new keys, you can't start from scratch.
HOWEVER. I have learned something important. Bytes 38-39/78-79 (counting up from 00) are the hexadecimal representation of your Security ID. I changed mine to 3039 and the code 12345 works! So, here is my plan now: (and at this point its just stubbornness, Im past the point where it would have been easier to tow to the dealership and pay for all new parts)
Give a friend with a running car some beer.
Rip all his EEPROM data.
Use his programming code to program one of my keys to his car.
Rip all his EEPROM data again, flash the original EEPROM data back.
Burn his EEPROM data to my components.
Use the key I programmed into his car to program the other keys for my car.
I should have a much better idea of how the rest of the data on the EEPROMs is formatted at that point.
What I would really like to do is get my hands on a brand new, unprogrammed set of components and look at whats on their EEPROMs. the SSM can tell that a unit has been previously programmed and wont let you remarry used components.
Well, she runs again. Unfortunately, I have no idea what I did!! Well, some idea but still.
There are a few things going on here. Ive been messing around with the VXDiag aftermarket SSM3 programmer, I had stopped trying to port over my key codes to the new hardware, and instead I was working with my original hardware and trying to program the new ECM to work with them, which is not something you're supposed to be able to do.
I mentioned in my last post that I had figured out the address where the security ID is located and changed it to hex 3039, or 12345 decimal. The only data in the ECM rom is the 10 bytes that Ryan figured were the key codes, the VIN (which is not important to functioning, at all, just there for reference), the digit following the VIN (3 in ryans example) and the 2 bytes he identified as possibly a checksum.
I had flashed the ECM eeprom to contain a mostly blank structure, only including the repeated 10 'keycode' bytes. I'm quoting that because I don't believe they are keycodes, possibly hashed key information? doesn't matter though. At some point in messing around with the SSM software, I read back the ECM rom and that checksum had populated itself. I have NOT been able to replicate this unfortunately. I thought it was interesting but it didn't fix the security light,and I was still getting a code for a mismatched key.
After messing around for a while, I was just about to give up, but on a whim I flashed back the original BIU eeprom, including the unaltered security ID... and the light goes out.
I may do some more experimenting, maybe see what happens if I put in someone else's security ID and checksum, but for now, my mission is finally accomplished. I reprogrammed a used ECM to work with my original security system, without the original rom. Something you're not supposed to be able to do!
There are a few things going on here. Ive been messing around with the VXDiag aftermarket SSM3 programmer, I had stopped trying to port over my key codes to the new hardware, and instead I was working with my original hardware and trying to program the new ECM to work with them, which is not something you're supposed to be able to do.
I mentioned in my last post that I had figured out the address where the security ID is located and changed it to hex 3039, or 12345 decimal. The only data in the ECM rom is the 10 bytes that Ryan figured were the key codes, the VIN (which is not important to functioning, at all, just there for reference), the digit following the VIN (3 in ryans example) and the 2 bytes he identified as possibly a checksum.
I had flashed the ECM eeprom to contain a mostly blank structure, only including the repeated 10 'keycode' bytes. I'm quoting that because I don't believe they are keycodes, possibly hashed key information? doesn't matter though. At some point in messing around with the SSM software, I read back the ECM rom and that checksum had populated itself. I have NOT been able to replicate this unfortunately. I thought it was interesting but it didn't fix the security light,and I was still getting a code for a mismatched key.
After messing around for a while, I was just about to give up, but on a whim I flashed back the original BIU eeprom, including the unaltered security ID... and the light goes out.
I may do some more experimenting, maybe see what happens if I put in someone else's security ID and checksum, but for now, my mission is finally accomplished. I reprogrammed a used ECM to work with my original security system, without the original rom. Something you're not supposed to be able to do!
Thanks to @Ryan J. Geyer, @l88m22vette and others for sharing info. Thought I'd practice reading the immobilizer on a spare 2008 3.0 ECU so ordered this FT232H breakout and clip from Amazon. However after lining up the clip and releasing the spring handle it just slips upwards and right over the chip. IC405 is very close to the PCB with everything covered in some sort of presumably protective lacquer. My photo below doesn't look too much different to the photo in post #6. Is there any trick to attaching this clip ?
![509459]()
I found that I had to hold mine in place while I was reading it
I could get my Amazon clip to stick maybe 1 out of 20 times. Tiny amounts of wiggling sometimes helped. Also strain-relieving the cable so it doesn't put weight on the clip.
I think the "name-brand" Pomona clips hold better, found them on Digikey.com .
I think the "name-brand" Pomona clips hold better, found them on Digikey.com .
Have wanted a spare ECU for a while now due to ‘bricking’ mine whilst tuning a couple years back. Turns out my car's OBD-II port under the dash had been physically strained causing an iffy electrical connection so a ROM write with EcuFlash failed midway. This led to a dead car whilst the ECU was sent to Tactrix hospital in San Francisco for recovery. So reading this post it was really cool to see Ryan found a method to achieve this and wrote it up well. Whilst my OBD-II port is now fixed I figured the unlikely event of water damage, electrical issues or further flashing issues for tuning having a backup ECU would be good, but mainly because this seemed like a fun project.
I picked up a backup ECU with the same Subaru part number from eBay, the ada fruit FT232H breakout USB board and Pomona 5250 clip from Amazon. Got a cheaper clip first but it would just not attach to the IC. Installed Python 2.7 32 bit, then the prerequisite software as per the old windows setup instructions on the ada fruit web page, not the new instructions. Allow some time for this, there’s a few steps to follow. Actually the Python GPIO library install process threw some error messages later in the script but this didn’t end up being a problem. Once these were installed I collected Ryan’s scripts from GitHub.
The plan was to use Ryan's scripts to read the immobilizer chip image from the ECU, flash it to the backup ECU and test to see if the car then accepted the backup ECU. So my car is a 2008 model year 3.0R from Japan and saw on a post that the chip to read is labelled IC405. When reading the image first time, I practiced on the backup ECU. Well it took a couple attempts, balancing the clip took some practise as the weight of the wires affected it and a couple of wiggles were required to secure a connection. Seemed to work best for me with the ECU PCB held gently in a clamp so there was no movement from the board. Otherwise... soldered the supplied pin connectors to the break out board and used long jumper leads to the clip for more room to arrange things.
The chip image read from my car didn’t have the same structure as the one posted at the beginning of the thread. Also it didn’t contain the VIN but as JDM Japan domestic cars don’t have a VIN didn’t worry too much about that. An example of the backup ECU’s original IC405 contents is shown here as an example of a later model year of course these keys are now overwritten. Anyway I thought I’d try to write the image to the backup ECU which went OK, popped into the car to test ... wouldn’t you know it worked great. Big thanks to Ryan and others that have contributed their experiences here.
![511148]()
![511149]()
I picked up a backup ECU with the same Subaru part number from eBay, the ada fruit FT232H breakout USB board and Pomona 5250 clip from Amazon. Got a cheaper clip first but it would just not attach to the IC. Installed Python 2.7 32 bit, then the prerequisite software as per the old windows setup instructions on the ada fruit web page, not the new instructions. Allow some time for this, there’s a few steps to follow. Actually the Python GPIO library install process threw some error messages later in the script but this didn’t end up being a problem. Once these were installed I collected Ryan’s scripts from GitHub.
The plan was to use Ryan's scripts to read the immobilizer chip image from the ECU, flash it to the backup ECU and test to see if the car then accepted the backup ECU. So my car is a 2008 model year 3.0R from Japan and saw on a post that the chip to read is labelled IC405. When reading the image first time, I practiced on the backup ECU. Well it took a couple attempts, balancing the clip took some practise as the weight of the wires affected it and a couple of wiggles were required to secure a connection. Seemed to work best for me with the ECU PCB held gently in a clamp so there was no movement from the board. Otherwise... soldered the supplied pin connectors to the break out board and used long jumper leads to the clip for more room to arrange things.
The chip image read from my car didn’t have the same structure as the one posted at the beginning of the thread. Also it didn’t contain the VIN but as JDM Japan domestic cars don’t have a VIN didn’t worry too much about that. An example of the backup ECU’s original IC405 contents is shown here as an example of a later model year of course these keys are now overwritten. Anyway I thought I’d try to write the image to the backup ECU which went OK, popped into the car to test ... wouldn’t you know it worked great. Big thanks to Ryan and others that have contributed their experiences here.
Joined
·
11 Posts
Hi All,
I'm looking at contributing to reverse engineering the crypto used between the ECU and BIU - why? Because I want to run the ECU standalone without the BIU or cluster. I'm still in the early days of my understanding, but here's where I'm at. I would love to discuss further!
Referring back to post #34:
www.borealisai.com
I need to figure out what to feed into the SAT solver. Just getting my head around it is a challenge.
I'm very interested in continuing the discussion further! I think my first step is to record a number of challenge/responses from the ECU and BIU. I have a running 2005 Legacy 3.0R to work on ;-)
Thanks!
Andrew
I'm looking at contributing to reverse engineering the crypto used between the ECU and BIU - why? Because I want to run the ECU standalone without the BIU or cluster. I'm still in the early days of my understanding, but here's where I'm at. I would love to discuss further!
Referring back to post #34:
Based on my other reading, it seems it is a challenge and response. My understanding is that the crypto probably involves:
- ECU: Creating a pseudo-random set of bytes (80 bits?)
- Using a linear-feedback shift register (LFSR) containing the private key, left shift these bits through the register
- Take the bits remaining in the register and send them as the challenge. Looking at the bits in the sample message, I would surmise that the challenge is 40 bits long (payload is 48 bits; the last 8 bits are probably a counter or a checksum)
- Feed the result back into the LFSR and store these as the expected result from the BIU
- BIU: take these 40 bits and shift them through its own LFSR with the shared private key and send the result back to the ECU
- ECU: compare result from BIU with previously stored values - report successful/unsuccessful authentication somehow
Tutorial #9: SAT Solvers I: Introduction and applications - Borealis AI
www.borealisai.com
I need to figure out what to feed into the SAT solver. Just getting my head around it is a challenge.
I'm very interested in continuing the discussion further! I think my first step is to record a number of challenge/responses from the ECU and BIU. I have a running 2005 Legacy 3.0R to work on ;-)
Thanks!
Andrew
Joined
·
11 Posts
A few additional thoughts... Since we believe the cypher is 80 bits, I am wondering if it uses something like the Texas Instruments DST80. If that's the case, then the last 48 bits from the register would be exchanged between the ECU and the BIU. The DST80 uses its last 24 bits but we know that the full response in our case is 48 bits.
Some interesting reading:
More thoughts when I've had the chance to capture some challenges/responses from my car!
Andrew
Some interesting reading:
More thoughts when I've had the chance to capture some challenges/responses from my car!
Andrew
Joined
·
11 Posts
And also, your keys are different from mine!
![]()
And 2012 cars onwards use DST-80:
So is it likely that the earlier ones do? I don't think so.
My situation is slightly complicated by the fact that my car has a Sigma alarm. I'm led to believe that the key PCB is a Sigma part, not a Subaru part. But it's obviously also compatible with the Subaru key reading antenna too. Ah well. Not my current focus - trying to understand the challenge/response between ECU and BIU!
Andrew
And 2012 cars onwards use DST-80:
So is it likely that the earlier ones do? I don't think so.
My situation is slightly complicated by the fact that my car has a Sigma alarm. I'm led to believe that the key PCB is a Sigma part, not a Subaru part. But it's obviously also compatible with the Subaru key reading antenna too. Ah well. Not my current focus - trying to understand the challenge/response between ECU and BIU!
Andrew
Joined
·
11 Posts
Sorry - some further thoughts - my brain is whirling on this one!
Based on this page: https://autoremotekeys.co.uk/product/software-module-188-toyota-lexus-subaru-smart-key-unit-denso/
It's highly likely that our 2005'ish cars use DST-40. Lucky because it's been cracked several times already... Just posting this here so it's out of my head and I can come back to it later!
More info:
hackaday.com
Andrew
Based on this page: https://autoremotekeys.co.uk/product/software-module-188-toyota-lexus-subaru-smart-key-unit-denso/
It's highly likely that our 2005'ish cars use DST-40. Lucky because it's been cracked several times already... Just posting this here so it's out of my head and I can come back to it later!
More info:
Tesla Opens With Precomputed Key Fob Attack
This clever precomputation attack was developed by a group of researchers at KU Leuven in Belgium. Unlike previous key fob attacks that we’ve covered in the past which have been essentially r…
hackaday.com
Andrew
Joined
·
11 Posts
Ahahaha! I may have stumbled across an even simpler approach - more details on the Tesla example... It also turns out that DST-40 and DST-80 are very similar in the ways they work. The only real difference is the key length (as far as I can determine). I'm still not 100% sure if the immobiliser uses DST-40 or 80 or some other scheme. But look at this:
nakedsecurity.sophos.com
This is all publicly available info, by the way. And I must state for the record that I have no nefarious intentions in any of this work - just a goal to use a Subaru ECU standalone.
In essence, if you know the crypto algorithm used, you can crack it pretty easily. In short:
More later...
Andrew
Drive away a Tesla today (even if it isn’t yours)
Raspberry Pi’s processing power versus Tesla’s Model S cryptography – victory for the little guy!
nakedsecurity.sophos.com
This is all publicly available info, by the way. And I must state for the record that I have no nefarious intentions in any of this work - just a goal to use a Subaru ECU standalone.
In essence, if you know the crypto algorithm used, you can crack it pretty easily. In short:
- You create your own random challenge
- Precompute the 24-bit hash of that challenge for every possible 40 bit key
- Send your random challenge to the BIU and capture the response that comes back
- Match that response to the precomputed table. Note that there will be many possible keys that match - 2 to the power of 16 (65536)
- Generate a second random challenge and pre-compute the possible responses from the BIU given all 65536 candidate keys
- Bingo! You'll now be able to identify the single candidate key by determining which response matches one of the 65536 candidate keys
More later...
Andrew
Joined
·
11 Posts
I'm now confused again. I had forgotten that the OP had posted that the transponder chip was the 4D62 - this is indeed an 80 bit chip. However, I surmise that the method for cracking it is still the same as mentioned in the links about Tesla as it's still a Texas Instruments chip and thus probably uses the same crypto as DST80. Will need to re-read the articles and see how to crack the 80 bit crypto. Seems that the principle is still the same.
Joined
·
11 Posts
An update! Sheesh this isn't easy...
I'm trying to monitor the comms on the dedicated immobiliser lines and getting weird stuff happening!
I've managed to lay the loom out on my floor(!) and have the immobiliser working properly.
I've built an RS232 sniffer that has two ports on it. However, when I have both sides connected, all comms are mirrored on both ports. Something weird is happening there... I can only successfully see the comms from the ECU to the BIM.
Also, when either line is connected to my sniffer, the immobiliser stops working. I'm now wondering if it's better to use my device as a man in the middle - receiving comms on one port and transmitting them out of the other, and vice versa?
Andrew
I'm trying to monitor the comms on the dedicated immobiliser lines and getting weird stuff happening!
I've managed to lay the loom out on my floor(!) and have the immobiliser working properly.
I've built an RS232 sniffer that has two ports on it. However, when I have both sides connected, all comms are mirrored on both ports. Something weird is happening there... I can only successfully see the comms from the ECU to the BIM.
Also, when either line is connected to my sniffer, the immobiliser stops working. I'm now wondering if it's better to use my device as a man in the middle - receiving comms on one port and transmitting them out of the other, and vice versa?
Andrew
Joined
·
11 Posts
A further update: if I connect only one of the lines from the ECU of the lines completely, then I just get the challenges from the ECU. Here's an example:
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
This seems to be repeatable and appears to be the beginning of the handshake.
If I reconnect it both lines this is the full comms:
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
8 0 D EE 0 33 1 DD 0 <---- this seems to be the first response from the BIM
3E FE 7 0 26 2A 60 5E 0
CF E4 8 0 D 4 0 26 0
0 0 0 3D E4 7 0 26 0
2A 60 5E CF E4 8 0 D 0
C 0 33 0 1 0 DD 3E 0
FE 7 0 26 2A 60 5E CF 0
E4 8 0 D EE C0 3 0 0
0 79 F7 E4 7 0 26 2A 0
60 5E CF E4 8 0 D 2A 0
0 48 5 40 DD 3E FE 7 0
0 26 2A 60 5E CF E4 8 0
0 D 1 0 26 0 0 40 0
CF E4 7 0 26 2A 60 5E 0
CF E4 8 0 D 66 0 22 0
1 40 DD 3E FE 7 0 26 0
2A 60 5E CF E4 8 0 D 0
AE 80 9 2 5E CF E4 7 0
0 26 2A 60 5E CF E4 8 0
0 D E 0 27 0 1 80 0
DD 3E FE 7 0 26 2A 60 0
5E CF E4 8 0 D 6E C0 0
3 0 0 79 F7 E4 7 0 0
26 2A 60 5E CF E4 8 0 0
D 2A 0 48 5 40 DD 3E 0
FE 7 1 0 0 0 0 0 0
8 8 1 0 0 0 0 0 0
0 9 7 1 0 0 0 0 0
0 8 8 1 0 0 0 0 0
0 0 9 7 1 0 0 0 0
0 0 8 8 1 0 0 0 0
I'm now beginning to think that the comms lines are not pure serial, but are some kind of differential signalling. That would explain why I get the same on both lines. Or maybe not - as you might expect I would get the inverse on one? Might be time to crack open the logic analyser!
Interestingly, I had to use inverse RS232 signalling to get things to work at all.
Andrew
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
This seems to be repeatable and appears to be the beginning of the handshake.
If I reconnect it both lines this is the full comms:
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
7 0 26 2A 60 5E CF E4 0
8 0 D EE 0 33 1 DD 0 <---- this seems to be the first response from the BIM
3E FE 7 0 26 2A 60 5E 0
CF E4 8 0 D 4 0 26 0
0 0 0 3D E4 7 0 26 0
2A 60 5E CF E4 8 0 D 0
C 0 33 0 1 0 DD 3E 0
FE 7 0 26 2A 60 5E CF 0
E4 8 0 D EE C0 3 0 0
0 79 F7 E4 7 0 26 2A 0
60 5E CF E4 8 0 D 2A 0
0 48 5 40 DD 3E FE 7 0
0 26 2A 60 5E CF E4 8 0
0 D 1 0 26 0 0 40 0
CF E4 7 0 26 2A 60 5E 0
CF E4 8 0 D 66 0 22 0
1 40 DD 3E FE 7 0 26 0
2A 60 5E CF E4 8 0 D 0
AE 80 9 2 5E CF E4 7 0
0 26 2A 60 5E CF E4 8 0
0 D E 0 27 0 1 80 0
DD 3E FE 7 0 26 2A 60 0
5E CF E4 8 0 D 6E C0 0
3 0 0 79 F7 E4 7 0 0
26 2A 60 5E CF E4 8 0 0
D 2A 0 48 5 40 DD 3E 0
FE 7 1 0 0 0 0 0 0
8 8 1 0 0 0 0 0 0
0 9 7 1 0 0 0 0 0
0 8 8 1 0 0 0 0 0
0 0 9 7 1 0 0 0 0
0 0 8 8 1 0 0 0 0
I'm now beginning to think that the comms lines are not pure serial, but are some kind of differential signalling. That would explain why I get the same on both lines. Or maybe not - as you might expect I would get the inverse on one? Might be time to crack open the logic analyser!
Interestingly, I had to use inverse RS232 signalling to get things to work at all.
Andrew
Joined
·
11 Posts
Aha! Is it RS485 rather than RS232? Might be!!! Time to do some digging...
Andrew
Looks like it may well be RS485 - now the challenge is that it's two-wire differential signalling and I have no idea which "side" is transmitting and which is receiving at any one time... Now need to order a RS485 breakout board
Andrew
Looks like it may well be RS485 - now the challenge is that it's two-wire differential signalling and I have no idea which "side" is transmitting and which is receiving at any one time... Now need to order a RS485 breakout board
Joined
·
11 Posts
I see I'm talking to myself again ;-)
Is anybody following this post that would like to chime in?
I've done yet more investigation. It's not RS485... It's a single wire serial communication protocol, where both lines are doing the same thing. In fact, they appear to be internally connected. I wonder if they are duplicated for some redundancy?
Anyway, I can confirm that they are 1200 baud, no parity, 1 stop bit. Communications from the ECU start with 0x07, and communications from the BIM start with 0x08.
I've written a small program to interpret these. Here's what I get for an example challenge and response:
And an invalid response where the key is not in the ignition:
Note that I can't be 100% sure that the successful challenge/response is successful as the security light is active - monitoring the comms does seem to cause the immobiliser to not work properly.
Andrew
Is anybody following this post that would like to chime in?
I've done yet more investigation. It's not RS485... It's a single wire serial communication protocol, where both lines are doing the same thing. In fact, they appear to be internally connected. I wonder if they are duplicated for some redundancy?
Anyway, I can confirm that they are 1200 baud, no parity, 1 stop bit. Communications from the ECU start with 0x07, and communications from the BIM start with 0x08.
I've written a small program to interpret these. Here's what I get for an example challenge and response:
Code:
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D EE 0 33 1 DD 3E FE
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D 4 0 26 0 0 0 3D E4
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D E 0 33 0 1 80 DD 3E FE
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D 6E C0 3 0 0 79 F7 E4
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D 2A 0 48 5 40 DD 3E FE
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D EE 1 0 0 0 40 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D 66 0 22 1 40 DD 3E FE
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D AE 80 19 2 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D E 0 33 0 1 80 DD 3E FE
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D 6E C0 3 0 0 79 F7 E4
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 D 2A 0 48 5 40 DD 3E FE
ECU: 7 1 0 0 0 0 0 8
IMM: 8 1 0 0 0 0 0 0 9
ECU: 7 1 0 0 0 0 0 8
IMM: 8 1 0 0 0 0 0 0 9
ECU: 7 1 0 0 0 0 0 8
IMM: 8 1 0 0 0 0 0 0 9 9 0 0
Code:
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 0 26 2A 60 5E CF E4
IMM: 8 0 0 0 0 0 0 30 38
ECU: 7 1 0 0 0 0 0 8
IMM: 8 1 0 0 0 0 0 30 39
ECU: 7 1 0 0 0 0 0 8
IMM: 8 1 0 0 0 0 0 30 39
ECU: 7 1 0 0 0 0 0 8
IMM: 8 1 0 0 0 0 0 30 39 0 0 0Andrew
121 - 140 of 180 Posts
