Suche einen Binary-Editor, der Bytes Dezimal (0-255) darstellen kann und ein solches mögliches 0 als 000 darstellt.

Hallo,

ich muss Dateien binary analisieren und dokumentieren. Es gestaltet sich aber schwer einen passenden Editor zu finden. Denn ich müsste das was ich da dann auch markiere identisch kopieren können und zwar so, dass ein byte identifizierbar bleibt. Entweder durch trennung eines Leerzeichen oder das jedes Byte, dargestelt als Dezimal, immer mit 3 Ziffern dargestellt wird.

Wenn möglich für Windows.

Gut ich könnte jetzt so einen Editor selber schreiben, hate ich auch schon einmal, habe aber die erfahrung gemacht, dass es schon bei leicht größeren Dateien zu unzumutbaren Ladezeiten kommt, wenn der Editor in Visual C++ geschrieben ist.

volkard

Wäre es nicht viel einfacher, sich ein wenig an Hex-Zahlen zu gewöhnen?

volkard schrieb:

Wäre es nicht viel einfacher, sich ein wenig an Hex-Zahlen zu gewöhnen?

Ich glaube nicht das dass Problem daran liegt, dass ich es optisch gerner in Dezimal sehe. Auch wenn es in Hexadezimaldargstellt ist, gilt das selbe Problem. Ein Byte 00000000 wird auch in Hexadezimal als 0 dargestellt.

Das ist komisch. Warum wird diese Formatierung bei Hexadezimal angewandt und bei Dezimal nicht?

Dennoch läst sich aber auch bei Hexadezimaler Darstellung ein Bereich nicht wie gewünscht kopieren.

ich müsste nämlich zur dokumentation bestimmte Bereiche markieren und kopieren. Und dort wo ich sie einfüge, müssten sie dann auch identisch sein. Wobei die Formatierung, 16 byte pro Zeile nicht wichtig ist.

DocShoe

Wirf mal einen Blick auf HHD Neo Hex Editor.

Perfomancezierer

DocShoe schrieb:

Wirf mal einen Blick auf HHD Neo Hex Editor.

Das ist aber nur eine Demo oder in Vollversion 14 Tage Drial.

Darüber hinaus ist mir jetzt eh in den sinn gekommen, das dass alles viel zu umständlich ist. Kurzerhand müsste ich mir doch ein kleines Programm schreiben. Aber in einer Sprache, die dann gewährleistet, dass das Programm sehr zügig arbeitet. Sicherlich werde ich da eine algorytmische Funktion brauchen die es schon als Header gibt.

Also da ich dann eine Sprache nehme, mit der eine GUI erstellung ziemlich umständlich wäre. Belasse ich es gleich einfach mal bei einer Konsolenanwendung. Dadurch fält auch gleich wiederum das Ladeproblem weg, was bei einer grafischen Darstellung der Bytes entsteht.. Wichtig were dann aber um das Ergebnis auswerten zu können, dass die Resultate in einer Datei geschrieben werden mit einer Formatierung, die Excel kennt um die Informationen dann per Excel impotieren zu können.

Dem Programm müsste ich dann eine reihe von Dateien oder eine Liste, die die Dateien angibt, angeben. Das Programm soll dann nach identischen Segmenten suchen. Nicht in einer Datei bei sich selbst, sondern bei den anderen Dateien. Solch ein Segment soll es dann nummeriert in die Resultat-Datei abspeichern.
Wichtig were aber auch das man dem Programm sagen kann, wie viel Bytes ein Segment min. haben muss, damit es als Resultat behandelt wird.

Wer kennt solch eine Header oder Klasse, die diesen Algorytmuss beherscht?
Und auch wenn es nur eine Funktion were, die blos anbietet zwei Strings anzu geben, in dennen es gleichheiten sucht, were mir schon geholfen. Denn das herbeiführen zweier Quellen aus je einer Datei läst sich ja leicht programmieren und mit Schleifen läst sich das abarbeiten der Liste gewährleisten.

Gegebenfalls diesen Thread bitte verschieben.

EDIT: Wie kann man denn eine Datei zu Arbeitszwecken in den Arbeitsspeicher (bei Windows) laden und wie dann auf sie verweisen?

DocShoe

Perfomancezierer

Vorstellung des Algorytmus:

Mindestlänge
Mindestbreite 1048576 Byte

Quelle 1
Quelle 2

Maske = Mindestlänge

Maske 1 auf Quelle 1 bei Position 0 setzten und am Ende der Maske Schnittposition-Quelle-1 setzten. #0 Maske 2 auf Quelle 2 bei Positon 0 setzten. #1 Die Bytes unter Maske 2 auf gleichheit mit den Bytes unter Maske 1 prüfen.

Falls gleichheit besteht, #2 Maske 2 mit Maske 1 so lange verlängern wie die Bytes unter beiden Masken gleich weren. Dann dort bei Maske 2 Schnittposition merken und Maske 1 auf Maske zurück setzten und an Position 0. Maske 2 auf Maske zurück setzten und an Schnittposition setzten. und wieder von vorne ab #1.

Falls nicht gleichheit besteht, Maske 2 so lange um +1 verschieben bis gleichheit besteht und dann weiter bei #2.

Falls Maske 2 nicht länger oder nicht weiter verschoben werden kann, weil Quelle 2 zu ende ist, Maske 1 um +1 erhöhen und bei #0 weiter machen. Falls Maske 1 nicht verlängert werden kann, weil die Mindestbreite bereits erreicht wurde, Maske 1 auf Maske zurück setzten und Anfang der Maske 1 an Schnittposition-Quelle-1 setzten. Ab #0 wieder weiter machen.

Falls Maske 1 nicht länger oder nicht weiter verschoben werden kann, weil Quelle 1 zu ende ist, nächste Datei als Quelle 2 einladen und wieder ganz von oben beginnen (#-1).

Ich behaupte mal, wenn du das unter Visual C++ nicht schnell genug bekommst ist nicht der Compiler die Ursache, sondern eher der Quelltext oder ein schlecht eingerichteter PC.

Oh ist das lange her - funktioniert das alte Debug immer noch?
Bei Fehlbedienung sind eure Daten in Gefahr
Aber das sollte auch so was anzeigen können. Aber wie du da was kopieren kannst

MfG f.-th.

Perfomancezierer

f.-th. schrieb:

Ich behaupte mal, wenn du das unter Visual C++ nicht schnell genug bekommst ist nicht der Compiler die Ursache, sondern eher der Quelltext oder ein schlecht eingerichteter PC.

Oh ist das lange her - funktioniert das alte Debug immer noch?
Bei Fehlbedienung sind eure Daten in Gefahr
Aber das sollte auch so was anzeigen können. Aber wie du da was kopieren kannst

MfG f.-th.

Das Problem liegt bei .net Framework. Wenn man da größeren Text z.B. in eine Textbox laden will, beginnt ein unsinniger riesen Prozess und extrem viel virtueller Arbeitsspeicher. Was fehlbedienung anbelangt, da braucht man sich überhaupt keine sorgen machen, da man a) eine Sicherung erstellen kann sowie nur Leseberechtigung für die Dateien geben kann, und b) den Zugriff auf die Dateien mit dem Schlüssel nur Lesen machen kann.

Bezüglich Kopieren, verstehe ich jetzt nicht was du meinst. Segmenttreffer sollen dann einfach nummeriert in einer bestimmten Formatierung in eine Datei abgespeichert werden.

Debug war damals unter DOS das Universalwerkzeug, das jeder DOS-Nutzer auf dem PC hatte um Programme zu schreiben, Fehler zu finden, Festplatten zu formatieren u.s.w.
Aber an copy&paste oder gar NET hat damals wahrscheinlich noch keiner gedacht.
Kann aber sein das das, wenn es noch auf der Festplatte ist, an der 64k Grenze zu knabbern hat.

Irgend wie werde ich den Verdacht nicht los dein Quelltext für deinen HEX-Editor sollte überarbeitet werden. Denn mit c++ geschriebene Programme sollten, wenn die gut geschrieben wurden, sehr schnelle Programme als Ergebnis haben. In welcher Sprache soll denn noch schnelleres möglich sein? Basis ist natürlich gleichwertiger Quelltext.

Perfomancezierer

f.-th. schrieb:

Debug war damals unter DOS das Universalwerkzeug, das jeder DOS-Nutzer auf dem PC hatte um Programme zu schreiben, Fehler zu finden, Festplatten zu formatieren u.s.w.
Aber an copy&paste oder gar NET hat damals wahrscheinlich noch keiner gedacht.
Kann aber sein das das, wenn es noch auf der Festplatte ist, an der 64k Grenze zu knabbern hat.

Irgend wie werde ich den Verdacht nicht los dein Quelltext für deinen HEX-Editor sollte überarbeitet werden. Denn mit c++ geschriebene Programme sollten, wenn die gut geschrieben wurden, sehr schnelle Programme als Ergebnis haben. In welcher Sprache soll denn noch schnelleres möglich sein? Basis ist natürlich gleichwertiger Quelltext.

Also das Debugen zegit während des ganzen Vorgangs kein Problem an. Das Problem ist die Zeit. Ich bezweifle nicht das C++ sehr schnell ist aber offenbar ist .net Framework eine echte Bremse. Aber das ist jetzt eh Pustekuchen, da ein Editor viel zu viel arbeit machen würde. Das were unmenschlich, einem Menschen zu überlassen nach identischen Segmenten zu suchen.

Ich habe die erfahrung gemacht, um so größer die sektoren um so langsamer. Das hat wohl was mit dem ständigen Springen der Nadel zu tun.

Und wie gesagt dieser Quellecode für den Binary-Editor kann man genau so gut auch als fatal weg werfen, weil eine optische Darstellung des Binary einer Datei per .net Framework zum Kolaps führt.

Daher werde ich jetzt ein anders, passerendes Programm schreiben ohne CLI.