Welcome to CaesarSuite Discussions!

[jglim]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[Feezex]

HI mate! I wonder your great work!
I have acces to some ecus, have alot equipment to work with, so we can colaborate in testing with real hardware\car.
What functios id like to see in future:

• recompile (Import) flash segments. Here i have solution so i can give you examples of same CFF's with different data(last 4 bytes is CS).
• variant coding (explain please why its still undone =) )
• how about SMR-D usage.
• FlashJob: WVC_FlashProg

[jglim]

Hi Feezex,

Appreciate your offer.

• FlashJob: WVC_FlashProg : Unfortunately this depends on diagnostics code which is a significant project on its on and is therefore unimplemented. You might have better results looking at jar files from SMR-D instead.

• SMR-D: I have published the basic decryption format for SMR/ODB files so that someone else might build a full parser for it. My ODBExtract tool demonstrates basic usage of the ODB library. I do not plan to look further into it at this time as it requires a lot of effort.

• Variant coding: I wrote about the issue in this section. Originally, the client seems to depend on diagnostics code (same problem as WVC-FlashProg).

  • When attempting to guess the data without being able to run diagnostics code, there seems to be about 4 bytes which are unaccounted, which may lead to unexpected issues. If you have any idea on how this works, please let me know and I can try to fix it. In my case, when I use Vediаmο, the 4 bytes are usually 00 00 00 01.

• Flash recompilation:

  • There is already basic extraction capability in Diogenes v1.3 that verifies the container's checksum.
  • However the reassembly will be more difficult as there are several tables that I ignored (unused when extracting). If you are trying to use the content of another CFF file, it might be possible if both CFF files are very similar (e.g. same CPU, different variant).
  • Can you explain further on how you plan to use it so that I can understand better? You can also let me know the flash name (e.g. 6519023101_001) and I will fetch it myself. (Please do not upload any copyrighted material here)

[JackDalton2A]

Hello jglim,
I would like to express my greatest respect and thank you very much for this great achievement. I signed up here under a different name to say that. Because unfortunately the reverse engineer is not so popular in my home country. But that's a different topic.
I would like to see the conversions methods (or values as input to this methods). If they are in ODX, that would be DATA-OBJECT-PROPERTY, but I don't know what the technical term in CBF format is. ODX knows these compute methods TEXTTABLE, IDENTICAL, LINEAR, RAT_FUNC, TAB_INTP and COMPUCODE. And I think something similar should be found in the CBF.

that's it for now :-)

[jglim]

Hi JackDalton,

Thank you for your kind words. I hope the situation in your country improves.

I do not know if I am answering your question correctly (I don't know SMR-D well enough), but I will try.

Data conversion occurs in a few stages. Lets take a look at CRD3::DT_2007_IN_Battery_voltage
First, the diagnostics service will usually specify one or more output preparations which may contain presentations.

When the diagnostics service is executed and receives a non-negative response, the presentations can interpret the ECU reply and generate a human-readable value.

The presentation specifies the data type (e.g. hexdump, string, integer, scaled value, booleans). The presentation will also specify the start position, length, so parsing most of them should be intuitive. Scaled values might be interesting for you as there is a conversion process. Inside the PRESENTATION structure, there is a list of SCALE structures (typically one). The scale may specify conversion offset and factor.

For the DT_2007 example, the ECU responded with 62 20 07 05 FC.

• 62 : UDS Read Data By Identifier
• 20 07 : Identifier
• 05 FC : Value (IN_Battery_voltage), big endian integer = 0x5FC = 1532

How does 1532 become 11.968750? The output presentation specifies a SCALE with a offset (addition) of 0, and a factor (multiplication) of 0.0078125.

1532 × 0.0078125 + 0 = 11.968750

The unit of measurement ("V") is also included in the output presentation. Putting it all together, you will get 11.968750 V.

[JackDalton2A]

Hello jglim,

Yes exactly. I would like to see the factor and the offset and the endiness. And ideally before I have sent the request (without an ECU). I would like to copy a measured value here and there when I tinker with my Arduino board. Sometimes it is easier to send a Diganose Service than to trace the internal CAN bus for hours to find the right message.

by the way your project inspired me to get everything out of it again. Now I'm ready to go. Unfortunately, I still have to find time.

Thanks :-)

[jglim]

That's a cool idea, especially since it is non-invasive. I'm glad to see that you can build the project locally. This specific debug print may be helpful in your endeavour as it can fetch the conversion values and load it into your Arduino :

CaesarSuite/Caesar/Caesar/Scale.cs

Line 60 in c54470c

public void PrintDebug()

I hope you succeed, and if you feel like it, do share about it so that I can learn from you :^)

[Feezex]

• tried to open CR4_NFZ.cbf - got an error (Check plz whats wrong with opening it);
• Heres an example of ori and modded with my tool cff's - (thats not some kind of real modifying flash) so what i've done - filled Section 40000 with 00, then exported modified file to cff. This "incorrect" file would 100% be accepted by DAS - so same with any other software. Last 4 bytes become to be a file CS.

[Feezex]

Actually i created an account here to be a part of this project and want to help you as much as i can.
So can provide you with access to "test" ecu or ...whatever you wish.
Give me some tasks so i can give you more informative answers, so this how we can move forward

[Feezex]

!!! Add a search option (Ctrl+F)... in some ecu scrolling takes too much time

[jglim]

Hello Feezex,

The new https://github.com/jglim/CaesarSuite/releases/tag/v1.3.2 may address some of your concerns.

CR4_NFZ:

CR4_NFZ appears to have one specific communication parameter that does not have a name to it. I am skipping it for now instead of crashing, so it should load properly now.

CFF modification

I have added a CFF splicing tool that allows for some CFF payload modification. It uses the original CFF file as a base, and allows the flash binary to be changed. The flash payload can be of a different size, and the destination ECU memory address can also be changed.

This method has some limitations, for example, sections cannot be added or deleted (edit-only).

I have tried it with your files (original CFF + modified 40000 segment), and the generated result is 100% identical to your modified CFF. This is very experimental, please let me know if it works or not as I have no experience with CFF flashing. It may be a good idea to try it on something cheap.

Search

Can I check if this is the feature that you might be looking for? Search is available on the top textbox

Search is available at the root level (no variant filtering) and variant level (only relevant to the selected variant) so I did not map it to the Ctrl+F hotkey.

Help

Thank you for offering your assistance. At the moment, I cannot think of a specific task for you. Can I suggest that you log and share your trace whenever you perform any variant-coding?

Before you start work on an ECU, activate tracing first.

When you are done, can you copy the trace values, and share them here? (along with CBF name and any comment that you might like to add)

Thanks again for your support.

[N0cynym]

Test vgsnag2

Vediamo

VCD_SCN_Variantencodierung_VGS_73

ID	Data
07E1	02 21 B1 55 55 55 55 55
07E9	10 30 61 B1 79 31 72 61
07E1	30 08 0A 55 55 55 55 55
07E9	21 0A 00 00 01 00 02 02
07E1	02 3E 00 00 00 00 00 00
07E1	30 00 0A 00 00 00 00 00
07E9	22 06 06 06 00 02 00 00
07E9	23 01 01 05 03 02 02 01
07E9	24 00 C7 00 01 07 04 0B
07E9	25 E8 03 E8 03 C6 07 C2
07E9	26 01 DF 70 90 55 68 00

Result = Y1RA

Diogenes

VCD_SCN_Variantencodierung_VGS_73

Starting VC for VGSNAG2 (VGS3_0403) with domain as VCD_SCN_Variantencodierung_VGS_73 Default variant coding data has been found and loaded Requesting variant coding read: RVC_SCN_Variantencodierung_VGS_73_Lesen : (21B1) Running diagnostic request : RVC_SCN_Variantencodierung_VGS_73_Lesen (21 B1) Send: 21 B1 Receive: 61 B1 79 31 72 61 0A 00 00 01 00 02 02 06 06 06 00 02 00 00 01 01 05 03 02 02 01 00 C7 00 01 07 04 0B E8 03 E8 03 C6 07 C2 01 DF 70 90 55 68 00 InternalDiagJob: 61 B1 79 31 72 61 0A 00 00 01 00 02 02 06 06 06 00 02 00 00 01 01 05 03 02 02 01 00 C7 00 01 07 04 0B E8 03 E8 03 C6 07 C2 01 DF 70 90 55 68 00 Variant coding received: 61B1793172610A000001000202060606000200000101050302020100C7000107040BE803E803C607C201DF7090556800

ID	Data
07E1	02 21 B1 00 00 00 00 00
07E9	10 30 61 B1 79 31 72 61
07E1	30 00 0A 00 00 00 00 00
07E9	21 0A 00 00 01 00 02 02
07E9	22 06 06 06 00 02 00 00
07E9	23 01 01 05 03 02 02 01
07E9	24 00 C7 00 01 07 04 0B
07E9	25 E8 03 E8 03 C6 07 C2
07E9	26 01 DF 70 90 55 68 00

Result = (warning: no matching subfragment)

I hope this style of report is ok. I will set VC tomorrow and check function.
At time I'm a bit busy but you'll get better reports as soon as possible.

[jglim]

Thanks for your traces, the raw frames are an interesting perspective.

I have tried to interpret the variant code in your logs 793172610A000001000202060606000200000101050302020100C7000107040BE803E803C607C201DF70 and it shows Y1RA. Does the VCD_SCN_Variantencodierung_VGS_73 behave similarly to below?

From your logs, I believe that the last 4 bytes in a variant code is the signature of the last system that performed the variant coding. I cannot confirm it, but if this is true, it may be one of the ways to detect if a variant-coding has been adjusted by a third party (since this value is normally not exposed even in Vediamo). With this, I will try to enable writing VC with Diogenes to reuse the last fingerprint.

Edit 18/12: The latest release allows VC writes without recompiling.

[Feezex]

Vedi\trace
EZS906.cbf varinat NCV3_0301
request for:
VCD_Variantcodierung
(3.Bremsleuchte - Nicht vorhanden / new value vorhanden)
18:41:08 Request:
21 72
18:41:08 EZS906:
61 72 01 00 03 87 98
18:41:14 Request:
21 70
18:41:14 EZS906:
61 70 9A 00 E5 5C 2D 00 14 0B 12 00 A8 00 07 15
80 00 3F 4E 4E 04 00 00 16 92 00 08 00 7F 00 00
00 00 00 00 00 00 00 10 50 01 24 00 03 87 98
18:41:37 Request:
3B 70 9A 00 E5 5C 2D 00 14 0B 12 00 A9 00 07 15
80 00 3F 4E 4E 04 00 00 16 92 00 08 00 7F 00 00
00 00 00 00 00 00 00 10 50 01 24 00 00 00 01
18:41:37 EZS906:
7B 70
18:41:37 Request:
21 70
18:41:37 EZS906:
61 70 9A 00 E5 5C 2D 00 14 0B 12 00 A9 00 07 15
80 00 3F 4E 4E 04 00 00 16 92 00 08 00 7F 00 00
00 00 00 00 00 00 00 10 50 01 24 00 00 00 01

(Akkuhorn - Nicht vorhanden / new value vorhanden)

18:47:26 Request:
21 70
18:47:26 EZS906:
61 70 9A 00 E5 5C 2D 00 14 0B 12 00 A9 00 07 15
80 00 3F 4E 4E 04 00 00 16 92 00 08 00 7F 00 00
00 00 00 00 00 00 00 10 50 01 24 00 00 00 01
18:47:37 Request:
3B 70 9A 00 E5 5C 2D 00 14 0B 1A 00 A9 00 07 15
80 00 3F 4E 4E 04 00 00 16 92 00 08 00 7F 00 00
00 00 00 00 00 00 00 10 50 01 24 00 00 00 01
18:47:37 EZS906:
7B 70
18:47:37 Request:
21 70
18:47:38 EZS906:
61 70 9A 00 E5 5C 2D 00 14 0B 1A 00 A9 00 07 15
80 00 3F 4E 4E 04 00 00 16 92 00 08 00 7F 00 00
00 00 00 00 00 00 00 10 50 01 24 00 00 00 01

[Feezex]

• BTW Diogenes wont open coding to compare with vediamo
• CFF updates is perfect!! for now this part seems to be done !! Applause

[jglim]

Like the other log #1 (reply in thread) , it may be an issue with KW2C3PE. I will look into it.

Glad to hear that the CFF patch meets your requirements. If you ever flash a device with a modified CFF, please let me know again if it works on real hardware.

[Feezex]

One more with my notes
TRACE.txt
Tried to contact EZS906.cbf with diogenes - it connects and show batt voltage /... variant no luck ... no further data can be received

[jglim]

Thanks for your traces, they are very helpful. Appreciate the effort to add the extra comments too.

It may be an issue with KW2C3PE, I will investigate and update you again as I make progress.

---

Edit: Can I check if this was the first time that the EZS906 has ever been variant-coded? I noticed this in your trace:

18:41:14 EZS906:
61 70 9A 00 E5 5C 2D 00 14 0B 12 00 A8 00 07 15
80 00 3F 4E 4E 04 00 00 16 92 00 08 00 7F 00 00
00 00 00 00 00 00 00 10 50 01 24 00 03 87 98
18:41:37 Request:
3B 70 9A 00 E5 5C 2D 00 14 0B 12 00 A9 00 07 15
80 00 3F 4E 4E 04 00 00 16 92 00 08 00 7F 00 00
00 00 00 00 00 00 00 10 50 01 24 00 00 00 01

The section that I now believe is a fingerprint has changed after the variant-coding was done, from 00 03 87 98 to 00 00 00 01 which is similar to my own experience with the CRD3.

[JackDalton2A]

Hi jglim,
i found a the old original export file .. maybe it will help you. Do you have any idea what the translation is based on? Name? Long-Name?Qualifier?
CDID2_TO_fILE.zip
:-)

[jglim]

Hi JackDalton,

The text file that you found is a CRD2 CBF file that was run through CxFViewer and exported as a text file report. Most CBF files have this "Translation" text in the header which appears to be autogenerated by the authoring tools, but I do not know more than this (doesn't seem to be required when parsing the CBF file).

Most tools that work with CBF will display qualifiers by default, since it does not require additional processing (vs reading from the string table). It is an interesting find, since CxFViewer seems to get exponentially slower as the input filesize increases; someone must have been very patient.

[Feezex]

How about :

• Tab that can show all possible ecu faults in list from loaded CBF.
• Frame with Ecu live faults state (current/stored/active) - Read & Erase functions

[Feezex]

yes, just exporting fault codes list, like DAS system can show all avaliable faults for current ecu.
I spent some time to trace out ecu erase process, seems it not that complicated, so far i have question -is there a way to create direct sending of packets, and for example creating a list and order of sending data by specific id's?

[jglim]

I'll look into adding the ability to export all fault codes, there should be no issues from a technical standpoint.
On your question on ECU erase process, can you help me understand with an imaginary trace example (with comments)?

[Feezex]

yes already done bunch of traces with all process, but wish that stay more private. Already informed you with my whatsapp several times.

[jglim]

I've written about communicating with me using private channels here.
I do not use (or intend to use) whatsapp, alternatives are available in that post. Hope you can understand, and again, appreciate your presence and contributions thus far.

[jglim]

RE: #1 (reply in thread) :

v1.5.1 includes an option to show all DTCs, that can be copied to another application for exporting (e.g. Excel)

[Feezex]

TRACES.zip
i bet youll find some answers

[jglim]

Thanks for the hard work Sergey, your logs are good; thanks for organizing them too. I will need some time to read through all of them.

Variant identification

For now, I am confident enough to add variant identification support for 1A 86 and 1A 87.
I notice CR4NFZ responding to 1A 9C and 1A 9D too, and I will look further into it.

VC Fingerprint

I noticed in the trace CR4NFZ_VC_NSG_KLIMA_TEMPOMAT______FINGERPRINT OR CS.txt that the written fingerprint is 00 10 09 25, which is unusual as I was expecting 00 00 00 01. Do you have any suggestions to explain the unusual behavior? (Vediamo version difference?)

03:19:17 Request:
         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 

Furthermore, the original SCN appears to be overwritten with 0000000000000000. The subsequent read confirms that the SCN has changed.

03:19:18   CR4_NFZ:
           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 

Also, here is a reference of some of the other observed variant-coding read/writes:

        91 88 51 00 00

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
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
61 01   91 08 59 00 00    30 30 36 34 34 38 30 33 34 30 31 31 30 30 30 32  00 30 10 65  // compare with C10V (1)
61 01   91 88 59 00 08    30 30 36 34 34 38 37 39 34 30 31 31 30 30 31 36  00 30 10 65  // compare with C10W (2)
61 01   91 08 59 00 00    30 30 36 34 34 38 30 33 34 30 31 35 30 30 36 30  00 04 98 94  // compare with C10V (3)

I also noticed that C10V (1) has the same fingerprint as C10W (2), but the SCN and variant string are different. I hope this indicates that the fingerprint does not affect the ECU operations, and is simply a form of metadata.

If the fingerprint does not affect ECU operations, the existing Diogenes operation should work OK. Diogenes will copy the last SCN and fingerprint, so the write operation will look like this:

        12 34 56 78 9A

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
3B 01   12 34 56 78 9A    30 30 36 34 34 38 30 33 34 30 31 35 30 30 30 33  00 03 03 60  // theoretical Diogenes write

[jglim]

I've been trying to understand why the fingerprint in your CR4_NFZ is different in your uploaded file CR4NFZ_VC_NSG_KLIMA_TEMPOMAT______FINGERPRINT OR CS.txt, where it changed from 00 03 03 60 to 00 10 09 25.

I built an ECU emulator to try and repeat your work. However, in my case, the fingerprint value (original 00 03 03 60) changed to 00 00 00 01 even though the trace looks pretty much 100% identical.

Setup looks like this:

                                  HSCAN               J2534
[ESP32 + CAN transceiver + 120Ω] ------- [OpenPort2] ------- [Vediamo 04.02.02 (WinXP)]

• Set protocol to KW2C3PE
• Init Contact (CR4_NFZ_Diag_54h)
• Variant Coding → set NSG_Klima_Tempomat

Maybe there is something different in our setup that I did not consider. (e.g. are you using J2534, or Actia C3/C4?).
Edit: I believe that was written with a C4, awaiting Sergey's confirmation. Please look at the comment here: #14 (comment)

My logs are below:

ECU Emulator

==============================
ECU_VariantCoding
91 08 59 00 00
ECU_Fingerprint
00 03 03 60
ECU_SoftwareCalibrationNumber
30 30 36 34 34 38 30 33 34 30 31 35 30 30 30 33
ECU_EROTAN
01 02 03 04 05 06
==============================
ECU Initialized

Receive: Buffer: 7E0 [2] 10 92
Changing session level to 146
Send: Buffer: 7E8 [2] 50 92

Receive: Buffer: 7E0 [2] 1A 86
Identify 86
Send: Buffer: 7E8 [18] 5A 86 00 44 46 79 40 31 06 46 06 03 4A 54 00 07 08 12

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 21 01
Read Data By Identifier 1
Read: ECU Coding (+SCN)
Send: Buffer: 7E8 [27] 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

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Receive: Buffer: 7E0 [27] 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 Data By Identifier 1
Writing to VC (+SCN)
Valid VC received, committing..
Send: Buffer: 7E8 [2] 7B 01
==============================
ECU_VariantCoding
91 88 51 00 00
ECU_Fingerprint
00 00 00 01
ECU_SoftwareCalibrationNumber
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
ECU_EROTAN
01 02 03 04 05 06
==============================

Receive: Buffer: 7E0 [2] 21 01
Read Data By Identifier 1
Read: ECU Coding (+SCN)
Send: Buffer: 7E8 [27] 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

Receive: Buffer: 7E0 [2] 3E 01
Tester Present
Send: Buffer: 7E8 [2] 7E 01

Vediamo 04.02.04:

00:11:57   CR4_NFZ:
           50 92 
----------------------------------------------------------------------------------
00:11:57 Request:
         1A 86 
00:11:57   CR4_NFZ:
           5A 86 00 44 46 79 40 31 06 46 06 03 4A 54 00 07 
           08 12 
----------------------------------------------------------------------------------
00:12:00 Request:
         21 01 
00:12:00   CR4_NFZ:
           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 
----------------------------------------------------------------------------------
00:12:23 Request:
         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 
00:12:23   CR4_NFZ:
           7B 01 
----------------------------------------------------------------------------------
00:12:23 Request:
         21 01 
00:12:23   CR4_NFZ:
           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 

[Feezex]

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
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
61 01 91 08 59 00 00 30 30 36 34 34 38 30 33 34 30 31 31 30 30 30 32 00 30 10 65 // compare with C10V (1)
61 01 91 88 59 00 08 30 30 36 34 34 38 37 39 34 30 31 31 30 30 31 36 00 30 10 65 // compare with C10W (2)
61 01 91 08 59 00 00 30 30 36 34 34 38 30 33 34 30 31 35 30 30 36 30 00 04 98 94 // compare with C10V (3)

The thing you call SCN out of this data.
30 30 36 34 34 38 30 33 34 30 31 35 30 30 30 33 = sw 0064480340 150003
30 30 36 34 34 38 30 33 34 30 31 31 30 30 30 32 = sw 0064480340 110002
30 30 36 34 34 38 37 39 34 30 31 31 30 30 31 36 = sw 0064487940 110016

Im quiet sure if the Software Calibration Number - contain only SW number and mnf date - then there would be no need to create online access. Till now i cant prove or disprove what SCN actually is - as for me it represent checksum. And Variables for it may be taken from HW/SW/VIN etc

[jglim]

Now that you mention that it is a date format, it makes sense as my 16-character SCN also ends in a YY-MM-DD format. The reason that I called this field "SCN" is from the CRD3's Diagnostic service name:

DT_SCN_Lesen (22 10 01)
PRES_16ByteASCII: 6519010601150231  (StringType)

This service is ReadDataByIdentifier with identifier 0x1001

The matching WriteDataByIdentifier with identifier 0x1001 brings us to the function WVC_CRD3_explizit_unrestricted (Write Variant Coding), with the usual variant string + fingerprint + SCN. Notice that the byte position and data size are identical.

For this reason, I called the 16-byte field "SCN" / "Software Calibration Number". While I do not know how to read out the manufacturing date (which command?), I think you are on the right path.

Also worth noting, there seem to be another function to read the SCN:

DT_STO_ID_Calibration_Identification (22 F8 04)
HexDump (16Byte): 36 35 31 39 30 31 30 36 30 31 31 35 30 32 33 31  (HexdumpType)

This may be an alias to the same SCN, as I notice quite a few 22 FX XX series of commands seems to be somewhat "standardized" across ECUs.

---

I also have no idea on how the SCN mechanism works, and for this same reason it makes experimentation more difficult. If I had to guess, the 16-byte SCN is only an identifier, and must have a matching key (e.g. DT_STO_ID_Calibration_Verification_Number @ 22 F8 06)

[Feezex]

only one way to make it, take a full dump from spare CRD2/3, then make real SCN, and again read it out fully.
Thus how we can compare changes made by scn kodierung, and then talk about what SCN actually are.
For this moment its not much than theoretical speach

[jglim]

Contacting @jglim

As much as possible, please keep the discussion public (in the spirit of free, open-source sharing), so that anyone is free to access and learn from it.

In the event where sensitive content is involved.

• I am reachable over Twitter as @jg_lim . Please bear in mind that Twitter has a spam filter that sometimes "mutes" new users invisibly, so it may not be an option for everyone
• I have created an unmonitored email inbox. Please let me know whenever I have to refer to any email from that inbox

---

If you plan to contact me, I hope that you can also help me with these aspects:

• CaesarSuite is one of several side projects that I sometimes work on in my off-hours. It is unrelated to my work, and I do not earn (or plan to earn) from it. Like everyone else here, my contributions are completely voluntary.
• If it is a personal feature/help request, I will listen, but may not be able to assist. I am currently unavailable for private consultation / contract work.
• If a technical solution is involved, it will eventually be shared in the main project.
• If there is no longer a need to use a private channel, please continue in Issues/Discussion; responses should generally be better on Github.
• There is no guarantee on a reply time (or any reply at all)
• Please do not try to contact me beyond the platforms indicated above.

Thanks for reading this post and for your presence in this project.