moin, ZITAT(Alison @ 2010-07-01, 15:35) äh, das klingt spannend (ernstgemeint) aber was bedeutet das?[/quote]
die NEX-Firmware ist ja überraschend groß, knapp 60MiByte.
Also reingeschaut:
Die Häufigkeitsverteilung der Bitmuster ist einfach ein Diagramm, auf der waagerechten x-Achse werden die möglichen Byte-Werte von 0-255 aufgetragen, und auf der senkrechten y-Achse deren relative Häufigkeit in der Datei.
Eine ausführbare Datei enthält typisch sehr viele 0-Bytes und viele Bytes, deren Wert für sehr häufige Befehls-Opcodes der verwendeten CPU codieren wie load- und store-Befehle. Das Muster ist für nicht zu kleine/einfache Programme einigermaßen typisch für die CPU und die verwendete Entwicklungsumgebung.
Hier ist es aber so, dass alle 256 möglichen Werte nahezu gleichverteilt sind, sie haben alle eine relative Häufigkeit von ungefähr 1/256. Eine geglättete Verbindungskurve durch die Werte ist einfach eine Konstante, also eine waagerechte Linie="flatline". Eine exakte Gleichverteilung wäre extrem auffällig, aber so ist der Inhalt der Datei ohne die paar Bytes des Headers von weißem Rauschen nicht unterscheidbar: das deutet mindestens auf einen sehr effizienten Packer, eher aber auf eine harte Verschlüsselung hin. Es wird sich wohl um AES-256 handeln.
Der Header ist mir völlig fremd, und Tante G hat auch nicht die geringste Ahnung (das ist schon sehr auffällig). Der magic-Wert 0x89UFU ist auch nirgends bekannt.
Zum Vergleich: die (ebenfalls gepackte/verschlüsselte) a700- oder a230/330/380-firmware ist um 5MiByte groß, die (ungepackte/unverschlüsselte) firmware der Dynax 5Di aka a100 sogar unter 2MiByte.
Die a900 hat 512MiByte RAM, 8MiByte Flash und 4KiByte EEPROM, dazu kommen noch 2x128MiByte RAM und 2x4MiByte Flash für die beiden DSPs.
Bei der a700 sind es 256MiByte RAM, 8MiByte Flash und 4KiByte EEPROM und dazu 1x128MiByte RAM und 1x8MiByte Flash für den einsamen DSP.
Die Dateien liefern keine flatline, sondern ein Stufenmuster in der Häufigkeitsverteilung: 0-63, 64-127, 128-191 und 192-255 sind jeweils in sich weitgehend gleichverteilt, die vier Blöcke unterscheiden sich aber stark. Einen header scheint es nicht zu geben, vmtl. steckt der loader samt dem Entpacker/Entschlüsseler im nur durch den Service flashbaren (oder sogar verriegelten) Teil der firmware und enthält auch den Dateiheader.
Eine 60MiByte große Firmware reizt also, mal reinzuschauen, was die so aufbläht. Aber: no chance!
Es sei denn, die blöde Win-SW zum Updaten wird benötigt, um die Datei zu entpacken und nur den benötigten Teil (Sprachversion der epischen Hilfetexte und Tutorials z.B.) zu Laden: dann steckt alles benötigte Zeuch in der Update-Applikation. Wäre nicht das erste Mal, dass eine Verschlüsselung durch solch einen dummen Fehler unwirksam würde...
Aber macht Euch keine Hoffnung: patchen oder gar verbessern könnte man selbst eine unverschlüsselte/unsignierte firmware nicht, siehe a100...
Dazu ist die viel zu komplex, ohne zumindest wesentliche Teile des Quellcodes ist da nichts zu machen. Die jpeg-Engine steckt zudem in den DSPs, ohne genaue Dokumentation dieser Custom-Chips ist selbst mit komplettem source nicht mal zu verstehen, wie die funktioniert.
gruesze, thomas (der weiter beim Objektivprotokoll bleibt und die fw in Ruhe lässt)
wieder da ...