[Gruni]

forgot, your Firmware is newer, so you can update to 74. directly too.

 

[TimmyTime]

Hello all! Sorry it's been a while before I've posted an update. ASH8, Gruni and others have been of great help to me here and I am massively appreciative. I have today been able to install the update!

I tried the steps for completing this from a mac by removing the hidden files using terminal commands but that didn't work for me so I borrowed a PC laptop from a friend, ran a clean format and followed the procedures again and it has now worked for me.

Again massive thanks to the people who give their time for free to help others, really appreciate that.

Best of luck all!

 

[Julake]

Hi! Does anyone still have the files for version 56 for Europe? I recently got a Mazda3 and I want to upgrade the infotainment system to be compatible with android auto but i can't find the files for this version anywhere
Any help is appreciated, thanks!

 

[Deano]

Hi! Does anyone still have the files for version 56 for Europe? I recently got a Mazda3 and I want to upgrade the infotainment system to be compatible with android auto but i can't find the files for this version anywhere
Any help is appreciated, thanks!

If you want official Aa, you'll need version 70 onwards.

 

[Julake]

Yeah, but I would like to try the one from mazda tweaks
I saw a lot of improvements that have potential from there
But I need the files for v56, if anyone is willing to share, please ))

 

[djcal_uk]

Great compilation of information! Posting to have access for messaging

 

[muthu_nagarajan]

Hi! Does anyone still have the files for version 56 for Europe? I recently got a Mazda3 and I want to upgrade the infotainment system to be compatible with android auto but i can't find the files for this version anywhere
Any help is appreciated, thanks!

Hi All,


I'm also looking for the files of version 56 for Europe.

Can someone please help.?

Thanks.

 

[Vog1K]

Great compilation of information! Posting to have access for messaging

And I'll reply for the same reason.

 

[_coderchris]

I have done the major tweaks already. I can't help but wonder if i can upgrade everything on this device. Completely make things modern... Run react instead of the old html, css, js... etc. As a full stack web developer I can't help but wonder how far we can tweak it. We can come together and create amazing ui's and open source them. I will be the first in line if anyone wants to work on it with me. I will need a dev environment, which i've read up on by creating an http server. I might try developing it locally on my pc and see how far i can get.

 

[airslider]

Hey guys, is anyone have a password for cmu150_EU_74.00.324A_update.up? (zip) Can't find online.

 

[alfran983]

Alguien que sepa como volver a encender la pantalla en mazda demio? Se apagando manipulando algunos script. Todo funciona menos la pantalla

 

[wooou]

Does anyone know if it is still possible to simply patch the libjcisecurity.so library or swap certificates on the root/update? User Duck picked the library apart back in v31 or so and got it working but I haven't really seen much discussion of unsigned/user-signed updates since. For official firmware, going that route and just patching in a hook on the linux rootfs seems like it could be a lot more simple than tearing apart the dash for a serial line if you're already on a vulnerable firmware.

Originally it reads like Duck and the other users then were interested in finding an outright exploit to hijack the firmware upgrade process from an untouched unit. Since we're probably on the final firmware with v74.324a we don't need to be concerned with that as much.

For v74 itself, there's already some XSS examples floating around that supposedly work. I'll try this out later on v59.330 and see how it goes. If it does then we own the rootfs regardless of firmware. I am thinking that we can either exploit the official upgrade process as before, or find out where (if?) that process is accessing memory blocks outside the rootfs for the rest of the chip/flash.

From what I can tell the i.MX 6 has some internal memory which I'd bet holds u-boot. If we get control of u-boot we own the house, but I'll do my homework and see what memory is available to dump from linux and try to find out if the bootloader is asking for signatures first.

 

[wooou]

Got the chance to run the xss payload on v59 and it works out well enough. Payload I had just ran a 'run-terminal' process through some part of a debug menu. Glad we're on a final firmware because every part of the process would be simple to patch against. Found some things (on v59) that could be interesting that I'll write here:

-) CPU is in fact i.MX 6Quad so datasheet says there's a 96k bootrom, will do up to GLES 2.0/VG 1.1, and secureboot. This was known, but worth repeating.

-) Wayland is being used with some specific weston patches for the i.MX gpu. I don't know if the compositor running on the CMU is comparable to the nxp link, but it's still a resource.

-) Memory exposed to linux:
- /dev/ffx01 -> main flash? part1 gets mounted as / but is only 64M. p4 is /tmp/mnt/data also 64M. Both are type relfs which I can only find references to some relational fs project from 2004. Neither mount on modern linux. Whole flash is 1GB w/ ~750MB empty space
- /dev/mtdblock -> 9 total blocks, block5 is /config-mfg. Probably that bootrom but I didn't notice it until rereading the outputs after disconnecting
- /dev/mmcblk0 -> maybe emmc, running /tmp/mnt/data_persist and /tmp/mnt/resources. Didn't look but guessing it's just infotainment resources that they didn't want on the flash

-) Unless its symlink somewhere else (didn't check), /jci lives on flash in /dev/ffx01p1

-) Will grab dmesg & kernel modules on my next run

-) Nearly all the infotainment functionality is run by /jci/sm/sm_svclauncher in the way of shared object libraries. There's so many going on that reverse engineering the backend functions might be easier by just snooping on the physical buses and implementing from scratch

-) Opera was running on a massive chunk of cputime/memory in the background. Even if the backend was left alone and the frontend got rebuilt outside the html/js sandbox, the whole system could be more performant

There's definitely a few things worth tracking down to get a clearer picture of the full stack and the framework under it. I really would be happy to hear if anyone has already done some work for the /jci directory and has some comprehensive understanding beyond editing the touchscreen script for when the car go fast

If we could break away from the jci system the CMU uses now, we could really do so much more with this thing. Most importantly, open software updates without mazda's legal team on the case. If we don't distribute Mazda property in the way of code, the whole firmware upgrade problem goes away for end users.

Please let me know if you know what a relfs filesystem type is there's no way they used some experimental binary from sourceforge on a corperate project

 

[wooou]

Got v74 firmware and the chance to dig around.

First, a x509v3 signed linux lives at /dev/ffx00. It's still the same as v59 at 3.0.35 but has a different build date. Not sure what changed. There's some other data included that goes in the partition that I haven't looked at so I'm not sure if it's safe to distribute or if there's even a meaningful difference between the builds to justify doing so.

The weston config doesn't look at all outlandish, so we might be able to just hijack boot out the gate at /sbin/init. /usr/sbin/splashplayer looks like it is the process that sets weston up and plays the boot animation

My biggest concern before was picking apart all the little libraries for reaching out to the rest of the car through canbus and the like, but everything seems mostly contained in /jci/vbs/. Getting the libraries into ghidra and seeing how things are exposed on dbus makes the picture much clearer

Not really much of a cpp dev, but QT is attractive for already having hardware accel support on i.MX 6. LVGL could probably do everything in C but doesn't look like seamless hw accel

 

[luyenok]

Hey guys, is anyone have a password for cmu150_EU_74.00.324A_update.up? (zip) Can't find online.

Did you get it?

 

[wooou]

Hey guys, is anyone have a password for cmu150_EU_74.00.324A_update.up? (zip) Can't find online.

It's a string inside libjcisecurity.so I'm not at my computer to tell you the memory offset but open it in a hexeditor I think it starts with 5X/ it's maybe 12 characters long

 

[wooou]

Some android auto/carplay information that might be useful to anyone following

I've tried to look around for documentation on the android auto protocol to find anything that might be useful. Best I have found is a head unit integration guide from google in 2016. Seems like its confidential material, so if anyone has anything more recent it would be much appreciated. Might need to pick apart some existing, newer binaries for reference. Back then at least, the hard requirements were a 50 mbps communication protocol, h264 decode, and implementation of some android open device protocol. USB 2 already covers for wired for sure, and h264 is already in imx gstreamer libraries. It seems like newer android auto units have some capacity for negotiating a transparent 802.11 style connection for wireless after authenticating ssl over bluetooth. Will try to find some info in that space since the CMU already runs regular wpa_supplicant

Also had a look at the aliexpress adapter modules that support wired & wireless aa/carplay. Can't speak to them in practice as I haven't seen them up close, but can make some guesses. Since they connect to the CMU through USB, there's probably some mitm soc work going on. Getting one and actually snooping on the transport packets with real aa/cp protocol documentation would confirm, but my guess is they act as a protocol translation layer between the jci/visteon software library and the other end on your phone. Bandwidth prohibiting, you could probably do the same thing on an esp32

 

[wooou]

Some android auto/carplay information that might be useful to anyone following

I've tried to look around for documentation on the android auto protocol to find anything that might be useful. Best I have found is a head unit integration guide from google in 2016. Seems like its confidential material, so if anyone has anything more recent it would be much appreciated. Might need to pick apart some existing, newer binaries for reference. Back then at least, the hard requirements were a 50 mbps communication protocol, h264 decode, and implementation of some android open device protocol. USB 2 already covers for wired for sure, and h264 is already in imx gstreamer libraries. It seems like newer android auto units have some capacity for negotiating a transparent 802.11 style connection for wireless after authenticating ssl over bluetooth. Will try to find some info in that space since the CMU already runs regular wpa_supplicant

Also had a look at the aliexpress adapter modules that support wired & wireless aa/carplay. Can't speak to them in practice as I haven't seen them up close, but can make some guesses. Since they connect to the CMU through USB, there's probably some mitm soc work going on. Getting one and actually snooping on the transport packets with real aa/cp protocol documentation would confirm, but my guess is they act as a protocol translation layer between the jci/visteon software library and the other end on your phone. Bandwidth prohibiting, you could probably do the same thing on an esp32

A little further reading says the android open accessory protocol is doing the negotiation magic. Looks like WiFi Direct (P2P) is the target for wireless aa. Hard to tell what exactly aa expects before starting p2p without new docs, but the cmu wlan is probably new enough to be compliant.

 

[edocastri]

For people using the Mazda Connect 1 Root MP3 hack: I already know that if you disable LVDS Speed or Speed, you lose the compass function. The question is, if you undo the changes, does the compass come back? Thx in advance.

 

[craz]

It's a known issue, but there's a fix in AIO tweaks.
Undoing changes should change back, but does the cluster compass work in your country? I thought cluster compass was a feature found only in North American cars.