Archiv der Kategorie: Technik

Ich beim täglichen Bad in meinem Datenschatz

Zeit meines Lebens habe ich als selbsternannter Datenmessie beinahe schon leidenschaftlich Datenhamsterei betrieben, aber gleichzeitig nie ausreichend viele Gedanken an Backups verschwendet. Wenn man das weiß, erkennt man, dass ich in der großen Datenverlust-Lotterie unverschämt viel Glück gehabt habe. Schlimmer noch, die sogenannten Single Points of Failure sind mit den Jahren immer größer geworden, angesichts immer umfassenderer Datengräber, besonders in den letzten paar Jahren. Von meinen ersten 3,5 Zoll 720 Kbyte DD-Disketten in den 80er Jahren, über 700 MB CDRs in den 90ern, den 4,7 GB DVDRs in den 00er Jahren, bis zu den heutigen 16 TB HDDs, habe ich alle verfügbaren Datenträger immer sehr gerne mit meiner Sammlung vollgeschrieben. Sammlung deshalb, weil ich in weiser Voraussicht und in schöner Regelmäßigkeit die Inhalte auf den schwächelnden, alternden Datenträgern der vergangenen Generationen auf neuere übertragen habe, und die Datenmenge so kontinuierlich anstieg, die ich als meinen ganz eigenen Schatz betrachtet habe. Zuletzt lag der gesamte Krempel von unzähligen Disketten, einer vierstelligen Anzahl von CDs, einer dreistelligen Anzahl von DVDs, und einem ganzen Stapel älterer Festplatten auf nur noch drei zentralen Datenträgern. Also Daten aus über 30 Jahren Computernutzung – und für diese hatte ich keine (echten) Backups.

Selbstverständlich wusste ich als computeraffiner Mensch schon immer um die große Bedeutung von Backups. Früh brachte mein Vater mir bei, dass man von wichtigen Original-Disketten erst einmal (mindestens) eine Sicherheitskopie macht, und dann ausschließlich diese verwendet. Beim Verstehen half mir auch die Tatsache, dass Disketten oftmals relativ schnell die Grätsche machten. Datenverlust erlebte ich daher häufig, aber es war eben immer nur eine einzelne Diskette betroffen und nicht etwa ein gigantisches Archiv, das Jahrzehnte umfasste. Im Jahr 1995 unternahmen wir gemeinsam eine große Archivierungsaktion, bei der wir hunderte unserer Atari ST-Disketten in tagelanger Kleinarbeit auf DAT-Bändern sicherten. Die Aktion war ein voller Erfolg, die Backups benötigten wir jedoch nie. Bald darauf dominierte der PC unseren Alltag und der Siegeszug der optischen Datenträger begann. Selbstgebrannte CDs, selbstgebrannte DVDs, randvolle Festplatten, bald lag das Zeug kreuz und quer im Kinderzimmer herum. Die ISDN-Flatrate und die darauf folgende heimische DSL-Leitung machten es leicht, immer verrücktere, noch unnötigere Dinge herunterzuladen und “wegzubrennen”. Mit Hilfe von Tools wie GetRight, Go!Zilla oder FlashGet musste ich mir nicht einmal Mühe geben. Nur wenige Mausklicks und komplette Seitenarchive fanden auf mysteriöse Weise den Weg auf meine Festplatte – der Download lief dann über Nacht. Ob ich diese Dateien jemals anschauen würde? Wahrscheinlich nicht, aber das war zweitrangig.

Disketten wurden auf CDs übertragen, CDs auf DVDs, DVDs auf kleine Festplatten, und kleinere Festplatten auf immer größere Festplatten. Und heute sitze ich auf einem schätzungsweise 12 TB großen Berg an Daten, wie Dagobert in seinem Geldspeicher. Der Ausfall nur einer einzelnen meiner drei zentralen HDDs würde den Verlust von mindestens 15 Jahren an gesammelten Daten bedeuten. Für mich ein Katastrophenszenario, um das ich mich wirklich kümmern musste. Im Jahr 2012, als ich endlich die nötigen finanziellen Mittel besaß, besorgte ich mir einen 15 TB Netzwerkspeicher. Mit Hilfe von Robocopy und einem Batchskript synchronisierte ich sporadisch eine Auswahl der wichtigsten Ordner auf das verschlüsselte Netzwerkverzeichnis. Dies funktionierte gut, doch der Katastrophenfall trat auch in den folgenden Jahren nie ein, weshalb ich zu selbstsicher und faul wurde und meine Bemühungen reduzierte. Endlich im Jahr 2018 konnte ich mich dazu überwinden, alle meine Festplatten vollständig mit VeraCrypt zu verschlüsseln. Nun wurden Backups jedoch sogar noch viel wichtiger, denn wenn die Live-Entschlüsselung mit VeraCrypt plötzlich nicht mehr funktionierte, wäre das gleichbedeutend mit einem Festplattenausfall.

Doch die Technik gab mir erstaunlicherweise keinen Grund zur Sorge. Nach vier Jahren täglichen Gebrauchs arbeitet die Verschlüsselung immer noch einwandfrei. Im Jahr 2020 sattelte ich auf Linux um, und so lösten “rsync” und “Grsync” das bewährte Robocopy ab, und Ext4 löste NTFS ab. Erneut überraschte mich die ausgereifte Technik positiv, denn rsync konnte mühelos die mit Robocopy erstellten Backups aufgreifen und erneuern. Seit dem Sommer 2022 habe ich radikal damit begonnen, eine vernünftige Ordnung in meinem Archiv zu etablieren, habe dazu alte Strukturen aufgebrochen. Dies schuf erneut ungewohnte Herausforderungen, denn trotz meiner schlimmen Unordnung in meinem Dateisystem wusste ich bisher von den meisten Dingen nach all den Jahren wo sie lagen. Nun habe ich zwar Ordnung ins Chaos gebracht, doch muss ich paradoxerweise vieles nun tatsächlich erst suchen. Mit Hilfe von Grsync habe ich mir außerdem Jobs erstellt, die zwei komplette Festplatten auf das NAS spiegeln. Erstmals in meinem Leben bin ich nun in der Situation, dass meine wichtigsten Datengräber vollständig ausfallen könnten, ohne dass ich spürbaren Datenverlust befürchten müsste.

Nicht nur, dass auf meinem NAS vollständige Kopien der Festplatten vorliegen, auch bieten die Paritätsinformationen des RAIDs eine weitere Stufe der Redundanz, denn selbst wenn im NAS eine der Festplatten ausfällt, können die Daten noch verlustfrei wiederhergestellt werden. Und hier hört die Geschichte noch nicht auf: Mir wurde klar, dass meine Wohnung der letzte verbliebene Single Point of Failure darstellte. Ein Wohnungsbrand, Diebstahl oder ähnliches könnte weiterhin alle meine Daten auf einen Schlag vernichten. Die Lösung hierfür ist ein sogenanntes Off-Site-Backup, also eine weitere Kopie an einem weiter entfernten Ort. Und so sicherte ich den vollständigen Inhalt des Netzwerkspeichers auf einer verschlüsselten externen Festplatte und gab sie in vertrauenswürdige Hände zwecks Lagerung für den Katastrophentag X, der hoffentlich nie kommen möge.

Endlich habe ich ausreichende Ausfallsicherheit um mich wirklich sicher zu fühlen. Wenn morgen eine Festplatte quietscht und klackert und nur noch Fehlermeldungen ausspuckt, dann muss mich das nicht mehr beunruhigen: Alles ist noch da. Und ich bin dankbar, dass ich von Ausfällen verschont geblieben bin, als meine Infrastruktur noch ziemlich fahrlässigen “Mut zur Lücke” bewies. Es hätte nämlich auch ganz anders ausgehen können. Da das Thema Backups nun für mich geklärt wäre, kann ich den nächsten offenen Punkt angehen: Das Datenarchiv systematisch durchsuchen, aufräumen und objektiv nutzlosen Müll löschen. Aber Löschen bzw. Wegwerfen ist bekanntlich etwas, das jeden Messie an seine absoluten Schmerzgrenzen bringt.

Was bisher geschah: Einem erfolglosen Remake-Entwickler ist es trotz aller Widrigkeiten schließlich doch noch gelungen, alle Originaldateien von SPACOLA mit Hilfe eines Debuggers in einem Atari ST-Emulator zu extrahieren. Doch das sollte noch lange nicht das Ende seiner abenteuerlichen Reise in die Heimcomputer-Vergangenheit des späten 20. Jahrhunderts sein, denn die antiken Hieroglyphen in den Originaldaten mussten erst noch aufwändig von einem gewieften Software-Archäologen entziffert und entschlüsselt werden. Dies ist seine haarsträubende Geschichte.

Da saß ich nun also, mit einem ganzen Haufen alter, unlesbarer Sprite-Dateien aus dem Spiel SPACOLA, ohne irgendeinen Hinweis, was ich damit anfangen könnte, und welche sagenhaften Geheimnisse diese historischen Dokumente letztlich bargen. Lediglich aus den perfekt erhaltenen Dateinamen ließ sich ungefähr ersehen, welche Sprites genau darin zu finden seien. Mein geschätzter Mit-Atarianer und Blogleser Gerry hatte mich glücklicherweise bereits Jahre zuvor mit einem wichtigen Zeitschriftenartikel aus der guten alten „ST Computer“ versorgt, in dem Meinolf Schneider höchstpersönlich im Jahr 1990 über die Entwicklung von Bolo und Esprit berichtet. Dieser Artikel erwies sich als pures Gold und enthielt so einige hochinteressante Einblicke und Fakten, die mir als Entwickler wiederum bedeutende Implementierungsdetails verrieten. Unter anderem beschrieb Meinolf darin einzelne Aspekte seines eigenen Sprite-Formats, den sogenannten „Shapelists“. Wie das Format aufgebaut war, war daraus zwar leider noch lange nicht ersichtlich, aber dafür andere wichtige Eigenarten, die später von Vorteil sein sollten.

Der Hex-Editor HxD zeigt eine SHL-Datei

Das Hilfsmittel Nummer eins war wiederum der Hex-Editor, mit dem ich mir die Dateien Byte für Byte quasi unter der Lupe ansehen konnte. Bei genauerem Hinsehen erkannte ich, dass diese Dateien immer aus mehreren „Blöcken“ bzw. Abschnitten bestehen, nämlich aus mindestens zwei, so wie im Falle der kleinsten Datei „SPI_MINE.SHL“. Diese spezielle Datei sollte mir schließlich zur Lösung des Rätsels dienen, da ich hierüber zum Glück ausreichend wusste. Da sie nachweislich aus genau zwei Blöcken besteht, wusste ich nun ziemlich sicher, dass nur die zwei einzelnen Sprites der beiden Sprengminen des Originals darin enthalten sein konnten. Ich wusste wie diese Sprites genau aussehen, wie groß sie sind, und am allerwichtigsten, dass diese Sprites zu einem großen Teil symmetrisch sind. Meine Chance bestand also darin, in den Shapelists nach genau diesen Symmetrien Ausschau zu halten. Würde ich eine Symmetrie im Bytemuster der Datei wiedererkennen, hätte ich schon einen äußerst wichtigen Ansatz gefunden.

Als ich einige Hexwerte (in Big Endian Bytereihenfolge) in der Shapelist in Dezimal umgerechnet hatte, fand ich so unter anderem die Dateigröße und die einzelnen Spritegrößen wieder, und so konnte ich sogar ausmachen, welches Sprite in welchem Block gespeichert ist. Ich konzentrierte mich also auf den kleineren ersten Block. Es dauerte nicht lange und ich hatte einen Teil ausgemacht, der symmetrisch aussah, und so folgerte ich, dass genau hier die Pixelinformationen begraben sein mussten. Bei einer Monochromgrafik war es zwar durchaus naheliegend, aber ich brauchte trotzdem einige Minuten, um darauf zu kommen, dass hier jedes Byte genau eine Reihe von 8 Pixeln darstellen konnte. Mit Hilfe des Windows-Taschenrechners ließ ich mir die Hex-Werte binär anzeigen, und so malte ich die gesetzten Bits auf ein Pixelgrid. Tatsächlich erkannte ich schon kurz darauf etwas, das zumindest teilweise nach den invertierten Umrissen der linken Hälfte des erwarteten Minen-Sprites aussah. Das war für mich erneut ein entscheidender Durchbruch. Ab hier war ich sicher, ich könne die Shapelists lesen.

In der Folge stellten sich mir bei der Analyse einige wichtige Merkmale des Dateiformats heraus: Die Sprites waren immer kodiert in „Scheibchen“ zu je 8 Pixeln Breite mit variabler Höhe. Zudem gab es pro Sprite meist zwei Schichten: Einen Hintergrund mit Transparenzinformationen, und einen Vordergrund. Manchmal gab es auch nur eine Schicht ohne Transparenz. Anschließend begann der nächste Block, der das nächste Sprite enthielt. Große Teile der Datei verstand ich bis dahin noch nicht, daher entschied ich mich zunächst, diese zu ignorieren, denn ich begann gleichzeitig damit, einen Konverter zu entwickeln, der SHL-Dateien laden und diese in ein anderes Grafikformat übersetzen konnte. Nach ein oder zwei Stunden hatte ich meinen Code schon soweit, dass er die beiden Minen aus der Originaldatei perfekt auf dem Bildschirm anzeigte. Ich wähnte mich bereits am Ziel, als ich zur Kontrolle eine andere SHL-Datei laden wollte, und der Konverter mit diversen Fehlern abbrach. Mit dem Format dieser Datei konnte er nichts anfangen, und so musste ich erneut mit dem Hex-Editor ran.

Ein monochromes Minen-Sprite aus der Shapelist mit Transparenzdaten in GIMP geladen

Ich entdeckte, dass Shapelists bisweilen mehrere „Versionen“ desselben Sprites beinhalteten, aber den Grund kannte ich nicht, bis sich herausstellte, dass jede folgende Sprite-Version im Grunde nur um jeweils einen Pixel nach rechts verschoben war. Die Lösung lieferte besagter ST-Computer-Artikel, in dem Meinolf erläuterte, dass er alle acht Möglichkeiten zur horizontalen Positionierung einer Grafik vorberechnete. Dies war nötig, weil er die Sprites direkt in den Grafikspeicher des Bildschirms kopierte, was natürlich nur in ganzen Bytes möglich war. Er schreibt hierzu genauer: „Will man die Figur auf eine beliebige horizontale Position darstellen, müssen die einzelnen Bits, die ja Bildpunkte repräsentierten, innerhalb eines Bytes verschoben werden. Und dies kann bei vielen zu zeichnenden Figuren für eine 72Hz-Animation zu langwierig sein.„. Diese bit-geshifteten Versionen sind in den Shapelists also allesamt enthalten. Ich entdeckte außerdem, dass die Shapelists im Header immer alle Offsets enthalten, die verwendet werden können, um direkt zum Beginn eines Blocks zu springen.

Nachdem ich meinen Konverter angepasst hatte und er flexibler mit dem Shapelist-Format umgehen konnte, erlaubte mir das bereits, einige Dutzend SHL-Dateien fehlerfrei zu laden, während so manche andere Datei jedoch noch Darstellungsprobleme hatte. Auch dies konnte ich wiederum korrigieren, so dass ich das SHL-Format dadurch immer besser zu verstehen lernte. Am Ende war mein Konverter problemlos in der Lage, alle Shapelists aus Bolo, Esprit, OXYD und Spacola zu laden. Die Shapelists aus OXYD 2 könnte er vermutlich auch konvertieren, aber diese müsste ich dazu natürlich erst mühsam aus dem Spiel holen. Eine letzte Erkenntnis konnte ich schließlich noch gewinnen: Zu jedem Sprite sind in der Shapelist die genauen horizontalen und vertikalen Pixeloffsets gespeichert, also die Zahlenwerte, um wieviele Pixel das Sprite relativ zur Position des entsprechenden Spielobjekts verschoben gezeichnet werden soll – im einfachsten Fall muss man das Sprite nämlich über dem Objekt zentrieren.

Ein Zusammenschnitt mehrerer konvertierter Shapelist-Inhalte aus Bolo (1987), Esprit (1989), und SPACOLA (1991)

Besagten Shapelist-Konverter habe ich mittlerweile nativ in das Remake SPACOLA ECLIPSE integriert, und das Spiel lädt folglich nicht nur die Original-Sounddateien, sondern inzwischen auch schon einige der Original-Spritedateien. Die Transition hin zu Shapelists ist aktuell noch im Gange und wird auch noch einige Monate andauern, aber der Vorteil ist für mich eindeutig: Absolute Originaltreue ohne unnötige Kompromisse. Durch die Verwendung von Shapelists werden all meine bisherigen Unsicherheiten verschwinden, ob ich dieses oder jenes Sprite auch wirklich pixelgenau und fehlerfrei gezeichnet habe, und ich kann meine geringe Aufmerksamkeit wieder anderen, deutlich wichtigeren Dingen widmen. Zum Beispiel dem Spiel.

Mit der Programmierung meines kleinen SPACOLA-Remakes habe ich übrigens heute vor exakt 10 Jahren begonnen. In dieser Zeit wuchs das Hobby-Projekt auf 54.300 Codezeilen in 326 Quelldateien an, und umfasst zusätzlich knapp 1500 Grafikdateien und 64 Audiodateien. Für volle 10 Jahre Entwicklungszeit ist das wahrlich nicht so viel, aber schneller bekomme ich es nicht hin. Ich habe eben mein ganz eigenes Tempo, das sowohl von motivierten als auch von faulen Phasen mitbestimmt wird. Dafür steckt trotzdem eine ganze Menge Herzblut, Schweiß und Erfahrung in meinem Werk. Wann das Spiel fertig oder wenigstens mal spielbar sein wird, steht weiterhin in den Sternen. Aber wer meine vielen kleinen Fortschritte bis heute fleißig verfolgt hat, und die Hoffnung immer noch nicht aufgegeben hat, den werde ich vielleicht in den kommenden Wochen doch noch ein bisschen überraschen können.

To be concluded…

Eines meiner heiligsten Prinzipien bei der Entwicklung meines Remakes von Spacola ist Authentizität. In dieser Hinsicht bin ich leider ein Perfektionist. Zumindest so weit es mir technisch möglich ist, versuche ich mich immer zu 100% an den Originaldateien und an Originalmechanismen zu orientieren, und ich weiche nur davon ab, wenn es absolut nötig, wirklich sinnvoll, oder mit meinem Know-How sonst nicht machbar ist. Zu Beginn der Entwicklung konnte ich lediglich rein aus der Beobachtung nachimplementieren, ich musste notgedrungen tausende selbsterstellte Screenshots verarbeiten und Tonaufnahmen aus dem Emulator aufnehmen. Das Ergebnis war natürlich oft nah am Original dran, aber für mich nie authentisch genug. Glücklicherweise habe ich mittlerweile so einige Fortschritte gemacht, die mir meine Mission deutlich erleichtern. In den vergangenen Wochen habe ich einen äußerst wichtigen Meilenstein bei der Analyse des Originalspiels erreicht. Um verstehen zu können, was mir da konkret gelungen ist, muss ich etwas weiter ausholen. Daher hier ein kleiner technischer Exkurs in meine Welt.

Schon wie zuvor im 1990 veröffentlichten OXYD hat Spacola einen eigenen Kopierschutz in Form eines Dongles (das Codebuch). Im Gegensatz dazu sind die Codes allerdings mittlerweile ein integraler Bestandteil des Gameplays geworden, und nicht mehr nur Steine, die den Weg blockieren. Den Kopierschutz schlicht auszubauen hätte im einfachsten Fall bedeutet, direkt das Gameplay von Spacola zu verändern, die Siegbedingungen im Spiel zu entfernen; das Spiel wäre quasi sinnlos geworden. (Spoiler-Warnung: Dennoch ist einem findigen Entwickler vor wenigen Jahren auch das schon auf intelligente Weise gelungen.) Weiterhin bringt das Spiel jedoch noch einen raffinierten Crackschutz mit, um zu verhindern, dass der Kopierschutz überhaupt angegriffen werden kann. Die Daten der Dongleware-Spiele bis einschließlich OXYD lagen noch offen da, wenn auch in proprietären Dateiformaten (SHL, IMG, CMP, PAC), mit denen man so jedenfalls nichts anfangen konnte, bis auf die Sounddateien, die einfach im Rohformat vorhanden waren. Da OXYD schließlich geknackt werden konnte (und auch das Codebuch trotz absichtlich schlechtem Farbkontrast kopiert wurde), wurden die Daten in Spacola inzwischen gegen unbefugte Zugriffe geschützt. Dies macht es natürlich für interessierte Remake-Entwickler wie mich deutlich schwieriger, die eigentlich nicht den Kopierschutz entfernen wollen, sondern Einblick in die Spieldaten brauchen.

Wie sieht dieser Crackschutz nun eigentlich aus? Bei Spacola lagen weder die Spieldaten noch die ausführbare Datei in lesbarer Form auf der Diskette vor. Auf dieser gab es lediglich ein großes mit PFXPak erstelltes, selbstextrahierendes Programm, das das Spiel zur Laufzeit ausschließlich in den Arbeitsspeicher entpackt und dort ausführt. Laut PFXPak-Dokumentation bringt das nicht nur den Vorteil, dass man mehr nutzbaren Netto-Speicherplatz auf der Diskette hat, sondern auch Performance-Verbesserungen, da weniger Daten über das langsame Diskettenlaufwerk geladen werden müssen. Außerdem werden zum einen die einzelnen Dateien immer erst dann entpackt, sobald sie vom Programm referenziert, also im Spiel benötigt werden, zum anderen werden die Dateien auch gleich noch dekodiert, da sie teilweise nur in verschlüsselter Form vorliegen. Und selbst das ist noch nicht alles: Sogar wer glaubt, es sei ihm gelungen, das integrierte LHarc-Archiv des Entpackers aus der Datei zu extrahieren, und dieses von Hand entpacken will, erhält leider kein Spacola, sondern nur ein Programm, das eine kleine Grußbotschaft an den Hacker auf dem Bildschirm anzeigt und gleichzeitig die Festplatte vollmüllt, sofern eine angeschlossen ist. Ja, man musste sich als Spieleentwickler wohl irgendwie gegen Raubkopierer zur Wehr setzen. Der wenig freundliche Inhalt besagter Grußbotschaft wurde mit dem ersten und wahrscheinlich einzigen Spacola-Patch einige Wochen später zensiert.

Wer sich mit Atari ST-Emulation intensiver befasst, weiß, dass es mit dem STeem Debugger ein äußerst mächtiges Debugging-Werkzeug gibt, das genutzt werden kann, um sämtliche ST-Software zu analysieren und zu modifizieren. Fürs Reverse-Engineering ist ein brauchbarer Debugger quasi unverzichtbar. Als ich vor etlichen Jahren zum ersten Mal die Oberfläche des Debuggers öffnete, war ich wie erschlagen von den endlosen Möglichkeiten, die sich mir hier boten. Und mir war sofort klar, dass ich nicht die nötigen Fähigkeiten hatte, um hier irgendetwas zu bewegen, denn natürlich setzt so ein Debugger unter anderem auch ein tieferes Verständnis der Hardware voraus. In meinem Studium hatte ich wenigstens zwei Semester Rechnertechnik, in welchen ich die Grundlagen von 68K-Assembly lernte und auch sehr kleine Programme schrieb. Dies brachte mich zumindest theoretisch in die Lage, die Funktionen des Debuggers rudimentär zu verstehen. Doch als ich mich damals spaßeshalber in ein laufendes Programm einklinkte, Schritt für Schritt durch den Programmcode bewegte, und die Hieroglyphen verstehen wollte, die der Prozessor da ausführte, hörte der Spaß irgendwie auf. Mein Verstand konnte zwar mühsam und sehr langsam erfassen, was dort in jeder Zeile ausgeführt wurde, aber mir fehlte jeglicher Durchblick dafür, warum es ausgeführt wurde, an welcher Aufgabe der Programmcode gerade arbeitete. Es gab keinen Kontext. Es ist ein bisschen so als würde ich mir unter einem Mikroskop nacheinander die einzelnen Holzfasern genauer anschauen, um dadurch herausfinden zu wollen, worum es in dem Buch geht. Dabei könnte ich nicht einmal erkennen, welchen Buchstaben ich mir da gerade ansehe.

Der STeem Debugger mit laufendem Spacola beim Ladevorgang

Aber die ersten kleinen Fortschritte ermutigten mich, den Kopf nicht hängen zu lassen. Der Memory-Browser des Debuggers bietet zum Beispiel eine Suchfunktion und erlaubt das Editieren des Speichers zur Laufzeit. So kann man Texte in den Programmen finden und ersetzen, was nette Spielereien ermöglicht. Eine andere nützliche Funktion ist der Speicherdump, der es erlaubt, den kompletten Arbeitsspeicher in eine Datei zu schreiben. Mit diesem wertvollen Hilfsmittel hatte ich endlich einen ersten direkten Zugang zu vielen Spielinhalten, wenn es auch noch lange nicht lückenlos war. Im Audiobearbeitungsprogramm Audacity konnte ich dieses Speicherabbild als Rohdaten einlesen und die Sounds von Spacola hörbar machen und grob „ausschneiden“, was mir wirklich enorm half. Eines meiner Probleme mit dieser Methode war jedoch, dass ich nie wusste, wo eine Datei beginnt oder aufhört. Die Dateien waren nicht byteperfekt. Und jahrelang waren die Audiodateien leider die einzigen, auf die ich dadurch Zugriff erlangen konnte. Ich wollte aber unbedingt auch an die Grafikdateien herankommen. Später gelang es mir mit großem Aufwand, das „Rentenbescheid“-Bild, das nach gewonnenem Spiel als Urkunde zum Ausdrucken verwendet wird, zu extrahieren. Die Monochrom-Rohdaten habe ich unter anderem durch einen emulierten Drucker als virtuelle Hardcopy in eine Datei schreiben lassen, mühsam rekonstruiert und mit STAD v1.3 laden können. Dadurch konnte ich einen Screenshot anfertigen. Dies war ein weiterer Motivationsschub, der mich daran glauben ließ, irgendwann alles zu schaffen.

Ende 2018 begann ich erneut damit, das Originalspiel aufwändig Schritt für Schritt im Debugger zu beobachten. Ich hatte erst angefangen, mich mit den Breakpoints und den Read- und Write-Monitors vertraut zu machen, und war überzeugt davon, ich könnte die entpackten Dateien abfangen, während sie gerade in den Arbeitsspeicher geschrieben werden. Im selbstextrahierenden Programm gibt es glücklicherweise eine Dateitabelle, die Dateinamen, Dateigrößen und Byte-Offsets enthält. Dies war letztlich der Schlüssel zum Erfolg. Jemand mit mehr Erfahrung im Reverse-Engineering hätte natürlich sofort gewusst, was hier zu tun ist. Ich musste es erst durch unzählige Fehlversuche und Rückschläge lernen. Am Ende dauerte es bis zum Frühjahr 2020, dann hatte ich endlich einen Plan. Durch das geschickte Setzen der Read- und Write-Monitors und Zurückverfolgen der Lese- und Schreibzugriffe, konnte ich genau den Teil des Codes ausmachen, der direkt für das Entpacken aller Dateien zuständig ist. Anschließend musste ich nur noch den Program Counter, die Schleifendurchläufe und die Adress- und Datenregister überwachen, dadurch konnte ich sehen, welche Datei gerade verarbeitet wurde, wo die Daten gelesen und wohin sie geschrieben wurden, und wann der Schreibvorgang exakt beendet ist. Ich führte Notizen darüber, welche Dateien ich dadurch erhalten konnte und ob sie die richtige Größe haben, um ihre Richtigkeit zu verifizieren.

Das Debugging beim Entpacken der Dateien

Das Modifizieren der Dateitabelle im Programm erlaubte es mir sogar, den Entpacker dazu zu bringen, die „falschen“ Dateien zu entpacken, darunter auch eine Sounddatei, die offenbar gar nicht referenziert, also im Spiel selbst niemals verwendet wird. Dies war immens hilfreich und verkürzte die weitere Zeit, um auch die letzten verbliebenen Dateien zu bekommen. Später bemerkte ich noch, dass Spacola leider wieder mal schlauer war als ich: Viele Sounddateien wurden im Spiel komprimiert, d.h. in der Größe reduziert, andere Sounddateien wurden aber nur in irgendeiner Weise kodiert, also bei gleicher Dateigröße unlesbar gemacht. Hierzu musste ich einen weiteren Codeabschnitt ausfindig machen, der Sounddateien entschlüsselt. Die zentralen Breakpoints waren mir in der Folge heilig, ich habe sie akribisch notiert und verwendet, um nacheinander alle 104 Dateien mühsam zu entpacken, aus dem Memory-Browser zu extrahieren und mittels HEX-Editor byte-perfekt auf die Festplatte zu schreiben. Das Ergebnis sind 557 KByte an Rohdateien, die exakt so im Originalspiel verwendet werden: 50 Sounddateien, 48 Sprite-Dateien, vier Bilddateien, eine Textdatei und eine IMG-Datei. Als Bonus erhielt ich auch die ungeschützte SPACOLA.PRG, also die ausführbare Datei ohne den Packer. Diese lässt sich auch starten und lädt sogar das Titelbild, anschließend hängt sie sich leider auf. Allerdings habe ich mich entschlossen, dieses Problem nicht weiter zu verfolgen, da es sich wahrscheinlich nicht lohnt.

Für mich war das bis hierhin schon ein großartiger Durchbruch. Dies war ein Thema, das mir noch Jahre zuvor wie eine unlösbare Aufgabe erschien, und plötzlich liegen mir alle Daten offen, um sie endlich in unberührter Form in meinem Remake zu verwenden. Aber da war natürlich weiterhin diese eine nicht ganz unbedeutende Hürde: Das selbstentwickelte Dateiformat der Sprite-Dateien ist leider unbekannt, undokumentiert und es gibt kein öffentlich verfügbares Programm, das die Dateien lesen könnte. Scheint so, als sei ich in einer Sackgasse gelandet.

Und in der nächsten Folge lesen Sie: Die Sprites von Spacola.

Ein kleiner Schritt für einen Nerd, ein weiterer Meilenstein auf meinem Pfad in die eigene Datensouveränität: Alle meine Festplatten sind heute vollständig verschlüsselt. Ja, irgendwann habe ich es einfach gewagt, Veracrypt installiert und damit begonnen, einen Datenträger nach dem anderen zu verschlüsseln. Zunächst vorsichtshalber nur bei Festplatten, die komplett redundant gesichert sind, um es anzutesten. Nach den ersten Monaten ohne Schwierigkeiten dann schließlich durchgängig bei allen anderen Festplatten. Ich habe bei dem Thema zuvor lange mit mir gerungen, und den Grund dafür werde ich in den folgenden Absätzen gerne kurz anreißen, denn es sind Dinge, die man hierzu unbedingt wissen sollte.

Schon damals im Studium im Jahr 2007 habe ich mit dem Veracrypt-„Vorgänger“ Truecrypt ein wenig experimentiert. So erstellte ich mehrere verschlüsselte Datencontainer auf meiner Festplatte, mit einem sicheren Passwort versehen, und kopierte einige Dateien hinein. Die Container konnten schon damals relativ einfach immer bei Bedarf wie ein eigenes Laufwerk unter Windows gemountet werden, was mir grundsätzlich sehr gefiel. Erstellt habe ich sie in Größen von 1 bis 2 GB und mit allerlei Dateien gefüttert, hauptsächlich Spiele und anderen Kram, den ich ohnehin auslagern wollte. Nichts Wichtiges zum Glück. Das hat eine Weile nämlich ganz gut funktioniert. Bis der größte der Container ganz plötzlich von heute auf morgen das Passwort nicht mehr akzeptiert hat. Eine Internetsuche zu dem Problem brachte mich auf die Idee, das Headerbackup, das man zuvor angelegt hatte, wieder auf den Container einzuspielen. Das Einspielen gelang, aber das Passwort nahm Truecrypt im Anschluss trotzdem nicht an. Eine längere Internetsuche brachte keine weitere rettende Idee. Die Dateien waren natürlich alle noch da, aber ich kam nicht mehr dran, und so verabschiedete ich mich bald davon. Das Experiment war gescheitert. Heute, 12 lange Jahre später, kann ich auch nicht mehr mit hundertprozentiger Gewissheit sagen, ob ich mich vielleicht mit dem Passwort vertan hatte, oder ob der Container doch irgendwie beschädigt wurde. Aus Erfahrung weiß ich beispielsweise, dass Scandisk/Checkdisk von Windows bei mir auch gerne mal große Dateien kaputtrepariert hat. Wäre also nicht so abwegig gewesen.

Ich lernte damals, von Truecrypt doch besser Abstand zu nehmen, denn man kann sich leicht daran die Finger verbrennen. Auch heute, wenn man in Internetforen nach Problemen mit Truecrypt/Veracrypt sucht, wird man überhäuft von Meldungen über plötzlichen Datenverlust durch Fehlfunktionen und verschlüsselte Container, die sich nicht mehr öffnen lassen bzw. das Passwort einfach nicht mehr akzeptieren. Viele verzweifelte oder verärgerte Hilferufe von Nutzern, die kein Backup haben und jemanden suchen, der ihre Daten retten kann – zur Not sogar gegen viel Geld. Offenbar ist dieses Thema selbst heute noch mit großer Vorsicht zu genießen, denn wird der Container durch einen Schreibfehler beschädigt, kann es im ungünstigsten Fall passieren, dass die Gesamtheit der Dateien sich in Sekundenschnelle in unlesbaren Datenmüll verwandelt. Bei einer unverschlüsselten Festplatte hätte man hier zumindest noch die Chance, alle unbeschädigten Daten zu extrahieren. Eine Festplattenverschlüsselung bietet ein ausgezeichnetes Maß an Schutz der Daten vor fremdem Zugriff, aber macht die Datenrettung bei einem Festplattendefekt leider gleichzeitig extrem schwer, wenn nicht sogar unmöglich. Ein großer Vorteil also, der im Katastrophenfall zu einem großen Nachteil werden kann.

Festplattenverschlüsselung taugt also gar nicht für den Alltag? Viel zu unsicher? Ganz im Gegenteil! Jeder, der mit dem Gedanken spielt, seine Dateien zu verschlüsseln, sollte sich natürlich darüber im Klaren sein, dass es unverzichtbare und verzichtbare Daten gibt. Unverzichtbares wird bei mir redundant an zwei Orten gleichzeitig gelagert und verschlüsselt. Fällt ein Datenmedium aus, habe ich immer ein Backup. Wer es sich leisten kann, setzt sogar auf mehrfache Redundanz, im Idealfall räumlich getrennt. Verzichtbares kann ich logischerweise auch ohne Backup verschlüsseln. Fällt dieses Datenmedium aus, ist der Tag womöglich ruiniert, aber ich breche nicht gleich in Tränen aus. Pech gehabt, das Leben geht weiter. So handhabe ich das im Moment. Alles wird verschlüsselt, aber nur das Wichtigste wird als Backup vorgehalten. Ein bisschen Risiko ist immer im Spiel.

Wie sieht meine bisherige Erfahrung nach mehreren Monaten mit Festplattenverschlüsselung aus? Derzeit habe ich 16 vollständig verschlüsselte Festplatten im Einsatz. Davon 5 im NAS, 2 intern, und 9 extern. Das entspricht insgesamt 105 Brutto-Terabyte (rein nach Herstellerangaben). Bislang sind keine Ausfälle oder Fehler zu beklagen. Selbst das mehrfache harte „Ausstöpseln“ von USB-Datenträgern durch ein Versagen der Stromversorgung hat Veracrypt gut überstanden, obwohl es jedes Mal eine Warnmeldung ausgegeben hat. Eine Schrecksekunde gab es, als die größte Festplatte sich irgendwann nicht mehr mounten ließ. Traumatisierende Flashbacks an den großen Datenverlust von 2007 geisterten mir sofort im Kopf herum. Nach einem Neustart und einem doch noch erfolgreichen Einhängen der Platte dämmerte es mir, dass ich wohl versehentlich unter Veracrypt die falsche Partition auf dem richtigen Laufwerk mounten wollte. Es handelte sich offenbar um diese komische unzugängliche Recovery-Partition auf WD-Festplatten, die mir zur Auswahl angezeigt wurde.

Keine Probleme also bei mehr als einem Dutzend verschlüsselter Festplatten. Keine schlechte Leistung. Also alles gut? Nunja, ich rechne noch mit dem ersten Ausfall im Lauf der Zeit. Vermutlich früher als mir lieb ist. Und dann hoffe ich, dass es eine der Festplatten trifft, die von mir regelmäßig gespiegelt werden. Eine gute Datenpflege und -strategie ist dabei natürlich unerlässlich, wenn man mit sovielen Datenträgern hantiert. Veracrypt macht es mir leicht, indem es beim Anschließen einer Festplatte sofort ein Password-Prompt einblendet und unaufgefordert das Einhängen übernimmt. Bis jetzt bin ich wirklich beeindruckt wie gut es funktioniert, und es beruhigt mich sehr. Wenn ich bisher alte Festplatten entsorgen wollte, musste ich zuvor daran denken, alles komplett zu formatieren, oder falls nicht mehr möglich, die Festplatte mechanisch zu zerstören. Der Inhalt einer verschlüsselten Festplatte ist dagegen völlig unbrauchbar für andere Personen, sie enthält quasi nur unverständliches Rauschen. Ich könnte also jede meiner Festplatten einer wildfremden Person in die Hand drücken, und meine Daten wären trotzdem sicher. Viel zu wenige Menschen machen sich Gedanken über den Inhalt ihrer weggeworfenen Festplatten, und was man davon noch problemlos rekonstruieren könnte.

Aus meiner Sicht war es mittlerweile wirklich an der Zeit, künftig ausschließlich mit verschlüsselten Daten zu arbeiten. Festplattenverschlüsselung ist heute absolut kein Hexenwerk mehr, die Möglichkeiten besser als je zuvor, der Aufwand hält sich stark in Grenzen. Ja, man muss beim Booten mehr Passwörter eingeben (oder Keyfiles angeben), aber die Vorteile überwiegen die Nachteile bei weitem. Es ist fahrlässig, seine Daten offen herumliegen zu lassen. Davon wird mindestens jeder ein Lied singen können, dessen Laptop einmal gestohlen wurde, oder der bereits Opfer einer Hausdurchsuchung geworden ist. Besser kein Risiko eingehen. Aber kostet das Lesen und Schreiben auf eine verschlüsselte Festplatte denn nicht viel mehr Performance? Nein, überhaupt nicht, denn AES-Verschlüsselung wird hardwareseitig in Echtzeit unterstützt. Es macht keinen Unterschied. Und mit Veracrypt bekommt man eine leistungsfähige, sichere und offene Softwarelösung, die zudem auch nichts kostet.

Ich kann also jetzt endlich guten Gewissens einen weiteren Punkt auf meiner Datenschutz-Checkliste streichen und werde mich hoffentlich im kommenden Jahr schon um den nächsten kümmern.

Ach, ich habe die letzten Monate so wenige Beiträge geschrieben, dass ich jetzt der Meinung bin, das kompensieren zu müssen, indem ich über echt uninteressante Dinge aus meinem Leben berichte. Aber vielleicht gibt es ja jemanden, der dieselben Gedanken und Probleme wie ich hat. Also dann, kopfüber in das nächste Blog-Thema. In der heutigen Folge: Was ich mir zuletzt angeschafft habe und mein Erfahrungsbericht dazu.

Ich bin ein Mensch, der am PC gerne sehr viele Fenster offen hat. Gleichzeitig! Damit ich alles im Blick haben kann. Das ist beispielsweise sinnvoll, wenn man ständig zwischen Instant Messenger, Dateibrowser, Webbrowser, E-Mail-Programm, Emulator, Texteditor, Entwicklungsumgebung und Grafikbearbeitungsprogramm hin- und herwechseln muss. Natürlich könnte ich auch in der Taskleiste immer umschalten, oder Alt+Tab bemühen (und das mache ich meistens auch so), aber es ist praktischer, wenn ich das erst gar nicht muss. Es ist eben viel komfortabler, wenn ich meine Arbeitsgeräte und Werkzeuge immer alle direkt griffbereit vor mir liegen habe, und nicht ständig in die untere Schublade greifen muss, um zwischen Stift und Schere zu wechseln.

Schon vor dreieinhalb Jahren habe ich mir privat erstmals eine Zwei-Monitor-Konfiguration aufgebaut, die mir völlig neue Möglichkeiten eröffnet hat. Damit kann man etwa mehrere Anwendungen auf verschiedene Monitore aufteilen, und selbst Vollbildanwendungen sind jetzt kein Grund mehr, nicht doch mehrere Programme im Blick zu behalten. Man könnte auf dem linken Monitor etwas im Vollbildmodus spielen, während auf dem rechten Monitor irgendeine Webseite mit hilfreichen Tipps geöffnet ist. Oder man könnte auf dem linken Monitor einen unglaublich wichtigen Artikel für einen bedeutenden Blog schreiben, während auf dem rechten Monitor gleichzeitig irgendein spannender Stream läuft. Und dann … öh … Oh, sorry, ich war gerade ein wenig abgelenkt. Naja, beim Arbeiten sollte man vielleicht doch besser für eine ablenkungsfreie Umgebung sorgen. Weniger ist da oft mehr. Aber in den meisten Fällen bin ich schon ganz glücklich damit, viel Desktopfläche zu haben.

Beim Thema Desktopfläche habe ich kürzlich wieder einen gewaltigen Sprung gemacht. Meine neueste technische Anschaffung ist ein Business-Monitor mit 28 Zoll Bilddiagonale, der den alten 27er nochmals leicht überbietet. Aber der wichtigste Punkt ist, dass es sich um einen UHD-Monitor mit der wahnwitzigen Auflösung von 3840×2160 handelt, ergo „4K“. Damit kann ich endlich 4K-Filmmaterial in nativer Auflösung bestaunen, ohne Skalierung. Mit dem neuen Monsterdisplay auf meinem Schreibtisch wurde dann leider mein alter, tapferer 24 Zoll-Monitor mit der 1920×1200-Auflösung in den Ruhestand geschickt. Neun Jahre lang hat das kleine Kerlchen alles mitgemacht, und selbst jetzt ist er noch gut in Form, obwohl er vor einigen Jahren auf einer Autofahrt einen dicken Kratzer auf der Mattscheibe abbekommen hat. Aber als Unterwegs-Monitor für kleine LAN-Partys bleibt er mir noch erhalten, denn dann spare ich mir das viele Ab- und Wiederaufbauen meiner Monitore.

Wo war ich? Achja… Wie ist das Leben mit so einer exorbitant hohen Desktopauflösung? Auf der einen Seite schon echt klasse, weil man damit wirklich viel Raum für alle seine Fenster hat. Man muss bedenken, der Monitor hat genug Platz für vier Full-HD-Videos, in jeder Ecke eins. Auf der anderen Seite ist es jedoch nicht immer ganz einfach. Ich sollte zumindest kurz auf den größten Nachteil eingehen: Es ist alles verdammt klein. Ich schätze mal, ein 28 Zoll-Monitor ist wirklich die absolute Untergrenze, ab der 4K funktioniert. Manchmal ertappe ich mich dabei, wie ich mit den Augen näher zum Bildschirm gehe, um kleine Texte entziffern zu können. Man gewöhnt sich aber recht schnell an die Mini-Bildschirmelemente, muss beim Klicken ein wenig besser zielen und auch mehr mit der Maus rudern, vor allem wenn man von der linken Kante des linken Monitors bis zur rechten Kante des rechten Monitors fahren will. Das sind bei mir zusammen immerhin 6400 Pixel Breite.

Aber das ist alles noch kein großes Problem. Bislang normalgroße Schriften sind neuerdings eben kleine Schriften. Und bei den kleinen Schriften muss man ab jetzt genauer hingucken. Natürlich kann man das Betriebssystem auch so einstellen, dass es alle Fensterelemente, Icons und Texte automatisch hochskaliert – aber wozu dann überhaupt 4K? Dann hätte ich einfach bei meinem alten Monitor bleiben können und noch eine Menge Geld gespart. Natürlich will ich den neu gewonnenen Platz auch nutzen, und nicht gleich dadurch wieder vergeuden, indem ich alles auf dem Bildschirm größer mache. Bilddateien, die mir noch vor 15 Jahren bequem als Windows-Wallpaper dienlich waren, sind mit dem neuen Monitor nur noch unwesentlich mehr als Thumbnails. Der einsame Browser im abgebildeten Screenshot ist übrigens schon geringfügig größer als Full-HD.

Meine größte Sorge vor meiner Anschaffung war ursprünglich: Packt meine Grafikkarte überhaupt 4K-Auflösung? Ein wenig Recherche in Internetforen und zu den Grafikkarten-Spezifikationen diverser älterer Modelle hat mir Zuversicht gegeben, und tatsächlich war meine Sorge eher unbegründet, denn in den allermeisten Fällen lautet die Antwort: Ja! 4K-Desktopauflösung ist für eine halbwegs moderne Grafikkarte selbst im Low-Budget-Bereich kein großes Kunststück, sogar Onboard-Grafikchips kriegen das längst mühelos hin. Meine Grafikkarte steuert auch gerne zwei Monitore mit 4K-Auflösung an, wenn man möchte. Einfach per HDMI, DVI oder DisplayPort anschließen und los gehts. Ob man damit Spiele in 4K-Auflösung spielen sollte, ist natürlich eine gänzlich andere Frage. In den allermeisten Fällen ist das weniger empfehlenswert, außer man besitzt eine teure Gaming-Grafikkarte. Aber kann man jedes Spiel immer auch in einer niedrigeren Auflösung rendern.

Wie sieht das denn mit tollem UHD-Filmmaterial aus? Kriegt man da wenigstens ordentlich was fürs Auge geboten? Ja und nein. Zum einen muss ich gestehen, dass ein 28 Zoll-Monitor wahrscheinlich nicht unbedingt ideal ist, um Filme in so hoher Auflösung qualitativ ausreichend zu beurteilen. Kurzgesagt, in schnellen Action-Sequenzen in denen sich relativ viel bewegt, hat Ultra-HD-Material praktisch keinen wahrnehmbaren Vorteil gegenüber Full-HD, schon gar nicht wenn man sich einfach nur auf den Film konzentriert. Seine größte Stärke spielt 4K z.B. bei Nahaufnahmen von Gesichtern aus, wenn man genug Zeit hat, sich die vielen winzigen Details anzusehen und darüber zu staunen. Aber das sind eigentlich Ausnahmen. In den meisten Fällen dürfte es Durchschnittsmenschen ohne ausgeprägtes Qualitätsempfinden oder Technikwissen schwerfallen, zu erkennen, ob sie gerade einen UHD-Film sehen oder nicht, zumal sehr viele UHD-Filme auf dem Markt entweder ohnehin Upscale-Mogelpackungen sind, oder ältere Filme generell mehr durch ultrawinzigen Filmgrain bestechen als durch echte, sichtbare, ultrahohe Bildqualität.

Für mich ist der erwartete Wow-Effekt leider ausgeblieben. Nicht, dass es ein Fehlkauf gewesen wäre, aber ein wenig mehr erwartet habe ich dann doch. Man könnte nun, wie gesagt, betonen, dass 28 Zoll keine geeignete Grundlage sind, um das richtig zu beurteilen, aber dafür sitze ich am Monitor eben auch sehr viel näher dran als am 50 Zoll Fernseher, den ich immer nur von der entfernten Couch im Blick habe. Im Prinzip sollte sich das also irgendwo ausgleichen. Aber es bleibt mir in jedem Fall ein Monitor mit einer gigantischen Desktopfläche, die ich mit Fenstern zuklatschen kann. Jetzt habe ich sogar soviel davon, dass ich die Hälfte davon als Werbefläche vermieten könnte. Oh Moment, das machen Webseiten ja schon lange so.