HENG Komprimierung?



  • Hallo alle miteinander,

    folgende Prpblemstellung sollte für alle Leute ineteressant sein, denen reverse engineering genausoviel Spaß macht wie mir : ich habe hier einige Files, in denen Bilddaten drinne stecken. So habe ich bereits rausgefunden, das :

    1.) an manchen Stellen Rohdaten 8Bit Grauwert drinne sind. Ermittelt mit meinem eigenen kleinen Reverse -engeniering tool, in das ich beliebige Daten reinschmeiße und dann solange an der Bildbreite schraube, bis ein Bild rauskommt :).

    2.) war schon schwieriger, aber dann habe ich im Hex-editor ein JFIF gefunden -> Fall war klar JPEG.

    3.) und da hänge ich jetzt: Ich vermute, das der 3.Typ immer die gleichen Dimension (Breite) hat. Die Blöcke, in denen die Daten Stecken sind aber immer unterschiedlich groß, also liegt die Vermutung nah, das diese auch irgendwie komprimiert sind. Die Blöcke beginnen immer mit dem String HENG. Leider ist mir sowas als Bildheader nicht bekannt. Wenn ich den kompletten Datenquark als file abspeicher kommt auch nix als Bild lesbares raus (wäre wohl auch zu einfach gewesen).
    Leider gehen mir jetzt die Ideen aus (gut hab damit auch gerade erst angefangen).

    Danke an alle, die mitknobeln wollen



  • Hallo Tobias,
    gibts das (rohdaten) auch mal zum ansehn, oder ist das schwierig. ich hab mal eben nach heng gegoogelt, und eine kleine sammlung von algorithmen gefunden. vielleicht passt ja einer drauf: http://pascalzone.amirmelamed.co.il/Graphics/JPEG/JPEG.htm



  • Wie bei Deinem Artikel ist das Problem, das ich kein Verfahren was so hieß gefunden habe, sondern immer -zig Artikel, bei denen lediglich der Verfasser so hieß (z.B. Hengstenberg 🤡 ).
    Aber der Artikel ist gut. Mein nächstes Vorgehen wäre auch gewesen, die Daten einfach mal in verschiedene De-kompression-libs "reinzustecken" und mal zu schauen, was am Ende rauskomt. Wenn es Dich interessiert maile ich Dir ein paar Beispiele. Nur soviel vorab: es geht um Aufnahmen des Augenhintergrunds.



  • Dieser Beitrag jetzt ist eigentlich nur als persönliches Manmahl für meine eigene Blindheit gedacht:

    das HENG in dem Bildabschnitt hat mit der Komprimierung rein gar nichts zu tun, sondern ist einfach nur die Abkürzung der Firma die es verbrochen hat. Tja, so hätte ich mir einige Tage Suche nach dem "Heng" Algorithmus sparen können 🙂

    Zurück zum Ernst des Themas : nachdem ich jetzt mal ein bischen gestöbert und probiert habe denke ich jetzt, das da irgendwie Huffman kodierte Daten rumfliegen ( Disassembler brachte mich bei der Quellanwendung jedenfalls irgendwann zu einer Funktion die da "EncodeHuffman" hieß). Das würde größenmäßig auch in etwa zu dem passen was ich dort als resultierendes, dekomprimiertes Bild erwarten würde.
    Nun die Frage: wie bekomme ich aus einem Haufen Daten, denen ich mal unterstelle, das sie Huffman kodiert sind, heraus wo der Tree anfängt, aufhört und wo die Daten liegen.
    Wenn ich von diversen Threads hier zu dem Thema ausgehe, bleibt mir wohl nichts weiter übrig, als mir irgendwo eine Huffman-lib zu schnappen und einfach zu probieren, wenn nicht jemandem was besseres einfällt.


Anmelden zum Antworten