Jeep key programming attempt using ELM - JeepForum.com
 1Likes
Reply
 
LinkBack Thread Tools
post #1 of 28 Old 02-17-2021, 03:46 PM Thread Starter
oh2WJ
Registered User
2002 WJ 
 
Join Date: Sep 2020
Posts: 36
Jeep key programming attempt using ELM

One of the members here posted some great info on how to use ELM to access the PDM and program key fobs. https://www.jeepforum.com/forum/f310...c-wjs-4338227/


I found this so cool and useful, then I wondered if a similar method could work for programming keys. Usually if someone lost a fob, they also lost a key. I bought a SBB key programmer and some cheap transponder keys, but after it went through the whole process it says if light is still blinking try again.


I have been working with the other member and so far we have determined that C0 is physical address of the SKIM. He also shared some known commands to get information from the SKIM. I have used the ELM to monitor my SBB key programmer while using it to program a key both on and off the vehicle. Next step is to follow Strokers direction about using SBB on vehicle with ELM command AT RA C0 to filter responses. See linked post for info on steps taken to this point. If anyone has a key programmer and ELM, more data could prove useful!

crusher8101 likes this.
oh2WJ is offline  
Sponsored Links
Advertisement
 
post #2 of 28 Old 02-17-2021, 05:01 PM Thread Starter
oh2WJ
Registered User
2002 WJ 
 
Join Date: Sep 2020
Posts: 36
I tried Stroker's advice to monitor SBB on vehicle with ELM command AT RA C0 to filter responses. The only other commands I used were L1, H1, SP2. I didn't see any data. (Maybe need to set header?) Then I remembered from the ELM pdf that another command MR will monitor a receive address like MA monitors the whole bus. Doing it this way got me pretty much the same data I collected on the bench, but with two new messages that I marked with bold and asterisks. Again, it goes through the whole process and says if light is blinking try again. Here is the data:


26 C0 51 01 01 00 04
4F C0 80 00 00 00 EA
4F C0 00 47 12 02 23 *
24 C0 01 00 00 00 FA
26 C0 7F 01 11 00 0F
4F C0 00 DB 76 2F 45 *
24 C0 27 02 52 80 42 Pin
26 C0 67 02 00 00 C2
24 C0 B4 28 00 00 4F
26 C0 F4 28 00 00 57
24 C0 22 28 00 00 36
26 C0 62 02 00 00 11



From the PDF I got the impression that MA, MR, MT just monitor the bus or specified address and return all messages regardless of protocol or what not. Maybe these commands are being sent using something other than SP2 (VPW).
oh2WJ is offline  
post #3 of 28 Old 02-17-2021, 07:05 PM Thread Starter
oh2WJ
Registered User
2002 WJ 
 
Join Date: Sep 2020
Posts: 36
Forgot to mention I also did a run with AT MT C0 and it only sent one message when Ign is turned on. I forgot I had a log of just the SKIM being powered on the bench and it helped eliminate two more messages. Here is the list that I believe is the sbb commands to the SKIM:


4F C0 00 47 12 02 23
24 C0 01 00 00 00 FA
26 C0 7F 01 11 00 0F
4F C0 00 DB 76 2F 45
24 C0 27 02 52 80 42 Pin
26 C0 67 02 00 00 C2
24 C0 B4 28 00 00 4F
26 C0 F4 28 00 00 57
24 C0 22 28 00 00 36
26 C0 62 02 00 00 11



Disclaimer! this all is just for information only. I don't recommend any one mess around with this stuff, you can damage your car possibly.


But for all I know this works I just have crappy blank keys.


Here are some links for info I found related to this kind of stuff


https://theksmith.com/software/hack-...p-easy-part-1/


https://www.elmelectronics.com/wp-co...1/ELM327DS.pdf
oh2WJ is offline  
 
post #4 of 28 Old 02-17-2021, 07:44 PM
Stroker347
Registered User
2004 WJ 
 
Join Date: Dec 2018
Posts: 26
oh2WJ,

The PIN number is a four digit number with each digit ranging from 0 to 9. This can be coded in HEX as four nibbles (one half of a byte) using two bytes. Since the value of each digit is less than 10 the HEX representation will be the same as the decimal representation. Therefore, your PIN number expressed as HEX appears identical to how you would write it.
The first two messages in your recent capture are identical to messages that I capture on the bench following a simulation of the ignition going from OFF to ON (first application of voltage to pin 3 of SKIM with pin 1 always hot). The first message is in the 2 byte header response format possibly intended for the PCM. One would expect there to have been a request message of 24 C0 11 XX YY ZZ preceding it, but obviously not. The second is in the 1 byte header message format typically used for inter-module communication and may be a message to set the Security System Lamp status on the instrument panel. My bench testing responses also show a lot of B1 XX CRC messages where XX = 01, 02, 03, 04 and 05. These could be the lamp status messages instead.
Your third and sixth messages are different than any that I get during bench testing. And if I send the various 24 C0 XX … request messages that you captured I get “Not supported” responses of 26 C0 7F XX … except for the last one for which I get a response of 26 C0 62 00 00 00 CRC. I’m guessing that I would have to have a PCM in the loop in order to get responses like you’re getting.
Thanks for starting a new thread.
Stroker347 is offline  
post #5 of 28 Old 02-17-2021, 08:11 PM Thread Starter
oh2WJ
Registered User
2002 WJ 
 
Join Date: Sep 2020
Posts: 36
Wow man you are like a wizard understanding the hex stuff! I just re-read your pdf to try and gain more understanding. So the messages starting with 26 are responses from the SKIM correct? also having 7F in the response means not supported? Maybe it doesn't work because the very first response has 7F in it? This is the info I found about 7F:


Mode $7F - General Response Message


PCM Mode $7F Response Codes:

Code $00 - Affirmative Response
Code $10 - General Reject
Code $11 - Mode Not Supported
Code $12 - Sub-Function Not Supported or Invalid format
Code $21 - Busy - Repeat Request
Code $22 - Conditions Not Correct or Request Sequence Error
Code $23 - Routine Not Complete
Code $31 - Request Out of Range
Code $33 - Security Access Denied
Code $34 - Security Access Allowed
Code $35 - Invalid Key



How do you know if the header is 1,2, or 3 bytes? Going from the PDF I linked above I was looking at the data with first 3 bytes as header. But I see that is not correct here. if it's only 2 byte header, is it priority and destination only?



The data I posted was edited, I removed all those B1 05 93 <DATA ERROR and similar. Also only showed each message once although it may have been in the stream multiple times. I was focused on what messages were specific to SBB programming.


Thanks for helping out!
oh2WJ is offline  
post #6 of 28 Old 02-17-2021, 08:43 PM Thread Starter
oh2WJ
Registered User
2002 WJ 
 
Join Date: Sep 2020
Posts: 36
reading more. Mode $27 - Security Access Mode that's the mode used in the message that has the pin code 24 C0 27 02 52 80 42. So perhaps the fault of my SBB is it's using the wrong mode for the first command. 24 C0 01 00 00 00 FA Mode $01 - Request Current Powertrain Diagnostic Data. Maybe it was supposed to be Mode $10 - Initiate Diagnostics Operation. The other mode I see used is Mode $22 - Request Diagnostic Data by PID. or perhaps this command has an incorrect mode 24 C0 B4 28 00 00 4F could not find any info for mode B4.



Am I misunderstanding this? oh and just to be clear i'm posting the entire message I see including CRC byte.
oh2WJ is offline  
post #7 of 28 Old 02-17-2021, 10:12 PM Thread Starter
oh2WJ
Registered User
2002 WJ 
 
Join Date: Sep 2020
Posts: 36
well I tried a few different modes but all came back 7F 11 mode not supported. I think I'm really starting to understand this stuff.


4F C0 00 47 12 02 23 - mode 00 PID 47 data 12 02
24 C0 01 00 00 00 FA - mode 01 PID 00 data 00 00
26 C0 7F 01 11 00 0F - mode 01 not supported
4F C0 00 DB 76 2F 45 - mode 00 PID DB data 76 2F
24 C0 27 02 52 80 42 - mode 27 PID 02 data 52 80 secure access mode
26 C0 67 02 00 00 C2 - mode 27+40 PID 02 data 00 00 accepted
24 C0 B4 28 00 00 4F - mode B4 PID 28 data 00 00 this seems to be the program step
26 C0 F4 28 00 00 57 - mode B4+40 PID 28 data 00 00 accepted
24 C0 22 28 00 00 36 - mode 22 PID 28 data 00 00 request for number of keys programmed?
26 C0 62 02 00 00 11- mode+40 I think this is showing 2 keys programmed.


I forgot about and didn't type in the first message 4F C0 00 47 12 02 23 before attempting to send 24 C0 XX 00 00 00 trying to see if XX is supposed to be a different mode. I can see why Stroker questioned it right away, mode 01 is Request Current Powertrain Diagnostic Data. So far for XX I tried: 08,10,22,31,B4. I have a list of modes for 10 to 3F but noticed some were missing like 15,16,18,2D,2E,3D,3E. Also mentions a range from 80 to BF. wonderful. Next two I plan to try are A2 - programming prompt and AE - request device control. why not.



I'm starting to think the key here (haha) is that mode 01 not supported right in the beginning. But finding the right mode is a needle in a hay stack.


Stroker correct me on anything I got wrong here please and thanks!
oh2WJ is offline  
post #8 of 28 Old 02-17-2021, 10:28 PM
Stroker347
Registered User
2004 WJ 
 
Join Date: Dec 2018
Posts: 26
Chrysler used the SAE J2178 1 byte header format, for the early VPW protocol based Jeeps, for normal inter-module communications. The first byte ranges from 00 to F5 and identifies the type of message. The J2178 document defines several types but most are “Reserved – Mfg”. Some of the predefined ones, from J2178-3 Figures 3A thru 3I, are: 10 for Engine RPM, Speed, and MAP; 42 for Last Ignition Off Duration; 60 for Dimming and Lamp Code; 72 for Odometer; A0 for Distance to Empty and A4 for Fuel Tank Level. Modules that make use of a given “type” of message will listen for it; otherwise the module will ignore it.
The two byte header format is used for “manufacturer specific” communication over the OBD2 port. J2178-3 Figure 3B defines the first byte to be 24 for a J2190 Diagnostic Request and 26 for a J2190 Diagnostic Report. The second bye is defined to be the physical address of the message target.
For mandatory OBD2 messaging, the standard VPW three byte header format of J1850 is used.
The <DATA ERROR you saw after the B1 05 93 messages result from them being only 3 bytes in length. The ELM expects more than 3 bytes (including the CRC) and flags them as errors.
The standardized Modes are only defined up to 3E; above that are Mfg specific Modes which are proprietary for Chrysler. I don’t know what Mode B4 is either. As you discovered Mode 27 is for Security Access and Mode 22 gets used a lot. I too am suspicious of the Mode 01 and think it should be something else like 10, which is why I wondered if it was a typo.
I think the 4F C0 … messages are of the 1 byte header variety and don’t include a Mode byte, just data where the second byte is the address of the message “source” rather than target. I don’t think they are commands and no response would be expected. Whatever module makes use of these messages would just take the data and use it.
I would say you’re beginning to understand this stuff pretty well!
By the way, do you find it difficult to post these replies before the *&^% website times out and logs you off? I've taken to composing my replies in Word and then copy and paste them when I'm ready to post.
Stroker347 is offline  
post #9 of 28 Old 02-18-2021, 12:14 PM Thread Starter
oh2WJ
Registered User
2002 WJ 
 
Join Date: Sep 2020
Posts: 36
haha yes it times out on me all the time. Thanks for that info very helpful. Question:


For 2 byte header, are the only known first byte codes 24 and 26?



I hooked my SBB up on the bench again directly to ELM and selected different chrysler vehicles in the same year range. most of them sent the same code as for my jeep, but a couple of them sent a different one. I think they were for slightly later years like 03-05. I tried a bunch so can't remember exactly. anyways the code it sent was 24 C0 22 20 15 00 EF I tried it but got 26 C0 7F 22 12 00 67 Sub-Function Not Supported or Invalid format. Seems like a weird initial message requesting diagnostic data by PID.



Unfortunately I put my SKIM back in the Jeep so not as easy to check on this, not sure how bored you are in life Stroker but I'm going to check all the modes to see which ones are supported. Maybe not all but the ones that make sense or aren't listed. I'm thinking that 80-BF range. Basically send 24 C0 XX 00 00 00 to all the modes and see which come back 7F 11 and which come back 7F 12. The ones with 12 are supported just not right PID or data. I mentioned this above but my list is incorrect because modes 22 and B4 are definitely supported. When the SBB sent messages with those modes the response came back accepted.


So list of known accepted modes and PID for SKIM:


Mode 22 Request Diagnostic Data by PID 20, 28 # of keys programmed?
Mode 27 secure access mode PID 02 Pin

Mode B4 program the key? PID 28 ?

Last edited by oh2WJ; 02-20-2021 at 12:03 PM.
oh2WJ is offline  
post #10 of 28 Old 02-18-2021, 01:33 PM
Stroker347
Registered User
2004 WJ 
 
Join Date: Dec 2018
Posts: 26
Yes, the J2178 two byte header request messages always begin with 24 and the responses with 26. And the second byte is always the physical address of the “target” module. So these messages are always directed to a single module. So the 24 C0 … messages you have captured are requests from the SBB to the SKIM.
The one byte header messages are not targeted to any module. A few one byte header messages include the physical address of the “source” module but most do not. A good example of one that does is the front door status message, beginning with byte 23 (see my pdf file for the codes). The same status codes are used for both the driver and passenger side doors. So these messages include the source module address so other modules, such as the EVIC (the overhead info display), know which door sent the message. The EVIC uses these messages to display door open pictures in the display. The rear door status message, beginning with 5A, uses different codes for each door because there are no modules in these doors so there is no physical address to identify them. I think the 4F C0 … messages that you have captured are messages from the SKIM, to be used most likely by the PCM and/or BCM modules.
Think of the one byte header messaging as “posts” in a forum and the forum as the PCI bus. The first byte is like the title of the post and the remaining bytes are the information of the post. These posts are not directed to any one in particular. Other people using the forum are like the modules in the system and if they see a title that interests them they will then read the post, otherwise they will ignore it. If the information in the post is useful to another module it can use it without replying but it has the option of “posting” its own messages in response.
For the two byte header messages, the trial and error method that you are suggesting for finding valid Modes is the same thing I have done. Be aware that the three bytes that follow the mode will affect whether you get a valid response or not. So you might get a “Not supported” response to 00 00 00, but get a valid response to XX 00 00, where XX is something besides 00. I try values of 00, 01, 10, 20, 30, 40, etc. hoping to get lucky and often do. Once you find a value that works there may be many more near that value that also work. That’s how I found the VIN number retrieval request messages. Figuring out what a valid response means is usually guesswork.
Stroker347 is offline  
post #11 of 28 Old 02-18-2021, 02:18 PM
Stroker347
Registered User
2004 WJ 
 
Join Date: Dec 2018
Posts: 26
oh2WJ,

By the way, here are some other valid request/responses that I discovered (CRC byte not shown):
24 C0 22 24 00 00
26 C0 62 E1 00 00

24 C0 22 2E 00 00
26 C0 62 C2 03 00

24 C0 22 36 00 00
26 C0 62 01 00 00
Stroker347 is offline  
post #12 of 28 Old 02-18-2021, 02:49 PM
Stroker347
Registered User
2004 WJ 
 
Join Date: Dec 2018
Posts: 26
oh2WJ,

If you don't have a service manual, I've attached a pdf of the section on the SKIM.
When you were doing your testing with the SBB did you have an already programmed key in the ignition, or was it an unprogrammed key? I'm trying to figure out whether one of the SKIM messages was a valid or invalid key message.
Attached Files
File Type: pdf Service Manual Section for SKIM.PDF (5.95 MB, 5 views)
Stroker347 is offline  
post #13 of 28 Old 02-19-2021, 05:29 PM
Stroker347
Registered User
2004 WJ 
 
Join Date: Dec 2018
Posts: 26
oh2WJ,

The sun was out and it was warmer today so I captured some in-vehicle SKIM responses to Key On and Key On-Start.
Here’s what I got for Key On:
26 C0 51 01 01 00 04
4F C0 80 00 00 00 00 EA
4F C0 00 92 A5 82 C5
4F C0 00 92 A5 82 C5
B1 01 E7 (four to eight times)
B1 00 FA (continues to repeat until key off)

Here’s what I got for Key On-Start:
26 C0 51 01 01 00 04
4F C0 80 00 00 00 00 EA
4F C0 00 B5 3C 7F EA
4F C0 00 B5 3C 7F EA
B1 01 E7 (six times)
B1 00 FA (repeats periodically until key off)

I then repeated the Key ON captures three times and found that the 4F C0 00 … messages vary each time:
4F C0 00 92 A5 82 C5 (first time)
4F C0 00 1A 05 F9 23 (second time)
4F C0 00 EB 2E 20 D2 (third time)
4F C0 00 39 C0 FC B4 (fourth time)
I didn’t send any commands during this session, maybe I’ll try a few tomorrow. But what I’ve gathered from your testing and the results above is that the repeated B1 01 E7 message tells the EMIC (instrument panel module) to turn on the SKIS lamp as a bulb test for about 3 seconds following Key ON (based on the service manual). After that B1 00 FA tells the EMIC to turn it off. For other B1 XX CRC messages, where XX > 01, I’m pretty certain (based on the service manual) they tell the EMIC to flash the lamp maybe at varying rates indicating a problem with the SKIS or with the Key.
The 4F C0 00 … messages must tell the PCM whether the Key is valid or not. Since my testing shows these messages vary with each Key ON event, for the same valid Key, I conclude that they must be randomized in some way to prevent hackers from capturing one and reusing it. Assuming that you were using an invalid key for your testing, it may be that the two sequential 4F C0 00 … messages will differ, as yours did for an invalid key, whereas they will be the same as mine were for a valid key.
The initial 26 C0 51 01 01 00 04 response I believe indicates that the SKIM has reset or completed self- testing. I have seen similar messages for other modules (physical addresses 01, 28, 58, 68 and 80) following Key ON.
Stroker347 is offline  
post #14 of 28 Old 02-20-2021, 12:12 PM Thread Starter
oh2WJ
Registered User
2002 WJ 
 
Join Date: Sep 2020
Posts: 36
hey sorry just saw your replies, I didn't get email notification and switched over to trying to get my micropod 2 clone working for all modules.

Yes I was using unprogrammed key when testing with SBB. I agree with all your assertions above. I think at this point recording a working key programmer doing it's thing would reveal the right mode, PID, and data needed for the first command. That's why I switched to trying to get the micropod 2 working. I confirmed through testing that it actually uses SCI to communicate with the PCM, which is why I think it can't talk to other modules. I couldn't get any data out of pin 2, and instead of a varying signal I got a steady ~4V (on a o-scope). I'm not sure if it is even supposed to use PCI but I think that is the culprit. Although I read that sometimes there is a gateway between the buses which is most likely in PCM.

Anyways back to SKIM, I did do a little testing. I tried your command for number of programmed keys and got 26 C0 62 04 00 00 CRC which actually seems odd 4 keys programmed. Unless the previous owner had both keys replaced at some point, then it would seem that the SBB programmed my two blank keys. but they always have the light flashing and car shuts off. It would be helpful if I could read the keys, but that is a whole nother can a worms. I have no data about that value before I tried programming with SBB. You mentioned in the other post: "I also got positive responses from 00 thru 08 for the 5th byte, which I suspect include the 8 memory slots for holding Sentry Key IDs." maybe both of us reading those and comparing could help.

Maybe the first command just lets SBB know SKIM is there and responding. If I don't have the SKIM connected, SBB will error right away ECU disconnected after sending the first command. But if it gets the reply, it keeps going through the whole process. Again for all I know it worked and these cheap keys are the issue. Or, the SKIM does need that first command to actually put it into programming mode. If I could read the keys and match them against those memory slots you found that would be helpful.

Definitely much easier just to get a clone or go to ACE hahahahaha but I've learned a lot
oh2WJ is offline  
post #15 of 28 Old 02-20-2021, 03:04 PM
Stroker347
Registered User
2004 WJ 
 
Join Date: Dec 2018
Posts: 26
Oh2WJ,

We aren’t doing this because it’s easy are we!
I figured out something else by studying the in-vehicle capture logs. I think the SKIM’s 4F C0 80 00 00 00 message announces that it is ready to send a key status message. Soon after the SKIM sends this message and before it sends any 4F C0 00 … messages a unique 3F XX YY YY XX message shows up, probably sent by the PCM. The XX and YY values vary with each key on event, so they are probably some kind of rolling code that is used by the SKIM to generate its key status message, which itself appears to be a rolling code of some kind. I took one of the in-vehicle 3F … messages and injected it into my bench testing of the junkyard SKIM and got several identical 4F C0 00 … messages in return. The same 3F … message does not produce the same 4F C0 00 … message for new Key ON events. Without the injection of the 3F … message I don’t get any 4F C0 00 … messages (and neither did you) during bench testing.
I also took a blank key (no transponder) and did some more in-vehicle Key ON testing and found that the SKIM sends an identical sequence of 4F C0 00 … messages in response to the 3F … message. So my theory that an invalid key will result in a sequence of different messages doesn’t hold up. I can’t tell the difference between valid and invalid key messages.
One other thought I had, regarding your bench testing compared to mine, is that a valid PIN number is needed to get a positive response to the 24 C0 27 … and 24 C0 B4 … requests. I don’t know the PIN for my junkyard SKIM so I always get 26 C0 7F … responses to those requests.
My junkyard SKIM responses (CRC byte not shown) to the 24 C0 22 20 XX 00 CRC requests were (in order from XX = 00 to XX = 09):
Prefix = 26 C0 62:
04 68 00
66 65 00
41 44 00
01 00 00
10 76 00
11 00 00
20 20 4B
4A 19 73
41 80 15
02 00 00 (only two keys programed)
I doubt that eight keys were ever programmed into that SKIM (who’s got 8 expensive keys for one vehicle!?!) so I suspect that the other slots were randomly programmed during manufacturing to validate the function of the SKIM. So I think only the first two Sentry Key IDs are valid. But I have no idea how to get an ID from the key and I think the value stored in SKIM memory is probably encrypted anyway.
Stroker347 is offline  
Reply

Quick Reply
Message:
Options

Register Now



In order to be able to post messages on the JeepForum.com forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.

User Name:
Password
Please enter a password for your user account. Note that passwords are case-sensitive.

Password:


Confirm Password:
Email Address
Please enter a valid e-mail address for yourself.



Email Address:
OR

Log-in











Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page



Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On

 
For the best viewing experience please update your browser to Google Chrome