MMI 2G / 3G / 3GP metainfo2.txt Checksummenberechnung

Vor einiger Zeit habe ich mich mal damit befasst, wie denn eigentlich die Checksummenberechnung der diversen 2G / 3G / 3GP Software-Update metainfo2.txt Files durchgeführt wird.
Dieses Verständnis ist z.B. nötig, um geänderte Files über den normalen MMI Update-Mechanismus einzuspielen, welche ihrerseits mit einer Checksumme im metainfo-File hinterlegt sind.

Also...
Grundsätzlich basieren alle metainfo2.txt Checksummenberechnungen auf einem normalen crc32 (cyclic redundancy check mit 32 Bit Checksumme) Algorithmus.
Nun gibt es von diesem verschiedene Ausprägungen.
- das verwendete Polynom
- initialer Wert der Checksumme (vor dem 1. Durchlauf)
- finaler XOR mit 0xffffffff oder nicht

Bei den genannten MMI Versionen kommt ein Polynom 0xEDB88320 zum Einsatz.
Initialisiert wird der Checksummenbuffer mit 0xFFFFFFFF und dieser wird nach der Berechnung mit 0xFFFFFFFF XOR verknüpft.
Die Berechnung fängt immer bei Adresse 0 an und geht bis einschließlich zum letzten Byte.

So ein metainfo2.txt File besitzt zuerst einmal eine "globale" Checksumme, welche die Integrität des jeweiligen metainfo-Files sicherstellt.
Zu erkennen ist diese Checksumme an der Variablenbezeichung "MetafileChecksum".

An dieser Stelle ist es wichtig, dass bei einer Änderung dieser "globalen" Checksumme, keine Berechnung mit der Checksumme in dem File enthalten möglich ist.
(was ja logisch betrachtet eigentlich auch klar sein sollte...)
Also, wenn man die MetafileChecksum neu berechnen möchte, muss man diese komplette Zeile aus der Datei löschen, die Checksumme (nach oben beschriebenen Muster) berechnen und dann die Zeile wieder hinzufügen. (natürlich dann mit der neu berechneten Checksumme)

Die übrigen Checksummen in den metainfo-Files werden auch nach oben beschriebenem Muster berechnet.
Einzig, wenn Files größer als 512 Kilobyte groß sind, dann wird alle 512k jeweils über die vorherigen 512k eine Checksumme berechnet und abgelegt.
Checksum, Checksum1, Checksum2 etc. sind dann die jeweilig zu findenen Variablen.

Für einfach Berechnungen funktioniert das DF CRC-SFV Tool.
Leider nicht für Files mit mehr als 512k Größe, da es immer nur eine Checksumme über das gesamte File berechnet.
Wenn man sich einen Checksummenberechner selber schreibt, dann ist die Sache natürlich einfach gelöst.
Notfalls kann man sich bei großen Files mit filesplit32 behelfen und die großen Files in kleine Häppchen splitten und über diese kleineren Stücke dann mit DF CRC eine Checksumme berechnen.

In Verbindung mit dem MMI 2G Startscreen-Format, könnte die Checksummenberechnung - insbesondere über das DF CRC-SFV Tool aber durchaus hilfreich sein.

Ich möchte nur extra noch einmal darauf hinweisen, dass Modifikationen an Update-CDs/DVDs nicht ungefährlich sind.
Insbesondere beim MMI 3G / 3GP ist nach einem Fehler häufig die EmergApp (der Emergency-Mode) der nächste Halt.
Ist man erst einmal in diesem Modus, so muss man unbedingt die Checksumme der zuletzt verwendeten metainfo2.txt sichern und gut aufheben.
Das 3G / 3GP (5F) akzeptiert im Emergency nur noch ein Update von der zuletzt verwendeten Quelle (SD1 / SD2 / DVD) und auch nur mit der zuletzt verwendeten Checksumme.
Man bekommt die 5F Unit auch in so einem Fall wieder aus dem Emergency, das Vorgehen in so einem Fall ist aber ein Thema für einen der nächsten Blogeinträge.

MMI 2G Startscreen Fileformat (.yim)

Irgendwann hatte ich mal Langeweile und habe mir das Dateiformat der MMI 2G Startscreens angesehen.
Die Dateien haben auf den 2G Update-CDs folgende Namen:
Screen0.yim
Screen1.yim
...
Screen5.yim

Schaut man sich die Datei in einem Hex-Editor an, so stellt man ein paar Dinge fest.
Header:

• 0x0 [24 Bytes] - Fileheader start
• 0x0 - 0xb Checksumme ???
• 0x10 [4 Bytes] - Dateigröße (ASCII Encodiert)
• 0x18 [4 Bytes] - Bildtyp [XIM2]
• 0x1c [4 Bytes] - Dateigröße mit Bildheader, aber ohne File-Header und ohne Bildtyp
• 0x20 [2 Bytes] - X-Bildauflösung (480 Pixel)
• 0x22 [2 Bytes] - Y-Bildauflösung (240 Pixel)
• 0x26 [2 Bytes] - Größe Bildheader
• 0x34 [4 Bytes] - hier findet sich die Nutzdatengröße in Bytes (+ 4) 

Ich habe mir dann die weiteren Daten angesehen und dabei festgestellt, dass es sich um eine RLE (Run Length Encoding) Kompression handelt.

Bei einer solchen Kompression werden aufeinander folgende Pattern durch die Anzahl und dann den Pattern ersetzt.
Beispiel: "07 FF 00 00" wird extrahiert als 32767 (0x7ff) mal der Pattern "00 00".

Da es sich um Bilder mit einer Farbtiefe von maximal 16 Bit handelt, ist jeder Pixel 2 Bytes lang. (in diesem Fall "00 00" = schwarz) Genauer gesagt handelt es sich nur um 15 Bit Farbtiefe. (R=5 Bit, G=5 Bit, B=5 Bit)

Weiter hat der Screen eine Auflösung von 480x240 Pixeln, so dass man insgesamt auf 230400 Bytes kommen muss. (115200 Pixel mit jeweils 2 Bytes)

Interessant ist dann natürlich bei einer RLE Kompression, wie denn sich nicht wiederholende Pattern abgebildet werden. Die geschieht über das MSB (Most Significant Bit) der beiden Steuerbytes.
Wenn also z.B. "FF FF" statt "7F FF" (im obigen Beispiel) gestanden hätte, so wäre auch noch das MSB gesetzt gewesen und es hätte sich um eine Zeichenfolge mit 0x7fff Länge gehandelt.

Wichtig, die Länge bezieht sich natürlich auch die "Grundeinheit" und diese ist immer 2 Bytes lang. Es wären also 2 * 32767 Bytes ohne Wiederholung in die Ausgabe zu übertragen.
Eigentlich kann man das File mit diesem Verständnis schon im Hexeditor mit den Augen und einem Taschenrechner decodieren.
Die Nutzdaten fangen immer bei 0x3c an und gehen bis zum Fileende.

Vielleicht hlft es ja jemandem, der bisher vor einem Rätsel gestanden hat?
Versuche Bilder zu encodieren und dann wieder per Software-Update einzuspielen sind leider fehlgeschlagen.
Meine Vermutung ist, dass die Bytes 0x0-0xB eine Form von Checksumme darstellen.
Leider bin ich bisher nicht dahinter gekommen, wie sich diese ASCII dargestellte Zahl errechnet.

Also, wenn es jemand basierend auf diesen hier zur Verfügung gestellten Informationen gelingen sollte einen veränderten Startscreen in ein MMI 2G Display Interface einzuspielen, so möchte ich nur darum bitten Licht in das Dunkel zu bringen was das Thema Checksumme angeht. Das fände ich jedenfalls nur fair...

Wie man die Metainfo-Checksummen berechnet werde ich in einem gesonderten Eintrag mal ausführlich erleutern.
(dieses Wissen braucht es zum Einspielen eines geänderten Files ja auch)

Audi MMI 2G FBAS Eingang nachrüsten

Wie ihr ja sicher schon wisst, braucht es bei einem MMI 2G um Video über den MMI Screen abspielen zu können, einen FBAS Eingang am Display Interface.
Dito natürlich auch, wenn man plant TV, RFK oder dergleichen nachzurüsten.

Ok, also entweder man sucht such ein passendes Gebrauchtteil mit der Hardware Teilenummer 4E0 035 729 A (das A am Ende steht für den vorhandenen Video-Eingang) und der für sein Fahrzeug passenden Software Teilenummer (z.B. 4F0 - für Audi 4F) oder man rüstet den fehlenden FBAS Videoeingang bei seinem im Fahrzeug bereits vorhandenen Interface nach.

Klar, an die Sache sollte sich natürlich nur jemand wagen, der gut Löten kann, die nötige Erfahrung hat und auch das passende Werkzeug sein eigen nennt.
Es handelt sich bei den Bauteilen teilweise wirklich um ziemlich kleine SMD Bauteile.

Ok, hier aber der Link zu dem Thema in einem internationalen Audi-Forum:
http://audiforum.us/threads/audi-2g-fbas-redevelopment-scheme-a-z-mmi-2g-video-input.15998/

Gleich im 1. Post finden sich Bilder von der Interface-Platine mit den Bauteilen und deren Werten.
Möge der Lötkolben mit euch sein! ;)

Edit: Ich habe viele Mails erhalten, dass man sich das Bild im verlinkten Forum so nicht anschauen kann, daher hier noch einmal das Bild.

DAB+ Umrüstung / Nachrüstung MMI 2G (alle Modelle)

Auf Motor-Talk gibt es ein spannedes Thema, welches sich mit der Umbaumöglichkeit des "alten" MMI 2G DAB Tuners beschäftigt.

 Zu finden hier

Bisher funktioniert der Ansatz leider noch nicht, ich würde aber schon davon ausgehen, dass er es früher oder später wird.
Ich werde euch aber auch gerne noch einmal gesondert berichten, wenn es der User djwenne (oder sonst jemand) hinbekommen haben sollte.

Ein wenig ist es schon ein Armutszeugnis, dass Audi es nicht für nötig erachtet für die alten MMI 2G Modelle eine Lösung zu erarbeiten und dann anzubieten.
Da sieht man mal wieder, dass ein Autohersteller primär an Verkäufen von Neufahrzeugen interessiert ist und ansonsten mit Scheuklappen durch die Welt rennt :(

Aktuell bin ich mir nicht sicher, ob die MMI 2G Kenwood DAB Tuner eigentlich auch sonst noch irgendwo in nicht-Audi Fahrzeugen verbaut worden sind.
Also, wenn euch da was bekannt ist, dann hinterlasst mir doch bitte mal einen Kommentar. (oder zwei, oder drei...)

Audi MMI 2G / 3G / 3GP TV / Video / DVD Freischaltung währen der Fahrt

Ich habe mich die Tage mal dran gesetzt und den Algorithmus (wenn man ihn denn so nennen möchte) für die TV-Freischaltung bei den diversen Audi MMI Systemen reverse engineered.
Eigentlich sollte die Freischaltung auch bei den neueren Harman-Becker VW Systemen funktionieren.
Ein Feedback diesbezüglich wäre aber wirklich super.

Ok, kommen wir nun zur Berechnung.
Ihr müsst zuerst einmal die Seriennummer eurer 2G / 3G / 3GP Unit auslesen.
Dafür, wie für die gesamte Prozedur, braucht es z.B. VCDS.
VAS oder VAG CAN Professional funktionieren natürlich genauso, wobei VAG CAN Pro sowieso schon eine Prozedur mitbringt, welche die Freischaltung auf Knopfdruck für euch erledigt.

Also, beim 2G per Diagnose in das 07er (Display Interface) Steuergerät gehen.
Beim 3G / 3GP respektive in das 5F (Infotainment 1) Steuergerät anstelle des 07er aufrufen. (das 07er gibt es bei diesen Systemen ja nicht mehr, da dessen Funktionen mit in die Mainunit gewandert sind)
"Advanced ID - 1A" Funktion ausführen.
Ihr seht nun ein Feld Seriennummer.

Berechnung des VIM-Codes:
MM 3G / 3GP / 2G
1. Stelle Login-Code: 0
2. Stelle Login-Code: vorletzte Stelle der Seriennummer
3. Stelle Login-Code: fünftletzte Stelle der Seriennummer
4. Stelle Login-Code: letzte Stelle der Seriennummer
5. Stelle Login-Code: viertletzte Stelle der Seriennummer

Danach dann mit dem zusammengesetzen Login-Code "Security Access - 16" Funktion im VCDS / Tester aufrufen und dort einloggen.

War das erfolgreich "Adaptation - 10" und Anpassungskanal 63 (MMI 2G) bzw. 48 (MMI 3G) auf 255 setzen.
Bekommt ihr an dieser Stelle ein "Anpassungskanal nicht verfügbar", dann habt ihr euch nicht mit dem Security-Code eingeloggt, bzw. irgendetwas ist dabei schief gelaufen.
In diesem Fall die Prozedur einfach in Ruhe noch einmal probieren ;)

Das schöne an der Sache ist, dass man für die Berechnung keine Online-Verbindung (wie bei der trick77.com-Lösung) braucht, sondern auch draußen im Feld bei einer Codieraktion sofort handlungsfähig ist ;)