Dateiformat Firmware

[Markus M. (adrock)]

Hi,

ich habe hier ein Firmwareupdate welches ich mir mal gerne genauer 
ansehen möchte, von was für einem Gerät es ist soll erstmal sekundär 
sein.

Die Datei hat folgendes Format:

25299774
90046
xxxxxxxxxxx MAINVer1.42        0S00E0000726F6D6F626A20206D6F74D8
S224000000090005A009000900090009000900090007DF020007D229200E4007D007D11120BF
S22400002007D008D1122008D06A4008D02B400900000000B80FFFFFDF040052A407A50000C1
S2240000401C0000FF08080000010004007A0000A002D003D1122003D02B4009001C0000FF17
...usw...

Mal vom Header abgesehen besteht jede Reihe aus

S<xx><aaaaaaa><daten>

<aaaaaaa> scheint die Adresse im Speicher zu sein für die Daten
<xx> ist mir aber noch nicht so ganz klar.

Es gibt auch kürzere Zeilen, z.B.

S2160C8E24D14BFE6C059F802C067BF57AD5ED80ED3FFBFC
S2150C8EB675C305007CE8EB700000FDD27C0CFEFFFB4F
S2060F00000100E9
S2080FFFFC368E0CFF1E
S804000000FB

Somit scheint das <xx> nicht die Anzahl der Datenbytes zu sein, sondern 
irgendwas anderes.

Auch merkwürdig ist, dass bei den Zeilen wo die Adresse immer um 0x20 
hochzählt (also 32 Bytes) jedoch 33 Bytes an Daten vorhanden sind. Evtl. 
eine Prüfsumme?

Kommt jemandem dieses Datenformat bekannt vor?

Gruß
Markus

[Ich (Gast)]

https://de.wikipedia.org/wiki/S-Record

[Markus M. (adrock)]

Tatsache! Vielen Dank, es kann so einfach sein :-)

[Nick M. (Gast)]

Motorola S-Format
Oh, da war ich zu langsam mit dem Schreiben ...

[Markus M. (adrock)]

So, nachdem ich mir die Binärdaten aus den S-Records angeschaut habe, 
ist es ersichtlich geworden dass diese komprimiert sind. Werden wohl 
beim Booten dekomprimiert in das RAM geschrieben und dann gestartet.

Allerdings glaube ich nicht das der Hersteller eine neue Komprimierung 
erfunden hat, die Frage ist nur welches Verfahren das genau ist.

Folgendes habe ich herausbekommen:

Es ist Byteorientiert, d.h. Daten die nicht redundant sind, werden 
byteweise 1:1 kopiert. Es werden jeweils Chunks gebildet, die aus 
normalen Daten und/oder Referenzen (oder RLE?) bestehen. Die Daten sehen 
wie folgt aus:

<token>[<daten>][<xxxxxx>]<token>[<daten>][<xxxxxxx>]....usw.

<token> steuert offenbar ob neben <Daten> die 1:1 kopiert werden auch 
noch eine Referenz <xxxxxx> vorhanden ist, die auf vorhergehende Daten 
oder einen Wörterbucheintrag (da bin ich mir noch nicht sicher) 
verweist.

Wenn <token> = 0xff ist, werden einfach die nächetsn 8 Bytes 1:1 
kopiert, danach kommt das nächste <token>.

Ist das eine LZ Abart?

Hier mal ein Ausschnitt:

000103C0  BC 6F A0 DC 55 72 6F 6F 74 DC 51 73 7F 63 69 66  ¼o ÜUrootÜQs.cif
000103D0  5F 69 6E 69 9E A2 FD 68 A6 A3 73 68 63 6F 6E 73  _iniž¢ýh¦£shcons
000103E0  FE A6 A3 63 74 6D 61 6C 6C 6F EF 63 5F 72 65 BB  þ¦£ctmalloïc_re»
000103F0  A4 00 00 66 AF 73 79 73 5F B8 A0 66 DC 50 75 F3  ¤..f¯sys_¸ fÜPuó
00010400  73 62 AF A4 E0 A4 6D 73 63 5F C7 64 72 69 84 70  sb¯¤à¤msc_Çdri„p
00010410  A6 A2 E2 A2 6C 6F FB 61 64 DC 50 67 75 69 5F 74  ¦¢â¢loûadÜPgui_t
00010420  87 61 73 6B A6 A1 9D A1 9A A1 11 B2 3A FF 20 25  ‡ask¦¡.¡š¡.²:ÿ %
00010430  73 20 65 72 72 6F FF 72 2C 20 65 78 70 65 63 FF  s erroÿr, expecÿ
00010440  74 65 64 3D 25 6C 64 2C 6F 20 72 65 74 3B B1 0D  ted=%ld,o ret;±.
00010450  0A DC 57 F1 08 DC 56 C2 A5 DC 55 74 6F 6F 20 FF  .ÜWñ.ÜVÂ¥ÜUtoo ÿ
00010460  6D 61 6E 79 20 61 72 67 BD 73 F3 91 6F 67 6F 75  many arg½só‘ogou
00010470  9D A0 71 FD 75 19 B2 00 20 3A 20 63 6F FD 6D 72  . qýu.². : coýmr
00010480  B0 64 20 6E 6F 74 20 CF 66 6F 75 6E 0A B1 8D B1  °d not Ïfoun.±.±
00010490  6D 6F FF 72 65 20 74 68 61 6E 20 7D 32 90 B5 73  moÿre than }2.µs
000104A0  20 68 61 76 AC B1 FF 65 20 73 61 6D 65 20 6E FC   hav¬±ÿe same nü
000104B0  C8 B0 8C B2 70 65 72 6D 69 73 7E 87 71 20 64 65  È°Œ²permis~‡q de
000104C0  6E 69 65 A1 B2 5E DC 51 25 31 35 73 ED F1 2A DC  nie¡²^ÜQ%15síñ*Ü
000104D0  50 EF 61 64 6D 69 27 90 00 61 6D FF 62 69 67 75  Pïadmi'..amÿbigu
000104E0  6F 75 73 20 67 73 75 62 91 B4 DC 51 6E 6F 0B C0  ous gsub‘´ÜQno.À

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Vergleiche mal die Größe der Firmware mit der verfügbaren Speichergröße.

Kompression hat nur Sinn, wenn du zumindest 50% einsparen kannst.
Wenn die Entropie der Daten groß ist (zip die Datei nochmal. Ändert sich 
an der Größe nicht die Welt, dann ist die Entropie groß), dann ist eine 
Verschlüsselung wahrscheinlicher.

Falls alles irgendwie zufällig aussieht, ZIP da aber einiges rausgeholt 
haben sollte, dann lebt offensichtlich noch jemand in der Zeit von 
ROT13&co :)

73

[Dieter (Gast)]

Hans W. schrieb:
>
> ... dann ist eine Verschlüsselung wahrscheinlicher.

Ein kurzer Blick auf den Ausschnitt weiter oben zeigt sofort dass das 
nicht verschlüsselt ist. Es gibt einige Kompressionsverfahren die so 
arbeiten. es sollte kein Problem sein das wieder auszupacken.

[Nick M. (Gast)]

Ob komprimiert oder nicht, sieht man ganz wenn man (nochmal) 
komprimiert. Wenn der Gewinn sehr klein war, war es wohl komprimiert. 
Wenn der Gewinn groß war, war es wohl nicht komprimiert.

Leider ist es aber so, dass eine Verschlüsselung ähnliche Ergebnisse 
zeigt.
Ich hab das mal probiert, und verschlüsselt konnte ich ein Image um nur 
3% verkleinern. Nicht verschlüssel hab ich aber nicht probiert, sorry.

Erkennt man an einer Datei, ob sie mit ZIP komprimirt wurde? Denn eine 
neue Kompression werden nur wenige implementieren wollen. Wenn, dann 
greif ich in die Bibliothek.