you're killing me, apple (AKA Java-base OpenBLT interface)

[mck1117]

[mck1117]

https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web which means you pretty much have to sign any binaries you want to run on macOS

[nmschulte]

Users and organizations have the option to allow only software installed from the App Store. Alternatively, users can override Gatekeeper policies to open any software unless restricted by a mobile device management (MDM) solution.

And meanwhile ... https://twitter.com/DylanMcD8/status/1718432019078627797

ETA: https://support.apple.com/en-us/HT202491#openanyway

[mck1117]

And meanwhile ... https://twitter.com/DylanMcD8/status/1718432019078627797

I bet that only works with signed apps :joy:

[mck1117]

ETA: https://support.apple.com/en-us/HT202491#openanyway

It's true, it works (you can also remove the "untrusted downloaded from internet" flag), but it's a bad experience.

[nmschulte]

but it's a bad experience

https://asahilinux.org/about/ :trollface:

[Krakert]

I hade the same problem, running some xattr commands will fix this:

xattr -dr com.apple.quarantine libopenblt_jni.dylib xattr -dr com.apple.quarantine libopenblt.dylib

[mck1117]

Yeah, that solution works, but isn't really a long term user-friendly fix. I don't expect users to just turn off the security mechanism so they can use their ECU.

[nmschulte]

One proposed solution is to implement the OpenBLT logic directly in Java, avoiding the unsigned DSOs.

OpenBLT works upon the XCP interface standard out of the box: https://www.feaser.com/openblt/doku.php?id=faq

What communication protocol is used during firmware updates?

The OpenBLT bootloader utilizes the standardized XCP protocol to communicate with the microcontroller target during the firmware update procedure. The XCP protocol is maintained and published by the The Association for Standardization of Automation and Measuring systems (ASAM).

The XCP protocol, officially called ASAM MCD-1 XCP, is a universal measurement and calibration protocol. It is a master-slave communication protocol to connect a microcontroller (slave) with a calibration and data acquisition system (master). Since the protocol contains features for non-volatile memory erasure and programming, it is quite suitable for the purpose of firmware updates as well.

The XCP protocol was selected because it contains everything you could wish for in a communication protocol for a bootloader:

• It includes features for non-volatile memory programming.
• It supports multiple transport layers such as RS232, CAN, USB, TCP/IP and be easily be embedded inside other transport layers.
• It features a build-in seed/key security mechanism for restricting access.
• The protocol distinguishes between mandatory commands and optional commands. This allows the implementation to have a low ROM footprint by stripping out those optional commands that are not needed for the purpose of a firmware update.

For more details you can download a copy of the XCP 1.0 protocol specification and you can have a look at the bootloader’s communication sequence chart.

Although we highly recommend the XCP protocol, it is definitely possible to replace it with another communication protocol, thanks to the bootloader’s modular architecture.

I found no open solutions to this end, but did find this interesting work of some Michigan State University students from 2014, that seems to implement XCP for Android (Java): http://www.capstone.cse.msu.edu/2014-08//schedules/all-hands-meetings/notes/11-10-beta-presentations/team-bosch-beta-presentation.pdf