Why I hate VZ V6 ECUs...

[The1]

lol

[hsv08]

hopefully the invalid pin is equal to another number

Im worrying it might be a none ASCII number... due to that bugger up

So it might be a value between.. 0x0... and.. 0xFFFFFF (4,294,967,295‬)

Which equates to 136 years of trial and error

[The1]

im not sure how you can upload 0x0000 though, would be good to know how, maybe make pin code string length an extra byte? Or set a pim back up the same way and log the packets.

[delcowizzid]

136 years hahaha good to see some more E55 action

[Tazzi]

Unfortunately didnt work... all 0000 to 9999 combos and all failed (Dammit!).

So... this leaves either to start trying non-ASCII immo codes... for the whopping 136 years.. or come up with another idea.

Im going to give a 0x0000 value a go which is the equivalent of this:
7E0 07 AE 7D 08 00 00 00 00

Whereas an ASCII 0000 immo code would look like this:
7E0 07 AE 7D 08 30 30 30 30

[Tazzi]

Now breaking down the security linkling between the PIM and ECU.. we have the following:

244 02 3B 63 55 55 55 55 55 - Sent from scantool to PIM - request perform security update to ECU
488 10 30 3B 63 33 32 30 37 - From PIM, multiline message, 0x30bytes to follow, Mode 3B (DID write), DID 63. Then 33 32 30 37 = 3207 which is the immo
488 21 00 00 00 00 00 00 00 - all zero data
488 22 00 00 00 00 00 00 00 - all zero data
488 23 00 00 00 00 00 00 00 - all zero data
488 24 00 00 00 00 00 2D 68 - Start of immobiliser function? Maybe key data?
488 25 23 03 3E BF 21 D0 A1 - More key data?
488 26 30 2C 4E 54 BC 44 7E - More key data?
490 02 7B 63 - ECU says Accepted
644 02 7B 63 - PIM says Accepted

Now with this logic... could we just do just this to write only the immo:
488 06 3B 63 33 32 30 37

Or better yet.. what if trying to do a DID read.. so... 488 02 1A 63
Maybe the ECU will actually repeat back all the data??

Cause Im properly sleep deprived... I think this will be a tomorrow adventure Still need to whip the immo bruteforcer into a quick standalone app also.

[The1]

Looks like a mode 10 diag doing the 3B write?

Perhaps also try 7E0 02 1A 63
or
7E0 06 3B 63 30 30 30 30

I havn't seen anything about 63 before though.

i wonder if there's anything else happening long before this is done. Or are those 488 messages updating the PIM and not ECU?

[Tazzi]

Looks like a mode 10 diag doing the 3B write?

Perhaps also try 7E0 02 1A 63
or
7E0 06 3B 63 30 30 30 30

I havn't seen anything about 63 before though.

i wonder if there's anything else happening long before this is done. Or are those 488 messages updating the PIM and not ECU?

I played around with it last night before passing out, and the 488 is the PIM.

Bascially scantool sends a message to the PIM (244 02 3B 63 55 55 55 55 55 ).. then the PIM broadcasts its 488 messages which the ECU picks up.

The reason I believe thats the case is if I remove the ECU, I lose the 490 response at the end (490 02 7B 63) and then the PIM responds back with a failed message.

The final 644 frame is the PIMs response back to the scantool to let it know if the linking was successful. Since the average person shouldnt be seeing the comms between pim and ecu.

Also, depending on what tool your using, the messages may look a bit confusing. The frame 488 10 30 3B 63 33 32 30 37, that intial 10 indicates "multi frame message", then the following byte is the length of data in total to be sent over multiple can lines, and the 3B is the mode (Which is DID write).

Ill give it another crack this morning.. see how it goes. I think if maybe I get an Immo into it.. it will allow me to reset it properly which will release that immobilizer function programmed parameter.

[The1]

nice work

Had a quick play with various strings writing with 3B but no luck, would only get the timeout 01 60 after it. No Reply. Like on that PID it's expecting more data.

I tried the extra strings with same result.

Only till i tried the last 3 frames of data, BINGO it worked, it now shows as security code programmed and immobilizer function programmed, i can reset it with that code as well. I wonder if you had a cars pin already then ran this through and swapped the ecu in if it's all happy then?

i tried resending it again once pin is programmed with another different pin, but i get 7F back, so we can program a pin without anything else connected now but still can't change or read the pin, i tried various 1A's on 63, see if you have any luck there. Perhaps trying to load 63 into a DPID and reading out the first 4 bytes may do it?

[The1]

looks like the last frame is doing work? If i arrange it like this.

488 [8] 07 30 2C 4E 54 BC 44 7E

i get a spam flood of this back

490 [8] FE 40 A1 2C 4E CC 00 00

I feel like weve seen this CC reply before somewhere?