Tatort Internet: Angriff der Killervideos
Seite 2: Bit-Schubser
Bit-Schubser
Laut Spezifikation stehen die ersten zwei Bytes des Datenblocks für den RECORDHEADER. Bei der Lektüre zur Definition dieses Datentyps stehen mir die Haare zu Berge: Warum diese Knauser bei Datenbrocken, die längst nach Megabytes bemessen werden, immer noch an einzelnen Verwaltungs-Bits sparen, wird mir wohl ewig ein Rätsel bleiben. Jedenfalls enthalten die oberen 10 Bits den Tag-Typ – der sollte hier 0x56 sein – und die restlichen 6 Bit dessen Länge.
Da man auch noch die Byte-Reihenfolge der Architektur zu berücksichtigen hat, die nach Intel-Art dafür sorgt, dass das höherwertige Byte hinten steht, muss ich mir das aufzeichnen.
Demnach ergeben die RECORDHEADER der beiden Datenblöcke A8 15 und 8C 15 jeweils den von swfdump angezeigten Tag-Typ 0x56 und die Länge von 40 beziehungsweise 12. So weit, so gut. Danach kommt die Anzahl der Szenen im Datentyp EncodedU32.
Was haben sie sich denn da wieder einfallen lassen? Die Spezifikation liest sich wie aus dem letzten Jahrtausend. EncodedU32 enthält demnach einen vorzeichenlosen 32-Bit-Integer-Wert, der je nach Größe mit einer variablen Länge von ein bis fünf Bytes kodiert wird – „um Platz zu sparen“, wie die Adobe-Doku freundlicherweise erklärt.
Kein Wunder, dass die Flash-Sicherheitslücken kein Ende nehmen. Statt mit regulären Datentypen wie unsigned int zu arbeiten, versuchen sie, ein paar Bytes einzusparen. Doch Komplexität ist der natürliche Feind von Sicherheit – und das schreit geradezu nach Ärger. Man stelle sich nur mal vor, die Designer des Formats für ausführbare EXE-Dateien oder für CPU-Befehle hätten solche Datentypen eingesetzt – wir könnten uns heute vor Sicherheitslücken überhaupt nicht mehr retten.
Außerdem ist es auch noch langsam, weil bei jedem Zugriff auf einen EncodedU32-Wert statt einer einfachen Leseoperation die Dekodier-Routine ausgeführt werden muss. Vollends unverständlich wird die Bitknauserei, wenn man bedenkt, dass SWF-Dateien ohnehin noch komprimiert werden können, was deutlich effizienter Platz spart.
Doch ich rege mich schon wieder auf; zurück zum SceneCount des angeblichen iPhone-Videos. Ist das jeweils höchste Bit eines Bytes gesetzt, muss man das nächste Byte noch dazunehmen. Ein Blick auf den Hex-Dump verrät mir, dass im ersten Datenblock die vier Bytes hinter dem RECORDHEADER alle das höchste Bit gesetzt haben. Also muss ich die maximalen fünf Bytes richtig zusammenzählen. Praktischerweise liefert Adobe gleich eine Referenzimplementierung zum Auspacken der EncodedU32-Werte als C-Code mit. Bevor ich jetzt anfange, selber Bits zu schieben, jag ich die schnell durch den Compiler.
Der Test von GetEncodedU32.exe mit den Daten des kürzeren, zweiten Datenblocks ergibt einen plausiblen SceneCount von 1. Doch beim ersten Datenblock spuckt es für \xa6\xe1\x8a\xa0\x08 den Wert 0x84039a19 aus. Über 2 Milliarden Szenen? Unmöglich! Meine Nase hat mich also nicht getäuscht. Da arbeitet jemand ganz offensichtlich mit schmutzigen Tricks.
