(Needs Testing) Additional fields in Variant Coding

[jglim]

Context

There appears to be a few distinct types of variant coding:

(1) Variant Coding String only

The simplest type only require a constant write-command and the actual variant string. There is no guesswork required, since we have all the information to send the command.

• 0 : Variant coding string

(2) Variant Coding String + Fingerprint

The more common variant-coding commands usually specify for a fingerprint of the tester-client. In Vediamo, the last value is typically 00 00 00 01. Diogenes will try to copy the last author's fingerprint, so the variant string will appear unmodified.

• Varcodestring : Variant coding string

• ‌0, #‌1, #‌2, #‌3 : Fingerprint

(3) Variant Coding String + Fingerprint + Additional Field(s)

There are some commands that specify additional fields. At present, Diogenes uses the same behavior for copying the fingerprint, where it uses the last-read value as the output value. However this behavior is unverified.

• Varcodestring : Variant coding string

• ‌0 : Additional Field (in this case, the 16-character SCN)

• ‌1, #‌2, #‌3, #‌4 : Fingerprint

• ‌5 : Variant coding string

How to help

To find out if Diogenes's behavior is correct, please submit logs/traces of official clients (DTS/Vediamo) when writing to a ECU that has variant-coding behavior that is similar to (3).

To check the variant-coding type (1/2/3), double click Execute Diagnostic Service under your variant, and search for WVC_, and pick the right option.

If the values are sensitive, they can be censored with a invalid hex value (e.g. 31 32 XX XX XX XX 37 38).

What I'm particularly looking out for

In the example of (3), I will be checking for the SCN field when the variant-string is read and written:

• If the RVC contains the SCN, and the WVC writes the same SCN, no changes are required (current Diogenes behavior)
• If the RVC contains the SCN, and the WVC writes all 00 00 .. 00 for SCN, minor changes are required
• If the RVC contains 00 .. 00 for SCN, and the WVC writes a non-zero value for SCN, this will be a breaking change

[jglim]

Update on: (3) Variant Coding String + Fingerprint + Additional Field(s)

@Feezex has provided logs for CR4_NFZ that shows an interesting perspective of behavior (3) in this thread.

Cmd     Variant String    SCN                                              Fingerprint
61 01   91 08 59 00 00    30 30 36 34 34 38 30 33 34 30 31 35 30 30 30 33  00 03 03 60  // original, unmodified
3B 01   91 88 51 00 00    30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  00 10 09 25  // write
61 01   91 88 51 00 00    30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  00 10 09 25  // read back

The client apparently resets the SCN, from 0064480340150003 to 0000000000000000. Interestingly, it also writes a different signature value of 00 10 09 25 instead of the usual 00 00 00 01.

I have replicated the test above, and can confirm that the SCN reset behavior on my setup, however the fingerprint in my case is still 00 00 00 01.

Cmd     Variant String    SCN                                              Fingerprint
61 01   91 08 59 00 00    30 30 36 34 34 38 30 33 34 30 31 35 30 30 30 33  00 03 03 60  // original, unmodified
3B 01   91 88 51 00 00    30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  00 00 00 01  // write
61 01   91 88 51 00 00    30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  00 00 00 01  // read back

I have also replicated this behavior on an emulated MED40:

Cmd         Variant String                                                                              SCN                                                Fingerprint
62 10 01    36 36 00 E5 17 41 09 57 83 41 89 3E 50 14 40 20 00 21 00 01 10 01 01 01 00 10 00 00 00 00   31 32 33 34 35 36 37 38 31 32 33 34 35 36 37 38    00 40 33 10
2E 10 01    36 36 00 E5 17 41 09 57 83 41 89 3E 50 14 40 20 00 21 40 01 10 01 01 01 00 10 00 00 00 00   30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30    00 00 00 01
62 10 01    36 36 00 E5 17 41 09 57 83 41 89 3E 50 14 40 20 00 21 40 01 10 01 01 01 00 10 00 00 00 00   30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30    00 00 00 01

The results are the same as my CR4_NFZ test, where the SCN is reset and the fingerprint was set to 00 00 00 01.

Implications

SCN: The "correct" behavior seems to be resetting all written SCN values to zeroes. I do not know if there are any side effects to this, so I will look into adding an option in Diogenes to behave like Vediamo when writing SCN fields in a variant-coding operation.

Fingerprint: Currently no change, still investigating why Sergey's fingerprint is different 00 10 09 25. I have a strong guess that the fingerprint is the SDConnect serial number, so any number can be used here. (J2534 = 00 00 00 01)

Apparently 100925 is a "famous" C4 serial number.

[Feezex]

ohh now i see 00 10 09 25 -100925 is s\n for my c4 ive been using it during VC, and looks like SM2 identify as J:1 so must be 00 00 00 01

[jglim]

Thanks for the confirmation, this fills up an important missing piece of the puzzle.

For now, Diogenes will clone the last fingerprint, though I will look into adding an option for writing different signatures.

[jglim]

Just a minor update, I can now confirm with certainty that the fingerprint value is the hardware card ID, specifically it retrieves this value using c32s.dll from the RMGetCardID function. As a test, I patched the function to always return my card ID as 12345678, and it seems to work, even on J2534 where it should normally be 00 00 00 01.

01 19 30 46 → 12 34 56 78

With the fingerprint out of the way, v1.4.7 should be capable of nearly identical behavior as Vediamo for variant-coding many common ECUs. (Configure Diogenes to SCN Mode → Write Zeros (Vediamo) and Fingerprint Mode → Custom Value: (1))

[N0cynym]

Hi I found in some smr-d files the exact composition from the fingerprint. I'm not really sure if they updated the size of information they are included but I can write it down if you want.

[jglim]

Sure, that would be great. If the files are bound by copyright issues, let me know if I can find it in my own Vediamo installation or library (e.g. filename)

[N0cynym]

1. Well you need following Program Files\Softing\Diagnostic Tool Set x\x.xx\bin\DatabaseDiffer.exe x means your version
2. Go to Program Files\Mercedes-Benz\Xentry\Kontexte\ODXProjekte\PKW_COMMON\dbr and chose for example vgsnag3.smr-d
3. Seach for PR_ReadFingerprint_Read

[jglim]

This issue seems to be fixed now, so it will be closed. If there are more fields beyond fingerprint and SCN, this will be the right issue to resume from.