Another question regarding menu items and labels/icons

[superwofy]

Hello @hufman,

Many thanks for creating and maintaining this application.

I've read your documentation of the CDS protocol, found the RHMI whitelist in the p7bs and had a look at your code.
I realize I'm going to most likely be on my own for this however, with filesystem access to the HU it was trivial to trace that the signature checks take place in a SO that is loaded as a plugin (libhmiremoting.so). The SO in question has not had its debug symbols stripped and so it's again quite simple to return 1 from "verifyResource".

With a patch like this in place (i.e any/no signature will be accepted), what do I need to do to push icons/labels for entries without them?
Say I were to edit the "Detailed Vehicle Info" label, presumably I want to modify /basecore/rhmi/common/texts.zip and add a new string. How do I make that string point to the menu entry? Or, do they already point to an empty ID I can just hijack?

[hufman]

Good afternoon!
That is very exciting, I'd love to learn more about how you were able to get filesystem access, and I wonder if it's possible to toggle this setting with a higher-level tool such as BimmerCode.
As far as I know, the resources must have a sha256 checksum listed in the p7b file. If you have managed to disable this enforcement, that is very exciting indeed!

The RHMI app icons are described in ui_description.xml as the <entrybutton> components. These entrybuttons have an imageId model and a textId model, and these point to numeric entries in the images.zip and texts.zip files.
Each AAIdrive application uses an existing BMW car app, for example the Detailed Vehicle Info uses the News application. To prevent confusion, this app does not send the images.zip or texts.zip files, so it appears as a blank line in the car. You would want to add these lines to send the resource packs and make the labels show up, which should show the Connected Classic icon and the News label. From there, you would experiment with editing the text files in app/src/main/assets/carapplications/news/rhmi/common/texts.zip. AAIdrive's build doesn't check the checksums of the resources, just their existence, so editing them should be pretty easy.

Watch the adb logcat for any crashes during the connection, and I'm very excited to hear what you discover! Feel free to reach out directly as well.

[superwofy]

Thank you for your reply.

Unfortunately, BMW has locked it down pretty tight. There used to be patches which would open SSH/Telnet access. If you're interested in physical access I've described it here: https://www.spoolstreet.com/threads/serial-ssh-telnet-open.9598/. It looks like some people have the L5 UDS private key which can be used to sign a request to execute commands - and they offer this as a service?

I patched libhmiremoting.so and successfully loaded a custom label for the Readout app. For some reason my png did not load for this PoC, either I made a mistake or the size is wrong? I will style it all properly at a later time.

Thanks for the guidance, it took me longer than I'd like to admit to understand the exact relationship between IDs in the XMLs.

[hufman]

Wow, that's super exciting!
Modding my car seems a little too advanced for me presently, but that's neat to know about :) I don't have any ESYS or advanced tooling set up presently, and I'm intimidated about taking apart my dashboard to get to the UART ports.

I'd have to take a peek at what you changed to have a better idea of what is going on. I don't think the icons themselves are very strict about PNG format, you probably matched the same 48x48 size and they're generally the normal RGBA format (except for the 256color greyscale format for icons that get tinted by the UI).
It looks like the build system adds {bmw/common/mini}/images.zip files, and the entryButton is specifying imageId 55010. The CarAppAssetResources class uses the brand that you pass to getImagesDb as the directory, so check that you placed your 55010.png file in the correct zip file. It looks like these image files aren't used anywhere else in AAIdrive, so for simplicity you could remove the brand-specific zips and just focus on common/images.zip

Thank you for sharing, that's super exciting!

[superwofy]

I understand completely, from the get-go I expected this to be very niche. The image issue was indeed the brand(s) zip.

I've forked the repos and will push once it's complete in case anyone else wants to copy. Here's where I'm at so far:

[hufman]

Wow, that's so cool! Congratulations! I'll have to try to figure out how to set up my (Mini MY2021) with such a capability, I'm hoping since I think it's based on IDrive5 that they might not have patched the holes as tightly. There are a bunch of little tiny inconsistencies all around that I'd love to have fixed!

I just merged an old branch that removes the unnecessary RHMI resources, which would have avoided the images.zip confusion, apologies!

I imagine if you make a separate carapplications directory and pass in a separate CarAppAssetResources object with these custom resources, it would be easy to use a try/catch block to try sending the custom resources and then revert to the current unlabeled behavior for regular cars. I'd probably still want it gated by a Gradle property so that the main release doesn't have the extra roundtrips, but I'd accept such a pull request :)

I would be able to test it against the Headunit Simulator, which doesn't implement any security checks haha

That's really cool and exciting, thanks for sharing! Keep in touch with what else you do with these powers :)

[superwofy]

Thank you. Here's my fork such as it is for now: https://github.com/superwofy/AAIdrive-Custom-Resources. All resources are included if you wish to see my changes. Nothing groundbreaking, I've simply added the missing icons and labels. Perhaps the extra resource calls could be behind a different build variant?

MY2021 would imply that it's past the 2018-11 iLevel meaning simple USB patches are out of the question. The only free method I know of is the physical access I've described. There's people doing it as a service through teamviewer with a utility that has the UDS key - pretty seedy.

I'm pretty happy with everything so far.
In terms of bugs, I'm looking into fixing the screen mirroring dimensions for ID6 8.8. GenericRHMIDimensions padding and width is completely wrong - but that's going to be a separate issue.
In terms of features, I would love a weather app since I'm not bound by any security checks. With that said, my understanding of this code base is still in its infancy.

[hufman]

That's super great, I'll take a look, thanks!
The dimensions are indeed mostly a guess. I have an old branch that adds support for specifying exact dimensions manually, which may help in your testing!
While you have disk access (or maybe there's public firmware images available for peeking around in), I wonder if you can find the built-in car apps? I think they use the same RHMI description and resources, just with a different app protocol, and maybe they would be helpful.
Feel free to reach out directly with any questions! A problem with being a solo developer is that I've been very lazy about updating the documentation and support libraries to help other developers, so I'm fully available to chat about any questions :) You've gotten me excited!

[superwofy]

I'll keep at it. I will try to make as many changes as possible into PRs instead of keeping them locked in my "custom" branches.

I've sent you an archive containing the filesystem dump - happy hunting!

Appreciate all the help!

[hufman]

Very fun :) I meant to prepare a branch to package up your RHMI icons customization, to show the approach I had in mind, but got busy over the weekend. I see your email and will take a look soon!
If you'd like, feel free to post stuff in IDriveExperiments too, which is meant to be more developer-focused than the IDriveAddons repo. Even if your experiments are very niche, the behaviors they discover would still be fun to see and perhaps implement in the Headunit Simulator.