Beim iMX8MQ braucht man für das LPDDR4 leider proprietäre firmware
(https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.9.bin (ist
eine Archivdatei)), das stört mich ein wenig. (Wenn man die Nummer in
der URL ändert, kann man noch andere Firmwareversionen finden).
Jetzt würde ich das gerne reverse-engineeren, und dann durch eigene
Firmware ersetzen. Leider hab ich etwas Probleme damit, überhaupt
irgendwas darüber rauszufinden. Ich habe versucht, binwalk darüberlaufen
zu lassen, das hat aber überhaupt nichts gefunden. Ohne die Architektur
zu kennen, kann ich dinge wie Disassemblieren aber ja erstmal komplett
vergessen.
Ich hab mal versucht, die Häufigkeit der Bytes, normalisiert von 00-FF,
ohne die 0 bytes, auszugeben. Ich glaube die Dateien sind nicht
komprimiert, die *_dmem.bin Dateien könnten Daten sein, und die
*_imem.bin ist vermutlich code, ich hab das oben mal angehängt. Man kann
da gewisse Muster sehen, X0 und 0X scheinen häufiger vorzukommen, als
die meisten anderen werte, insbesondere 10, 20, 40, 80, C0, E0, F0, FF,
0F, 78, etc. wobei C0 am häufigsten vorkommt. Die Werte erinnern mich
sehr an typische Bitmasken.
An dem Punkt bin ich jetzt aber etwas hängen geblieben, wie gehe ich nun
weiter vor?
Hm. Eine Suche nach "iMX8MQ" ergibt als Treffer "i.MX 8 Series
Applications Processors | Arm® Cortex®-A72/A53/A35/M4"
Das wäre also ein ARM.
Ich meine, irgendwoher musst Du doch die Bezeichnung "iMX8MQ"" haben. Wo
her? Von einem IC abgelesen? Auf ner Verpackung? Manual? Dann wüsste
man, ob die Zuordnung plausibel ist.
Theor schrieb:> Eine Suche nach "iMX8MQ" ergibt als Treffer "i.MX 8 Series> Applications Processors | Arm® Cortex®-A72/A53/A35/M4"> Das wäre also ein ARM.
Ja, der Hauptprozessor schon. Aber der DDR-PHY in dem SOC, auf dem der
Code läuft, scheint aber was anderes zu sein. Meine Versuche, das als
diverse varianten von ARM code zu disassemblieren, haben jedenfalls
nichts hervorgebracht, was mir plausibel erschienen wäre.
Theor schrieb:> Ich meine, irgendwoher musst Du doch die Bezeichnung "iMX8MQ"" haben. Wo> her?
Das ist der SOC, der im L5 Devkit & Phone verbaut ist.
Ein Prozessor extra zur Ansteuerung von RAM klingt etwas kurios...
Sicher dass das Programmcode ist, und nicht einfach eine Art Tabelle mit
Kalibrations-Daten für das Timing des PHY für verschiedene RAM-Typen?
Wie wird diese Datei denn eingesetzt - an eine bestimmte Speicher Stelle
geschrieben?
Du könntest schauen was NXP sonst noch so an (proprietären?)
Architekturen verwendet und schauen ob das ein entsprechender Code ist.
Wenn schon wird das was Low-Cost mäßiges sein, 8051 oder sowas. ARM wäre
für so ein Helferlein zu teuer...
Ja. Mir kommt es auch wahrscheinlicher vor, dass das Code ist der eine
andere PHY-Konfiguration beinhaltet und auf dem ARM läuft. Oder eine
Datendatei die vielleicht nur Konfigurationsdaten enthält.
Gibts denn keine Angaben dazu, was man mit der Datei anfangen soll? PHYs
mit eigenen Prozessor? Hm. IP-Cores kenne ich dafür noch.
Theor schrieb:> und auf dem ARM läuft.
Also ARM A32 Code ist das fast sicher nicht. Wenn schon dann T32 oder
A64.
Welcher i.MX ist das genau? Einer mit ARMv8? Welcher ARM-Kern?
DPA schrieb:> Meine Versuche, das als diverse varianten von ARM code zu> disassemblieren, haben jedenfalls nichts hervorgebracht, was mir> plausibel erschienen wäre
Zeig mal...
Vielleicht wäre es sinnvoll die Datei als großes Integer Array zu
interpretieren und darüber Statistiken zu machen (Histogramm und so).
Wenn das eine Tabelle ist, sollten sich da Tendenzen erkennen lassen...
Eine Version 5.4 findet man öfters, hier steht eine Beschreibung dazu:
https://github.com/Freescale/meta-freescale/blob/master/SCR/SCR-4.1.15-2.0.0.txt
Package: firmware-imx-5.4.bin
Outgoing License: LA_OPT_BASE_LICENSE v12 March 2016
License Files: COPYING
Package Category: BSP
Type of content: Binaries
Description and comments: BSP firmware - EPDC, SDMA, VPU
Release Location: i.MX Yocto Project mirror
Origin: Freescale Semiconductor, Inc. (proprietary)
Chips & Media, Inc. (proprietary)
(BSP = board support package ?)
EPDC, SDMA, VPU scheint unterschiedliche Hardware zu sein, die hier
bedient wird
Wenn das die FW für die Training-Engine ist, die die korrekten
Phasenoffsets für die Übernahme der Daten bestimmt, könnte das sonstwas
selbstgestricktes sein. Besonders intelligent und umfangreich muss die
CPU da nicht sein. Könnte also auch ein 8051 sein ;)
die sind alle excuteable im Gegensatz zu dem Rest. Die *_imem.bin und
*_dmem.bin haben laut binwalk eine Entropy von ca. 0.8 das legt den
Verdacht nahe da diese Gepackt oder Verschlüsselt sein können. Sollte es
ein Schlüssel sein, wirst du nicht drumherum kommen diesen zu Extrairen,
woher auch immer.
interessant können auch die txt Datein sein, welche dir ein paar
Begriffe URLs und schlag Wörter für google liefern könnten um die
Firmware mehr zu verstehen.
imonbln schrieb:> An deiner Stelle würde ich mich zuerst für die folgenden Dateien> interessieren.> ./firmware-imx-7.9/firmware/vpu/vpu_fw_imx8_dec.bin> ./firmware-imx-7.9/firmware/vpu/vpu_fw_imx8_enc.bin> ./firmware-imx-7.9/firmware/epdc/epdc_ED060XH2C1.fw.nonrestricted> ./firmware-imx-7.9/firmware/hdmi/cadence/signed_dp_imx8m.bin
Die Dateien verwende ich momentan aber garnicht. Auf den RAM hingegen,
kann ich nicht verzichten.
DPA schrieb:> Die Dateien verwende ich momentan aber garnicht. Auf den RAM hingegen,> kann ich nicht verzichten.
Und? wie du im Original Post geschrieben hast:
DPA schrieb:> Jetzt würde ich das gerne reverse-engineeren, und dann durch eigene> Firmware ersetzen. Leider hab ich etwas Probleme damit, überhaupt> irgendwas darüber rauszufinden.
Du brauchst also etwas das, dir Hilft die originale Firmware zu
verstehen. Die Entropy der Teile die dich Interessieren deutet an, dass
Sie Komprimiert sind oder Verschlüsselt.
Diese Dateien welche ich Dir genannt habe, haben A eine Entropy von ca
0.2 und B unterscheiden Sie sich von den anderen dadurch das Sie
excuteable sind.
Es lohnt sich also hier zu forschen um Erkenntnisse über das gesamt
System zu erhalten auch wenn das nicht die Droiden sind die Du suchst.
Die alliierten, haben unter anderem die Wetterdaten zum Knacken der
Enigma verwendet. (siehe
https://de.wikipedia.org/wiki/Enigma_(Maschine)#Entzifferung ) ich kann
dir Garantieren, die wollten sicher auch nicht über das Wetter reden, es
hat Ihnen aber geholfen an die wichtigen Informationen zu kommen.
Deine Aufgabe ist es nun ein Zugang zu den Daten zu finden und deshalb
schlage ich vor, jeder Abweichung nachzugehen, bis du genügend
Informationen hast um den Teil zu verstehen der Dich interessiert.
imonbln schrieb:> Die Entropy der Teile die dich Interessieren deutet an, dass> Sie Komprimiert sind oder Verschlüsselt.
Dann wäre das aber keine besonders gute Komprimierung. Schau dir nur mal
das Bild im ersten Post an. Bei verschlüsselten Inhalten, gegzipten
Dateien und weissem Rauschen hab ich eine sehr gleichmässige Verteilung,
aber bei der Firmwaredatei sieht man da eindeutig muster und bytes die
öfter vorkommen. Wenn man nur die geraden oder ungeraden bytes anschaut,
wird es sogar noch eindeutiger.
> Diese Dateien welche ich Dir genannt habe, haben A eine Entropy von ca> 0.2 und B unterscheiden Sie sich von den anderen dadurch das Sie> excuteable sind.
Diese sind aber auch für komplett andere Komponenten. Selbst wenn diese
mit dem DDR-PHY interagieren, die Ansteuerung von aussen ist ja kein
Geheimnis, da schau ich besser im U-Boot code oder in den Datenblättern
nach (wenn ich die mal finde). Ich muss rausfinden, was das Ding intern
mit dem Firmwarecode macht, und da hilft es definitiv nichts, wenn ich
mir was davon komplett unabhängiges anschaue.
Das ist auch nicht wie die Wetterdaten bei der Enigma, die SOC
Hersteller kaufen sich die einzelnen Komponenten doch von
unterschiedlichen anderen Herstellern ein, und verbinden die dann halt,
dadurch sind interne gemeinsamkeiten zwischen diesen dort doch sehr
unwahrscheinlich.
1 MByte ist aber schon ordentlich viel für bisschen DDR-PHY training und
intialisieren - da ist doch sicher noch mehr drin für irgendwas anderes
(möglicherweise also sogar unterschiedliche Architekturen in einem
Binary).
Unbenannt.PNG
(20 KB)
