OBDX Development - Developer Tools and Suggestions

[Tazzi]

Hiya,
While on the phone, I was looking and found some of my notes. Let me know if this is correct.

27 01 = Request seed
67 01 = Return seed
27 02 = Send Key
67 02 = Positive response

26 04 = Request 4x
66 04 = Positive response

Sheesh, how fast I forget stuff Let me know if this sounds correct.

When I get some time I will try to break down the packets, but if you already know, save us both some time

Looks like you have logged the raw USB communication there.

I am unfortunately not too familiar with the USB protocol to decipher it.

A typical PWM seed request would be 64 10 F1 27 01

Where:
64=priority byte
10 = Destination is ECU
F1 = Source is Scantool
27 = Security request
01 = Request level 1 seed

[In-Tech]

Looks like you have logged the raw USB communication there.

Yes, My serial port sniffer was sooooo much easier back in the day
The packets are still the same buried in there, I just gotta remember how to parse some stuff later. I can still weed out desired packets manually.
I also just found my J2190 doc. Let me grab some dinner and a beer and I'll get to sifting.

[In-Tech]

It's also possible the HPT interface might be doing some trickery. If so, that could slow me down a bit. I have a KESS, a ford VCM, and an elm(1x, but can still use that for 1x seed/key) They will have to pull my dead, cold hands from the keyboard

[In-Tech]

Example from 2020 when I was parsing a bit better

Code: Select all

004008: Bulk or Interrupt Transfer (DOWN), 2020-07-13 01:19:20.2978213 +0.0001881 (1. Device: Playback)
Pipe Handle: 0x5d049b8 (Endpoint Address: 0x2)
Send 0x5 bytes to the device
 6C 10 F0 27 01                                    l.ð'.

004010: Bulk or Interrupt Transfer (UP), 2020-07-13 01:19:20.3116323 +0.0130017. (1. Device: Playback) Status: 0x00000000
Pipe Handle: 0x5d04988 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
 31 60                                             1`

004012: Bulk or Interrupt Transfer (UP), 2020-07-13 01:19:20.3126447 +0.0009797. (1. Device: Playback) Status: 0x00000000
Pipe Handle: 0x5d04988 (Endpoint Address: 0x81)
Get 0xb bytes from the device
 31 60 08 00 6C F0 10 67 01 34 98                  1`..lð.g.4˜

004014: Bulk or Interrupt Transfer (UP), 2020-07-13 01:19:20.3276623 +0.0149938. (1. Device: Playback) Status: 0x00000000
Pipe Handle: 0x5d04988 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
 31 60                                             1`

004016: Bulk or Interrupt Transfer (DOWN), 2020-07-13 01:19:20.3342168 +0.0065256 (1. Device: Playback)
Pipe Handle: 0x5d049b8 (Endpoint Address: 0x2)
Send 0x1 bytes to the device
 07                                                .

004018: Bulk or Interrupt Transfer (DOWN), 2020-07-13 01:19:20.3348310 +0.0001965 (1. Device: Playback)
Pipe Handle: 0x5d049b8 (Endpoint Address: 0x2)
Send 0x7 bytes to the device
 6C 10 F0 27 02 FB 19                              l.ð'.û.

004020: Bulk or Interrupt Transfer (UP), 2020-07-13 01:19:20.3436530 +0.0080131. (1. Device: Playback) Status: 0x00000000
Pipe Handle: 0x5d04988 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
 31 60                                             1`

004022: Bulk or Interrupt Transfer (UP), 2020-07-13 01:19:20.3596428 +0.0159692. (1. Device: Playback) Status: 0x00000000
Pipe Handle: 0x5d04988 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
 31 60                                             1`

004024: Bulk or Interrupt Transfer (UP), 2020-07-13 01:19:20.3606389 +0.0009746. (1. Device: Playback) Status: 0x00000000
Pipe Handle: 0x5d04988 (Endpoint Address: 0x81)
Get 0xa bytes from the device
 31 60 07 00 6C F0 10 67 02 34                     1`..lð.g.4

[In-Tech]

Tazzi,
Just to save a bit of time...what transactions do you want to see? Let me address that one task at a time so I can reply and you can play with that information as I look for the next task. As you can see by the time stamp, it does a pretty good job of sampling

[Tazzi]

Yeah, thats alot more readable. They could be applying a basic encryption which make it look all garbage if monitoring a commercial tool.

If you have an ELM, you can set it up to monitor traffic using a serial terminal. Itll fail once it goes to highspeed, but we dont care about actually seeing highspeed, we just need to actual be able to go to highspeed!

Using an ELM, just need to use:
ATL1
ATH1
ATSP1
ATMA

This turns on the line feed, turns on headers, sets protocol to PWM and then finally monitors all traffic

[Tazzi]

Tazzi,
Just to save a bit of time...what transactions do you want to see? Let me address that one task at a time so I can reply and you can play with that information as I look for the next task. As you can see by the time stamp, it does a pretty good job of sampling

We are looking specifically at the seed/key stuff and what happens after that.

So it should be something like:
64 10 F1 27 01
64 F1 10 67 01 00 XX

64 10 F1 27 02 MM NN
64 F1 10 67 02 34

Something like that I am expecting. Where XX seems to be the rolling seed on the EECV ecus, so the total seed is 00XX.
Then the key is MMNN.

Once I can see a few of these attempts, I can start trying to track down where this occurs in IDS. I found a DLL labelled securityAlg.... so... one would think its running here

[In-Tech]

OK, cool. I am on it It's 11pm here, we'll see how far I get 'till I have to crash.

[In-Tech]

Hiya Tazzi,
I found one of my notes from ~2 years ago...

18v FEPS required
FF C4 10 F2 27 01
FF C4 F2 10 67 01 EF F1 DF
FF C4 10 F2 27 02 64 BE
FF C4 F2 10 67 02 34
Do it again for high speed mode
FF C4 10 F2 27 01
FF C4 F2 10 67 01 07 09 CF
FF C4 10 F2 27 02 43 CB
FF C4 F2 10 67 02 34
Note to self, diff seed and seems like it's a diff key calc on second request to enter high speed.

I'm not so good at the seed/key calc stuff From memory, I think that is when I lost interest
See if this helps. I'm hooking up a Y cable to do some manual logging after the interface

[Tazzi]

Hiya Tazzi,
I found one of my notes from ~2 years ago...

18v FEPS required
FF C4 10 F2 27 01
FF C4 F2 10 67 01 EF F1 DF
FF C4 10 F2 27 02 64 BE
FF C4 F2 10 67 02 34
Do it again for high speed mode
FF C4 10 F2 27 01
FF C4 F2 10 67 01 07 09 CF
FF C4 10 F2 27 02 43 CB
FF C4 F2 10 67 02 34
Note to self, diff seed and seems like it's a diff key calc on second request to enter high speed.

I'm not so good at the seed/key calc stuff From memory, I think that is when I lost interest
See if this helps. I'm hooking up a Y cable to do some manual logging after the interface

Somethings better then nothing!

Interesting that I have FEPs on (18v), yet I don't seem to get a varying 2byte value for the seed. Mine is always just 1 byte changing.

Next, I thought there might be a change in the level requested for the seed/key when doing highspeed... as in: 27 03 instead of 27 01.
Maybe thats not actually done?

A log of the whole process until it actually stops seeing data would be perfect!

Looking at the above, we have:
Seed: EF F1
Key: 64 BE

And

Seed: 07 09
Key: 43 CB

*Edit
I absolutely have FEPs enabled (18v), yet I always receive back something like this: C4 F2 10 67 01 00 15 B3
Where C4,F1,20 = header.
67 = security mode response
01 = request seed
00 15 = seed
B3 = PWM checksum

Every single time, its 00XX. I feel like the AU ECUs are just absolutely cooked, which is why there no information online about them