.bin Datei bearbeitbar?

enigma2man

Newbie
Registriert
Feb. 2024
Beiträge
4
Hallo Forum-Gemeinde,

ich habe ein kleines Problem, welches ich trotz intensiver Recherche nicht alleine lösen kann. Und vielleicht ist ja ein Experte hier im Forum der mir bei der Lösung behilflich sein kann oder entsprechende Anleitung geben.
Ich versuche mich so kurz wie möglich zu halten. Zunächst kurz zu meinen Voraussetzungen. Ich habe Kenntnisse in HTML, CSS, und Java. Und da ich einige Webseiten betreue habe ich auch ein paar Grundkenntnisse in MySQL und PHP.
Derzeit beschäftige ich mich auch mit Python, bin aber auch schon Mitte 60 und mit dem Lernen wird das auch nicht einfacher. :confused_alt::D

Nun zum Problem:
Ich habe mir für mein Bike einen CarPlay Monitor (Iphone) gekauft. Dieser hat als Basis OS Linux. Vom Hersteller habe ich zur Aktualisierung eine ISPBOOT.bin Datei und eine Anleitung bekommen um das Gerät auf den neusten Stand zu bekommen.

Die Originalsoftware hat folgendes Bild als Bootlogo.

Screenshot (18).png

Dieses möchte ich gerne austauschen gegen ein Bild welches ein Bild meines Herstellers zeigt.

Spruce_ktk_large_gallery_1280_960.png

Das Bild liegt in der richtigen Größe und allen gängigen Formaten vor.

Ich habe den Hersteller gefragt ob es möglich ist dieses Bootlogo auszutauschen. Das wurde bejat. Ich sollte ein entsprechendes Bild einsenden was ich auch getan habe. Dennoch werde ich immer mehr hingehalten. Kurz die wollen mir (China) wohl nicht helfen.

Meine Frage ist nun: Wie kann ich diese .bin Datei so bearbeiten, dass ich die Bilddatei in dem Image austauschen kann. Oder vielleicht ist ja hier im Forum jemand der da Erfahrung hat und mit helfen kann die Flashdatei zu bearbeiten. Eventuelle Risiken das Image zu breaken sind mir bewusst.

ich danke euch im Voraus für eure Zeit meinen Beitrag zu lesen
 
Du nicht.
 
  • Gefällt mir
Reaktionen: BeBur
Und sonst hier voraussichtlich auch niemand. Wird niemand hingehen und random bytes in einer Datei zu analysieren nur damit irgendwer ein anderes Bild beim Booten hat.
 
Da die Dateiendung .bin halt erstmal nur für das generische "binary" steht, kann das schlicht alles Mögliche sein, was kein lesbarer Text ist. Das kann eine umbenannte Zip-Datei sein oder eben auch eine komplett unbekannte, proprietäre Ansammlung an Binärdaten, dessen Struktur letztlich nur der CarPlay Monitor (und halt der Hersteller) kennt.
 
  • Gefällt mir
Reaktionen: enigma2man, Gizzmow, Azghul0815 und eine weitere Person
Die Kenntnisse in HTML/CSS/Java/PHP/MySQL nützen dir hier alles nichts - außer dass technisches Verständnis natürlich immer hilfreich ist!

Der Hersteller listet die Firmware Updates nicht öffentlich (nur per Mail für Käufer) aber mit etwas googeln findet sich ein Facebook Post des Herstellers von 2022 mit einem öffentlichen Download Link für die Firmware des MAXCA Xplay C5. Dein Gerät nennst du nicht aber die Architektur und Software sind sicher ähnlich.

Neben der ISPBOOOT.BIN finden sich im heruntergeladenen Archiv ja noch ein paar weitere Dateien (die auf der SD Karte liegen bleiben oder beim Update ausgelesen werden?), siehe dazu den von @jodd2021 verlinkten Post.

Aus Interesse habe ich mir die ISPBOOOT.BIN (72 MiB) mal angeguckt. Verschlüsselt ist die nicht. Darin finden sich zahlreiche uImages für den uBoot bootloader. Diese umfassen 3 identische Kopien von uBoot selbst (424 KB), dann eins mit dem eCos RTOS (2,5 MB), ein Kernel Image von Linux 4.9.217 (4,2 MB) und zwei Images mit dem Titel ISP script for ISPBOOOT.BIN (44,8 KB und 29,7 KB) sowie 6 SquashFS Dateisysteme.

Am Ende der Datei befindet außerdem eine gzip-kompromierte Linux-Binary isp (1 MB). Diese enthält reichlich nützliche Strings und hat wohl die Aufgabe die ISPBOOOT.BIN auf den internen NAND zu installieren. Mit etwas suchen findet man heraus das es sich dabei um dieses Werkzeug von Sunplus handelt welches ISPBOOOT.BIN Dateien packen und flashen kann. Das Beispiel in der README entspricht ziemlich genau unserer ISPBOOOT.BIN: 3x uboot, Kernel image, eCos image sowie SquashFS für die Applikation.

Die SquashFS Dateisysteme enthalten ein rootfs mit Linux userland (libc + busybox + dbus) und einigen low-level Android Komponenten (Android Init, logcat, setprop). Die restlichen werden wie folgt gemountet
Code:
on init
    mount squashfs /dev/blockrom9  /opt wait ro
    mount squashfs /dev/blockrom10 /usr/local wait ro
    mount squashfs /dev/blockrom11 /application wait ro
    mount squashfs mtd@appdata /media/flash/appdata
    mount squashfs mtd@appbins /application/bin/
    mount yaffs2 mtd@nvm /media/flash/nvm wait noatime
    mount yaffs2 mtd@userdata /media/flash/userdata wait noatime
  • /opt enthält nur eine libstdc++.so.
  • /usr/local enthält einige Treiber/Kernel-Module und bekannte Linux-Software, u.a. OpenSSL, ffmpeg, gstreamer, wpa_supplicant/hostapd, sqlite3, mDNSd, tslib für touch input sowie DirectFB+Qt5 für grafische Ausgabe. An mehreren Stellen wird dieses Paket als "SP SDK" bezeichnet. SP steht hier wahrscheinlich für Sunplus, den Hersteller des SoCs im Gerät.
  • /application enthält die Software des Geräteherstellers (MAXCA). Aus irgendeinem Grund wurde das Unterverzeichnis bin/ auf eine weitere Partition separiert. Die Software besteht aus mehreren dutzend Binaries und Libraries. Neben Fonts, Sprachen und Icons finden sich in /application/resource/logo endlich die Bilder die während dem Start angezeigt werden; JPEGs und eine BMP in der Größe 800x480.
  • /media/flash/appdata enthält den Treiber für den Touchscreen und diverse kleine Konfigurationsdateien.
  • Die letzten beiden Mounts sind beschreibbar und finden sich nur auf dem NAND des Geräts. Dort werden Nutzerdaten abgelegt.
Interessante Strings mit Bezeichnungen zum SDK bzw. dem Gerät in /application/appinfo.rc:
Code:
on app_laterc
    export SP_CONFIG_MODEL_PLATFORM_CFG 4RlsCode_8368_U_demov1.4_openall_ew_qt_cfg
    export SP_CONFIG_GLB_GMNCFG_MODEL_UBOOT_CFG gemini_evb_def_config
    export SP_CONFIG_GLB_GMNCFG_MODEL_ECOS_CFG sunplus/gemini_disc
    export SP_CONFIG_GLB_GMNCFG_MODEL_KERNEL_CFG gemini_8368_U_td_defconfig 
    export SP_CONFIG_GLB_GMNCFG_MODEL_SDK_CFG gemini_servo_cfg
    export SP_CONFIG_GLB_GMNCFG_MODEL_APP_CFG sunplus/ew

Auf dem Github Account sunplus-plus1 wo man auch das isp Tool findet veröffentlicht der SoC-Hersteller vorbildlich sämtlichen Quellcode ihrer uBoot und Linux forks, firmware und build tools. Hardware-Bastler dürften hier reichlich Freude haben!

Interessanter Fund /etc/usb_action_8368-U: Schließt man einen mit FAT32 oder exFAT formatierten USB-Stick an und befindet sich darauf eine Datei mit dem Namen gemn_auto.sh wird selbige scheinbar automatisch mit root-Rechten ausgeführt. Grundsätzlich läuft in dem System alles als root und standardmäßige Sicherheitsfunktionen wie ASLR werden noch explizit abgeschaltet. Dies alles hat aber scheinbar der Geräte-Hersteller MAXCA eingebaut.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: JumpingCat, nonick65, dms und 9 andere
Hallo, vielen Dank für eure Antworten. Ich muss mir erstmal alles in Ruhe anschauen und die verschiedenen Lösungen angehen.
Danke!!!
 
Der Mensch ist neugierig und will überall reinsehn. Ich hab die bin auch geladen und damit gespielt. :lol:
 
  • Gefällt mir
Reaktionen: enigma2man
@Marco01_809 Danke für deine Ausführlichen Erklälungen. Ich brauche etwas länger um mich da einzuarbeiten. Mein Gerät ist ein Navifly 5" von der Firma Mekede , www.szmekede.com.
Im Grunde das gleiche wie die anderen Geräte.
So nun gucke ich mal ob ich das hinbekomme und würde an dieser Stelle nochmal schreiben. ;)
 
Dieses hier, Mekede (SS-)MTC5? https://www.mekede.com/Wireless/3361.html
Dafür finde ich leider auf die schnelle gar keine firmware zum Download.
In dem Markt werden leider endlos viele kaum zu unterscheidende Geräte auf den Markt gepumpt und auf diesen Marktplätzen unter ungenauen Namen verkauft.

https://www.mekede.com/Software Download Address1/
Hier sind für andere Geräte Downloads gelistet aber die Links funktionieren alle nicht bei mir.

Man kann wohl davon ausgehen dass Mekede wie MAXCA die gleiche Hardware-Platform von Sunplus und das bereitgestellte "SP SDK" verwenden (Sunplus scheint spezialisiert zu sein auf solche Car displays), aber die tatsächliche grafische Anwendung könnte eine andere sein.

Die generelle Vorgehensweise wäre mit binwalk die ISPBOOOT.BIN zu extrahieren so dass man die squashfs Dateisysteme hat. Aus den *.rc Dateien für Android Init lässt sich rauslesen wie die Partitionen gemountet werden. Und dann muss man die Anwendung finden und wo diese die Bilder ablegt. Aber die Daten die binwalk da rauszieht sind nicht vollständig da es die ISPBOOOT Struktur nicht kennt und nur nach bekannten Fomaten innerhalb des Binärmatsches sucht.

Der eigentlich schwierige Teil wird aber eine funktionsfähige ISPBOOOT.BIN selber wieder zusammenzubauen. Dazu wird man das isp Tool von Sunplus kompilieren und verstehen müssen. Wenn das Tool keinen Befehl hat um die Images sauber zu extrahieren bleibt nichts als die Dateistruktur aus der isp.c zu lernen und die Daten händisch von den richtigen Byte-Offsets der ISPBOOOT.BIN rauszukopieren.

Dann nur das eine squashfs mit den Bildern modifizieren, re-komprimieren und zusammen mit den anderen Bestandteilen mit isp wieder zu einer ISPBOOOT.BIN zusammenfügen. Dazu muss man den Befehl kennen, bzw. anhand der originalen Datei bestimmen. Und hoffen dass man alles gefunden hat was in die ISPBOOOT.BIN gehört. Ich habe zwar keine Signatur gesehen die eine Modifikation unmöglich macht, aber man riskiert auf jeden Fall das Gerät bei der Installation zu bricken.

Insgesamt sehe ich wenig Chance das alles hinzukriegen. Ohne das Gerät genau zu kennen weiß man nicht welche Änderungen gehen und welche nicht. Man müsste sich schon sehr ausgiebig damit beschäftigen wie der bootloader und flash-prozess in dem Gerät funktioniert, was die ISPBOOOT-Struktur alles kann und vorallem was es mit den ISP scripts auf sich hat. Man sollte damit rechnen mehrere Tage in Hex-Editoren zu verbringen wenn man das wirklich durchziehen will. Insbesondere Recovery-Mechanismen wären gut zu wissen wenn man es versaut. Ansonsten läuft das auf Gerät auseinandernehmen und mit JTAG/UART debuggen hinaus.

Die Alternative ist in der Linux-Umgebung (die man ziemlich vollständig allein mit binwalk bekommt) irgendeinen Mechanismus zu finden worüber man als root auf das System kommt (wie das usb_action script das ich bei MAXCA gefunden habe). Und dann die Änderungen nachträglich vornehmen. Dabei würde man nämlich nur mit der Linux-Umgebung arbeiten und würde sich das ganze Geraffel und Risiko mit Bootloader, ISP und Flash-Prozess sparen. Man braucht etwas know-how in Sachen mounts auf Linux um die Bilddateien zu tauschen obwohl die Dateisysteme read-only sind. Ist als root aber machbar. Für Persistenz über reboots hinweg muss man sich noch was einfallen lassen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Evil E-Lex, ni-sc und JumpingCat
@Marco01_809 , ja genau. Du hast in dem Link genau das Gerät um was es geht. Die die aktuell Originalfirmware habe ich. Die hat mir der Support mit einer Flashanleitung geschickt. Aber auch da ist ja das hässliche Moped als Bootbild drin.
Aber ich lese aus deinem Post das dies sehr schwierig wird aus dien funktionierende ISPBooot.bin wieder zu basteln.
Ich denke das ich da wohl leider passen muss. Aber versuchen werde ich das.

Danke nochmal für deine Zeit
 
Zurück
Oben