(LINUX) Herausfinden, welches Format eine Datei hat?

[Markus Pitha]

Hallo,

durch meine Recherchen, einem Programmcode, der eine Animation erzeugt auf die Spur zu kommen bemerkte ich, dass oft irgend eine Datei eingelesen wird. Zum Verständnis wollte ich nachprüfen, welches Dateiformat das denn ist, damit ich besser erkennen kann, was im Programm vor sich geht.
Nun habe ich aber das Problem, dass ich diese Datei nicht öffnen kann, da ich nicht weiß, welches Format es eigentlich ist.
Auf jeden Fall ist es eine binäre Datei (was sonst), aber eine Umbenennung nach .bmp, .jpg, .gif, .png,.. o.ä hat nichts gebracht.
Mit "file back.16" (so heißt die Datei) bekomme ich auch nur die Meldung "data" als Ausgabe, was auch nicht gerade hilfreich ist.
Der dazu im Programm angeführte Code sieht so aus:

  
  fichier = open ( "back.16" , O_RDONLY );  
  if (fichier<0) {  
    printf("impossible d'ouvrir back.16 \n");  
    exit(0);  
  }  
  
  read ( fichier ,texture1, 2*256*256  );  
#ifndef X11  
{  
  Uint16 *p = (Uint16 *)texture1;  
  int i;  
  for (i=0; i<256*256; ++i, ++p)  
    *p = SDL_SwapLE16(*p);  
}  
#endif  
  close ( fichier );  

Hat jemand Ahnung, was sich in diesem File befinden könnte, oder wie ich es öffnen und darstellen kann?

Markus.

[Christian Kruse]

你好 Markus,

Hat jemand Ahnung, was sich in diesem File befinden könnte, […]

Ein Array von u_int16_t-Elementen.

[…] oder wie ich es öffnen und darstellen kann?

Mit einem Hex-Editor deiner Wahl ;) (khexedit kann ich empfehlen).

再见,
 克里斯蒂安

[Markus Pitha]

Hallo,

Mit einem Hex-Editor deiner Wahl ;) (khexedit kann ich empfehlen).

Ja du hast Recht. Damit kann ich es öffnen. Allerdings ist mir das mit Hexadezimal-Code,.. usw etwas zu hoch :) Ich habe eigentlich keine Ahnung (obwohl ich die gerne hätte), was ich damit anfangen kann, aber trotzdem danke für den Tipp.
Wie aber hat der Autor ursprünglich diese Datei gespeichert? Mit einem Hexeditor kann ich sie zwar öffnen, aber wie die Daten zu interpretieren sind, verstehe ich leider nicht. Ein jpg-File kann ich damit beispielsweise auch öffnen. Hier weiß ich aber, dass es ein jpg File ist. Mit dieser ursprünglichen Datei weiß ich aber noch immer nichts anzufangen.

Markus.

[Christian Kruse]

你好 Markus,

Mit einem Hex-Editor deiner Wahl ;) (khexedit kann ich empfehlen).

Ja du hast Recht. Damit kann ich es öffnen.

Ein Hex-Editor öffnet _jede_ Datei ;)

Allerdings ist mir das mit Hexadezimal-Code,.. usw etwas zu hoch :) Ich
habe eigentlich keine Ahnung (obwohl ich die gerne hätte), was ich damit
anfangen kann, aber trotzdem danke für den Tipp. Wie aber hat der Autor
ursprünglich diese Datei gespeichert?

Das, was du da siehst, ist die ganz normale Darstellung von
u_int16_t-Elementen, wie sie auch im Speicher vorliegen. Die sind direkt
vom Speicher auf die Festplatte geschrieben worden. Stell dir vor, du hast
die Zahl 65000. Der Computer rechnet im Binär-Syste, so dass sie dann so
dargestellt werden kann: 1111110111101000 oder auch verkürzt: 0xFDE8 (dabei
stehen zwei Hex-Ziffern für acht Binär-Ziffern bzw. eine Hex-Ziffer für vier
Binär-Ziffern). Im Computer hast du jetzt also zwei Speicherzellen mit
dem Inhalt 0xFD und 0xE8 (pro Speicherzelle 8 Bit). Das ist das, was du im
Hex-Editor idR siehst. Du musst jetzt also die ersten beiden Bytes nehmen
und aneinanderhängen: 0xFDE8. Damit hast du dann wieder die Orginal-Zahl.

Der Autor macht nichts anderes als Unsigned-16-Bit-Zahlen auf die
Festplatte zu schreiben und wieder einzulesen. Dadurch, dass er die
Umwandlung nach ASCII weglässt, weiss er immer, wie gross eine Einheit
ist (nämlich 16 Bit = 2 Byte beim PC).

Mit einem Hexeditor kann ich sie zwar öffnen, aber wie die Daten zu
interpretieren sind, verstehe ich leider nicht.

Das geht auch nur anhand einer Spec oder anhand des Sourcecodes. Ansonsten
kann man nur Vermutungen anstellen ;)

再见,
 克里斯蒂安

[Markus Pitha]

Hallo,

Alles klar, aber interessenhalber gefragt: Was habe ich dann eigentlich davon, wenn ich die ursprüngliche Zahl weiß? Ich welchen Anwendungsgebieten wird so ein Editor idR verwendet?

Markus.

[Christian Kruse]

你好 Markus,

Alles klar, aber interessenhalber gefragt: Was habe ich dann eigentlich
davon, wenn ich die ursprüngliche Zahl weiß? Ich welchen
Anwendungsgebieten wird so ein Editor idR verwendet?

Debugging und Reverse-Engineering. Nicht immer sind Speicher-Algorithmen
Fehlerfrei und manchmal muss man das Format erraten ;) Halt immer dann,
wenn man Inhalte ansehen will, die nicht offensichtlich sind und dekodiert
werden müssen.

再见,
 克里斯蒂安

[Markus Pitha]

Hallo,

Debugging und Reverse-Engineering.

Das finde ich interessant. Das heißt also, dass ich aus diversen kompilierten Programmen die Informationen herausziehen kann. Hast du irgendwelche Links, die sich mit diesem Thema befassen, bzw zumindest irgendwelche Grundlagen?

Markus.

[Christian Kruse]

你好 Markus,

Debugging und Reverse-Engineering.

Das finde ich interessant. Das heißt also, dass ich aus diversen
kompilierten Programmen die Informationen herausziehen kann. Hast du
irgendwelche Links, die sich mit diesem Thema befassen, bzw zumindest
irgendwelche Grundlagen?

Nein… für Reverse-Engineering braucht man wirklich sehr viel Wissen. Das
ist sozusagen „schwarze Magie“. Das kann man nicht aus irgendwelchen
Tutorials lernen. Dazu braucht man einen sehr grossen Wissensschatz,
Erfahrung, Erfahrung und viel Wissen.

Es gibt zwar ein Buch, dass man als Einstieg lesen könnte, jedoch musst du
dir darüber klar sein, dass das noch lange nicht ausreicht; soetwas zu
lernen braucht Jahre-lange Arbeit. Wenn dich sowas interessiert, kann ich
dir nur empfehlen: lerne C, lerne ASM, lies Bücher über Betriebssysteme,
und wie sie arbeiten, lies Bücher über Compiler und wie sie arbeiten, etc,
pp – alles, was eben so dazu gehört.

Das soll jetzt nicht arrogant oder schulmeisterhaft klingen, sorry wenn es
so herübergekommen ist. RE ist halt einfach eine Meister-Disziplin.

再见,
 克里斯蒂安

[Der Martin]

Hallo Markus und Christian,

Nein… für Reverse-Engineering braucht man wirklich sehr viel Wissen. Das
ist sozusagen „schwarze Magie“. [...] RE ist halt einfach eine Meister-Disziplin.

Das ist so, als würdest du das neueste Modell eines Sportwagens kaufen, es zerlegen und vermessen, und daraus die Konstruktionszeichnungen und Baupläne rückgewinnen.
Das ist bis zu einem gewissen Grad möglich, erfordert aber -wie CK schon ganz richtig erwähnt- ein sehr umfassendes und fundiertes Fachwissen und viiiel Aufwand. Und selbst dann ist es oft nicht hundertprozentig möglich, weil viele Verfahren und Algorithmen nicht eindeutig umkehrbar sind.

So long,

Martin

[Markus Pitha]

Hallo,

tja, am Interesse würde es gar nicht scheitern, sondern an meiner nicht vorhandenen Zeit. Trotzdem danke für die Info.

Markus.

[Christian Kruse]

你好 Markus,

tja, am Interesse würde es gar nicht scheitern, sondern an meiner nicht
vorhandenen Zeit.

Du bist doch noch jung? ;)

再见,
 克里斯蒂安

[Henryk Plötz]

Moin,

Das finde ich interessant. Das heißt also, dass ich aus diversen kompilierten Programmen die Informationen herausziehen kann. Hast du irgendwelche Links, die sich mit diesem Thema befassen, bzw zumindest irgendwelche Grundlagen?

Gesunder Menschenverstand, eine Menge Allgemein- und Basiswissen über das jeweilige Themengebiet, Google, etwas Zeit und Freude am Experimentieren bringen einen schon ganz schön weit. Ich kann dir zumindest sagen, was ich bei http://www.ploetzli.ch/ipod/ gelernt habe, zumal es hier rein passt.

Du weisst also schon, dass die Daten vermutlich ein Bild darstellen, dann ist Imagemagick ab jetzt dein bester Freund. (Wobei ich zugeben muss, dass die Doku von Imagemagick grauenhaft ist. Such gar nicht erst nach einem Index, es gibt keinen.)

Du hast die Daten immerhin schon als eigene Datei vorliegen, das macht es etwas einfacher (ich musste die erst rauspfriemeln). Da sie offenbar keinen Header haben sind sie wohl einfach nur rohe Daten, da hat file schon ganz recht.

Der interessante Punkt ist jetzt: a) wie groß ist das Bild, b) wie ist es codiert. Das kann man jetzt raten, oder sich durch Experimente mit Imagemagick da rantasten. Da du aber schon ein bisschen Code gezeigt hast, tippe ich mal auf 256 * 256 Pixel. Offenbar sind da jeweils 2 Byte pro Pixel verwendet worden. Interessant ist dann die Bytereihenfolge, ob Big Endian oder Little Endian. Der Code deutet auf Little Endian hin, gut. (Sonst müsste man das einfach ausprobieren.) Nächster und Knack-Punkt: Farbe oder Monochrom? Ich gehe jetzt einfach mal von Monochrom aus, wirst gleich sehen warum.

Wenn du all diese Parameter gut geraten hast (der englische Ausdruck "educated guess" ist hier sehr passend), kannst du mal versuchen, dir das Bild anzusehen:

  
display -size 256x256 -depth 16 -endian LSB gray:back.16  

Wenn einer der geratenen Parameter nicht stimmt, experimentiere mit anderen. (Also etwa -endian MSB.) Wenn die Bildgröße nicht genau stimmt, dann wirst du zwar trotzdem etwas sehen, aber das Bild verschiebt sich von Zeile zu Zeile, sieht merkwürdig verzerrt aus oder es gibt mehrere Geisterbilder. Mit ein klein wenig Erfahrung kannst du aber die nötigen Korrekturen an der Bildgröße richtig einschätzen.

Was die Farbe angeht: Da du (vermutlich) zwei Bytes pro Pixel hast, ist das zumindest in Imagemagick nicht so einfach. Zumal es da mehrere Möglichkeiten gibt. Eine unwahrscheinliche ist YUV mit 4:2:2 Subsampling (das ist das was der iPod für den TV-Ausgang macht), das kann Imagemagick sogar direkt.

Sehr wahrscheinlich wirst du (wenn du Farbe in 2 Bytes antriffst) RGB 565 haben. D.h. 5 Bits Rot, 6 Bits Grün, 5 Bits Blau (macht 16 Bits = 2 Bytes). Das kann Imagemagick leider nicht, aber bei meiner oben verlinkten Seite findest du ein kleines C-Progrämmchen (nicht sehr schön allerdings) dass das in normaleres RGB (also 888) umwandelt, was du in Imagemagick dann mit -depth 8 rgb:... öffnen kannst.

Solltest du ganz und gar ungewöhnliche Farbkodierungen antreffen, musst du entweder so lange raten bis dich ein Geistesblitz trifft, im (ggbf. dekompilierten Code) spicken oder ... versuchen ein eigenes Bild irgendwie in das Format zu kriegen. Als eigenes Bild nimmst du dann eine Art Testbild wo möglichst großen Flächen vollständig einfarbig sind, und dann kannst du zum Beispiel mit einem Hexeditor durch konzentriertes Draufstarren rausfinden welche Bits zu welcher Farbe gehören.

[Markus Pitha]

Hallo,

Danke für die ausführliche Information. Ich glaube jetzt auch, dass ich weiß, wie das Bild in Wirklichkeit aussieht.

display -size 256x256 -depth 16 -endian MSB gray:back.16

Damit ist es zwar nicht farbig, aber dennoch erkennt man, wie die Oberfläche der Grafik höchstwahrscheinlich aussieht. Ich konnte das auch mit einem anderen Beispiel des offensichtlich selben Programmierers nachvollziehen.

Markus.

[Henryk Plötz]

Moin,

display -size 256x256 -depth 16 -endian MSB gray:back.16

Damit ist es zwar nicht farbig, aber dennoch erkennt man, wie die Oberfläche der Grafik höchstwahrscheinlich aussieht

Ja, dass das nicht farbig ist ist klar, dafür ist ja das gray da (Graustufenbild). Das hatte ich im letzten Posting noch vergessen zu erwähnen: Dadurch wie RGB 565 aufgebaut ist, sieht das erstmal ganz normal aus, wenn man versucht, das Bild als 16-Bit-Graustufenbild anzuzeigen (das hatte mich beim iPod auch erst in die Irre geführt).  Das sieht dann fast so aus, als würdest du dir nur den roten Kanal als Graustufenbild ansehen.

Der Grund ist ganz einfach: Wenn man RGB 565 als reine Graustufen interpretiert, dominieren die ersten 5 Bits (also Rot) den Grauwert ganz erheblich. Das Grün spielt noch ein bisschen mit, kann den Wert aber nur um ein 32stel ändern. Das Blau sieht man üblicherweise gar nicht mehr.

[Markus Pitha]

Hallo,

Alles klar, aber dennoch bin ich fast davon überzeugt, dass die Ausgabe fast richtig war, da das andere Bild, das ich testete, ein schachbrettartiges Muster hatte, was ich mir bei der Animation bereits gedacht hatte.
Ich frage mich nur, was es bringt, dass der Programmierer es einem so schwer macht, die Grafik zu erkennen. Warum wird nicht einfach ein "normales" Bild eingelesen? Hat es für das Programm irgendwelche Vorteile, eine Grafik dieser Art zu benutzen? Schnelligkeit, o.ä?

Markus.

[Christian Kruse]

你好 Markus,

Ich frage mich nur, was es bringt, dass der Programmierer es einem so
schwer macht, die Grafik zu erkennen.

So schwer ist es ja nun wirklich nicht.

Warum wird nicht einfach ein "normales" Bild eingelesen? Hat es für das
Programm irgendwelche Vorteile, eine Grafik dieser Art zu benutzen?
Schnelligkeit, o.ä?

Es ist einfacher und schneller als ein kompliziertes Bild-Format wie JPeg
oder GIF oder so.

再见,
 克里斯蒂安

[Cybaer]

Hi,

Nun habe ich aber das Problem, dass ich diese Datei nicht öffnen kann, da ich nicht weiß, welches Format es eigentlich ist.

Wenn es kein "Spezial-Format" ist: whatis ist dein Freund.

Gruß, Cybaer

[Christian Kruse]

你好 Cybaer,

Nun habe ich aber das Problem, dass ich diese Datei nicht öffnen kann,
da ich nicht weiß, welches Format es eigentlich ist.

Wenn es kein "Spezial-Format" ist: whatis ist dein Freund.

Du meinst sicher „file“? Whatis durchsucht doch „nur“ die System-eigene
Dokumentation.

再见,
 克里斯蒂安

[Cybaer]

Hi,

Wenn es kein "Spezial-Format" ist: whatis ist dein Freund.
Du meinst sicher „file“?

Oh ja, natürlich. Mein Alzheimer ermöglichte nur noch den Zugriff auf "da gibt es was". >;->

Zumal ich weder whatis noch file jemals selbst benutzt habe ... =:-)

Gruß, Cybaer