(Needs Traces/Info) EZS Firewall

[jglim]

Context

In my limited understanding, some ECUs are not accessible on the CAN bus until the EZS firewall is disabled. This appears to be the case for some newer vehicles.

Apparently for official clients, operators have to click the EZS authentication button (3 times, no idea why) before starting normal diagnostics work. There are also advice to replace the existing DTS/Vedi‌amo EZS*.smr-d files with X‌e‌ntry versions.

I cannot replicate this firewall issue, since my CRD3 bench ECU does not have this feature, and have not experienced this myself. However, this feature feels critical for modern vehicles, hence help is needed to implement it.

How to help

Log DTS/Ved‌iamo (CAN/J2534/Trace are all welcome), and complete the EZS authentication.
(Optional) Show the before/after when trying to initiate contact with the ECU.

[Feezex]

have you tried to place 120 Ohm resistor between hi/lo?

[Feezex]

And yes - some ecu necessary need wake up signal over can bus to work on bench

[jglim]

I have not encountered this problem myself (my bench CRD3 works OK), though I have seen comments about this issue.

For example: https://mhhauto.com/Thread-diagnostic-Firewall-On-New-MB-Cars

[N0cynym]

I have not encountered this problem myself (my bench CRD3 works OK), though I have seen comments about this issue.

For example: https://mhhauto.com/Thread-diagnostic-Firewall-On-New-MB-Cars

I have checked the otx script in DTS and the only magic thing seems to be Security Access to Level 3b.

[jglim]

Got it, thanks for checking. Interestingly, my EZS213 CBF does not have a level 3B (unlike the SMR), so I might have to add an extra menu item to authenticate for level 3B.

I don't seem to have a EZS167 CBF, so finding the communication parameters (e.g. request identifier, response identifier) will be necessary if the CBF does not exist.

For both EZS167 and EZS213, the key generation process for level 3B has been reverse engineered, so implementing it is definitely possible. I will wait for more feedback, if anyone runs into this EZS firewall issue before working on it.

[N0cynym]

Definitely you'll not find a cbf for this authorization concept. So if latest cars/ecus whould be interesting soon we need to import smr-d files.

[DiMO]

I know about it....

[jglim]

Welcome, @DiMO :

CaesarSuite is a open-source project; here, knowledge and help is shared freely and in public.
If you would like to share constructively, there are a few ways to do so:

• Answer the question. Any answer that gets the asker going in the right direction is helpful, but do try to mention any limitations, assumptions or simplifications in your answer. Brevity is acceptable, but fuller explanations are better.
• Provide contexts for your links (if any) so that fellow users will have some idea what it is and why it’s there.
• Write to your best of your ability. Many contributors here do not use English as their first language so mistakes are generally OK.
• Some of our contributors do not write code, but instead share logs, CAN traces, or instructions which can also push the project forwards

[DiMO]

Are you writing with permission for what I know? Or do I just wear it? I didn't even know this, so I didn't make a mistake, so I just mentioned it a little bit.

[jglim]

My earlier post is a welcome guide as I believe this may be your first time here 👋

Regarding your earlier post, I hope you can improve it, as "I know about it...." can have more meaning added, to contribute to the discussion here.

Don't worry about mistakes, posts can be edited.

[wojciech300]

Hello, not all EZS213 and EZS167 have security acces 3B, but if it have like N0cynym said, u need to unlock first EZS with 3B before coding others ECU's, u can check what "variant" of EZS have acces 3B by DTS.

"Authentifizierung EZS" = seccurity acces 3B EZS, never had issuse like 3 time push, always one time.

U need replace smr-d file in project beacause its to old and dont have 3B acces. File from Xentry have this lvl.

Sorry for my basic English

[jglim]

Hi @wojciech300,

Appreciate your input (your English is fine!). I am glad to hear that activating it once is sufficient. This also opens up a new mystery of how to identify the EZS variant.

At this point, looking at the UnlockECU definitions, there are only two EZS modules with level 3B, (EZS167 and EZS213), though I do not seem to have a EZS167 file. I will have to think about how to add a EZS unlock process without adding too much clutter.

[WSorban]

Hi, very good job with what you have done!!!

I can confirm with EZS213, if you run the 3B unlock mechanism twice, then the firewall is taken down, while the session to the EZS is maintained.

Ending the session on the EZS will restore the firewall.

[jglim]

Hello @WSorban,

Thank you for the compliment and the confirmation! It is good news to know that the technical aspect is feasible.
The client is getting a bit bloated so I might have to figure out a plugin system and include this feature. Appreciate the additional details on the firewall restoration too.

[WSorban]

Happy to help, as we were able to obtain the EZS213 algo, thanks to your tool: https://github.com/jglim/ODB
What I said above, regarding EZS, is tested and confirmed :)

[jglim]

That's great to hear! Glad to see it in use ^^

(Tangential to the current issue) In case you missed it, I have another project that that might be of help in your endeavours as several algos have been reverse engineered and ready to use. It's MIT licensed, so commercial use is OK :^)

https://github.com/jglim/UnlockECU/blob/main/UnlockECU/UnlockECU/Security/EsLibEd25519.cs

[WSorban]

Yes, I saw that today, thanks :)

I have reversed the algos myself also, the problem is, I want to call them directly from DLL files, like Sergey (not sure if you heard of him) and others also did.
The idea is to store all this data on a server, but right now, the technical limitation of the server is, it supports only JavaScript.

I translated the EZS's Java code to JS, but to do that for every other algo, or find a way to host C++ dll's and jar files on the server, I guess I just had other priorities :p

Let me know if and where I could contribute towards your work, even financially, I'll be glad to do so! :)

Or if you are interested, I could give you full access to unlimited seed-key for the cluster ECU's, and read/write tools, for personal research.
If you think they might be useful to you, just hit me up

[jglim]

If I could suggest a solution, porting the C# implementation might actually be the easiest way forward. With Curve25519 aside, the earlier algos are much simpler (shift/xors). UnlockECU's architecture is designed to follow the original autogenerated Daimler algo parameters, and the definitions are centralized in a single db.json file.

An alternative that doesn't involve rewriting might be to build a server around it; Caesar interacts with UnlockECU by calling it from the command line (if DLLs are an option, maybe this might be practical).

I am very grateful for your offer -- my automotive-related projects are generally "hobbyist" as I do not work in the automotive field, and it would be too much to ask for financial contribution. I would appreciate it a lot to be able to experiment with clusters, and would love to take up your offer on access to seed-key tools for personal research (contactable via this address). Thanks again for coming here to offer your support, it is very kind of you.

[WSorban]

Perfect then, if you sign up to my platform, you can download the program from www.mbtools.me/#/app
Once you signed up, I will grant you all the necessary access rights :)

I will not forget also, to open source the code regarding HexBox modifcations and UDS read/write generation.
Will keep you posted (Y)

By the way, this is a hobby for me also, done in my spare time, beside a full-time job and family

[jglim]

Thanks and thanks! I just registered and browsed your homepage, and that's an incredible amount of work. Amazing to see your platform is a hobby that's adjacent to your full-time job (and family!). Looking forward to your PR ^^

[fseidenii]

Interesting project, this CaesarSuite
Great Work! What a hobby indeed... ;)

I will do some testing tomorrow for the project (Platform: GL350 164.825 OM642), and upon this EZS issue as well... I like the idea of using this tool, just for the respect for simplicity in it's Ux.... The GUI is a intuitive treat, compared to the typical Deutsche SWs.

Input from @wojciech300 and @WSorban is appreciated regarding updating 3B smr-d to the Xentry version, and confirmation done in EZS213.

Also, the comments made by @Feezex regarding the terminating resistors on CAN B, on to possibilities of sim the Wake-up signals sent to CAN C, will be another place I will need to focus some attention.

[MasterCodeIT]

That's great to hear! Glad to see it in use ^^

(Tangential to the current issue) In case you missed it, I have another project that that might be of help in your endeavours as several algos have been reverse engineered and ready to use. It's MIT licensed, so commercial use is OK :^)

https://github.com/jglim/UnlockECU/blob/main/UnlockECU/UnlockECU/Security/EsLibEd25519.cs

Where is did you locate the "PrivateKey" in the smr-d? I have some EZS use EsLibEd25519, would like to add them, just need to know the location of the key.

[Feezex]

add definitions to db.json

[MasterCodeIT]

add definitions to db.json

Yes, correct, but I do not how to locate or the physical location of the PrivateKey to add the definition. I have the rest of the info, just not that.

[Feezex]

decompile smr-d