Sioni Hex Editor Pro – warum ich meinen eigenen Hex-Editor entwickle

Ein Hex-Editor gehört wahrscheinlich nicht zu den Programmen, die jeder täglich benutzt.

Für mich liegt aber genau darin der Reiz.

Wenn ich eine Datei mit einem normalen Editor öffne, sehe ich das, was mir das jeweilige Dateiformat zeigen möchte. Öffne ich dieselbe Datei in einem Hex-Editor, sehe ich die Datei selbst.

Byte für Byte.

Keine Interpretation. Keine hübsche Oberfläche, die irgendetwas für mich übersetzt. Keine versteckten Annahmen.

Genau dieser direkte Zugriff auf Daten hat mich schon immer fasziniert.

Und irgendwann kam bei mir wieder der Gedanke auf, der hinter inzwischen mehreren meiner Sioni-Projekte steckt:

Warum eigentlich nicht mein eigenes Werkzeug dafür entwickeln?

Ein Hex-Editor muss vor allem eines sein: zuverlässig

Bei vielen Programmen kann man kleinere Fehler noch irgendwie verschmerzen.

Bei einem Hex-Editor sehe ich das anders.

Wenn ich direkt an Binärdaten arbeite, möchte ich mich darauf verlassen können, dass das Programm exakt das tut, was ich ihm sage.

Nicht ungefähr.

Nicht meistens.

Sondern exakt.

Ein falsch gesetztes Byte kann ausreichen, um eine Datei unbrauchbar zu machen. Eine fehlerhafte Offset-Berechnung kann dazu führen, dass eine Änderung an einer völlig anderen Stelle landet. Und wenn eine Software beim Speichern unbemerkt zusätzliche Daten verändert, ist das für mich bei einem Hex-Editor schlicht nicht akzeptabel.

Darum ist der Sioni Hex Editor Pro für mich eines dieser Projekte, bei denen Genauigkeit wichtiger ist als eine möglichst lange Funktionsliste.

Ich wollte kein technisches Spielzeug

Natürlich gibt es bereits Hex-Editoren.

Darunter auch sehr leistungsfähige Programme.

Trotzdem hatte ich Lust, meine eigene Vorstellung davon umzusetzen, wie so ein Werkzeug aussehen und funktionieren sollte.

Ich wollte keinen Editor bauen, der nur beweist, dass ich Bytes in einer Tabelle anzeigen kann.

Das wäre relativ schnell erledigt gewesen.

Mein Anspruch war von Anfang an höher.

Wenn ich den Namen Sioni Hex Editor Pro verwende, soll dahinter irgendwann auch ein Werkzeug stehen, das ich selbst für ernsthafte Arbeiten einsetzen kann.

Das bedeutet für mich:

Eine Datei muss zuverlässig geladen werden.

Positionen und Offsets müssen stimmen.

Änderungen müssen eindeutig erkennbar sein.

Navigation muss funktionieren.

Speichern darf keine Überraschungen produzieren.

Und die Oberfläche darf den eigentlichen Inhalt nicht unter Bergen von Design verstecken.

Gerade bei einem technischen Werkzeug ist mir das wichtig.

Hexadezimal klingt komplizierter, als es eigentlich ist

Für jemanden, der noch nie mit einem Hex-Editor gearbeitet hat, sieht die typische Ansicht zunächst wahrscheinlich ziemlich abschreckend aus.

Zeilen voller Zahlen:

4D 5A 90 00 03 00 00 00 ...

Daneben Zeichen.

Davor Adressen beziehungsweise Offsets.

Eigentlich ist das Prinzip aber ziemlich logisch.

Ein Hex-Editor zeigt die einzelnen Bytes einer Datei in hexadezimaler Darstellung. Statt Zahlen von 0 bis 255 zu schreiben, verwendet man Werte von 00 bis FF.

Damit kann ich genau sehen, was sich an welcher Position in einer Datei befindet.

Das ist beispielsweise bei der Analyse unbekannter Dateiformate interessant, beim Vergleichen von Dateien, beim Untersuchen von Dateiköpfen oder einfach dann, wenn man wissen möchte, was wirklich in einer Datei steckt.

Mich interessiert genau diese Ebene.

Nicht nur:

„Was stellt dieses Programm aus der Datei dar?“

Sondern:

„Was steht tatsächlich darin?“

Bei diesem Projekt wurde mir wieder bewusst, wie schwer „einfach“ sein kann

Ein Hex-Editor wirkt auf den ersten Blick wie ein relativ überschaubares Projekt.

Links Offsets.

In der Mitte Hex-Werte.

Rechts die Textdarstellung.

Fertig.

So einfach ist es natürlich nicht.

Sobald aus einer Anzeige ein echter Editor wird, fangen die interessanten Probleme an.

Wie verhält sich die Markierung?

Wie synchronisiert man verschiedene Darstellungen derselben Daten?

Was passiert beim Überschreiben?

Wie navigiert man zuverlässig durch große Datenmengen?

Wie verhindert man, dass die Benutzeroberfläche bei bestimmten Aktionen in einen falschen Zustand gerät?

Was passiert beim Abbrechen?

Was passiert bei einer ungültigen Eingabe?

Was geschieht mit noch nicht gespeicherten Änderungen?

Und vor allem:

Kann ich nach einer Bearbeitung sicher sein, dass nur das verändert wurde, was ich verändern wollte?

Das sind keine besonders spektakulären Fragen.

Für einen Hex-Editor sind sie aber entscheidend.

Die ersten Versionen waren ein Lernprozess

Der Weg zu einem brauchbaren Stand war beim Sioni Hex Editor Pro nicht geradlinig.

Es gab Versionen, bei denen Dinge funktionierten und andere Dinge wieder nicht. Manche Probleme zeigten sich sofort. Andere erst bei genauerem Testen.

Das ist bei Softwareentwicklung nichts Ungewöhnliches.

Bei einem Werkzeug wie diesem nervt es mich trotzdem besonders.

Ich möchte keine neue Versionsnummer veröffentlichen und anschließend feststellen, dass eine grundlegende Funktion an anderer Stelle beschädigt wurde.

Deshalb war Version 0.7.6 für mich ein wichtiger Punkt.

Sie war die erste Version, bei der ich nach meinen realen Tests sagen konnte:

Das ist die erste einigermaßen fehlerfreie Version.

„Einigermaßen“ klingt vielleicht nicht besonders werbewirksam.

Aber genau so wollte ich es formulieren.

Ich halte nichts davon, ein Entwicklungsprojekt künstlich schöner darzustellen, als es zu diesem Zeitpunkt ist.

Später habe ich diesen Stand nach dem tatsächlichen Einsatz unter Windows auch ausdrücklich bestätigt.

Damit wurde 0.7.6 für mich zu einer wichtigen Basis für die weitere Entwicklung.

Ein bestätigter Stand ist mehr wert als zehn neue Funktionen

Diese Erfahrung hat bei mir generell etwas verändert.

Früher ist man schnell versucht, nach einer funktionierenden Version sofort die nächste Funktion einzubauen.

Noch ein Menüpunkt.

Noch eine Ansicht.

Noch ein Spezialwerkzeug.

Heute sehe ich das kritischer.

Bei einem Programm, das direkt Binärdaten verändert, ist ein stabiler und tatsächlich getesteter Stand viel wertvoller als eine beeindruckende Funktionsliste auf einer Webseite.

Deshalb arbeite ich inzwischen sehr bewusst mit bestätigten Arbeitsständen.

Wenn eine Version auf meinem realen Windows-System funktioniert und geprüft wurde, ist sie ein Anker.

Von dort aus wird weitergearbeitet.

Nicht aus irgendeiner älteren Zwischenversion.

Nicht aus einer Datei, von der niemand mehr genau weiß, was darin verändert wurde.

Und schon gar nicht nach dem Prinzip:

„Das wird wahrscheinlich passen.“

Bei einem Hex-Editor möchte ich dieses Wort möglichst selten hören.

Auch beim Bauen der Software brauche ich klare Regeln

Während der Entwicklung habe ich meine Arbeitsweise ebenfalls immer stärker formalisiert.

Tests gehören für mich vor eine Auslieferung.

Nicht irgendwann danach.

Wenn ich ein ZIP erstelle, das als Prüfkandidat herausgeht, dann müssen die vorgesehenen internen Prüfungen vorher abgeschlossen sein.

Danach wird dieses Paket nicht mehr heimlich verändert oder durch zusätzliche Testläufe in einen anderen Zustand gebracht.

Das klingt vielleicht übertrieben.

Für mich ist es inzwischen eine Frage der Nachvollziehbarkeit.

Wenn ich eine bestimmte Datei teste, möchte ich auch genau diese Datei später beurteilen.

Nicht eine fast identische Version.

Nicht „eigentlich denselben Stand“.

Sondern exakt denselben.

Gerade bei Softwareprojekten habe ich gelernt, dass solche Unterschiede irgendwann sehr relevant werden können.

Ich möchte sehen, was passiert

Diese Haltung passt eigentlich perfekt zu einem Hex-Editor.

Ein Hex-Editor ist für mich das Gegenteil einer Blackbox.

Er zeigt Daten offen.

Er zeigt Positionen.

Er zeigt Werte.

Und genau diese Philosophie möchte ich auch im Programm selbst wiederfinden.

Wenn ich etwas ändere, möchte ich erkennen können, dass es geändert wurde.

Wenn ich irgendwohin springe, möchte ich wissen, an welcher Position ich mich befinde.

Wenn ich eine Datei speichere, muss klar sein, was passiert.

Ich brauche keine Oberfläche, die versucht, jede technische Information vor mir zu verstecken.

Aber ich möchte genauso wenig ein Programm, das kompliziert wirkt, nur um besonders professionell auszusehen.

Technische Software darf technisch sein.

Sie sollte nur logisch sein.

„Pro“ bedeutet für mich auch hier Anspruch und nicht Marketing

Wie bei anderen Sioni-Projekten verwende ich den Zusatz Pro nicht deshalb, weil ich künstlich eine abgespeckte Variante danebenstellen möchte.

Für mich beschreibt er den Anspruch.

Der Sioni Hex Editor Pro soll kein kleines Experiment bleiben, das irgendwann in irgendeinem Projektordner vergessen wird.

Ich möchte daraus ein ernstzunehmendes Windows-Werkzeug entwickeln.

Eines, das Dateien nicht nur anzeigen kann, sondern bei dem ich mich mit der Zeit darauf verlassen kann.

Ein Werkzeug, das übersichtlich bleibt.

Das kontrollierbar ist.

Das sich vorhersehbar verhält.

Und bei dem Stabilität nicht geopfert wird, nur weil eine neue Funktion auf einer Versionsliste gut aussehen würde.

Warum ich gerade solche Programme gern entwickle

An meinen Sioni-Projekten fällt mir inzwischen selbst etwas auf.

Mich reizen besonders Programme, bei denen der Benutzer Kontrolle zurückbekommt.

Beim Windows Toolkit geht es darum, Windows besser verwalten zu können.

Beim Content Blocker darum, selbst zu bestimmen, welche unerwünschten Verbindungen auf dem Rechner stattfinden dürfen.

Und beim Hex Editor geht es auf die elementarste Ebene:

Ich möchte meine eigenen Daten direkt sehen und bearbeiten können.

Ohne dass mir irgendeine Software vorher sagt, wie ich diese Datei zu interpretieren habe.

Das gefällt mir.

Ein Byte ist ein Byte.

FF bleibt FF.

Offset 00000100 bleibt Offset 00000100.

Es gibt daran nichts zu diskutieren.

Diese Eindeutigkeit hat etwas Angenehmes.

Der Sioni Hex Editor Pro ist noch nicht am Ende

Version 0.7.6 war für mich ein wichtiger Stand.

Aber natürlich ist das Projekt damit nicht abgeschlossen.

Es gibt noch genug Stellen, die weiter verbessert werden können. Funktionen können ausgebaut werden. Bedienabläufe können sauberer werden. Und mit jeder Erweiterung muss ich wieder darauf achten, dass bestehende Funktionen nicht beschädigt werden.

Genau darin liegt für mich inzwischen die eigentliche Entwicklungsarbeit.

Nicht möglichst schnell von Version 0.7 auf 1.0 zu kommen.

Sondern dafür zu sorgen, dass jede Version ihren Namen verdient.

Ich brauche keine Versionsnummer 1.0, nur weil sie besser aussieht.

Ich möchte irgendwann eine Version 1.0 haben, bei der ich sagen kann:

Ja. Jetzt ist es ein Werkzeug, dem ich meine Dateien anvertraue.

Das ist für mich der wesentlich bessere Maßstab.

Ein Blick unter die Oberfläche

Vielleicht ist das am Ende der Grund, warum ich einen Hex-Editor überhaupt interessant finde.

Unsere Computer versuchen ständig, Technik vor uns zu verstecken.

Normalerweise ist das auch sinnvoll.

Niemand möchte beim Öffnen eines Fotos erst JPEG-Strukturen analysieren oder beim Starten eines Programms einen PE-Header lesen.

Aber manchmal möchte ich eben doch unter diese Oberfläche schauen.

Dann möchte ich sehen, was wirklich da ist.

Byte für Byte.

Ohne Interpretation.

Ohne Umweg.

Genau dafür entwickle ich den Sioni Hex Editor Pro.

Nicht weil die Welt unbedingt noch einen weiteren Hex-Editor gebraucht hätte.

Sondern weil ich meinen eigenen haben wollte.

Einen, dessen Entwicklung ich kontrolliere.

Einen, dessen Verhalten ich nachvollziehen kann.

Und irgendwann hoffentlich einen, bei dem ich eine Binärdatei öffne und gar nicht mehr darüber nachdenke, ob ich ihm vertrauen kann.

Dann hat das Projekt sein eigentliches Ziel erreicht.

Sioni Hex Editor Pro Download: https://sioni.de/download.php?slug=sioni-hex-editor-pro