Software carplay implementation for devices with MFI chip

[Timu5]

I own a 5-inch motorcycle CarPlay/Android Auto display. I managed to unpack its Linux firmware and do some reverse-engineering work. My goal was to extend its functionality by adding a data display from the CAN bus. I found a way to load a custom .elf file in place of the original one, as well as modify the original .elf to extend the UI.

However, injecting custom code is not easy and debugging it is even harder. Because of this, I thought it might be simpler to try running LIVI on it. The only problem I have encountered is that LIVI doesn't support software-based CarPlay. Since these devices contain MFi chips as well as hardware video codecs, they would make the best development platform. They even have ADB running, so you can control them over USB.

Is there a plan to add sofware carplay protocol implementation?

[f-io]

It's on the to-do list, and I already have a test setup for it, incl. an MFi co-processor.

Does LIVI already run on the device? You mention ADB, but LIVI doesn't run on Android, and that's not something I'm planning to work on either.

[Timu5]

The device I own is running a tiny Linux distro called Tina Linux (which is based on OpenWrt). It's not Android in any form, yet it contains an ADB daemon, that's probably a shortcut made by the developer to make debugging easier.

I haven't tried to run LIVI on this device yet, as that would require building LIVI's dependencies first. Now that I know that software carplay is on to-do list I will spend some time on getting dependencies to work. I will post my updates here.

[mbt28]

Do you have device specifications? Recently I have implemented similar device not with with Tina linux but with buildroot. It uses Allwinner F1C200S which has 400mhz cpu and 64mb ram. Carplay video is decoded totally in hardware, cpu usage is around 5%. It boots in few seconds and carplay screen comes in less than 20seconds. Currently it is just in proof of concept stage.

Initially I am also looking for mfi implementation to get rid of the dongle totally. You can see the test setup in this video:
https://www.youtube.com/shorts/TGMVSZ9vUlo

[mbt28]

Once you've finished the native CarPlay support, I'll add this feature to my FastCarPlay build. That will finally let us to change firmware with free software devices like the Timu5 purchased.

[mbt28]

Hi,

I received MFI ICs today, however I was not really careful with packaging and I dont have an QFN8 adapter. Which MFI chip are you using? Does anybody know an MFI chip which is hand soldering friendly packaging like SOIC8?

[f-io]

I have verifyed the code against 2.0b, 2.0c and 3.0, including the case if RESET is high during boot.
Coldstart to stream is now at 4000ms.

I think only the 2.0b is available in a SOIC8.
The carlinkit dongle has it as well (not in SOIC8 but the same die).

[mbt28]

This is the chip I have: MFI343S00177-L. It looks like it is XDFN8 package 2x3mm. If anybody finds more soldering friendly MFI IC please let us know.

https://www.lcsc.com/product-detail/C33770534.html?s_z=n_q_MFI343S00177&spm=wm.fly.bg.0.xh&lcsc_vid=QFlbU1xfTwBfUwJRQVVaX1BWRwVYX1QFQwJaV1YAQVAxVlNeQ1RbV1JXQ1NYVTsOAxUeFF5JWBYZEEoKFBINSQcJGk4NBhADEA4cHktfQ1hADxALGw%3D%3D

[f-io]

That is a CP3.0. This is a DFN8 2×3 package (if you’re looking for an adapter).

I was once so lazy that I used a regular hot air gun to solder that chip because my hot air station wasn’t on the desk. Also these small hot plates working well for this kind of jobs. It’s definitely solderable, just drown it in flux. For dev boards, it’s also fine to use leaded (Pb) solder. It has a higher surface tension, so the chip is more likely to self-align during reflow.

[mbt28]

Thank you for confirming the package. I have a cheap hot plate and an amateur hot air gun, I soldered before 1mm pitch but this chip is very tiny. I ordered DFN-8 2x3 breakout pcbs from Poland. I guess I will have them next week. I will let you know how it goes.

[f-io]

[mbt28]

I received breakout boards today. Do you know the pinout for this chip? Also "dot" means first pin?

[f-io]

https://github.com/BertoldVdb/WACResearch/blob/master/hardware/schematic.pdf

[mbt28]

I tried a bit last week to solder it but because the ground plane is not the same size with MFI IC surface tension rotates the chip 45 degree. I will try to solder only the pins without the ground plane. As you said if the footprint is the correct one, it is not that hard to solder it with a hotplate and generous amount of flux.

Do you think it would be possible to store the certificate inside the MFI chip in filesystem? Is it any different than an I2C eeprom chip?

	regDeviceVersion                      chipRegister = 0x00
	regAuthenticationRevision             chipRegister = 0x01
	regAuthenticationProtocolMajorVersion chipRegister = 0x02
	regAuthenticationProtocolMinorVersion chipRegister = 0x03
	regErrorCode                          chipRegister = 0x05

	regAuthenticationControlAndStatus chipRegister = 0x10
	regChallengeResponseDataLength    chipRegister = 0x11
	regChallengeResponseData          chipRegister = 0x12

	regChallengeDataLength chipRegister = 0x20
	regChallengeData       chipRegister = 0x21

	regAccessoryCertificateDataLength chipRegister = 0x30
	regAccessoryCertificateData       chipRegister = 0x31

	regSelfTestStatus     chipRegister = 0x40
	regSystemEventCounter chipRegister = 0x4D

[f-io]

This is not how the coprocessor works. During authentication, it signs a challenge sent by the phone. There is no way to read out the private key, it is never exposed. There is no register or command that allows the key to be read. The chip is a secure cryptographic coprocessor, not a simple EEPROM.

I also want to make it clear that I’m not planning or attempting to break Apple’s security. This code was written for interoperability, not to bypass or attack any security mechanism. The entire CarPlay session is end-to-end encrypted, and we are only using the protocol as intended.