Suche Audi 3G+ (HN+R) Instrument map activation

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.

Bei Offset 88 - 4 Bytes geändert wird im Vergleich zu P1001 von : 51 45 41 05 zu 96 03 11 EE - für mich für eine VIN eindeutig zu kurz.
Bei Offset 30F18 - 9 Bytes geändert wird im Vergleich zu P1001 von : 23 3F 09 00 04 42 4A 32 4A zu 24 3E 72 B1 04 42 4A 32 43

Im letzten Teil könnte ein Teil einer FIN drin sein, aber wenn man eine VIN wie WAUZZZ4G6MD038903 hätte, dürfte man nur 6MD038903 nutzen, um 9 Bytes abzubilden, und das müsste dann auch dort irgendwie verschlüsselt sein, denn ich bekomme hier nichts in dem Format heraus.