Ich bin noch über diese Threads gestolpert:
https://xdaforums.com/t/any-idea-wh...s-wireless-aa-carplay-display-screen.4561807/
https://salvatorenoschese.it/carplay-lite-c5-aggiornamento-firmware/
Anscheinend sind die Firmwares der Hersteller MAXCA, Mekede und Carsara quasi gleich und in neueren Versionen der Firmware hätten sie ein Feature eingebaut um das Boot-Logo auszutauschen. Dazu eine
LOGO.jpg in 1024x600/800x480 (je nach Gerät?) auf den gleichen Speicher legen wo man auch die ISPBOOOT.BIN hinkopiert. Wie man die Firmware dann dazu kriegt dieses Bild zu verwenden ist etwas unklar. Da wird gesprochen von einfach 2x Rebooten.
Der andere Artikel sagt die
LOGO.jpg und
ISPBOOOT.BIN auf einen FAT32 USB Stick, bei laufendem Gerät anstecken und es rebootet automatisch. Oder es gibt ein verstecktes Herstellermenü wo man eins von mehreren Logos auswählen kann und die jpeg Datei wäre auch darunter.
Diese Vorgehensweise wäre auf jeden Fall vorzuziehen. Ich habe in der Zwischenzeit aber auch nochmal ein bisschen rumgespielt und einen gangbaren Weg gefunden um die ISPBOOOT.BIN zu modifizieren. Ich habe das nicht bis zum Ende vollzogen und kann es mangels Gerät ohnehin nicht testen, aber meine gesammelten Erkenntnisse will ich zumindest aufschreiben
Es gibt
hier ein paar Grafiken zur Struktur der ISPBOOOT.BIN. Die Partitionen treffen nicht genau zu weil dort ein SP7350 beschrieben ist. Aus den Strings der appinfo.rc wissen wir aber dass zumindest das MAXCA Gerät mit einem SPHE8368-U arbeitet. Die SPHE8* Familie ist für Car Displays gedacht und wird
hier von Sunplus beschrieben.
Zum bearbeiten der ISPBOOOT.BIN schrieb ich ja das man sich die Struktur anhand der
isp.c anlernen müsse um die richtigen Byte-Offsets zu finden. Ich hätte mir denken können dass jemand dafür bereits ein Tool gebastelt hat:
https://github.com/tibbotech/ispe Das kann die Partitionen in der ISPBOOOT auflisten, löschen, anlegen und den Partitionsinhalt in eine Datei kopieren oder mit einer Datei überschreiben. Schaut man in die
examples/mender.repack.sh wird aber klar: Sooo viel Arbeit nimmt einem das Ding dann doch nicht ab
Ich gehe hier von Linux aus (WSL1/2 gehen) da wir eh die squashfs Werkzeuge brauchen.
Wir brauchen Git, GCC/G++, Make, die Entwicklerversion von OpenSSL und die Squashfs-Tools. Unter Debian z.B.
Code:
$ sudo apt update && sudo apt install git build-essential libssl-dev squashfs-tools
Dann
ispe runterladen und kompilieren mit dem Flag
SOC_SPHE. Das ist wichtig weil die SPHE-SoCs eine minimal abweichende ISP Struktur zu anderen Sunplus Systeme haben.
Code:
$ cd ~; git clone "https://github.com/tibbotech/ispe"
$ cd ispe
$ make CFLAGS+="-DSOC_SPHE"
Einen Ordner zum Arbeiten anlegen (auf einem Linux-Dateisystem!) und unsere ISPBOOOT.BIN dort reinkopieren. Original behalten nicht vergessen.
Mit
ispe können wir uns jetzt die Partitionen anschauen. Wir überprüfen dass die Daten Sinn ergeben: mehrere Partitionen gelistet, keine negativen sizes oder tail data len.
Code:
$ cd ~/Mod
$ ~/ispe/ispe ISPBOOOT.BIN list
HEADER 0x100000 :
sign (str,32/32): Gemini_ISP_image
sign (hex,32/32): 47656D696E695F4953505F696D6167650000000000000000
init script (str,16/1976): if test "$isp_if<skipped...>
init script size: 1328
flags: 0x1
PARTITION[0]
filename: xboot1
md5sum: f310fe4cfedb35b60ac3ff86ff684b4c
file offset: 0x104000
file size: 20480
[....]
Dann kopieren wir die Partition die wir bearbeiten wollen in eine separate Datei. Falls nötig probieren bis man die richtige gefunden hat. In der MAXCA Firmware die mir vorliegt heißen die Squashfs-Partitionen
rootfs. (/),
opt. (/opt),
spsdk. (/usr/local),
spapp. (/application),
appdata (/media/flash/appdata) und
appbins (/application/bin). (Der Punkt bei den ersten 4 ist kein Fehler).
Code:
$ ~/ispe/ispe ISBOOOT.BIN part spapp. extp
Das erstellt uns eine Datei
isp.p.spapp. die nur den Inhalt dieser Partition enthält. Mit
file können wir testen ob es sich um ein squashfs handelt. Ist das der Fall schauen wir uns noch die Squashfs-Metadaten an und entpacken es als root damit die ganzen Dateiattribute erhalten bleiben. (Darum ist auch das Linux-Dateisystem wichtig).
Code:
$ file isp.p.spapp.
isp.p.spapp.: Squashfs filesystem, little endian, version 4.0, lzo compressed, 14518236 bytes, 826 inodes, blocksize: 32768 bytes, created: Fri Jul 15 04:24:30 2022
$ sudo unsquashfs -s isp.p.spapp.
Found a valid SQUASHFS 4:0 superblock on isp.p.spapp..
Creation or last append time Fri Jul 15 06:24:30 2022
Filesystem size 14518236 bytes (14177.96 Kbytes / 13.85 Mbytes)
Compression lzo
algorithm lzo1x_999
compression level 9
Block size 32768
[...]
$ sudo unsquashfs isp.p.spapp.
Nun haben wir einen Ordner
squashfs-root in dem die ganzen Dateien aus dem squashfs liegen. Diese können wir jetzt modifzieren. In diesem Fall die bmp und jpg Bilder in
resource/logo. Mit
file vorher und nachher sollten wir überprüfen das wir die Dateiformate möglichst genau nachahmen, da wir nicht wissen wie genau die App es nimmt.
Aus einem Grund der erst später klar wird dürfen wir in Summe nicht mehr Bytes haben als vorher. Das können wir z.B. beeinflussen indem wir die Qualität der jpg runterdrehen bis sie kleiner ist als die alte. Oder wir überschreiben alle dort liegenden jpgs durch unsere eigene; durch die squashfs deduplication wird der Platz in Wirklichkeit nur einmal gebraucht.
Dann bauen wir uns eine neue squashfs zusammen. Dabei berücksichtigen wir die Block size und Komprimierung die wir vorher aus den Metadaten ausgelesen haben:
Code:
$ mksquashfs squashfs-root/ spapp.sqfs -b 32K -comp lzo -Xcompression-level 9
Wir stellen sicher dass das neue Squashfs auf das Byte genau gleich groß oder kleiner ist als das alte. Dann füllen wir die neue Datei mit Nullen auf die gleiche Größe auf:
Code:
$ stat --printf '%s\n' isp.p.spapp.
14520320
$ stat --printf '%s\n' spapp.sqfs
14053376
$ fallocate -l "$(stat --printf '%s\n' isp.p.spapp.)" spapp.sqfs
$ stat --printf '%s\n' spapp.sqfs
14520320
Jetzt schreiben wir unser neues squashfs in die
spapp. Partition der ISPBOOOT. Vergleichen wir die Ausgabe vom list Befehl auf der modifizierten und originalen ISPBOOOT sehen wir das sich außer dem md5 hash der partition nichts geändert hat.
Code:
$ ~/ispe/ispe ISPBOOOT.BIN part spapp. file spapp.sqfs
Schön wärs wir wären jetzt fertig. Leider machen uns die ISP scripte einen Strich durch die Rechnung.
Wenn man mit einer ISPBOOOT.BIN das Gerät startet, dann wird der uboot0 aus dieser Datei geladen und führt das ISP script aus. Dieses ISP script enthält Befehle für die uBoot-Umgebung die die relevanten Partitionen aus der ISPBOOOT.BIN auf den NAND bzw. eMMC des Geräts kopieren. Leider parsen diese Scripte gar nicht die ISPBOOOT Struktur die wir jetzt so schön angepasst haben. Die Scripte wurden automatisch generiert und alle Offsets, Größen und MD5 hashes sind hardcoded.
Wir haben zwar sichergestellt das Offsets und Größen alle gleich geblieben sind, aber da die Daten anders sind passt der MD5 hash nicht mehr. Würde man die ISPBOOOT.BIN jetzt booten bekäme man irgendwo in der Mitte des Firmware Updates einen MD5 Fehler.
Die ISP scripte zu modifizieren ist leider nochmal etwas Aufwand. An dieser Stelle hab ichs dann auch gelassen aber es müsste so gehen: Mit
ispe ISPBOOOT.BIN head exts das Init ISP script auslesen. Darin sind die Byte-Offsets zu zwei weiteren ISP scripts die ans Ende der ISP Struktur angehängt sind ohne in der ISP Partitionstabelle zu stehen: Eins für Geräte mit eMMC, eins für NAND.
Die Scripte sind als uImage verpackt - daher diese mit dumpimage aus den u-boot-tools zum script zurückwandeln. Dann die entsprechende Stelle im Script finden (
echo verifying spapp. ...). In mehreren Absätzen wird da jeweils der MD5 hash von 2MB großen Blöcken berechnet und verglichen. Also unsere neue spapp.sqfs in 2MB Häppchen hashen (
split -b 2M --filter="md5sum" spapp.sqfs) und die neuen Hashes eintragen. Dann das script mit mkimage wieder in ein uImage verpacken und mit geeigneten Tools an das gleiche Byte-Offset in der ISPBOOOT.BIN schreiben.
Ich überlegte zuerst einfach mit sed die hashes über die ganze ISPBOOOT.BIN zu ersetzen (was auch geht da die uImages die Scripte im Klartext enthalten), aber die uImages sind selbst auch nochmal gehasht.
Wenn man das alles erledigt hat sollte die neue ISPBOOOT.BIN meiner Kenntnis nach vollkommen valide sein und auf die gewohnte Art geflasht werden können. Aber keine Garantie; gut möglich dass ich noch was übersehen habe und das Gerät beim flashen bricked. Sollte nur ausprobiert werden wenn der völlige Verlust des Geräts hinnehmbar ist.
