komprimierte binäre daten



  • hallo zusammen,
    ich habe zwei dateien, die inhaltlich ein und dasselbe signal und dessen parameter beinhalten. hier könnt ihr beide runterladen:
    http://gemini-sites.de/forumImages/binaryEncoding.zip
    in der .sig datei ist der inhalt leserlich, in der .xym datei binär gespeichert. ich muss die messdaten weiter unten in der .xym datei einlesen können, sie beginnen ca. ab position 0x958.
    mein problem ist, dass die daten offensichtlich nicht unkomprimiert sind und ich die kompression nicht erkenne? kann mir jemand helfen?
    danke!



  • Da offenbar ca. 4 Byte pro Datensatz gebraucht werden, ist es denkbar, dass es sich um eine Deltakompression handelt - 4 bit pro Messwert, als Differenz zum letzten Wert aus dieser Reihe. Größere Deltas würden dann mit einem Escape-Mechanismus behandelt.

    Gibt es keine Dokumentation zu diesem Dateiformat?



  • danke, ich schaue mir die delta kompression mal an. ich vermute auch, dass es keine besonders aufwändige oder komplizierte kompression sein dürfte, da das format wahrscheinlich älter als 20 jahre alt ist.
    und im hex editor ist eine struktur der daten zu sehen, deswegen dachte ich, jemand würde das vielleicht direkt erkennen können?

    leider gibt es keine dokumentation.



  • Ich würde mit 7zip komprämieren.



  • da das format wahrscheinlich älter als 20 jahre alt ist.

    hast du die passenden Applikation dazu oder wie kommst du auf das alter

    und wenn ja wie heisst die Applikation/was macht die - manchmal helfen solche Informationen auch schon weiter



  • es handelt sich um eine alte programmversion meiner firma von vor meiner zeit. leider hat der damalige programmierer die firma im streit verlassen, deswegen habe ich keinen quellcode von ihm und kann ihn nicht fragen. das programm wurde nur inhouse benutzt, insofern bringt der name wohl nichts.
    es handelt sich um eine aufnahme eines vierkanaligen signals mit jeweils x und y werten, das kann man gut in der .sig datei sehen.

    ich habe im vergleich zu einer anderen .xym datei festgestellt, dass es zu beginn des datenblocks bei 0x954 soetwas wie eine zuordnungstabelle geben könnte, damit häufige werte mit weniger bits gespeichert werden könnten?
    die eigentlichen daten scheinen erst bei 0x197F zu beginnen.

    hier zwei kurz aufeinander getätigte aufnahmen, jeweils die .sig datei in lesbarer form und .xym binär.
    http://www.gemini-sites.de/forumImages/binaryEncoding2.zip

    danke!!!



  • man könnte das alte Programm ja auch Reverse Engineeren - was ist es denn DOS/Linux/Windows GUI/Konsole, ASM,C/C++,Pascal,VB(...Java,C#) (falls bekannt) - ich denke der Datenverarbeitungsteil könnte schnell lokalisierbar sein



  • Nachdem ich mir die Datei unter dem Hexeditor angesehen habe, erscheint eine Deltakompression eher unwahrscheinlich. Wäre dies der Fall, würde die Datei fast ausschließlich aus den Halbbytes 0x0, 0x1 und 0xF oder 0x6, 0x7 und 0x8 bestehen, da das Signal sehr gleichmäßig ist. Die Bytes 0x77, 0x00 und 0xFF kommen auffällig oft vor, aber nicht oft genug (außerdem macht es keinen Sinn, dass 0x77 und 0x00 beide oft vorkommen - das sind zwei verschiedene Varianten um "keine Veränderung" zu kodieren).

    Vielmehr erinnern die Daten von der Struktur her an ein unkomprimiertes RGB-Bild, also ein 8-bittiges, dreikanaliges Signal.

    Bist du sicher, dass die Binärdatei die Daten aus der Textdatei verlustfrei kodiert?



  • Gast3 schrieb:

    man könnte das alte Programm ja auch Reverse Engineeren - was ist es denn DOS/Linux/Windows GUI/Konsole, ASM,C/C++,Pascal,VB(...Java,C#) (falls bekannt) - ich denke der Datenverarbeitungsteil könnte schnell lokalisierbar sein

    es ist leider ein dos programm. ich habe es mal in ida geladen, zumindest so relativ schnell wie bei einem normalen 32bit programm ist die struktur für mich nicht nachvollziehbar. aber ich habe auch nicht allzu viel erfahrung damit.
    es werden nichtmal die verwendeten strings aufgelistet. anhand derer bin ich sonst immer ganz gut in die relevanten funktionen gekommen, weil sie bei 32bit programmen logischerweise mit den sie aufrufenden menüpunkten verknüft sind. 😞

    Kenner der Formate schrieb:

    Die Bytes 0x77, 0x00 und 0xFF kommen auffällig oft vor, aber nicht oft genug

    ich vermute ungefähr gleich viele positive und negative werte, das kann man ganz gut in der .sig datei sehen. müssten nicht 0xFF bei kleinen negativen und 0x00 bei positiven werten häufig vorkommen?

    Kenner der Formate schrieb:

    Bist du sicher, dass die Binärdatei die Daten aus der Textdatei verlustfrei kodiert?

    die .sig datei ist dadurch entstanden, dass ich die .xym datei mit dem programm geladen und direkt wieder als .sig datei gespeichert habe. deswegen gehe ich davon aus, dass zumindest die messdaten in beiden dateien identisch sind, nur halt in der .xym datei irgendwie binär encodiert.
    da sie .sig datei also sekundär aus der .xym entstanden ist, müssen die daten in der .xym irgendwie verlustfrei drin sein.

    vielen dank für eure mühe!! 🙂



  • es ist leider ein dos programm.

    dann ist es meist weniger Code und leichter zu analysieren als hochoptimierter x64 Code

    kannst du die Exe rausgeben?



  • Gast3 schrieb:

    kannst du die Exe rausgeben?

    denke das müsste ok sein. die funktion zum speichern wird erreicht über das hauptmenü "Messung" -> "Meßsignal speichern" und dann im Untermenü "Binär (*.XYM-Datei)"
    http://gemini-sites.de/forumImages/ED30I.zip
    danke!



  • laut IDA: Turbo Pascal 7, NE-Image und nutzt den RTM-Extender - und in der String-Liste sind relativ viele Einträge



  • eher wohl BC3.1 C/C++



  • Gast3 schrieb:

    eher wohl BC3.1 C/C++

    danke, ist bei mir leider schon ein paar jahre her, mit welchen einstellungen bekommst du eine relativ lange string liste? wenn ich die exe in ida lade und ms-dos exectable wähle, dann bekomme ich eine "extra information at the end" fehlermeldung und vier kryptische strings.



  • das ist ein NE-Image (weil es einen DOS-Extender nutzt) - dafür brauchst du einen etwas aktuelleren IDA - ich hab 6.5.x oder sowas



  • Ist Pascal - wegen WriteBlock usw., 16Bit

    entweder mit dem DosBox-Debugger reinsteppen oder mit https://github.com/wjp/idados - eine IDA/DosBox-Erweiterung damit man 16Bit schön Debuggen kann 🙂



  • mael15 schrieb:

    es handelt sich um eine alte programmversion meiner firma von vor meiner zeit. leider hat der damalige programmierer die firma im streit verlassen, deswegen habe ich keinen quellcode von ihm und kann ihn nicht fragen.

    Warum kannst du ihn nicht fragen?

    Das Fragen ist doch nicht daran gekoppelt, ob noch jemand für die Firma arbeitet.

    das programm wurde nur inhouse benutzt, insofern bringt der name wohl nichts.
    es handelt sich um eine aufnahme eines vierkanaligen signals mit jeweils x und y werten, das kann man gut in der .sig datei sehen.

    Schon daran gedacht, das Programm zu disassemblieren?
    Das erscheint mir jedenfalls vielversprechender als die Kompression zu erraten.
    Was wenn es gar keine Kompression ist, sondern eine einfache Verschlüsselung oder beides?



  • Schon daran gedacht, das Programm zu disassemblieren?

    die 6 letzten Posts gelesen?



  • @mael15

    hast du schon was herausgefunden


Anmelden zum Antworten