Bild im Hexdump finden

[Olli Z. (z80freak)]

Ich habe hier ein Ford Kombiinstrument mit TFT-Display. Dieses zeigt 
beim anlegen einer Betriebsspannung (im Auto wäre das Zündplus) ein 
Startlogo an (siehe Bilder).

Auf der Platine befinden sich im uC-Teil, ein EEPROM (da ist sicher der 
Kilometerstand enthalten), ein NXP-uC (MAC7116) mit 1MByte Flash für die 
Betriebssoftware, ein LCD-Controller, ein paar Logik-ICs (Pegelwandler 
und Buffer) und ein 2 MByte Flash (S29GL016).

Den habe ich mal ausgelötet und ausgelesen (Dumpfile anbei). Beim 
anlegen der Betriebsspannung mit ausgelötetem Flash kommt nur ein kurzes 
"rauschen" im Bildschirm. Nach dem wiedereinlöten hatte ich wohl einen 
Datenkontakt nicht sauber verlötet und das Startlogo blieb aus 
(schwarzer Bildschirm, nur mit KM-Anzeige). Daher vermute ich das das 
Logo da drin steckt.

Das Flash ist auch nur etwas weniger als zur Hälfte gefüllt. Mit dem 
Dump kommte ich aber nicht klar, sprich ich finde dort kein Bild. 
Vielleicht hat ja hier jemand eine Idee wo und wie das da drin steckt!?

Um ein paar Randparameter zu bestimmen habe ich mir das Display 
angeschaut (siehe Bild). Leider konnte ich über das gute Stück nichts 
rausfinden, noch ein Datenblatt irgendwo herunterladen. Über eine 
China-Verkaufsseite konnte ich 800x480 ermitteln. Ob das jedoch 
stimmt...

Das Logo sieht irgendwie gedithert aus, also scheinbar kein 24-Bit RGB.

[Wolfgang (Gast)]

Olli Z. schrieb:
> Mit dem Dump kommte ich aber nicht klar, sprich ich finde dort kein Bild.

Wie versuchst du denn das Bild zu identifizieren.
Wenn das komprimiert abgelegt ist und du keine Zeilenkorrelationen mehr 
erkennen kannst, wird das IMHO mühselig.
Da wäre es vermutlich einfacher, wenn der Kumpel mal seinen Kumpel beim 
Softwarehersteller vom Gerät fragt, wie das Logo abgelegt ist.

Hast du mal abgeschätzt, wie groß ein flach im Speicher abgelegtes Bild 
sein müsste und wie das zum Speicherinhalt passt. In dem Flash kann 
natürlich auch noch was anderes drin sein, oder funktioniert ohne sonst 
alles?

[Olli Z. (z80freak)]

Wolfgang schrieb:
> Wie versuchst du denn das Bild zu identifizieren.
Ich habe erstmal nach bekannten Magics gesucht. Evtl. ist es ja ein 
JPEG, BMP, oder sonst wie bekanntes Format.

> Wenn das komprimiert abgelegt ist und du keine Zeilenkorrelationen mehr
Ob die sich bei genügend Platz die Mühe einer Kompression gemacht 
haben... erscheint mir jetzt irgendwie unplausibel, auch wenn es möglich 
ist.

> erkennen kannst, wird das IMHO mühselig.
Stimmt wohl (seufz)

> Da wäre es vermutlich einfacher, wenn der Kumpel mal seinen Kumpel beim
> Softwarehersteller vom Gerät fragt, wie das Logo abgelegt ist.
So einen Kumpel hab ich leider nicht.

> Hast du mal abgeschätzt, wie groß ein flach im Speicher abgelegtes Bild
> sein müsste und wie das zum Speicherinhalt passt. In dem Flash kann
Also wenn die 800x480 Pixel laut Verkaufsplattform stimmen und man das 
Bild wirklich 1:1 abgelegt hat und nicht nur das Logo mit 
Positionsangaben und ich von einer kleinen Farbpalette ausgehe (ui ui, 
so viele Konjungtive):
800x480x8 = 3 MB. Jedoch ist es nicht ganz so hoch weil unten noch der 
KM-Zähler steht. Dennoch wäre es selbst mit 8Bit Farbpalette zu groß 
fürs Flash. Vielleicht haben die doch komprimiert, so was einfaches wie 
LZW.

> natürlich auch noch was anderes drin sein, oder funktioniert ohne sonst
> alles?
Witzigerweise ja. Als das Flash falsch eingelötet war, konnte ich auf 
dem CAN-Bus normale Aktivität feststellen. Auch konnte ich IGN als 
CAN-Botschaft senden und das Display sprang in den Betriebsmodus. Daher 
bin ich mir sehr sicher das es da drin stecken muss.

[Olli Z. (z80freak)]

Von dem EPSON LCD-Controller (S2D13A05F00A1) finde ich leider auch 
nirgens ein Datenblatt :-(
Evtl. hätte man darüber an die Auflösung und Farbtiefe kommen können. 
Womöglich sogar aufs Bildformat.

[Christopher J. (christopher_j23)]

Hast du mal binwalk darauf losgelassen?

[Rufus Τ. F. (rufus)]

Olli Z. schrieb:
> 800x480x8 = 3 MB

Interessante Rechnung. Wie kommst Du auf 8 Byte pro Pixel?

Bei 24-Bit-RGB sind das 1152000 Bytes (800 x 480 x 3). In Dein 
2-MByte-Flash würde das schon 'reinpassen; wie präzise ist Dein "nur zur 
Hälfte gefüllt"?

> Dennoch wäre es selbst mit 8Bit Farbpalette zu groß fürs Flash.

Erst recht nicht. Das sind doch nur 384000 Bytes + Größe der 
Farbtabelle.

Ansonsten wäre eine 16/15-Bit-Darstellung denkbar, dann wäre das Bild 
768000 Byte groß, was auch immer noch locker in Dein halbvolles Flash 
passt.

[Hmmm (Gast)]

Olli Z. schrieb:
> Also wenn die 800x480 Pixel laut Verkaufsplattform stimmen und man das
> Bild wirklich 1:1 abgelegt hat und nicht nur das Logo mit
> Positionsangaben und ich von einer kleinen Farbpalette ausgehe (ui ui,
> so viele Konjungtive):
> 800x480x8 = 3 MB.

Nicht Bits und Bytes verwechseln!

800x480 sind 384.000 Pixel, also bei 8 Bits pro Pixel auch 384.000 
Bytes.

[TestX (Gast)]

hast du mal versucht blockweise "müll" in den flash zu schreiben ?

[Olli Z. (z80freak)]

Aaargh! IHR HABT JA RECHT, wo war ich mit meinen Gedanken?!!

[Olli Z. (z80freak)]

Christopher J. schrieb:
> Hast du mal binwalk darauf losgelassen?

Das tool kannte ich nicht. War grad dabei mir in PHP was zu 
programmieren, um die Daten Zeilenweise in ein Bild zu schreiben... ich 
meine im Texteditor geladen die Logostruktur zu erahnen...

[Äxl Real (Gast)]

Die Jungs von "Conversmod" nehmen 20Euro dafür, das Du Dir von denen 
dein Startlogo aufspielen lassen kannst, gegen aber (natürlich) keine 
Infos raus.
https://www.conversmod.de/index.php?page=files&language=de

[wendelsberg (Gast)]

Äxl Real schrieb:
> Die Jungs von "Conversmod" nehmen 20Euro dafür, das Du Dir von denen
> dein Startlogo aufspielen lassen kannst, gegen aber (natürlich) keine
> Infos raus.

Also: Flashdump - 20EUR - wieder Flashdump und vergleichen.

wendelsberg

[Olli Z. (z80freak)]

TestX schrieb:
> hast du mal versucht blockweise "müll" in den flash zu schreiben ?

Ne, die Idee hatte ich zwar auch, aber es ist schon recht mühselig das 
immer aus und wieder einzulöten :-/ Ich muss mir mal den vermeintlichen 
JTAG-Header näher ansehen, vielleicht komme ich ja da drüber, via dem 
NXP-Chip, zu den Flash-Signalleitungen...

[Äxl Real (Gast)]

Ich hab Schiß, mein Convers+ zu verammeln. Ich hab nur den einen Mondeo 
;)
Aber prinzipiell sollte das gehen. Das Bild wird in RGB565 abgelegt.

[Hmmm (Gast)]

Äxl Real schrieb:
> Das Bild wird in RGB565 abgelegt.

Ab 0x90db8 kommt nur noch 0xef, macht 593336 Bytes, also gerade mal rund 
12 Bits pro Pixel bei 800x480. Bei 800x400 (80 Pixel "Footer" kommen in 
etwa hin) sind es knapp 15 Bits.

In einem Forum ist von Logos mit 400x198 die Rede, evtl. wird das Logo 
im Flash auch auf 800x396 hochskaliert.

[Olli Z. (z80freak)]

Äxl Real schrieb:
> Ich hab Schiß, mein Convers+ zu verammeln. Ich hab nur den einen Mondeo
;)
Ich auch, aber ein Spiel- und Bastelconvers noch dazu :-) "Leider" hab 
ich nen FL und da geht das vFL Convers nur mittels Patch (weil etwas 
andere CAN-Messages), daher sind meine Versuche auf die Werkbank 
reduziert.

> Aber prinzipiell sollte das gehen. Das Bild wird in RGB565 abgelegt.
Cool! Wenn Du dir da sicher bist. Wären 16 Bit für 2 Pixel, je 5-Bit pro 
R und B-Farbkanal und 6-Bit für G. Ich kann ja mal versuchen mit meinem 
PHP-Script alle Bytes des Flash nach dieser Logik in ein RGB-Image zu 
legen und dann mal mit dem Startoffset und der Bildbreite spielen...

Hmmm schrieb:
> Ab 0x90db8 kommt nur noch 0xef, macht 593336 Bytes, also gerade mal rund
> 12 Bits pro Pixel bei 800x480. Bei 800x400 (80 Pixel "Footer" kommen in
> etwa hin) sind es knapp 15 Bits.
Ich glaub eher das nur ein Teil des Bildes, der mit dem eigentlichen 
Logo, dort drin steckt. Und das es auch keinen schwarzen sondern 
"transparenten" Hintergrund hat. Aber alles noch Spekulatius. Wir kommen 
der Sache aber scheinbar näher :-)

> In einem Forum ist von Logos mit 400x198 die Rede, evtl. wird das Logo
> im Flash auch auf 800x396 hochskaliert.
Eher nur das es so groß ist und nicht skaliert wird.

Achja, den JTAG hab ich inzwischen ausgemessen. Jetzt suche ich gerade 
an welchen Pins der NXP mit dem Flash verbunden ist. Die haben dort noch 
Levelconverter (LCX16245) zwischengeschaltet. Mit dieser Info wüsste ich 
dann an welchen Bitpositionen vom JTAG BS-Register die Pins liegen und 
könnte diese evtl. via JTAG ansprechen und so das Flash mit meinen 
Wunschwerten programmieren. Bis dahin ist aber noch ein Stück Arbeit...

[Hmmm (Gast)]

Olli Z. schrieb:
>> In einem Forum ist von Logos mit 400x198 die Rede, evtl. wird das Logo
>> im Flash auch auf 800x396 hochskaliert.
> Eher nur das es so groß ist und nicht skaliert wird.

Nein, das Logo ist etwas breiter als der halbe Bildschirm.

Zudem ist 400x198 ziemlich passend bei einem 800x480-Display mit einem 
rund 80 Pixel hohem Footer, die 4 Pixel sind wohl die schwarze 
Trennlinie.

[Rufus Τ. F. (rufus)]

Olli Z. schrieb:
> Wären 16 Bit für 2 Pixel, je 5-Bit pro R und B-Farbkanal und 6-Bit für
> G.

Äh ... nein. 16 Bit für ein Pixel.

[Olli Z. (z80freak)]

So, habe mit angefügtem PHP-Skript den Dump mal auf verschiedenste Weise 
"Visualisiert". Als Theorie habe ich folgendes angewand:

Annahme:
Jeder Farbpixel ist im RGB565-Format gespeichert, also 16 Bit pro Pixel.
Die Daten liegen im Big-Endian Format vor, also zuerst das MSB und dann 
LSB.
Die Daten enden bei Adresse 0x90D9E.

Visualisierung:
Ich beginne bei Offset 0x0000 im Dump und erzeuge Bilder variabler 
Breite, beginnend von 128 Pixel bis 800 Pixel.
Die Höhe ergibt sich dann aus der verfügbaren Datenmenge.
Jeder 16-Bit Wert wird in einen Wert pro Farbkanal zerlegt:
R = (DUMPWERT >> 11)  & 0b00011111;
G = /DUMPWERT >> 5) & 0b00111111;
B = DUMPWERT & 0b00011111;
und anschließend hoch transponiert (simulation fehlender 
Farbtiefe/Auflösung):
R = R * 8;
G = G * 4;
B = B * 8;

Ergebnis:
Die so entstandenen Bilder weisen zwar regelmäßige Muster aber kein 
Erkennbares Bild auf. Auch die Umstellung auf Little-Endian, oder die 
Verwendung von Offset=1 bringen kein klares oder phasenverschobenes Bild 
zu Tage.

Ich glaube langsam doch an einen Packalgorithmus :-(

[Olli Z. (z80freak)]

Hmmm schrieb:
>>> In einem Forum ist von Logos mit 400x198 die Rede, evtl. wird das Logo
>>> im Flash auch auf 800x396 hochskaliert.
Welches Forum wäre das denn? Vielleicht kann ich da nochmal nachfragen.

[Olli Z. (z80freak)]

So, die Kontakte des Flash habe ich soweit "durchgeklingelt". Alles da, 
A0-A16, DQ0-DQ15, Steuerpins. Witzigerweise gehen die Adressen fast 1:1 
auf die korrespondierenden Pins vom MAC7116 (hat der vielleicht DMA?). 
Ebenso die Datenbytes. Einzig merkwürdig ist das die Adressbits um eins 
nach oben verschoben sind, also A0 vom Flash geht auf A1 vom MAC, A16 
vom Flash auf A17 vom MAC. Wozu das gut sein soll...

Flash    MAC7116 (PIN)
A0       ADDR1 (10)
...
A15      ADDR17 (119)
DQ0      DATA0 (138)
...
DQ15     DATA15 (65)
/WE      R/W* (85)
/CE      /CS0 (84)
/RESET   PB15 (78)
/OE      /OE (68)
BYTE#    + (HIGH)
WP#/ACC  -nicht verbunden-
RY/BY#   -nicht verbunden-

Jetzt mach ich mich mal auf die Suche nach einem BSDL File.

[Μαtthias W. (matthias)]

Olli Z. schrieb:
> Einzig merkwürdig ist das die Adressbits um eins nach oben verschoben
> sind, also A0 vom Flash geht auf A1 vom MAC, A16 vom Flash auf A17 vom
> MAC. Wozu das gut sein soll...

Ist ein 16 Bit Flash und A0 ist die Byteadresse. Braucht man also nicht. 
Das passt schon so.

Matthias

[René F. (Gast)]

Probiere mal die Software „Tile Molester“.

[Olli Z. (z80freak)]

René F. schrieb:
> Probiere mal die Software „Tile Molester“.

Vielversprechendes Tool, Danke! Werde mich mal mit beschäftigen.

[Hmmm (Gast)]

Olli Z. schrieb:
> Hmmm schrieb:
>>>> In einem Forum ist von Logos mit 400x198 die Rede, evtl. wird das Logo
>>>> im Flash auch auf 800x396 hochskaliert.
> Welches Forum wäre das denn? Vielleicht kann ich da nochmal nachfragen.

Hier gibt's ein Beispiel, wo man auch ein grosses Logo sieht:

http://www.talkford.com/community/topic/226452-convers-firmware-modifications-new-functions/page-54

Und die Info, dass es nicht 400x200, sondern 400x198 Pixel sind:

https://mondeo-mk4.de/index.php/Thread/15230-Custom-Firmware-f%C3%BCrs-Convers-mit-netten-Features/?pageNo=44

[Philipp K. (philipp_k59)]

Das Bild ist doch definitiv gedithert.

16bit ist man da weit entfernt und im Flash sind bestimmt auch die Fonts 
und sonstige Bildchen abgelegt..

[Olli Z. (z80freak)]

Also suche ich nach einem Bild mit 400x198 Pixel, mit vermutlich nur 256 
Farben aus einer Palette. Das wären dann 8 Bit pro Pixel und hat nix mit 
RGB565 zu tun. Die Palette müsste ich erstmal ignorieren können, denn 
erkennen sollte man es auch ohne diese. Nur halt etwas „psychodelisch“ 
;-)

Unkomprimiert wären das dann nur 79.200 Bytes (0x13560). Da wär ja noch 
elend viel Platz für anderes Zeugs... womöglich die restlichen Grafiken 
vom Displaysystem?!

[Olli Z. (z80freak)]

Also egal was für eine Farbpalette verwendet wird. Wenn ich den 
Indexwert des Pixels als RGB Wert nehme habe ich s/w. Einzig muss och 
herausfinden wo die Pixeldaten starten. Also den Offset solange erhöhen 
bis ein erkennbares Bildmuster da ist. Immer vorausgesetzt es wirkt 
nicht zusätzlich eine kompression...

[Philipp K. (philipp_k59)]

Brauchst ja nur deinen PHP Code in 8bit umschreiben.

[Olli Z. (z80freak)]

Philipp K. schrieb:
> Brauchst ja nur deinen PHP Code in 8bit umschreiben.

Hab ich sofort gemacht, die Ergebnisse sind jedoch ebenso, nur 
verrauschter Müll.

Was mir aufgefallen ist, weil ich eine Patternsuche schreiben wollte, 
das die initiale Bytesequenz (ab Adresse 0x0000) recht häufig zu finden 
ist:

00 00 FF 00 00 01 00 00 00 00 00 00 00

Dazwischen ist immer unregelmäßig viel Platz. Könnte ein Teil eines 
Bildheaders sein. Ein passendes Magic konnte ich dazu bislang nicht 
ermitteln.

Hinter dieser Sequenz folgen unterschiedliche Werte die aber nicht so 
direkt zu den sich häufig wiederholenden Pixelwerten passen. Das könnte 
ein Header ein. Ich versuch mich da mal weiter dran.

[Olli Z. (z80freak)]

Auffällig oft wiederholt sich in jedem durch den o.g. Header-Block ein 
bestimmtes Byte. In jedem Segment ist es ein anderes, aber es kommt mehr 
oder weniger regelmäßig immer wieder vor.

Im ersten Block z.B. ist es die 0x49:

00 00 FF 00 00 01 00 00 00 00 00 00 00 0D 49 01 00 1B 49 01 00 1B 49 01 00 1B 49 01 00 1B 49 01 00 1B 02 00 52 49 00 1A 02 00 49 50 00 29 49 1C 00 1F 0F 00 00 49 00 00 49 49 00 00 49 00 00 49 00 00 0C 49 00 00 49 10 00 49 49 00 00 00 00 49 00 49 49 00 00 00 0D 49 00 00 49 13 00 00 00 49 49 00 49 00 00 00 00 49 49 00 00 00 00 49 49 04 00 05 18 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 00 49 00 49 49 00 49 00 49 00 00 04 18 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 49 49 00 00 49 00 49 00 49 00 00 04 35 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 00 49 00 49 49 00 49 00 49 00 00 00 49 00 49 49 00 00 49 49 00 00 49 00 00 49 00 00 00 49 49 00 49 00 49 00 49 00 00 00 00 00 1C 00 11 00 1C 00 00 00 00 30 0C 00 00 30 00 00 00 00 38 56

Hier mal "umbrochen" und kommentiert das erste Bild im Datenbereich 
0x0000 - 0x00F7 (Len 0xF8):

HEADER: 00 00 FF 00 00 01 00 00 00 00 00 00 00 
0D 
49 01 00 1B 
49 01 00 1B
49 01 00 1B 
49 01 00 1B
49 01 00 1B 02 00 52 
49 00 1A 02 00 
49 50 00 29 
49 1C 00 1F 0F 00 00
49 00 00
49 49 00 00
49 00 00
49 00 00 0C 
49 00 00 
49 10 00
49 49 00 00 00 00
49 00 
49 49 00 00 00 0D
49 00 00 
49 13 00 00 00
49 49 00
49 00 00 00 00
49 49 00 00 00 00
49 49 04 00 05 18 00 00
49 49 00 00 00 00
49 00 
49 49 00 00 00 00 
49 00 
49 49 00
49 00 
49 00 00 04 18 00 00 
49 49 00 00 00 00 
49 00
49 49 00 00 00 
49 49 00 00
49 00
49 00 
49 00 00 04 35 00 00
49 49 00 00 00 00 
49 00 
49 49 00 00 00 00
49 00
49 49 00
49 00
49 00 00 00 
49 00
49 49 00 00 
49 49 00 00 
49 00 00
49 00 00 00
49 49 00 
49 00
49 00
49 00 00 00 00 00 1C 00 11 00 1C 00 00 00 00 30 0C 00 00 30 00 00
EOI: 00 00 38 56

In einem anderen Block ist es das Byte 0x33, in wieder einem anderen das 
0x8D, usw. Das könnte ein Indiz für eine Kompression sein (RLE, 
Huffmann). Da die Blöcke aber keine feste größe haben muss es irgendwo 
einen Index, bzw. Zeiger auf den nächsten Block (Bild) geben, sonst 
könnte sich die Software nicht orientieren. Sowas habe ich noch nicht 
entdeckt. Auch eine Längenangabe im Header, sodass die Software durch 
einmaliges durchlaufen der der Kette die Positionen selbst ermitteln 
könnte.

Am Ende jeden Blocks steht zudem diese Sequenz wie eine Art EOI 
(End-Of-Image) Marker: 00 00 38 56

Am Ende eines jeden Blocks finde ich zwei Zeiger auf seinen Anfang. Kurz 
vor dem EOI kommen, durch 0x30 getrennt, zwei Little-Endian kodierte 
WORDs, der erste zeigt auf den Beginn der Daten, der zweite auf den 
Anfang des Blocks. Demnach könnte man die Kette nur "rückwärts" gelesen 
aufbauen...

0x0000 - 0x00F7 (Len 0xF8)
0x0000: 00 00 FF 00 00 01 00 00 00 00 00 00
0x000C: 00 0D 
49 01 00 1B 49 01 00 1B 49 01 00 1B 49 01 00 1B 49 01 00 1B 02 00 52 49 00 1A 02 00 49 50 00 29 49 1C 00 1F 0F 00 00 49 00 00 49 49 00 00 49 00 00 49 00 00 0C 49 00 00 49 10 00 49 49 00 00 00 00 49 00 49 49 00 00 00 0D 49 00 00 49 13 00 00 00 49 49 00 49 00 00 00 00 49 49 00 00 00 00 49 49 04 00 05 18 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 00 49 00 49 49 00 49 00 49 00 00 04 18 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 49 49 00 00 49 00 49 00 49 00 00 04 35 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 00 49 00 49 49 00 49 00 49 00 00 00 49 00 49 49 00 00 49 49 00 00 49 00 00 49 00 00 00 49 49 00 49 00 49 00
49 00 00 00 00 00 1C 00 11 00 1C 
00 00 00 00
30 0C 00 00   # Pointer to 0x000C
30 00 00 00   # Pointer to start of block 0x0000
00 38 56      # End-Of-Image marker

0x00F8 - 0x12BF (Len 0x11C8)
0x00F8: 00 00 FF 00 00 01 00 00 00 00 00 00 
0x0104: 00 C2 
06 00 9C 98 A8 A6 AA AA AB 05 06 00 AA AA A6 A8 98 9C 00 27 09 00 A8 9D AF AC AD AF AB AC 05 AB 00 AA AB 09 AC AB AF AD AC AC 9B A8 00 22 06 00 AC A2 AE AF AA AB A9 08 0D 00 A9 A8 A9 A8 A9 A8 A9 A8 AD AA AC AC 1E A2 00 00 9C 0D B0 AC AA AB AA A9 A9 A9 A8 A8 A7 A7
...
04 8A 00 90 8D 04 00 90 1E 90 00 00 8D 05 8D 00 8D 90 90 13 03 00 00 8D 23 8D 00 00 8D 15 8D 00 8D 00 8D 00 8D 00 8D 00 00 00 00 90 8D 00 8D 00 8D 00 00 29 0D 00 00 8D 00 8D 00 00 00 8D 90 00 00 00 FE 8D 42 00 00 00 00 00 3B 00 73 00 3B
00 00 00 00 
30 04 01 00   # Ptr to Data
30 F8 00 00   # Ptr to start of block
00 38 56


0x27AC - 0x28AB (Len 0x100)
00 00 FF 00 00 01 00 00 00 00 00 00
0x27B8: 00 36
33 0D 00 0B 33 01 00 0B 33 01 00 08 33 04 00 0B 33 01 00 08 04 00 00 33 33 00 00 0B 33 01 00 08 04 00 00 33 33 00 00 0B 33 01 00 08 06 00 00 33 33 00 38 34 00 09 33 01 00 08 07 00 00 33 38 00 33 35 08 34 01 00 08 33 01 00 05 33 00 00 34 02 07 35 01 00 08 33 01 00 05 33 00 00 38 03 38 33 00 06 33 01 00 08 33 01 00 06 02 00 38 33 00 06 33 01 00 08 33 01 00 05 03 00 33 38 06 38 01 00 08 33 01 00 05 33 00 00 34 02 07 35 01 00 08 33 00 00 33 07 00 00 35 38 34 33 00 08 33 01 00 08 06 00 00 33 33 00 38 34 00 09 33 01 00 08 04 00 00 33 33 00 00 0B 33 01 00 08 04 00 00 33 33 00 00 0B 33 01 00 08 33 04 00 0B 33 01 00 0B 33 01 00 0B 33 01 00 0B 
33 0D 00 35 00 00 00 00 18 00 17 00 18
00 00 00 00
30 B8 27 00
30 AC 27 00
00 38 56

0x28AC - 0x29AB (Len 0x100)
00 00 FF 00 00 01 00 00 00 00 00 00
0x28B8: 00 36
36 0D 00 0B 36 01 00 0B 36 01 00 08 36 04 00 0B 36 01 00 08 04 00 00 36 36 00 00 0B 36 01 00 08 04 00 00 36 36 00 00 0B 36 01 00 08 06 00 00 36 36 00 32 37 00 09 36 01 00 08 07 00 00 36 32 00 36 39 08 37 01 00 08 36 01 00 05 36 00 00 37 02 07 39 01 00 08 36 01 00 05 36 00 00 32 03 32 36 00 06 36 01 00 08 36 01 00 06 02 00 32 36 00 06 36 01 00 08 36 01 00 05 03 00 36 32 06 32 01 00 08 36 01 00 05 36 00 00 37 02 07 39 01 00 08 36 00 00 36 07 00 00 39 32 37 36 00 08 36 01 00 08 06 00 00 36 36 00 32 37 00 09 36 01 00 08 04 00 00 36 36 00 00 0B 36 01 00 08 04 00 00 36 36 00 00 0B 36 01 00 08 36 04 00 0B 36 01 00 0B 36 01 00 0B 36 01 00 0B 
36 0D 00 35 00 00 00 00 18 00 17 00 18
00 00 00 00 
30 B8 28 00
30 AC 28 00
00 38 56

0x29AC - 0x2AAB (Len 0x100)
00 00 FF 00 00 01 00 00 00 00 00 00 
0x29B8: 00 36
01 0D 00 0B 01 01 00 0B 01 01 00 08 01 04 00 0B 01 01 00 08 04 00 00 01 01 00 00 0B 01 01 00 08 04 00 00 01 01 00 00 0B 01 01 00 08 06 00 00 01 01 00 42 40 00 09 01 01 00 08 07 00 00 01 42 00 01 41 08 40 01 00 08 01 01 00 05 01 00 00 40 02 07 41 01 00 08 01 01 00 05 01 00 00 42 03 42 01 00 06 01 01 00 08 01 01 00 06 02 00 42 01 00 06 01 01 00 08 01 01 00 05 03 00 01 42 06 42 01 00 08 01 01 00 05 01 00 00 40 02 07 41 01 00 08 01 00 00 01 07 00 00 41 42 40 01 00 08 01 01 00 08 06 00 00 01 01 00 42 40 00 09 01 01 00 08 04 00 00 01 01 00 00 0B 01 01 00 08 04 00 00 01 01 00 00 0B 01 01 00 08 01 04 00 0B 01 01 00 0B 01 01 00 0B 01 01 00 0B
01 0D 00 35 00 00 00 00 18 00 17 00 18
00 00 00 00
30 B8 29 00
30 AC 29 00 
00 38 56

0x2AAC - 0x2F7C (Len 0x4D1)
00 00 FF 00 00 01 00 00 00 00 00 00
0x2AB8 : 00 04
09 01 1A EE 02 00 16 18 00 07 03 00 1A 09 F0 17 00 03 15 02 04 15 00 00 09 02 F5 17 03 03 01 00 F6 1A 00 03 10 04 09 00 F6 17 00 03 13 03 1A 00 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10
...
1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 18 10 03 F8 02 00 16 10 03 F8 03 00 00 10 F6 15 00 03 10 04 00 00 F6 15 00 03 10 04 00 00 F5 00 01 03 05 10 00 00 10 02 F0 13 00 03 10 02 08 10 F0 00 05 10 00 00 FA 00 C3 00 FA
00 00 00 00 
30 B8 2A 00 
30 AC 2A 00 
00 38 56

Von diesen 0x100 langen Blöcken ist das Dump geradezu durchsäht. So als 
wäre es ein Tile oder ein Character.

[Olli Z. (z80freak)]

Jetzt habe ich mein Convers wohl gekillt...

Hab heute versucht es via JTAG anzusprechen. Zuerst mit dem USB-Blaster 
und dem JTAG-Debugger der Quartus-Suite. Die konnte den Chip sofort 
erkennen. Dann mit dem Segger JLINK, der kennt sogar den MAC7116 und 
connectete ebenfalls spontan.

So beflügelt habe ich dann mit JLINK-Commander versucht einen Flash-Read 
durchzuführen. Das sah zuerst sogar gut aus, aber dann gab es am Ende 
einen Verify-Fehler und seitdem startet das Convers nicht mehr :-(

Die CPU wird via JTAG noch erkannt, aber man kann sie nicht mehr in den 
HALT zustand versetzen.

Könnte es sein das der MAC sich durch Selbstlöschung meinem Zugriff 
entzogen hat? Gibt es sowas in diesem Chip?
Hat irgendwer ne Idee wie man das jetzt noch retten kann? Die Firmaware 
die auf dem Chip drauf ist habe ich ja.

[Anatoliy G. (ursadon)]

I made some research:

========================================================
12B - 00 00 00 FF 01 00 00 00 00 00 00 00 - Header
2B+ - xx xx - Magic number(??)
............. Data
2B - XX XX - width
2B - XX XX - height
2B - XX XX - width (again?)
4B - 00 00 - Gap
4B - 30 XX XX XX - Ptr to Data
4B - 30 XX XX XX - Ptr to start of block
4B - 00 00 56 38 - End of image
========================================================


>In einem Forum ist von Logos mit 400x198 die Rede, evtl. wird das Logo
>im Flash auch auf 800x396 hochskaliert.

i found 3+12 images with maximum size: 0x00190 0x00c6 0x0190 or 400 198 
400

But i still cant parse data :(
Maybe RLE?

[Olli Z. (z80freak)]

I bet it would be something really easy to process, because the system 
has limited ressources in CPU and RAM. I would expect somewhat 
uncompressed. RLE, maybe because its easy. but more like something ready 
for LCD interface. So shurely not true-color RGB ;-)

[Toto mit Harry (Gast)]

Ich würde mir ein tool basteln das die Hex Daten die zu einem Bild 
gehören in verschiedenen Farbtiefen,startpointern und ändernder 
vermuteten Bild Breiten auf dem Bildschirm abwechselnd anzeigt.. so 
brauch man dann nur warten bis man etwas erkennt.

[Olli Z. (z80freak)]

Meist erkennt man schon Mister wenn man die Bytes einfach als indizierte 
Farbpixel darstellt (256 Farben Palette) und mit unterschiedlichen 
Breiten testet. Oder noch einfacher, als Ascii Zeichen in einen 
Texteditor lädt, die Schriftgröße auf Mini stellt und mit Zeilenumbruch 
auf Fensterbreite einfach mal rumprobiert.

Es gibt auch Online Tools zur Analyse von Bilddaten... hab nur den Link 
grad nicht parat.

[Anatoliy G. (ursadon)]

I finally parsed FLASH
so format is:

===================================
00 00 00 01 1F 00 00 00 - Header
...
... RLE-Encoded (with zero-pad)
...
XX XX - width
XX XX - Height
XX XX - width
00 00 - <probably> Height - but seems like always 00 00
30 XX XX XX - PTR to start of data frame
30 XX XX XX - PTR to start of image
00 00 56 38 - End of image (EOI)
===================================

So hat is "RLE-Encoded (with zero-pad)" ?
its mean: if previous byte is zero, then next byte contains count of 
repeats next-next byte
if previous byte is non-zero (and prev. RLE is fullfillment) then next 
byte contains count of bytes to read (to framebuffer).
First 2 RLE's we must treat as "count of repeats"

Also "EOI marker" is not a marker! Its offset to function, wich used to 
parse data. At ROM, at 0x00005638 sits DisplayDraw function (asm BX R4, 
but R4[1:0] is zero - treat function as ARM (not Thumb))

Also ROM contains 0 functions for direct send commands to LCD 
controller. PBL configures DMA and defines mem region (0x20002000+, i 
forgot :) ) to use as framebuffer.

All images stored as RGB8 picture, so we have only 256 colors, but 
colortable is not standart. It have too many bits for blue. We can see 
correct table at Display test (self-test of IPC)

PS. Sorry for my bad english, i'm from Ru
PS.2 Я реально заебался с этими оффсетами. Спасибо водке и медведю - без 
них не разобрался

[Olli Z. (z80freak)]

Great work!!! Would love to reproduce it, but i guess my Convers+ 
firmware images are from a different version. I do not find the exact 
marker you tell, only similar. Maybe it does not start with "00 00 00 
1F" but with "1F .." ?

Could share the dump you used? I will drop you a private message, even 
if anybody could download the Firmware from Ford ;-) Maybe on other 
versions there are different EOIs (jumppoints).
Or even tell the partnumber/calibration number you used? Best match for 
now was 8M2T-14C026-ED.

But as you say
> At ROM, at 0x00005638 sits DisplayDraw function (asm BX R4,
but R4[1:0] is zero - treat function as ARM (not Thumb))
there i only got data:
00 7A 7A 00 00 05 7A 00 10 00 00 7A 7A 00 00 00 7A 7A 7A 00 00 00 7A 00 
7A 07 00 00 05 7A 00 00 00 7A 05 00 01 7A 05 00 05 7A 03 00 00 00 00 00 
00 0B 00 0B 00 0B 00 00
So it does not match.
BX is a branch operation regard on the content of register R4. Why 
should Thumb set be used anyhow?

Also an example for the RLE would be fine. I think i know how RLE works 
but this seems specific.

[Olli Z. (z80freak)]

Here i found a place where your pattern machtes, but starting with 01 
1F:

Firmware: 7M2T-14C026-BC
Address: 0x6CFF
Header:        01 1F 00 00 00
Width (29px):  00 1D
Height (15px): 00 0F
Width (29px):  00 1D
Pad:           00 00
Start of data: 30 00 6C CC
Start of image:30 00 6C C0
End of image:  00 00 56 38

The resulting image should be 29 x 15px = 435 pixel total.

For RGB8 i found this description: "The RGB8 color format is an 8 bit 
monochrome format. Every pixel is represented by one byte. The 
organization of the pixels in the image buffer is from left to right and 
bottom up. In other words: The first byte of the image buffer 
corresponds to the first pixel of the last line of the image."

I'm shure you mean 8 bit per pixel in an indexed color table. So the 
resulting image would be 435 bytes.

Don't know what is the difference of start of data and start of image?

Data found at
0x6CB8:
00 FF 00 FF 00 AD 9D 94

0x6CC0:
00 00 00 02
01 00 00 00
30 00 6C B8 (looks like a pointer to me also...)

0x6CCC:
2B 00 01 01 (this what you mean with RLE zero padded?)
1B 00 03 01
19 00 05 01
17 00 07 01
15 00 09 01
13 00 0B 01
11 00 0D 01
0F 00 0F 01
0D 00 11 01
0B 00 13 01
09 00 15 01
07 00 17 01
05 00 19 01
 (looks like upwarts counting on first byte from 05 by 2 up to 1B, and 
downwards on third byte)

0x6D00: (see above) 1F 00 00 00 00 1D 00 0F 00 1D 00 00 30 00 6C CC 30 
00 6C C0 00 00 56 38

[Anatoliy G. (ursadon)]

Yes, i use 8M2T-14C026-ED (flash) + 8M2T-14C026-CE (ROM)

I have a typo in the header, it should be like this: 0x000000FF 
0x01000000 0x00000000
I attached an Excel file, where I explain how to parse a file using the 
example image at 0x00000000

About 0x00005638 i'll answer later, now i don't have access to IDA.

[Olli Z. (z80freak)]

Now i get it! Thanks a lot. I have IDA too but just begin to learn ARM 
assembler.

[Olli Z. (z80freak)]

Wen es interessiert wie es weitergeht, hier gibt es die Fortsetzung zum 
Thema: 
http://microhacker.denkdose.de/viewtopic.php?f=25&t=24&sid=e4b289ee128920bddce94ed11afa3f9c