Hey,

 

can I kindly ask you for wise suggestions and help? Will start with a description of my way so far, if you find it lengthy - just scroll down to the bottom where you can find questions.

 

It all started 2 years ago when I bought a 1st car. As an engineer I had an idea to choose not very pricy one that will teach me fixing mechanical problems, also I can become familiar with electrical side of it, and finally programming. And it all worked quite good, I spent some amount of money for fixing and replacing broken parts gaining priceless experience and slowly I came to adding new 'features'.

So, I'm happy owner of Chevrolet Cruze G1 (J300) 2009 from Korea and I decided to add cruise control (K34 RPO) to it. I learned the schematic, added left side buttons panel to the steering wheel, added additional wire from buttons to the BCM. So far all was fine. Then I decided to check that buttons really work...

I took my oscilloscope and started investigating CAN bus waveforms, started learning about GMLAN on pin 1, high speed bus, KWP2000.

Then I switched to logic analyzer, manual waveform decoding (as software decoder was broken)..

Then I fixed software decoder (it was on Python, Sigrok-compatible code) and was happy I can collect large CSV files with CAN data, that I can analyze statistically, compare, look how data changes when I press buttons.
Then I purchased J2534 from VXDiag, sniffing became even easier, and I was able to start learning GDS2, DPS, Tech2Win then TIS2000 and GlobalTIS.

The latter 2 I still looking at as my initial installation was on Hyper-V hosted VM, and it have issues talking to VCX device.

Also so far I wasn't successful on paying for ACDelco TDS account for SPS2 access.

 

During my way I found that car was assembled from different parts (nevertheless I'm driving it for 2 years now):

ECM - does not have VIN, has immo-off

TCM - KLAJA69ED9K098886

EBCM - KLAJA69ED9K106551

BCM, IPC, SRS, Radio, HVAC, Parking Sensor - KLAJA69ED9K132666 - also this VIN is printed on the sticker

 

there are several DTCs:

B3902 - Incorrect Immobilizer Identifier Received - as I already learned, that requires immobilizer relearn, to delete and relearn car keys

C0569 - System Configuration - have no exact idea what it related to, but probably because of configs of EMC\TCM\EBCM

C0775 - Tire Pressure Monitoring System Sensors - that's strange tbh, as I don't have TPMS on this car (again - config related?)

 

So, seems like adding K34 RPO isn't the only thing I will have to program on this car) And now the question is - what would be your suggestion for the proper and economical way solving all that mess? Taking into account that this is car from Korea, and I (and a lot of others) do have issues with access to ACDelco account\SPS2 and cannot obtain xml config and build record...

Also from what have I learned - probably SPS2 won't be able to download anything related to my ECM as it does not have VIN for now.

Would it be possible then (and is it a correct way?):
1. Ask somebody to download calibrations for KLAJA69ED9K132666 (korean)
2. Change ECM, TCM, EBCM VINs to KLAJA69ED9K132666 with DPS Type 4 app
3. Use service from Troy to obtain PINs for modules (nice to have?)
4. Relearn immo
5. Fix (adjust) odometer readings (I saw slight difference may be like < 100km if I'm not mistaken)
6. Program RPO K34 to IPC, BCM, ECM
7. Not sure if I will need to do other 'relearn' operations for some of those modules

Did I forget something?... Kindly asking for your wise suggestions.

 

You can manually input the VIN in SPS when programming the module.

Manually type or copy and paste the VIN into the GM SPS service.

 

On 9/27/2024 at 11:28 AM, Troy said:

You can manually input the VIN in SPS when programming the module.

Manually type or copy and paste the VIN into the GM SPS service.

Yep, thanks, I learned it several weeks ago. But for that to be possible - I need to have access to SPS2. Even more.. as it is Korean car, as far as I understand, european access could be not sufficient.

 

Nevertheless, in the past weeks I overhauled cooling and power steering - nice new experience) And continued my learning of the software part and how GM makes our lives harder.

So, I created table where listed info about part numbers and CVNs that GM thinks should be in my car (took VIN that is most common for all components), and in the next column - put data from GDS2. Cross-checked with RPOs from VINs.
Observations:

1. EBCM - full match of part numbers in the car and in VINs - so probably just change of VIN (and PIN?) should work
2. TCM - almost full match - Transmission Calibration should be 25187214 per GM, but in car - 25183728 - may be older version? But without access to SPS2 I believe I couldn't tell if it is the case. So... probably VIN (and PIN?) change also should work.
3. ECM - hard to tell.. no VIN, part numbers does not match anything. Immo-off. What will happen if I will update it through SPS2 (kind of most genuine way)? Will it be complaining about PINs in other modules? Will immo-off survive this? What will happen if I will just change VIN? Will immo-related error disappear when I will change all PINs?
4. IPC - Indication Calibration has part number related to RPO with 15' disc/drum brakes, VIN points to 15' disc/disc brakes, and in reality I do have 16' disc/disc 🤦‍♂️
5. BCM - it has most of the part numbers different from what is GM think's it should be. May be just not updated to recent versions?

So, probably next step would be to ask here for EBCM, TCM, IPC files - for backup and to see if it would be possible to download them at all. And then look for simplest VIN\PIN changes. And later - update IPC with proper Indication Calibration, and look for ways to enable cruise control. Most probably SPS2 access will be required here.

And finally - ECM - tbh, I don't know what to do with it yet.

New update - slowly learning Utility file format, PTP/bin, interpreters concept, 27 and 3B 90. Seems like that will be my 'WOW!' moment.

New update - building my bench, waiting for delivery from china. Good read - GMW3110, Interpreters. Will try to find keys for modules, starting from EBCM. Also, managed to properly install and use Chevrolet GlobalTIS/SPS from VM, no luck - invalid VIN. Started thinking about emulator - new idea for me, not new in general. Also now, I guess, I'm in position to add details to my initial rather naive plan:

1. Find keys for modules I will be programming (the only way I'm aware of - brute force on bench, are there quicker ways?). And then try to reset MEC to FE, just for the sake of experimentation.
2. Read PIN from IPC EEPROM. And seems like I will need to find PINs for EBCM, TCM and ECM (somehow..).
3. Change VIN, PIN of EBCM
4. Change VIN, PIN of TCM
5. With all VINs and PINs aligned, I will probably be in position to change VIN and PIN on ECM, then try to use SPS to update modules and disable immo-off.
6. Obtain config and build record for IPC, update to 16' disc/disc + K34.

Received cables and devices and built my bench. First results:

1. IPC: Read EEPROM - started identification and mapping of areas and values inside EEPROM to DIDs, have two candidates for PIN.

2. EBCM: Read all (0x00 to 0xFF) DIDs from EBCM - quite interesting finding.

3. EBCM: Found algo and key for 0x01/02 security access. Successfully reprogrammed VIN. Run search for 0x03/04 security access, will wait those 8 days, maybe it will find something interesting.

Also, I have a question - is it possible to read PIN (theft deterrent code) by non-corporate DID?

And more questions - if anyone worked with J2534 via Python, how to add SW_CAN_PS protocol? It always says 'Invalid ProtoID' while in the Registry proto is available and supported, and 3rd party apps do list it.
And then how to properly do High Voltage Wakeup? Is it just matters of connecting with correct ProtoID and sending 00 00 01 01 via CAN?

Answering to my own questions:
SW_* (Single Wire) family of protocol works as expected. It's better to use logs from scanners like VXDIAG and try to mirror relevant parts of the communication.

DPS does HV Wakeup during communication via 1 pin, so it is easy to use same settings.

 

New updates:
1. IPC: read all DIDs, updated EEPROM mapping.
2. IPC: found seed\algo\key for security access level 1.

Probably it's time to move to ECM, BCM and TCM...

And again, answering my own questions... yes, indeed some modules (EBCM in my case) can expose PIN via non corporate DIDs (0x0F in my case). Question now - is it writeable and if so, what access level is required?

Updates:
1. BCM: read EEPROM, read all DIDs, found seed/key/algo, confirmed PIN for my VIN - I was unsure after reading EEPROM from IPC, more sure spotting same string in EBCM DID 0x0F, and now it is confirmed
2. ECM: read all DIDs, found seed/key/algo

Next steps: TCM (but it is cold outside.. meh), play with scripts - try to write scripts to change VIN code in all modules I do have keys for, try to change MEC (if it is possible, just for fun), try to change PIN in EBCM, try to identify area of IPC EEPROM where I need switch this precious bit to enable Cruise Control.

Keep answering yourself 🙂 

I'm following along and will chime in if I have anything to add 

And new updates:
1. When trying to change MEC in EBCM with ordinary 3B and security access lvl 1 - error code 22 ConditionsNotCorrectOrRequestSequenceError
2. When trying to change PIN in EBCM with ordinary 3B and security access lvl 1 - error code 31 RequestOutOfRange
3. VIN change - wrote scripts for all modules and successfully tested on EBCM and IPC
4. Did backup of calibration areas of ECM - seems like Simtec 76.1 requires BSL mode access to do a full dump. Trying to identify areas where VIN and PIN should be located - doing comparison with dumps available in public. But it's not easy, and I couldn't find stock for CAO95BD2.
Identified areas in dumps where seed and key are stored - I didn't look at it before, nice to know it is there.

Idea - attach oscilloscope to EEPROM in IPC or BCM, and request MEC via $1A - it should help identifying exact address where MEC is stored in EEPROM.

Open questions:
Does getting security access lvl 1 really changes something when reading DIDs via $1A? As so far I didn't see any changes in the data I read.
Trying to find ways to change PIN. Probably I need deeper understanding of 'security access' vs 'security code access'. If I correctly understood: 'security code' == PIN == 'theft deterrent security code'.
'Security access' is all about seed/algo/key and $27 and 'security code access' related to AE Mode?

Update - first of all, will start using appropriate terminology - not scripts but utility files.
TCM - decided to postpone it until I have full picture (or it will be less cold outside)
ECM - identified immo area, where VIN and PIN should be stored. It is clean. Will try to look into calibrations with WinOLS.
EBCM - found security access code for lvl 3 security access (DevCtrl), interesting that it wasn't following any of the algorithms - pure brute-force from 25.11 till 06.12.
Opimizied my python scripts to follow specs, now it takes less time to read DIDs. Tried to read DIDs without gaining security access, with security access lvl 1 (SPS) and security access lvl 2 (DevCtrl) - no changes in read values.
Started experimenting with AE Mode and 25 and AE opcodes. Identified CPIDS (1,2,3,4) that return not $31 RequestOutOfRange.
1 - always returns $E3 DeviceControlLimitsExceeded with values [80, 4].
2 - returns success $EE after $78 RequestCorrectlyReceived-ResponsePending
3 - always retruns $EE
4 - returns $EE if without security access, but with it returns - $E3 DeviceControlLimitsExceeded with values [80, 4]
All tests were done with $25 OpCode behaviour (80, 40 and 20 as Device Control Trigger byte, and pin as 4 other bytes in $AE service.
To be honest I wasn't able to change PIN in any other way, so now I'm thinking about next:
1. What if I set device to Theft Deterrent Relearn state with CPID $FE, wait 10 minutes
2. Then on next power up I will send message similar to what OpCode $25 is doing, first with $80 Device Control Trigger, then with $40
Or, try to experiment with CPID $FE but EEPROM access, wait 10 minutes and try to write with $3B to $0x0F DID.
That's all ideas so far.
Ah, also want to try to replace physical power off with ECU reset - may be it will be faster.

Aaand with new DevCtrl security access I was able to change MEC to FF via $3B service 🥳

ECU reset - $11 not supported on GMLAN, AE FD 40 00 00 00 also responds with $31. No luck, seems like L-Line power cycling is the only available method, at least for this module.
$AE Mode - I noticed that I missed $7E CPID that also responded with success, it was buried in the logs, and I did't saw it. Interesting that it lies so far away from other CPIDs.
Also GMW3110 corporate common CPIDs $FE and $FD respond with $31 no matter what I do (security access).
So seems like those 5 CPIDs are the only ones that are supported.
Idea - use GDS or Scanmatik and try to control the device, collect J2534 logs and compare with identified list of CPIDs.
Also I don't remember, but may be GlobalTIS databases have some info related to CPIDs?

Playing with AE mode and 25 OpCode behavior and known CPIDs:
 

Security access level:		0		1 & 3
AE 01 80 [not pin]		50 04		50 04
AE 02 80 [not pin]		+		+
AE 03 80 [not pin]		+		+
AE 04 80 [not pin]		+		50 04
AE 7E 80 [not pin]		FE 03		FE 05

AE 01 80 [pin]			+		50 04
AE 02 80 [pin]			+		+
AE 03 80 [pin]			+		+
AE 04 80 [pin]			+		50 04
AE 7E 80 [pin]			FE 03		FE 03

RESTART

AE 01 80 [pin]			50 04		50 04
AE 02 80 [pin]			+		+
AE 03 80 [pin]			+		+
AE 04 80 [pin]			+		50 04
AE 7E 80 [pin]			FE 03		+

AE 01 80 [not pin]		+		50 04
AE 02 80 [not pin]		+		+
AE 03 80 [not pin]		+		+
AE 04 80 [not pin]		+		50 04
AE 7E 80 [not pin]		FE 03		FE 05

So, seems like CPIDs $01, $02 and $7E react on PIN somehow, I identified next patterns (with $01 and $02 it is a sequence):
 

Security access: 0
AE 02 [not matter 5 bytes]		+
AE 01 [not matter 5 bytes]		+

Security access: 1 & 3
AE 7E 80 [pin]				+

So, seems like $01 and $02 not related to PIN at all. And for $7E response codes looks like: $FE - error, $03 - no security access, $05 - incorrect PIN.
Then I looped through 'trigger' byte, that was 0x80 previously (sec access lvl 1 and 2 gave same results). Results pretty in line with 'interpreters':

 

0x20 [not pin]		FE 07
0x40 [not pin]		FE 07
0x80 [not pin]		FE 05

RESTART

0x20 [pin]		FE 07
0x40 [pin]		FE 07
0x80 [pin]		+

RESTART

0x80 [not pin]		FE 05
0x40 [not pin]		FE 07
0x20 [not pin]		FE 07

RESTART

0x80 [pin]		+
0x40 [pin]		FE 07
0x20 [pin]		FE 07

All other byte values resulted in 31 RequestOutOfRange, omitted for clarity.

 

Another observation - 80 40 and 20 trigger byte values for 25 OpCode from 'interpreters' match GMW3110 CPID FD (80, 40) and FE (80,40,20) byte 1 values - same pattern with setting single bit to 1.

Update:

1. EBCM - seed/algo/key found, old PIN found, VIN and PIN changed - done
2. IPC - seed/algo/key found, need to change calibrations to enable Cruize Control
3. TCM - need to find seed/algo/key, need to find PIN (need to write Python script that will loop through all 9999 combinations), need to change VIN and PIN
4. ECM - seed/algo/key found, need to change VIN and PIN, but waiting for TCM

It would be nice also to update software of all those modules if possible.

Update:

1. Could not remove connector from TCM - I'm afraid I will break it, so I purchased similar one from aliexpress, will use it to create cable to quickly connect scanner to TCM, or as a replacement if I will break original one... so, will be waiting several weeks for delivery.
2. Immobilizer - I started learning basics how it works, also collected oscillogram from LIN Bus 11 between it and BCM, during ignition and engine start. Will be working on decoding meanwhile.

Update:

 

Received 2 connectors for my transmission from Ali. Replaced original connector with one of the new, as it was barely usable, plastic was cracking in my hand.
And with 2nd one I created cable and spent lovely day inside freezing car) Achievements so far:
1. Found key for TCM, for level 1 security access

2. Changed VIN

3. Read all DIDs

4. Looped through CPIDs

Seems like CPID used by other modules to change PIN isn't present here. So far I was brute-forcing key for 3rd level security access and thinking what to do and how to find proper CPID... $FD, $FE also not present here.
No ideas so far...

Also I touched new for me area - DSP - digital signal processing - to digitize readings from immo LIN bus communication. It was not successful as in the end some bits were missing or misinterpreted, but still it was fun. I think in the end I will buy LIN bus sniffer and that's it. But it was nice experience.

Today I changed VIN in ECM, but in a weird way - I have written script utility file for GMLAN interpreter where I use $1A and then $3B. And it worked fine for other modules. But for ECU $1A returned $31. That was very strange.

So, I quickly did the same with Python script, and it worked fine - VIN was set.

Could it be that some PreSteps run by the DPS itself was root cause (like 0xA5 programming mode)? Was it some protection that I jumped over?

After changing VIN in ECM I checked DTCs and B3902 - Incorrect Immobilizer Identifier Received gone but instead I do have:
B101E - Electronic Control Unit Software with symptom byte 43 - EEPROM Incorrect Programming

Not sure is it worse or not?

Also when I read calibrations from ECM - there are no changes. Seems like the area (emulated EEPROM?) where VIN is stored is not readable via OBD.
So now I have all VINs aligned. And different PINs in ECM and TCM.
I wasn't able to change PIN in ECM - CPID is supported but I do receive $03 error when accessing with trigger byte 80. Trigger bytes 40 and 20 return $07 error code as usually without proper 'unlocking'. Not sure how to proceed with it?

I noticed that ECM supports $FD CPID, $FE returns $31 so far.

So questions now:

1. Did I really correctly changed that VIN without programming session?
2. How to change PINs for ECM\TCM? How it can affect immo-off?
3. Will SPS be able to connect in this state of the car?
4. How to identify bit I need to switch in IPC to enable cruise control? Are there any changes in BCM that also had to be done?

Ah also I did some experiments with TCM - I connected GDS2 and played with TCM controls while sniffing the bus. I identified that CPIDs 0x00, 0x30, 0x34, 0x38 has nothing to do with the PIN change. Then I tested CPIDs that are left - 0x28, 0x3A, 0x3B using known trigger bytes - without much success.

Theory regarding ECM and my weird VIN change: could it be that immo-off was written into "virginized" ECM?
I do not know (yet?) how immo-off works, and never seen "virgin" module, but it could explain why it had no VIN (DID $90 returned 4E 6F 20 56 49 4E 20 53 65 6C 65 63 74 65 64 20 20 "No VIN Selected  "), so probably it has no PIN also...
I tried with empty textbox (to make DPS send FF FF FF FF instead of old PIN) and with 0000 (30 30 30 30), and also with 0x00 0x00 0x00 0x00 via Python script.
And if I correctly remember every time I received 0x03 error code from $AE. Could it be that module should learn it's environment first?

15 hours ago, geku said:

Today I changed VIN in ECM, but in a weird way - I have written script utility file for GMLAN interpreter where I use $1A and then $3B. And it worked fine for other modules. But for ECU $1A returned $31. That was very strange.

So, I quickly did the same with Python script, and it worked fine - VIN was set.

Could it be that some PreSteps run by the DPS itself was root cause (like 0xA5 programming mode)? Was it some protection that I jumped over?

After changing VIN in ECM I checked DTCs and B3902 - Incorrect Immobilizer Identifier Received gone but instead I do have:
B101E - Electronic Control Unit Software with symptom byte 43 - EEPROM Incorrect Programming

Not sure is it worse or not?

Also when I read calibrations from ECM - there are no changes. Seems like the area (emulated EEPROM?) where VIN is stored is not readable via OBD.
So now I have all VINs aligned. And different PINs in ECM and TCM.
I wasn't able to change PIN in ECM - CPID is supported but I do receive $03 error when accessing with trigger byte 80. Trigger bytes 40 and 20 return $07 error code as usually without proper 'unlocking'. Not sure how to proceed with it?

I noticed that ECM supports $FD CPID, $FE returns $31 so far.

So questions now:

1. Did I really correctly changed that VIN without programming session?
2. How to change PINs for ECM\TCM? How it can affect immo-off?
3. Will SPS be able to connect in this state of the car?
4. How to identify bit I need to switch in IPC to enable cruise control? Are there any changes in BCM that also had to be done?

hi i read your all updates you doing great job... if you want cruise control enable in ipc i dont know which bit need to change but i enabled it always by doing config and setup ipc and select k34 option while config and it will work fine and for bcm you need to replace 2 calibration files in package and it will work and next you have to config setup ecm and select k34 option thats all

On 12/31/2024 at 1:21 PM, TunnerXP said:

hi i read your all updates you doing great job... if you want cruise control enable in ipc i dont know which bit need to change but i enabled it always by doing config and setup ipc and select k34 option while config and it will work fine and for bcm you need to replace 2 calibration files in package and it will work and next you have to config setup ecm and select k34 option thats all

Thank you that's quite helpful!

ECM-related updates for today:
1. Added support of $A5 programming mode to my python scripts
2. Observation - when without 'programming mode' enabled - seed\key unlocking process requires 10 sec waiting time, when with - I do 2 retries, so 20 sec
3. VIN change does not work anymore - $3B responds with success, new VIN can be read, but after power cycling, it reads old VIN. Thanks gods I've written correct VIN in the beginning) But I believe I will be able to experiment with this more, when I will have access to the full flash, including emulated EEPROM area (0x4000 - 0x7FFF).

4. Still could not guess correct PIN. Looping through 0x00000000 to 0xFFFFFFFF will take 400+ days, so that's another reason I'm leaning towards accessing full flash... Also was reading about different ECU programming tools, I saw that some of them treat 'virginization' as resetting VIN and PIN. Interesting if it is true for all types of modules.

 

Still could not find original for ECM, so if someone has it or at least some dump from 25181280, please share 🙏:

 

Simtec 76.1
End model part #: GM 25181280
MF Code: 5WY1J12A
Broadcast code, software ID: AAG5
Serv No., Part number: 96964295
Manufacture date: 08.05.09/3 0238
* 86 AAG5 B 1J12A 9194 0238 *


Soft: CAO95BD2.DAT
ID: 10123893
Calib: 12345678

 

I have a collection of dumps I managed to download elsewhere but there are still differences in some areas. Most similar one do have almost 1500 differences.

 

And, finally, I think, I will be requesting files for ECM, IPC, BCM and TCM soon. Really hope Korean VIN will not be an issue..

Late update: updated my python scripts with implementation of $23 service - now I can read dumps aka tools that require quite some money.

Read part of the dump of ECM - it matches dump I read by paid tool. And still 0x4000 EEPROM area is locked. Probably could be unlocked by $AE $FE CPID but it does not work as it should..
Also with the same script I was able to download dump from EBCM: 0x000-0x7FF
Quite interesting. Will try with BCM and IPC and compare with dumps I read directly from EEPROM.

15 hours ago, geku said:

Thank you that's quite helpful!

ECM-related updates for today:
1. Added support of $A5 programming mode to my python scripts
2. Observation - when without 'programming mode' enabled - seed\key unlocking process requires 10 sec waiting time, when with - I do 2 retries, so 20 sec
3. VIN change does not work anymore - $3B responds with success, new VIN can be read, but after power cycling, it reads old VIN. Thanks gods I've written correct VIN in the beginning) But I believe I will be able to experiment with this more, when I will have access to the full flash, including emulated EEPROM area (0x4000 - 0x7FFF).

4. Still could not guess correct PIN. Looping through 0x00000000 to 0xFFFFFFFF will take 400+ days, so that's another reason I'm leaning towards accessing full flash... Also was reading about different ECU programming tools, I saw that some of them treat 'virginization' as resetting VIN and PIN. Interesting if it is true for all types of modules.

 

Still could not find original for ECM, so if someone has it or at least some dump from 25181280, please share 🙏:

 

Simtec 76.1
End model part #: GM 25181280
MF Code: 5WY1J12A
Broadcast code, software ID: AAG5
Serv No., Part number: 96964295
Manufacture date: 08.05.09/3 0238
* 86 AAG5 B 1J12A 9194 0238 *


Soft: CAO95BD2.DAT
ID: 10123893
Calib: 12345678

 

I have a collection of dumps I managed to download elsewhere but there are still differences in some areas. Most similar one do have almost 1500 differences.

 

And, finally, I think, I will be requesting files for ECM, IPC, BCM and TCM soon. Really hope Korean VIN will not be an issue..

hi dear i have some simtec 76.1 dump please check these maybe you can find something what you need..

Cruze simtec76.1.zip