New tool: udsinterpreter

[maziu]

Hello,
I'm extending can-utils toolset for my personal usage, and wanted to discuss whether these tools may be useful to be added to repo.
I've created tool for finding possible ISO TP traffic on a bus, and interpreting frames as UDS services.
Goal is to create tools for preliminary analysis of network/devices structure. I find them useful for analysis of unknown high-load buses, as isotp* tools right now needs source and desination addresses, which may be unknown at the beginning.

Please have look at these use cases:

Simply interpret candump frames as UDS and display possible match:

$ candump -t z vcan0 | ./udsinterpreter -r   
[601] 22 0B 0C 0D 0E 0F AA AA 
[601] [SRQ] ReadDataByIdentifier DID: 0x0B0C
[600] 22 3E 39 38 3B 3A 55 55 
[600] [SRQ] ReadDataByIdentifier DID: 0x3E39
[600] 21 31 30 33 32 3D 3C 3F 
[600] [SRQ] Unknown service

Interpret each frame from candump as separate one - find ISO TP type and (for Single and First frames) perform UDS analysis

$ candump -t z vcan0 | ./udsinterpreter -r -i -u
[600] 02 27 05 55 55 55 55 55  ISO TP Type: Single Len:    2  | [SRQ] SecurityAccess Sub: Unknown (0x05)
[600] 30 00 0A 55 55 55 55 55  ISO TP Type: FlowCt IDX:    0
[601] 21 04 05 06 07 08 09 0A  ISO TP Type: Consec IDX:    1
[601] 22 0B 0C 0D 0E 0F AA AA  ISO TP Type: Consec IDX:    2
[600] 10 12 27 06 35 34 37 36  ISO TP Type: First  Len:   18  | [SRQ] SecurityAccess Sub: Unknown (0x06)
[600] 22 3E 39 38 3B 3A 55 55  ISO TP Type: Consec IDX:    2
[600] 21 31 30 33 32 3D 3C 3F  ISO TP Type: Consec IDX:    1
[601] 30 00 01 AA AA AA AA AA  ISO TP Type: FlowCt IDX:    0
[601] 02 67 06 AA AA AA AA AA  ISO TP Type: Single Len:    2  | [PSR] SecurityAccess Sub: Unknown (0x06)
[600] 04 31 01 05 73 55 55 55  ISO TP Type: Single Len:    4  | [SRQ] RoutineControl Start routine (0x01) ID: 0x0573 data:55 55 55 
[601] 04 71 01 05 73 AA AA AA  ISO TP Type: Single Len:    4  | [PSR] RoutineControl Start routine (0x01) ID: 0x0573 data:AA AA AA 
[601] 10 12 67 05 00 01 02 03  ISO TP Type: First  Len:   18  | [PSR] SecurityAccess Sub: Unknown (0x05)

Interpret each frame from isotpsniffer (or isotprecv) as UDS message, display possible match (sorry for 'unknown service' here, I don't have good traffic at the moment here, it will display found service in a same way as in the use cases above)

$ ./isotpsniffer -s 1da -d 482 -q -t z -f 1 vcan0 | ./udsinterpreter -r 
[482] 00 1E 32 02 08 02 3A 12 12 10 E2 9A 94 2C A8 DB B4 B3 33 36 E3 D2 A6 C7 19 8A 52 04 0A 02 08 05 
[482] [???] Unknown service
[482] 00 20 32 02 08 02 3A 12 12 10 E2 9A 94 2C A8 DB B4 B3 33 36 E3 D2 A6 C7 19 8A 52 06 0A 04 08 06 20 02 
[482] [???] Unknown service

Do you find that useful?
Any comments about formatting? What do you think about using the tool with pipe, not as standalone?

[olerem]

Looks interesting interesting as for me, i would love to have it for j1939 ;) . @hartkopp , what do you think?

[hartkopp]

Isn't this already part of isotpdump?

[hartkopp]

Just to follow up on this pending discussion:

First the use of the "human readable" candump output is a bad idea as it would make much more sense to use the compact log-file format. And then also use the functions provided by lib.c and lib.h.

Another approach could be to move the entire UDS decoding stuff from the current isotpdump into some uds.h and uds.c files. This UDS decoding can then be used similar to lib.[ch] either from isotpdump and isotpsniffer.

@olerem : is there any substantial difference between ISO-TP and UDS for automotive diagnosis and its use in J1939?

[maziu]

@hartkopp ISO-TP is transport protocol (like TCP in TCP/IP stack), while UDS is application layer.
ISO-TP can carry different data than UDS, however, most common use case is actually transporting UDS.
But UDS frames can exist on a bus without ISO-TP (only single ones, but seen cars that use only them).

Imho it makes sense to extract UDS to separate library, however, I can't decide which one.

I'm willing to work in next few weeks moving uds interpreter to separate library if you find if neccessary - I'm using these tools now daily and can contribute to them.

Also, answering your previous comment - it's partially in the isotpdump right now. However, when analysing unknown traffic on a bus (eg. reverse engineering) it's not practical. Isotpdump required source and target address, and use case described by me helps to find interesting addresses, by analysing all of them.

[hartkopp]

@hartkopp ISO-TP is transport protocol (like TCP in TCP/IP stack), while UDS is application layer. ISO-TP can carry different data than UDS, however, most common use case is actually transporting UDS. But UDS frames can exist on a bus without ISO-TP (only single ones, but seen cars that use only them).

Yes, I'm aware what UDS looks like. You can also put it on top of IP with DoIP.

Imho it makes sense to extract UDS to separate library, however, I can't decide which one.

Maybe "library" is a bit too high level naming. My wish would be to minimize code duplication and simply have UDS definitions in one place. Mainly moving these definitions out of isotpdump and make them accessable for isotpdump and isotpsniffer.

I'm willing to work in next few weeks moving uds interpreter to separate library if you find if neccessary - I'm using these tools now daily and can contribute to them.

Thanks! That's very valuable that you use these tools and therefore can form requirements.

Also, answering your previous comment - it's partially in the isotpdump right now. However, when analysing unknown traffic on a bus (eg. reverse engineering) it's not practical. Isotpdump required source and target address, and use case described by me helps to find interesting addresses, by analysing all of them.

Ah, ok. Got your point.

Although isotpsniffer got a new feature to monitor broadcast/functional addressing yesterday (367e0df), you would like to have a tool which not only displays a single UDS communication but can show multiple UDS interactions??