Holla, da hat sich viel getan!

Drei Anmerkungen, dann hat Tiny Hexer endlich einen Nachfolger gefunden:

Eine alte Frage:

BenBE hat folgendes geschrieben :

Zusätzliche Gruppierungslücken nach X Gruppen: Also wenn man Einzelbytes einzeln hat, dass man nach je 4 oder 8 Bytes zusätzlich eine Leerzeichenspalte einblenden lassen kann.

Und was auch toll ist in TH ist der Struktureditor, der zum Beispiel PE-oder Dateisystemheader aufdröseln kann, und dann zu den jeweiligen Offsets springen kann. Das macht für Disk-Editoren (gerade bei Imagedateien) auch Sinn, weil man damit z.B. den MBR reinschauen kann und von dort aus die Partitionen suchen.
Zum gleichen Thema: wenn man eine Partition öffnen will und nicht Administrator ist, kommt einfach eine "Zugriff verweigert"-Meldung. Eine etwas eindeutigere Fehlermeldung wäre praktisch.

Ja, die Strukturanzeige ist das einzige, das ich wirklich sehr vermisse.

Maël, Dein Hexeditor ist ja wirklich ein einmaliges Ergebnis im Bereich der mit Delphi programmierten Freewares.

Was mich jedoch erheblich stört - und was auch im Gegensatz zum sonstigen Niveau dieses Deines Programmes steht - sind gleich mehrere sprachliche Fehler, mit denen man in der ersten Messagebox (der portablen Version) "begrüßt" wird.

Delphi-Laie hat folgendes geschrieben :

Maël, Dein Hexeditor ist ja wirklich ein einmaliges Ergebnis im Bereich der mit Delphi programmierten Freewares. Was mich jedoch erheblich stört - und was auch im Gegensatz zum sonstigen Niveau dieses Deines Programmes steht - sind gleich mehrere sprachliche Fehler, mit denen man in der ersten Messagebox (der portablen Version) "begrüßt" wird.

Auch diese Fehler gerne melden, braucht keine enttäuschte Vorrede Mir ist bisher nur eine denglische Formulierung, "auf eine portable Art" (war: "in einer portablen Art"), aufgefallen. Die Meldung beim Start ist schon seit Jahren drin, möglich dass ich da noch was übersehen habe. Schreib mir doch was dich genauer stört per PN.

Ich verwenden den HxD schon seit 2009. Wirklich super.

Hansi

Danke für das Feedback soweit. Gerne mehr, vorallem Fehlerberichte damit ich dies vor dem Release korrigieren kann.

Die aktuelle Version gibt es unter: mh-nexus.de/downloads/HxD20BetaDeu.zip

Ich habe schon mal die Kommafehler entfernt und etwas umformuliert, da das wichtig für die Übersetzer ist. Sonst soweit keine weiteren Unterschiede zur ZIP-Datei vor zwei Tagen.

Martok hat folgendes geschrieben :

Eine alte Frage: BenBE hat folgendes geschrieben : Zusätzliche Gruppierungslücken nach X Gruppen: Also wenn man Einzelbytes einzeln hat, dass man nach je 4 oder 8 Bytes zusätzlich eine Leerzeichenspalte einblenden lassen kann.

Vielleicht mal später, würde als nächstes (nach dem Release) eher gerne größere Features implementieren. So eine Art Feature ist klein vom Effekt, aber bedeutet größere Änderungen an der Zeichen-/Auswahl-/Hitpoint-Logik.

Martok hat folgendes geschrieben :

Und was auch toll ist in TH ist der Struktureditor, der zum Beispiel PE-oder Dateisystemheader aufdröseln kann, und dann zu den jeweiligen Offsets springen kann. Das macht für Disk-Editoren (gerade bei Imagedateien) auch Sinn, weil man damit z.B. den MBR reinschauen kann und von dort aus die Partitionen suchen.

Das kommt auf jeden Fall (nach dem Release von 2.0), der Dateninspektor war ein erster Schritt dahin.

Martok hat folgendes geschrieben :

Zum gleichen Thema: wenn man eine Partition öffnen will und nicht Administrator ist, kommt einfach eine "Zugriff verweigert"-Meldung. Eine etwas eindeutigere Fehlermeldung wäre praktisch.

Guter Vorschlag, werde ich noch ändern.

Danke an alle für ihr Feedback, schön zu sehen, dass Interesse besteht

HxD ist als 2.0 RC verfügbar.

Es gibt im Prinzip nur noch einen Cachingfehler der Rest sollte stabil sein.

Der Cachingfehler bewirkt einfach nur, dass Dateien, die gelöscht oder nicht lesbar sind, mit Fragezeichen dargestellt werden, bis sie wieder lesbar sind. Sonst sorgt der Cache dafür dass die schon gelesenen/dargestellten Bereiche erhalten bleiben und macht es so etwas praktischer.

mh-nexus.de/downloads/HxDSetup.zip

Es gab eine kleine Fehlerkorrektur für das Speichern. Gleicher Link wie oben.

Ist schon seit Jahren mein Lieblings Hexeditor, dabei wusste ich nicht (oder hab es vergessen), dass der hier aus dem Forum stammt!

Hallo.

Ich habe über die Monate weitere Fehlerkorrekturen (inklusive des Cachingfehlers) und Änderungen gemacht.

mh-nexus.de/downloads/HxDSetup.zip


Jetzt sollte es fertig für den Produktiveinsatz sein. Wenn ihr noch Fehler bemerkt, bitte melden.

Mir gefällt dieses Programm, doch noch besser fände ich eine installationslose bzw. portable Version des Hex-Editors.

Im Anfangsposting dieses Threads ist eine Liste mit Downloads verlinkt, wenn man dort nach unten scrollt, gibt es auch portable Versionen.

Delphi-Laie hat folgendes geschrieben :

Mir gefällt dieses Programm, doch noch besser fände ich eine installationslose bzw. portable Version des Hex-Editors.

Das Setup kann eine portable Version erzeugen, es ist ein "All-In-One"-Paket. Ein weiterer Vorteil ist, dass man so auch eine schreibgeschützte Version erzeugen kann (z.B. für CDs/schreibgeschützte USB-Sticks), und vorher die Einstellungen ändern kann.

Es ist zuverlässiger als die Unzip-Methode.

Christian S. hat folgendes geschrieben :

Im Anfangsposting dieses Threads ist eine Liste mit Downloads verlinkt, wenn man dort nach unten scrollt, gibt es auch portable Versionen.

Die Downloads dort sind noch die Version 1.7.7.0.

Entschuldige die Frage, aber wofür ist dieser Hex-Editor gut? Also ich meine wer bitte kann hexadezimalschrift/code/binaries so bearbeiten, dass am Ende noch etwas sinnvolles bei rauskommt?
Ich kann mir das wirklich nicht vorstellen.
Bitte klär(t) mich auf
Danke!!

LG,
Symbroson

Symbroson hat folgendes geschrieben :

Also ich meine wer bitte kann hexadezimalschrift/code/binaries so bearbeiten, dass am Ende noch etwas sinnvolles bei rauskommt?

Falls Englisch kein Problem ist, hilft das vielleicht etwas weiter:
blog.mh-nexus.de/201...ata-in-a-hex-editor/

Symbroson hat folgendes geschrieben :

Entschuldige die Frage, aber wofür ist dieser Hex-Editor gut?

Immer dann, wenn es auf jedes Byte ankommt.
Es kommt natürlich darauf an, was für Arten von Programmen man schreibt. Der Datenbankentwickler (wie ich es bin) wird vermutlich eher selten einen Hexeditor verwenden.

Aber trotzdem benutze ich ihn manchmal. Wenn ich zum Beispiel Schnittstellen bedienen muss. Die verlangen eine ganz klare Struktur der Daten. Z.B. wird bei Ascii-Schnittstellen oft verlangt, dass ein Datensatz mit LF abschließt. Wenn es mit CR + LF abschließt sind manche Schnittstelle so pingelig und akzeptieren das nicht. Die meisten Texteditoren (notepad, etc.) akzeptieren aber beide Varianten. Da fällt einem also nichts auf.
Dann schaut man sich seine Datei im Hexeditor an und kann dann sehen, was am Datensatzende wirklich steht.

Oder man bekommt Daten von einem anderen Hersteller (auf welchem Weg auch immer, als Datei oder über irgendwelche Webschnittstelle, per RS232, usw...). Dann schaut man es sich im Hexeditor an, um festzustellen, was da genau drin steht, um die Daten im Programm richtig zu interpretieren.

Symbroson hat folgendes geschrieben :

Also ich meine wer bitte kann hexadezimalschrift/code/binaries so bearbeiten, dass am Ende noch etwas sinnvolles bei rauskommt?

Das mußte in der Computer-Urzeit jeder und in der Computer-Frühzeit wohl noch fast jeder, der programmierte, beherrschen.

Erst mit dem Aufkommen der ersten Programmiersprachen (inklusiv Assembler) gab es diesbezüglich eine leichte Entspannung.

Die ersten dieser Übersetzungsprogramme mußten logischerweise komplett Byte für Byte "manuell" entworfen und vor allem implementiert werden, da es noch keine Programme gab, die Wörter bzw. Mnemonics (die Wörter, die Assembler) verstehen. Es gibt eben keinen unendlichen Abstieg.

Symbroson hat folgendes geschrieben :

Entschuldige die Frage, aber wofür ist dieser Hex-Editor gut? Ich kann mir das wirklich nicht vorstellen.

Alle Daten im Computer müssen irgendwie dargestellt werden. Bei digitalen Computern sind das Folgen von 0 und 1.

Dieses abstrakte Konzept lässt sich besser anhand mechanischer Spieluhren verstehen. Deren Musik (bzw. die zu spielenden Noten) sind auf einem Zylinder als Erhebungen gespeichert.

Der Tonkamm hat verschieden lange Stahlzungen. Wird so eine Stahlzunge angehoben und dann "losgelassen" erzeugt sie einen Ton -- je kürzer die Stahlzunge, desto höher der Ton.
Eine horizontale "Zeile" entlang des Zylinders bestimmt also welche Zungen zu einem Zeitpunkt x erhoben werden, und dadurch welche Töne gespielt werden. So wie auf einem Klavier, welche Tasten man gleichzeitig mit den Fingern drückt.
Dreht der Zylinder weiter, erreicht die nächste Zeile den Tonkamm und wird gespielt.

Man kann so eine Zeile wie ein Byte interpretieren: eine Folge von acht Bit (0 oder 1) sind ein Byte, so wie eine Folge von 18 Erhebungen (oder Ebenen) auf dem Zylinder eine Zeile sind.

Man kann also diese Erhebungen/Ebenen auf diesem Zylinder auch als Bytefolgen darstellen. Hier würde man 3 Byte (=24Bit) pro Zeile nehmen, da man mindestens 18 bit braucht. Es blieben von den 24 Bit also 6 Bit übrig, die man einfach ignoriert.
Liest man eine Datei die wie eben beschrieben codiert ist, und spielt für jedes Bit das 1 ist einen der Bitposition entsprechend hohen Ton, dann könnte man die Musik des Zylinders reproduzieren.
Die Darstellung der Musik als Zylinder oder als Datei wären also äquivalent: Sie kodieren die gleiche Information, und erzeugen mit passenden Interpretatoren/Abspielgeräten, die gleichen Effekte/Musik.

Solche Kodierungen sind nicht immer einfach zu erkennen, deswegen gibt es einen Dateninspektor in der Version 2.0, der übliche Dekodierungen automatisch anzeigt. Die rechte Spalte in einem Hexeditor ist auch nur eine Dekodierung der Bytefolgen als Text, unter der Annahme dass der Text gemäß eine bestimmten Kodierung wie ASCII oder UTF-8 kodiert ist. Ist das nicht der Fall sieht die rechte Spalte eher chaotisch oder unsinnig aus.

Bei noch komplexeren Datenformaten sind Struktureditoren hilfreich.


Schreibt mal aber die Datei selbst, ist man sich im Klaren über das Datenformat, und kann dann im Hexeditor nachsehen ob auch wirklich geschrieben wurde was geschrieben werden sollte. Z.b. ob die richtige Textkodierung verwendet wurde, die Bytefolge richtig ist (Little-Endian-Maschinen speichern 32-Bit-Integer in einer anderen Byte-Reihenfolge als Big-Endian-Maschinen), tatsächlich ein 32-Bit-Integer und nicht nur 16-Bit-Integer gespeichert wurde (Vermeidung von eventuellem Datenverlust).

Ein gutes Beispiel sind auch Bitmaps. Bitmaps sind einfach Folgen von Pixeln. Jedes Pixel is ein Byte-Trippel, also je ein Byte für Rot, Grün, und Blau. Da lässt sich schonmal ein Fehler anhand der Zahlen erkennen, wenn das Bild wenige Farben oder viele Flächen verwendet.
Im Programm werden Bitmaps/Bilder auch nur als Arrays von Zahlen dargestellt, also muss man lernen auf gewisse Art damit umzugehen, ähnlich wie im Hexeditor.
Man kann z.B. abrubte Kontrastwechsel erkennen, wenn man nach großen Zahlennterschieden zwischen zwei benachbarten Pixeln sucht.

Ich hoffe all das gibt eine bessere Intuition.


Hexeditoren zeigen einfach die Kodierung auf dem niedrigsten Niveau, ohne auf die physische Kodierung (Strom, mechanische Erhebungen usw.) einzugehen.

Diese Idee der Kodierung ist fundamental um zu verstehen wie man die echte Welt in einem Computer modellieren kann. Daher auch mein Interesse an Hexeditoren und allgemein Interpretation von Datenformaten usw. KI und Machine Learning ist auch sehr interessant, z.B. um Muster in Daten zu finden, Datentypen zu identifizieren, usw. Im Prinzip ist das alles das Gleiche: Numerische/Symbolische Modelle der Welt und wie man das praktisch umsetzt.

Es hat damit angefangen dass ich Spiele gesehen habe wo man durch Hexeditoren die Leben, Fähigkeiten oder sonstigen Spieleigenschaften ändern konnte. Irgendwie war das magisch und ich wollte das besser verstehen.


P.S.:
Bei digitalen Computern gibt es zwei mögliche Zustände, 0 und 1 was elektrisch gesehen als 0V und 5V realisiert wird (bei aktuellen Prozessoren kann anstatt 5V auch nur 0.8V verwendet werden um 1 zu repräsentieren). Wie bei mechanischen Computern/Spieluhren, sind die Bits also eigentlich keine Zahlen, sondern Symbole die zwei Zustände unterscheiden. Man kann sie aber auch als Zahlen interpretieren und damit Rechnen, weil das häufig nützlich ist.

Ok danke euch
Ich glaube ich hab den Sinn jetzt verstanden ^^

Im Grunde bewitkt der Hex-Editor also, dass man jedes Zeichen einer Datei lesen und bearbeiten kann. Was ja bei normalen Text-Editoren nicht der Fall ist, geschweigedenn diese in ruhe lassen.
Die Idee/Notwendigkeit kam also noch vor Assembler - das ist heftig

Danke nochmal

LG,
Alex