KI221 Communication

[FlashY7]

hi guys,

having issue with Unlock KI221. Its connecting well but when i want unlock a level, its not doing it. 10 03 ok, 10 92 ok, 27 01,FD not ok. When continue trying more things, it stops even to receive the commands until you do a reconnect.

I used the last build I found in the KI211 thread. CaesarSuite_dbg_2023_02_02-A Last official Build its also not working with it, but there you can see only in TRACE after 1 minute around: the 27 01 requested seed key.

I have tested same Build on same PC for IC172, its working perfect.

Trace_20230315_1835.txt

Anyone idea?

Best regards

[mbw211]

If you try to unlock KI221 on bench, you won't be able to do it. This issue was also found by Feezex: https://github.com/jglim/UnlockECU/issues/21

[Feezex]

два англичана ахах)))

[FlashY7]

Thank you for answers.

Iam trying in the car, not bench.

When taking vedi or other tools, I can send commands and get direct the requested keys.

[jglim]

Hello FlashY7,

Since the same J2534 device works in Vediamo but not here, this is likely to be a valid issue.

In 7F 27 80, the NRC is "ISO SAE Reserved" which doesn't explain much about the issue. From what I can tell from the trace, the connection appears to be up, but the ECU is actively rejecting the 27 request only.

Could you consider uploading both (Vediamo/Diogenes) j2534 traces using J2534-Shim? This post will explain the setup process. This setup takes some effort, but will produce detailed logs to compare the difference with Vediamo.

[FlashY7]

Hi jglim,

i have just did it. I logged 1x ved and 2x with different builds of CaesaerSuite. So what I see is, ved is taking and reacting on every UDS I send without any issue.

CaesarSuite seems you can send some UDS, than again come no answer - its looking like the SW is stucking to receive or send commands. Even 11 01, 10 03 in such moment not work. But, when you "wake" it with 10 92, you can do 27 01, 11 01, 10 03 and all. But after it, again not working. 27 02 seems to be not working in any moments - no Mather if you wake it before send key, its gives anyway 7F 27 80.

VEDIShimDLL_2023-03-16_10-59-17_0363.txt Caesar2022ShimDLL_2023-03-16_11-02-54_0567.txt LastBuildShimDLL_2023-03-16_11-06-50_0994.txt

[mbw211]

два англичана ахах)))

третьим будешь?))

[mercikc55]

два англичана ахах)))

третьим будешь?)) легко.))))

[jglim]

@FlashY7 I'm still looking at this issue, and it is interesting to see that there are 67 01 responses in the 2022 trace.

In the meantime, if you are keen to try a "development" build, this version of Diogenes has a rewritten networking stack that behaves a bit more like Vediamo. Most features are not implemented yet as I am still getting the connectivity in order. I have only tested this on UDS targets as I do not have any KW2C3PE devices to try on.

The new build requires .net 5 or later. The interface has some changes; here is a screen recording on how to connect to an ECU:

https://user-images.githubusercontent.com/1116555/226410519-e8d848be-c63a-4f5e-af78-b9c7397deae6.mp4

[FlashY7]

Hi jglim, this diogenes 2 looks very nice. simple and clean! I took the KI221 and I took IC172 for testing. Both cannot connect or recognize the variant. I attache you both Loggs from Shim and some Screenshots. Let me know if I can test more iam ready for it! logg ic172 ki221.zip

[mercikc55]

Diogenes 2 test ki211, can't connect and recognize the variant.

[jglim]

Hi folks, I appreciate the positive feedback and the bug reports very much. I've attached to a CRD3 on the bench, encountered the same issue (still UDS) and applied a fix:

Diogenes_dbg_2023-03-23-A.zip

[Feezex]

trc.txt

[FlashY7]

i have just try it. I was able to connect, unlock it, and I was able to read and write the whole EEPROM of KI221. The rollover popup about the "READ FROM ECU" button is super helpfull! Great Idea! Needed some clicks to find how to drag down the Interactive console / Interpreter Log - to find the other buttons of Memory Editor. However, great job!! Lets continue for the DTC, Coding and Services inside Diogenes II ! :)

[mercikc55]

[Feezex]

how you like that:

REQ: 27 61 ECU: 67 61 C0 FF 7D 7D AB B2 F4 F3 REQ: 27 62 C4 69 ED 1A 6C E1 C6 C8 ECU: 67 62 REQ: 22 F1 00 ECU: 62 F1 00 00 CA 0A 03 REQ: 22 F1 54 ECU: 62 F1 54 00 9E REQ: 22 F1 50 ECU: 62 F1 50 12 1F 00 REQ: 22 F1 11 ECU: 62 F1 11 39 30 37 39 30 31 33 32 30 32 REQ: 22 F1 53 ECU: 62 F1 53 12 29 00 REQ: 22 F1 55 ECU: 62 F1 55 00 9E 00 9E 00 9E 00 9E 00 9E 00 9E REQ: 22 F1 51 ECU: 62 F1 51 12 29 00 12 29 00 12 29 00 12 29 00 12 29 00 12 29 00 REQ: 22 F1 21 ECU: 62 F1 21 39 30 37 39 30 34 31 38 30 30 39 30 37 39 30 32 30 39 30 33 39 30 37 39 30 32 31 30 30 33 39 30 37 39 30 32 31 31 30 33 39 30 37 39 30 32 31 32 30 33 39 30 37 39 30 32 31 33 30 33 REQ: 22 F1 5B ECU: 62 F1 5B 01 00 9E 00 00 00 00 00 00 00 01 00 9E 00 00 00 00 00 00 00 01 00 9E 00 00 00 00 00 00 00 01 00 9E 00 00 00 00 00 00 00 01 00 9E 00 00 00 00 00 00 00 01 00 9E 00 00 00 00 00 00 00

IC907.smr-d seed + identification

[jglim]

Folks, thanks for testing it out. I'm glad to see that it's generally working, at least for ECUs with CP_CANECU_CLASS 2 (e.g. KI221).

For "class 1" ECUs such as KI211 I am still unsure if the 500<->83.3k issue is fixed yet https://github.com/jglim/CaesarSuite/issues/52 . In the screenshot from @mercikc55 , there are multiple 7F xx 80 messages which is concerning and might require more testing.

Also, please note that there is a known visual bug in the ComParam list, where it does not automatically refresh when loading a new CBF, until it is clicked at least once.

@Feezex Thanks for the trace. The new networking stack is a bit too tight on the timings, and those requests without responses exceeded the p2max timeout (default ~150ms). UDS typically adds a bit more slack through the CAN_TRANSMIT parameter, which is usually an extra 100ms+. I'll be adding a similar mechanism to KW2C3PE, which should comfortably allow those slower messages to pass.

Also of note is https://github.com/jglim/CaesarSuite/issues/55 : ComParams are now editable. It should be possible to load a similar CBF for an unknown ECU, adjust the ComParams, then initiate the connection.

[mbw211]

I tried your first Diogenes II dbg ver. on KI211 on car, connected but no variant. Probably, second dbg was tested by mercikc55, also no variant. I will try to make a trace soon, or maybe mercikc55 will be faster than me :)

[mercikc55]

I tried your first Diogenes II dbg ver. on KI211 on car, connected but no variant. Probably, second dbg was tested by mercikc55, also no variant. I will try to make a trace soon, or maybe mercikc55 will be faster than me :)

Diogenes II dbg ver_2. Ki211+zgw211 on bench

[mbw211]

Ki211+zgw211 on bench

Probably trace with https://github.com/jglim/CaesarSuite/discussions/11 j2534 logger will be more useful

[mercikc55]

Probably trace with #11 j2534 logger will be more useful

Yes, sure ShimDLL_2023-03-25_21-13-04_0727.txt

[mbw211]

Don't know about bench connection, but last dbg build connects with ki211 on the car, identify variant but for 27 01 cmd i get 7F 27 80 Upd: first time variant was identified but when i try to connect 2 time it cannot identify

[mercikc55]

Don't know about bench connection, but last dbg build connects with ki211 on the car, identify variant but for 27 01 cmd i get 7F 27 80 Upd: first time variant was identified but when i try to connect 2 time it cannot identify

exactly the same on the bench

[Feezex]

if you read nicely - ki221 bench doesnt work, as of security access issue, Seems there is lack of data received by ki from eis, zgw, sam and so on. Tested KI+ZGW+EIS build, still security acces query becomes rejected. >>>

[jglim]

Hi folks, I'm still looking at this; though I have no concrete answers, 7F xx 80 feels like a familiar issue from the KI211 thread from @mbw211 (https://github.com/jglim/CaesarSuite/issues/52).

Here are some notes from my observation:

Looking at the trace from @mercikc55 (https://github.com/jglim/CaesarSuite/issues/56#issuecomment-1483889663), there are two 10 92 session initialization requests.

The first message is sent at 4.236s and the functional destination address is correct (0x1C) : 00 00 00 1c 10 92. Diogenes is supposed to send this request twice in a short interval (vediamo: 2x, cgmb: 5x), but the followup request is never sent. I am assuming that an exception might have occurred, and quietly suppressed, so I will have to generate another build with more logging information.

After the 10 92 request, 1A 86 is sent, but the request times out. Next few requests are uneventful.

At 13.159s, another 10 92 request is sent. This time, it is sent to a physical address: 00 00 05 b4 10 92. I cannot tell from J2534, but it looks like this may have been manually sent by mercikc55. Interestingly, there is a 50 92 response, and the subsequent 1A 86 request is correctly answered with 5a 86 21 15 40 47 11 37 03 05 02 11 07 00 00 03 10 14.

This is unexpected since KI211 should be a "class 1" ECU, where session-related requests (10 92, testerpresent) should be sent to the functional address 0x1C instead of the physical address (0x5B4).

---

I'll find time to generate a build with more logging information soon. This might take a while since I am still away on my annual reservist training.

[jglim]

Hello all again,

I saw an issue where the 10 92 request could only be requested once due to a bug. This build should now send 2x 10 92 as intended. In my earlier post, subsequent messages appeared to work after the second 10 92, though this could also well be because the address is physical instead of functional.

Diogenes_dbg_2023-04-08-A.zip

[VladLupashevskyi]

Hey @jglim, just read this issue.

Response 7F xx 80 means usually on Mercedes that diagnostics session level is incorrect. Like for example you would need to switch to programming mode via 10 92.

Also on ki211 like clusters there is a highest mode, which is called VDO mode and you can call any diag function, but not sure how it works on other clusters.

You can enter in VDO mode via this command: 10 F0

[VladLupashevskyi]

And yes, I can confirm that for ki211 you need to send tester present message periodically to 0x1c can id, otherwise any diag request will fail with 7f xx 80. Or more like it will start to fail after some timeout since sending 10 92

[jglim]

Hello @VladLupashevskyi,

Thanks for your advice.

VDO mode is new to me; I've assumed so far that privileges are automatically granted when completing security access challenges. I assume that entering VDO mode is a requirement before raw memory read/write commands are made available?

For other clusters, I can only add on my experience on the 204, where privileged commands (full access to volatile and nonvolatile memory, and external eeprom) are automatically granted after entering level 9, then level 13.

As for the connectivity and session issue, I am still unsure as to where the application is failing right now. As far as I can tell, the current implementation should send 10 92 twice, then starts sending testerpresent messages to 0x1C.

If there's a chance that you might be able to look at it, please use the v2 branch. (v2 also has a somewhat functional interpreter which might be of interest to you)

[VladLupashevskyi]

@jglim hey v2 branch looks interesting :) Will take a look at it in about 2 weeks when I'm back home.

VDO mode unlocks functions which start from 31 FA xx and 31 FB xx, many of them do not exist in CBF, just happened to find them during reverse engineering of ki211. For other functions you should be fine with 10 92. Raw memory can also be read/written with 10 92, however to enter for example into flash loader mode you need to enter vdo mode and also enable programming mode with 10 85.

I think it does not really matter what is sent first either 10 92 or TP to 0x1C. Main point here is to periodically send TP messages after entering diag mode, because otherwise it will timeout, diag session will reset and you get 7f xx 80 on any request afterwards (you would need to enter it again with 10 92)

[mercikc55]

Don't know about bench connection, but last dbg build connects with ki211 on the car, identify variant butlast for 27 01 cmd i get 7F 27 80 Upd: first time variant was identified but when i try to connect 2 time it cannot identify

last dbg build + can hacker works, no 7F 27 80

[Feezex]

Hi folks, I appreciate the positive feedback and the bug reports very much. I've attached to a CRD3 on the bench, encountered the same issue (still UDS) and applied a fix:

Diogenes_dbg_2023-03-23-A.zip

Open a repo for Diogenes II or post a source please. Appreciate your work and time.

[jglim]

It is visible when you choose from the branch menu; here is a direct link. The repo has been there for a while (~April '23) but I don't think github makes it very obvious that it is available.

One of my prior goals was to get ki211-like ecus working with v2, but I have underestimated the amount of work that is required for that. Hopefully more folks might notice and experiment with that branch.

[Feezex]

got it! havent pay attention before that theres a branches inside!