I wrote earlier that I really wanted a working Audi Connect (not to be confused with myAudi) in the car, but back then I found out that Audi no longer provides these services and a subscription cannot be bought, so I shelved the whole thing.
I knew that custom private servers exist and that for 100–150 dollars a year someone can hook you up to one, but I did not like the idea much: no guarantees whatsoever.
Two years have passed since I last tried to figure it out, and now, with AI making its way into our lives, I decided to give it another go and build my own server for the Audi Connect services.
I had once talked to people who ran their own custom servers or were connected to one. Naturally, the owners did not share a ready-made solution — they either made money on it or used it purely for themselves, and, I suppose, distributing something like that and charging for it may well be illegal. But these people did drop a few hints: that you can point the hosts file at your own servers, add a no-ssl-cert-check flag, and so on.
With the help of Claude AI I started digging into it. I put my host into hosts and added no-ssl-cert-check, but it turned out this does not work on my MIB — presumably it was closed off in newer firmware. The MIB ignores no-ssl-cert-check and tries to verify the certificate of the domain, which, of course, is not Audi’s.
I asked Claude to look for ways around it, and it found one. It turned out the head unit does not take the backend address from hosts at all, but from the config of one of its own service modules — there are more than twenty backend profiles in there: the production Live one, the test Development_1, Development_2 and so on. And some of the test profiles talk plain HTTP, with no TLS whatsoever. Since the head unit allows that, all it took was replacing Audi’s server address in the active profile with my server’s address over http — and the certificate check went away by itself. Along the way it turned out the head unit has no DNS settings at all: without them it cannot resolve a single domain name, so they had to be created.
Next, Claude wrote a primitive PHP backend so that our server could answer and log requests. We pointed the head unit at our backend, and it went there: it reached our server and asked for authorization.
I had an old backup of my firmware with the caches of the Audi Connect services (from the days when they still worked in the US), and I also got similar caches from friends. The caches held all kinds of service images, ServiceList.txt, XML and SCXML + HTML server responses. The most valuable file is ServiceList.txt: it let us trace the whole chain of calls the car makes to the server. Claude figured out how it works very quickly and immediately sketched out the whole chain on our backend. The head unit successfully reached and authorized on our backend, and from there it was a matter of technique: we had to serve some service. Among the simple services in the cache was “Weather”; Claude glanced at the format and, using a free weather API, added it for us. Besides the service response itself, you also have to issue a licence saying the service is available to us — that is one line in the response.
The MIB successfully went to our backend, authorized, received the licence and put some information on the screen.
Next I had to work out the response format in more detail and add the graphics and the screen logic. I had never seen a working Audi Connect in real life: half the cars in our country come from the US, and once they arrive in Ukraine these services do not work — different LTE bands, and the head unit itself is provisioned for the American backend, which was switched off long ago. Even cars officially bought in Ukraine hardly ever have these services. But as a reference I took Alexey’s (AlexDark) article https://mqb-blog.com/ru/2019/12/29/mib2-high-pt4/ — it has plenty of photos of these services, so at least I could see what the original looked like. He also had Audi Connect through a custom server, but essentially it just proxied the requests to the original Audi Connect.
First I decided to polish the “Weather” service. I did not have all the icons and backgrounds, so I found vector icons as close to the original as possible and generated all sorts of backgrounds (raster weather pictures in day/night versions).
It came out looking fairly close to the original.
Then, following the same routine and whatever I found in the caches, I built the other services: news, fuel prices, train and flight schedules, charging stations, parking. The Audi connect menu itself, by the way, is also served from the server — which services are in it and in what order is up to me. As data providers I used Open-Meteo, RSS news feeds, my own parser of Ukrainian fuel stations, Ukrzaliznytsia (train schedules), AeroDataBox (flights), OpenStreetMap (parking) and HERE (charging stations, plus trains abroad). Free tiers everywhere; the limits are enough for one car.
I spent about a week on these services. But of all the services, what I really wanted was live traffic on the stock map and the satellite view.
Finding a data source seemed easy enough — HERE provides such data — but HERE has no road traffic data for Ukraine: it has been unavailable since February 2022 because of Russia’s invasion of Ukraine; the feature was simply switched off.
I thought for a long time about how to pull it off. TomTom has traffic too, but their ready-made automotive TPEG feed does not cover Ukraine either. However, Claude said that if the car supports OpenLR, the traffic can be assembled by ourselves from TomTom’s other endpoints — Traffic Flow (vector tiles) and Traffic Incidents — and those do have data for Ukraine. I ran to the car almost immediately, we did a few tests with fake data, and it was confirmed that this works for Ukraine. Then Claude built an encoder that assembles a TPEG2 stream on the server with the road segments referenced through OpenLR, and the head unit lays them out on its own map by itself. Abroad, where HERE does have data, the traffic comes from HERE. No patching of the head unit was needed for this: the stock traffic module takes the server address from our own backend’s response.
Next in line was the satellite map view. At first I went down the wrong path a little: everything in the firmware is built around Google Earth, so I thought I needed to look for a newer P51XX firmware where the provider had changed to HERE. In fact it turned out only the endpoint had changed, while the server response format stayed the same. For a long time I could not understand why the test tiles were not showing — it turned out that if the provider logo is not served in the response, the MIB simply ignores the tiles. One more nuance: the satellite tile client, unlike the other services, goes over HTTPS only and checks the certificate against its own list of root authorities from 2018, which did not yet include Let’s Encrypt — so that root had to be appended to the list on the head unit.
After the test tiles rendered successfully, Claude switched everything over to HERE as the provider and also added tile caching on our server so as not to exceed HERE’s monthly limits: one city weighs about 150 MB across a couple of zoom levels.
That’s it! I plan to finish a couple more services: a travel guide to sights based on Wikipedia data is already built but has not been tested in the car yet. For the rest I currently have no sample responses, and there is nothing to build them from.
Also, anticipating your questions: I do not plan to provide access for other cars — neither for free nor for money. Do not expect me to publish a ready-made solution anywhere, or any more details about what goes on under the hood of the server. A lot of time, effort and tokens went into this, and beyond using it in my own car I do not plan to distribute it — at least not for now.