Open source GM OBD2 flash tool using a ELM327 device

Posts: 21
Joined: Thu Sep 21, 2017 3:00 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Postby 160plus » Mon Nov 13, 2017 5:21 pm

Tazzi wrote:Ah I see the problem/confusion.. so see this quick break down:

6C 10 F0 27 01 B0 -Request Seed
6C F0 10 67 01 77 EC 7B - ECU respond with see 77 EC
6C 10 F0 27 02 A6 EF 3A - Attempt key A6 EF
6C F0 10 67 02 35 56 - Response code 35 (Incorrect)

6C 10 F0 27 01 B0 -Request Seed
6C F0 10 67 01 77 EC 7B - ECU respond with see 77 EC
6C 10 F0 27 02 A6 EE 27- Attempt key A6 EE
6C F0 10 67 02 36 71 - Response code 36 (Incorrect 2nd attempt)

6C 10 F0 27 01 B0 -Request Seed
6C F0 10 67 01 37 B8 - NO seed provided.. response of 37 (security timeout not met)
6C 10 F0 27 02 A6 ED 00 - Attempt key of A6 ED (Seed request failed anyways)
6C F0 10 67 02 37 6C - Response code 37 (security timeout not met)

You can see the seed response from the ECU changed on that third attempt.. the actual response is 1 byte shorter than the other seed responses since its not actually providing the seed anymore, the ECU responded saying mode 37 which is essentially the ECUs way saying of "Mate, give me a 10second break you talkative bugga!". :thumbup:



Your calculations were correct, made some changes to the way it works and now stops after the 02 36 71 response for 10 seconds. I let it run last night and it ran 4400 keys with out getting one 37 response code.

I've added a couple of things to make it a bit safer from a time stand point, the app stores and updates every 3rd key tried in a local db in the app that can be viewed even if the app is shut down and restarted so your able to pick back up from the last key that worked. Using every 3rd key worked out well with the security timer cool down so that the last key saved is one that didn't receive a response 37 code so even if the app were to start beating against the security timer for what ever reason the last know key that wasn't smashing the timer is whats saved. I also added a counter that well....counts the number of keys tried. Trying to figure out how many keys have been used in Hex makes my head hurt. If any one would be kind enough to give me the maximum number of keys possible between FFFF and 0000 I could also put in a timer that could give an estimated time to unlock. I think that could be a nice touch if your only letting the app run for a couple of hours at a time to get an idea of how much time it'll actually take.

I've also added a save file to the app that records the full log for every Send/Receive the app makes. Since space on a phone is a bit more limited then on a PC I'm wondering if I should include all the lines or perhaps have it omit the 27 01 and the line with the seed response, that would make the log about 33% smaller. Any ways here's a sample of the log, see if you guys think this is good the way I have it or if some lines can be deleted.

Code: Select all
Key Cracker Log - Starting At: 0xFFFF
Key Number: 0
Key Number: 1
27 01
6C F0 10 67 01 54 45 8E

27 02 FF FF
6C F0 10 67 02 35 56

Key Number: 2
27 01
6C F0 10 67 01 54 45 8E

27 02 FF FE
6C F0 10 67 02 36 71

Key Number: 3
27 01
6C F0 10 67 01 54 45 8E

27 02 FF FD
6C F0 10 67 02 35 56

Key Number: 4
27 01
6C F0 10 67 01 54 45 8E

27 02 FF FC
6C F0 10 67 02 36 71

Key Number: 5
27 01
6C F0 10 67 01 54 45 8E

27 02 FF FB
6C F0 10 67 02 35 56




If I omit the sending lines it looks like this......
Code: Select all
Key Cracker Log - Starting At: 0xFFFF
Key Number: 0
27 02 FF FF
6C F0 10 67 02 35 56

Key Number: 1
27 02 FF FE
6C F0 10 67 02 36 71

Key Number: 2
27 02 FF FD
6C F0 10 67 02 35 56

Key Number: 4
27 02 FF FC
6C F0 10 67 02 36 71


Previous

Return to Tool Development

Who is online

Users browsing this forum: No registered users and 2 guests