So manch einer wünscht sich endlich die Abkehr von den ach so scheußlichen Passwörtern im digitalen Alltag. Besonders von IT-Laien hört man seit Jahren immer wieder gebetsmühlenartig, dass das Konzept der Passwörter doch wirklich vollkommen überholt sei, so wie sie auch der Meinung sind, dass etwa die E-Mail oder die HDD vollkommen veraltet seien, dabei gibt es Stand heute immer noch keine Technologie, die diese in allen Kriterien übertrifft bzw. obsolet macht. Richtig ist hingegen, dass die guten alten Passwörter bis heute der perfekte und ungeschlagene Kompromiss zwischen Sicherheit und Einfachheit darstellen. Sofern man sie denn richtig einsetzt. Und hier scheitert es bei vielen Exemplaren leider immer wieder. Denn auch Brain 1.0 kann man damit immer noch nicht ersetzen.

Wie war das nun nochmal mit den Passwörtern? Weiß man denn inzwischen wenigstens, wie sichere Passwörter auszusehen haben? Ja, das weiß man schon sehr lange (Pun not intended). Das Problem ist, dass sich das jahrzehntealte Halbwissen noch immer extrem hartnäckig hält und selbst von Leuten weiterverbreitet wird, die es nachweislich besser wissen. So wurde in meinem beruflichen Umfeld vor etlichen Jahren eine neue Passwortrichtlinie erlassen, die mich erschaudern ließ: Möglichst kompliziert musste es sein, im Idealfall unlesbare Kombinationen aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen – und das alles bei einer minimalen Passwortlänge von 8 Zeichen. Wer jetzt verzweifelt die Pointe sucht: 8 Zeichen lange Passwörter sind von Angreifern per sogenanntem Bruteforce innerhalb von Minuten geknackt, egal wie komplex das Passwort da noch ist. Die Passwortrichtlinie sabotierte sich im Grunde selbst und bot so praktisch keinen Schutz. Dafür wurden die Nutzer auf der anderen Seite unnötig schikaniert mit der im Endeffekt sinnlosen Vorgabe, was sie in ihrem Passwort alles verwenden müssten, um bloß mit der Richtlinie konform und dadurch vorgeblich sicher zu sein. Hier wurde also das Schlechteste aus zwei Welten vereint.

Bei der nächsten Gelegenheit sprach ich einen Mitautor der Passwortrichtlinie darauf an. Die Richtlinie sei meiner Ansicht nach Quark und beruhe nicht auf wissenschaftlichen Fakten, sagte ich ihm. Und noch während ich mich auf eine Diskussion vorbereitete, stimmte er mir völlig unerwartet zu. Er antwortete, er wisse natürlich selbst, dass die Länge eines Passworts einen deutlich größeren Stellenwert im Sinne der Sicherheit habe als dessen Komplexität, und dass 8-Zeichen-Passwörter als fahrlässiges Sicherheitsrisiko betrachtet werden müssten. Aber er erklärte mir auch, dass es im Prinzip unmöglich sei, dies einem Laien heutzutage zu vermitteln. Die Menschen, fleißig gefüttert mit dem Halbwissen aus der Computerbild und anderen seriösen Quellen, reagierten darauf oftmals mit Unverständnis und mit „hilfreichen Tipps“, dass man doch unbedingt Groß- und Kleinschreibung, Ziffern und Sonderzeichen erzwingen müsse, denn dann könnte man auch die Passwörter wieder „normal“ kurz machen. Die neue Passwortrichtlinie ging daher den Weg des geringsten Widerstands, anstatt die Nutzer umzuerziehen, so wie es richtigerweise hätte sein müssen.

Absolut sicher: Lange, komplexe Passwörter am besten auf sichere Post-Its schreiben

Dies erklärt dann auch, warum man diese naive 8-Zeichen-Empfehlung auch im Jahr 2020 noch in zahllosen IT-Diensten weltweit wiederfindet, denn nicht einmal Tech-Konzerne wie Microsoft oder Google wollten ihren Nutzern erklären müssen, dass kurze Passwörter in jedem Fall unsicher sind, egal wieviel Mühe sie sich mit ihrem Zeichensalat geben. Gegen die Gewohnheit und Bequemlichkeit kann man bekanntlich so schlecht argumentieren. Die etwas IT-affineren und mathematisch nicht völlig unbedarften Leser werden sicherlich bereits den bekannten und sehr informativen XKCD-Comic zum Thema Passwortstärke kennen. Auch wenn man mittlerweile berechtigterweise einwenden darf, dass auch Dictionary-Attacks ein Thema sind. Im Idealfall verwendet man also nicht ausschließlich Wörter, die in jedem Wörterbuch stehen, denn auch diese lassen sich in Rekordzeit automatisiert und in allen Kombination durchprobieren.

Wieso verwenden wir denn immer noch Passwörter, es gibt doch längst sowas wie biometrische Merkmale? Das werden sich bevorzugt jene fragen, die ihr iPhone via Gesichtserkennung oder ihr Android-Smartphone mittels Fingerabdrucks entsperren. Dazu habe ich eine eindeutige Meinung: Biometrische Authentifizierung als Passwortersatz ist ein gefährlicher Holzweg, den wir hoffentlich niemals ernsthaft beschreiten werden, denn im Gegensatz zu Passwörtern können mir meine Körpermerkmale gegen meinen Willen, ohne meine Mitwirkung und sogar ohne mein Wissen abgenommen werden; Fingerabdrücke lassen sich problemlos kopieren und reproduzieren, Gesichts-, Venen- und sogar Iris-Scans lassen sich unbemerkt anfertigen und vervielfältigen, wenn man sich damit auskennt. Und wenn dies geschieht, sind meine Daten nicht nur nicht mehr vor fremdem Zugriff sicher – ich kann meine Fingerabdrücke, mein Gesicht, und meine Augen leider auch zeitlebens nicht mehr verändern. Diese Biometrie-Merkmale wären damit endgültig verbrannt. Neue Passwörter kann ich mir mühelos jederzeit ausdenken. Und ja, natürlich kann man mit körperlicher Gewalt auch Passwörter aus jemandem herausfoltern, aber dazu gehört schon eine ganze Menge mehr kriminelle Energie und ist natürlich auch viel weniger diskret.

Aber spielt das alles überhaupt eine Rolle in einer Welt, in der die Menschen sich ihre Passwörter auf Post-Its an den Monitor oder unter die Tastatur heften? Eine Welt in der selbst IT-Fachkräfte ihre Passwörter in geordnete Excel-Tabellen schreiben oder immer ausschließlich per Autofill im Browser speichern? Und dann gibt es natürlich noch die absoluten Spezialisten, die ohnehin seit 15 Jahren überall dasselbe Passwort verwenden, das sie sich gut merken können. Bei den meisten Menschen müsste erst eine Katastrophe geschehen, bevor sie verstehen, dass sie etwas an ihrer Routine ändern sollten. Ich selbst habe da auch einen langen Weg zurückgelegt: Von den Post-Its, über den Notizblock und die Textdateien, bis hin zum Passwortmanager war bisher alles irgendwann dabei. Auch meine Passwortstärke hat sich im Laufe der Zeit kontinuierlich auf Grund der Notwendigkeit verbessert. Entweder die eigenen Accounts sind es einem Wert, oder eben nicht. Dass mir noch kein „Hacker“ irgendwelche Daten gestohlen hat, ist allerdings kein verlässliches Maß für die eigene Passwortsicherheit.

Erst die beruflich einmalige Gelegenheit vor mehreren Jahren, eine umfassende, netzwerkfähige Enterprise-Passwortverwaltung vollständig zu entwickeln, brachte mich zum Überdenken meiner alten Passwortgewohnheiten und Ansichten zum Thema IT-Sicherheit. Seitdem verwendete ich privat KeePass, bzw. später KeePassXC, einer freien und umfangreichen Passwortverwaltungssoftware, mit der ich sehr komfortabel meine knapp 300 Passworteinträge zusammenhalten und ordnen kann. Die eingebaute Statistikfunktion offenbart mir sogar, dass meine durchschnittliche Passwortlänge 18 Zeichen beträgt. Auf USB-Sticks kann ich meine verschlüsselte Passwortdatenbank auch jederzeit überall dabei haben. Den eingebauten Passwortgenerator habe ich etliche Male genutzt, denn inzwischen gehört es zum Glück nicht mehr zu meinen Erstellungskriterien, dass ich mir ein Passwort merken können muss. Im Gegenteil: Viele meiner eigenen Passwörter habe ich noch nie gesehen! Und das muss ich dank STRG+C/STRG+V natürlich auch gar nicht. Lediglich das Master-Passwort zur KeePass-Datenbank muss ich wissen und zur Sicherheit an einem zweiten Ort aufbewahren.

Also bis endlich jemand eine Alternative entwickelt, die mindestens genauso sicher, genauso einfach, und genauso flexibel wie selbstgewählte Passwörter sind, wird es auch weiterhin das Mittel der Wahl sein, um Zugänge abzusichern. Gerade habe ich jemanden das Stichwort Zwei-Faktor-Authentifizierung dezent reinhusten gehört. Stimmt, die gibt es natürlich. Aber Zwei-Faktor-Authentifizierung bedeutet ja eben nicht, dass der erste Faktor wegfällt, der meistens immer noch etwas mit einer PIN oder einem Passwort zu tun hat. Außerdem will sicher niemand behaupten, dass er für alle seine Passwörter vorsorglich jeweils einen zweiten Faktor eingerichtet hat. Das macht man höchstens dort, wo es um Geld geht. Da es also eher die Ausnahme als die Regel bildet, bleibt ein starkes Passwort immer eine wichtige Voraussetzung um die Sicherheit der eigenen Daten zu gewährleisten.

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…

Ladies and Gentlemen, werte anwesende Gäste, vielen Dank, dass Sie alle so zahllos gut zählbar zur großen Feier zum zehnjährigen Jubiläum von SuccessDenied.com erschienen sind. Wie Sie wissen, begeistere ich die Welt nun schon seit genau zehn Jahren mit meinen schriftlichen Ergüssen, und das hat selbstverständlich Spuren hinterlassen. Vielleicht nicht unbedingt bei Ihnen, aber in jedem Fall bei mir: Meine Tastatur ist inzwischen ganz schön abgenutzt. Nach zehn Jahren wird es auch Zeit, mir endlich eine Neue zu kaufen. In den vergangenen zehn Jahren konnte ich mir über viele Dinge in meinem Bloggerleben ausgiebig Gedanken machen: Wer bin ich? Worüber soll ich schreiben? Wohin verschwinden all die Socken in meiner Waschmaschine? Und nun habe ich zehn weitere Jahre, in denen ich über diese wichtigen Dinge nachdenken kann, denn eine Antwort habe ich bislang nicht finden können.

Schon der große deutsche Philosoph Friedrich Nietzsche sagte einst: „Die sogenannten Paradoxien des Autors, an welchen der Leser Anstoß nimmt, stehen häufig gar nicht im Buche des Autors, sondern im Kopfe des Lesers.„. Das hat zwar mit meiner Webseite nicht viel zu tun, aber es klingt äußerst tiefgründig. So tiefgründig wie meine vielen Artikel über Spiele, Filme, TV-Serien, Hitzewellen in meiner Wohnung, und auch über professionelle Prokrastination. Und nun, nach dieser langen Zeit, wird es allmählich Zeit, mir die Zeit zu nehmen, um ein Resümee zu ziehen: Es hat sich überhaupt nicht gelohnt. Und genau deswegen muss ich unaufhörlich weitermachen. Als ich anfing, war ich noch Student, jung, dynamisch, optimistisch, weltoffen. Inzwischen bin ich seit vielen Jahren berufstätig, verbittert, nörgelig, stur, mit Rücken. Das gibt mir die Gelegenheit, aus einem völlig anderen Blickwinkel über das tägliche Geschehen in der Welt zu berichten. Nämlich leicht gebeugt, mit Krückstock und viel Ibuprofen.

Ich bin wahrlich kein großer Redner, daher möchte ich mich möglichst kurzfassen und im folgenden nur aus den knapp 100 meiner einflussreichsten und bedeutendsten Blog-Beiträge der vergangenen zehn Jahre zitieren. Ich möchte nicht prahlen, aber unzählige Verfasser wissenschaftlicher Publikationen auf der ganzen Welt, Fachblätter aus allen Wissenschaftsbereichen, und außerdem viele anerkannte Koryphäen, darunter sogar mehrere Nobelpreisträger, haben sich für meine qualitativ hochwertigen Artikel auf SuccessDenied.com zwar bislang leider nicht interessiert, aber möglicherweise würden sie das, wenn sie sie gelesen hätten. Es wäre ohnehin zuviel der Ehre gewesen, und wie schon gesagt, ich wollte ja nicht prahlen.

Anschließend werde ich detailliert auf die 50 spannendsten Kommentare meiner großartigen Blog-Besucher eingehen und diese zur Diskussion stellen. Wenn uns im Anschluss noch etwas Zeit bleibt, würde ich sehr gerne den Abend ausklingen lassen mit einer Lesung einzelner Kapitel aus meinem neuen Buch „Erfolglos Bloggen für Dummies“. Vielleicht wird sich der eine oder andere sogar dadurch inspiriert fühlen, sich ebenfalls dieser beinahe vergessenen, brotlosen Kunst anzunehmen, und mit meiner Hilfe und unter meiner kompetenten Anleitung garantiert nicht reich und mächtig zu werden, sondern – wie ich – ganz auf dem Boden der Tatsachen zu bleiben.

Das Buch gibt es für nur 14,99 EUR UVP in jedem gut gepflegten Buchhandel, den ich zuvor aufgesucht und einige Exemplare dort heimlich im Regal versteckt habe. Ich komme übrigens regelmäßig zu Signierstunden nach Hintertupfingen in die aufstrebende Buchhandlung hinter dem alten Bahnhof, direkt am Friedhof. Sie müssen nur bei „Meier“ klingeln und nach mir fragen, dann werden Sie direkt in den Hinterhof zum großen Bücherschuppen geführt. Die verrosteten Fahrräder und Gartengeräte können Sie ignorieren. Achja, wenn ich zur Mittagszeit noch nicht wach sein sollte, ziehen Sie einfach fest an der Zeitung, mit der ich mich zugedeckt habe, oder treten sie lautstark gegen eine der leeren Schnapsflaschen, die am Boden herumliegen. Für 5 EUR mache ich auch Selfies mit meinen Fans, für 10 EUR sogar gekämmt und mit einem sauberen Hemd.

An die beiden unruhigen Herren hier vorne in der ersten Reihe: Ich darf doch um Ruhe bitten. Keine Sorge, das Buffet wird bald eröffnet, ich möchte nur meine Rede noch beenden. Aber danke, dass Sie mir dieses passende Stichwort geben. Denn wie ich bereits im Vorfeld zu dieser Feier angekündigt hatte, würden wir das geplante opulente Festmahl vollständig von den reinen Werbeeinnahmen und Spenden auf SuccessDenied.com bezahlen! Sie haben richtig gehört. Alles was meine vielen Leser mir im Laufe der Jahre gegeben haben, fließt natürlich direkt wieder an Sie in Form des Caterings zurück. Und da kam definitiv einiges an gutem Willen und frohen Gedanken zusammen. Ich kann daher voller Stolz verkünden, dass sich die Tafel unserer wunderschönen Kommune bereit erklärt hat, uns mit Essen zu versorgen. Jeder Gast bekommt daher einen ganzen Teller klare Suppe mit einem kleinen Stück Brot.

Achja, ein herzliches Dankeschön an die treuen Leser von SuccessDenied.com! Es ist mir völlig unverständlich, aber irgendwie schön zu wissen, dass ihr immer noch regelmäßig, oder wenigstens ab und zu vorbeischaut. Ich weiß es sehr zu schätzen, dass ihr die Hoffnung noch nicht aufgegeben habt, dass ich irgendwann mal wirklich etwas aus meinem Blog mache. Bis dahin bleibt hier einfach alles so wie es ist. Und ihr bleibt hoffentlich so wie ihr seid. Es sei denn, ihr wollt etwas Besseres sein. Dann werdet etwas Besseres.

Auf die nächsten zehn Jahre!
Vince

In Vorbereitung auf das baldige Ende von Windows als meinem Haupt-Betriebssystem nach mehr als 23 Jahren experimentiere ich unter anderem mit VirtualBox als Ausführungsumgebung für alte Windows-Versionen, um darin alte Spiele auch weiterhin verwenden zu können. Nachdem sich in meinem letzten Artikel zu diesem Thema PCem als PC-Emulator für Windows 98 SE zumindest im Rahmen meiner Stichprobe bereits als überraschend kompatibel und ergiebig erwiesen hat, wollte ich den Schwierigkeitsgrad nun deutlich erhöhen. Heute geht es um das Thema Virtualisierung mit der beliebten Open-Source-Lösung VirtualBox.

Die Unterstützung für Windows 95/98 unter VirtualBox ist bekanntermaßen miserabel, weil die Entwickler darauf bedauerlicherweise überhaupt keine Lust haben. Daher gibt es auch keinerlei Guest-Additions (wie etwa unter VMware), und die Hardware-Unterstützung ist bestenfalls rudimentär. Keine gute Voraussetzung, um damit Spiele testen zu wollen. Aber was wäre die Community ohne ihr Ideenreichtum, denn es gibt durchaus fundierte Anleitungen im Internet, um zum Beispiel Windows 98 einigermaßen genießbar zu machen. Wie einigermaßen genießbar das am Ende sein würde, darüber wollte ich mir nun selbst ein Bild machen, um zu sehen, ob diese Option für mich eine Zukunft haben könnte.

Google funktioniert im Jahr 2020 immer noch mit dem beliebten Internet Explorer 5

Wie bereits im Artikel zuvor möchte ich betonen, dass das hier keine Anleitung werden soll, denn für interessierte Mitleidende gibt es bereits genug Hilfestellung im Netz. Stattdessen gehe ich auf die Dinge ein, die mir aufgefallen sind. Während man bei der Konkurrenz von VMware zur Installation von Windows 98 zum Beispiel mit einer vollständigen Unattended-Installation und sehr leistungsfähigen Guest-Additions umschmeichelt wird, bekommt man unter VirtualBox nicht einmal einen Knochen hingeworfen. Windows 98 verbrennt Out-Of-The-Box unter VirtualBox mangels ACPI-Unterstützung leider CPU-Zyklen ohne Ende, was das Betriebssystem komplett unbenutzbar macht. Das Problem ist zwar lösbar, allerdings muss man dazu den Installationsvorgang etwas modifizieren.

Am Ende des recht langwierigen Prozesses hat man ein lauffähiges und auch noch relativ reaktionsschnelles Betriebssystem, aber die Grafik- und Soundtreiber bleiben leider ein Problem, und die Gast-zu-Host-Kommunikation ist minimal. Eine Internetverbindung über LAN lässt sich noch mühelos konfigurieren, und schon darf man mit dem gruselig antiquierten Internet Explorer 5 ins Netz. Selbstredend gibt es für den senilen Browser hier nicht mehr viel zu sehen, da die meisten Webseiten längst auf völlig neue Technologien setzen. Um die Grafikeinstellungen zu verbessern, ist der SciTech Display Doctor 7 heute das Non-Plus-Ultra, der einen universellen SVGA-Treiber mitbringt, mit dem man Windows 98 auf bis zu 1600×1200 Pixeln und sogar 32 Bit Farbtiefe einstellen darf. Letzteres soll angeblich die Performance unter VirtualBox deutlich verbessern. Zumindest in dieser Hinsicht bekommt man also ein ganz brauchbares, modernes Setup in angenehmer Auflösung.

Das Thema Sound ist unter VirtualBox leider ein gewaltiger Hemmschuh. Die Virtualisierungssoftware bringt wahlweise eine virtuelle SoundBlaster 16 oder einen RealTek AC’97-Chip mit. Der geneigte Retrogamer bekommt natürlich feuchte Augen, wenn er nur die SoundBlaster 16-Option sieht, denn die wäre ja vollkommen ausreichend in 99% der Fällen. Aber leider haben die Flachzangen bei Oracle wohl an der Implementierung gespart. Die Leistung ist selbst mit dem offiziellen Creative-Treiber nur schwer zu ertragen, und MIDI-Unterstützung sucht man vergeblich, womit man in vielen Spielen von vor 1998 eben gänzlich ohne Musik auskommen muss. Aber es gibt Hoffnung, denn technikversierte Community-Mitglieder haben stattdessen einen obskuren Windows 95-Treiber für den AC’97-Chip aufgetan, der schließlich sogar MIDI ermöglicht. Dies ist heute offenbar das Mittel der Wahl, wenn man Windows 98 verwenden möchte. Das Umkonfigurieren der VM ist zum Glück nur eine Angelegenheit von Sekunden, und schon hat man eine andere Soundkarte drin.

Noch ist wenig los am Ballermann, in Holiday Island von 1996 in VirtualBox

Nun war es also an der Zeit, ein paar wirklich alte Spiele auf meine Installation loszulassen, darunter das von mir geschätzte und heutzutage kaum noch bekannte „Holiday Island“ von der Firma Sunflowers Interactive. Hierbei handelt es sich um ein witziges Aufbauspiel für ein Urlaubs-Resort auf einer tropischen Insel, ähnlich wie das neuere Rollercoaster Tycoon. Holiday Island ist berüchtigt dafür, bereits ab Windows 2000/XP nicht mehr problemlos lauffähig zu sein. Es lässt sich oft mit Hilfe von Registry-Tricks und anderen technischen Kniffen starten, zeigt dann aber während des Spielens unterschiedlichste Probleme, ist also nur noch bedingt spielbar. Das fällt natürlich nicht auf, wenn man immer nur die ersten 5 Minuten vom Spiel sehen will, um zu beweisen, dass es läuft.

Die Installation von Holiday Island verlief noch beinahe ohne Zwischenfälle, aber der CD-Kopierschutz machte daraufhin Schwierigkeiten, und die SVGA-Autoerkennung schlug bei mir fehl. Der erste erfolgreiche Start des Spiels nach einiger Bastelarbeit im Installationsverzeichnis machte Hoffnung und die Videos liefen einwandfrei. Nachdem ich die ersten Gebäude platziert hatte, erhielt ich einen Bluescreen in der VM, das Spiel lief aber weiter. Soundeffekte und Musik funktionierten mit dem AC’97-Soundchip ganz passabel. Die Performance war im großen und ganzen halbwegs brauchbar, wenn auch nicht optimal. Die Tonausgabe stotterte gelegentlich. Das Optionsmenü zeigte teilweise keine Beschriftungen. Nach etwa 15 Minuten fiel der Sound plötzlich grundlos aus. Fazit: Das Spiel ist spielbar, aber ein wenig leidensfähig muss man mindestens sein.

Zweites Spiel auf meiner Liste war Sim City 2000. Dieses ließ sich ganz einfach installieren und starten. Die Animation im Hauptmenü funktionierte nicht (benötigt wohl 256 Farben), und im Spiel gab es bei mir keine Soundeffekte, aber die MIDI-Musik läuft immerhin. Die Spielperformance sah soweit gut aus. Das Soundproblem ist natürlich eine gewaltige Einschränkung, die ich nicht lösen konnte, aber spielbar ist es irgendwie. Anschließend wollte ich Theme Hospital kurz testen, aber auch hier hat der CD-Kopierschutz den Start verhindert, und ich wollte keine Zeit damit vergeuden, noch mühsam eine lauffähige Version zusammenzupatchen.

Ein Weltraum-Monster greift Atlanta an, in Sim City 2000 aus dem Jahr 1993 in VirtualBox

Das dritte getestete Spiel war Myst von 1993, ein ebenfalls von mir sehr geschätztes Rätselspiel. Auch hier lief die Installation zunächst rund, bis der Installer mir mitteilte, dass er nun Apple Quicktime installieren wolle, woraufhin aber die Installation plötzlich beendet war, und nichts mehr passierte. Ein wenig verdutzt startete ich das Spiel, was auch funktionierte, aber es gab kein Introvideo zu sehen. Stattdessen lag direkt das mysteriöse Buch vor mir. Mit zwei Mausklicks konnte ich es öffnen um zum Pier der Myst-Insel katapultiert zu werden, aber das Spiel hing sich an dieser Stelle auf. Die Transition funktionierte nicht. Ein Neustart der VM war nötig. Das Experiment war für mich hier beendet.

Spiele unter Windows 98 in VirtualBox? Leider nein. Naja, einiges funktioniert natürlich, manchmal sogar erfreulich gut. Anderes dagegen klappt nur mit Einschränkungen oder überhaupt nicht. Die Spielekompatibilität ist hölzern und unkomfortabel, die Performance ok – wenn man Glück hat -, aber gern auch ruckelig und eher langsam, der Sound geht entweder nicht oder stottert. Videos funktionieren mal prächtig unter Holiday Island, aber in Myst leider wieder nicht. Selbstverständlich kann ich nicht ausschließen, dass meine Windows 98-Installation und meine VM-Konfiguration sich noch verbessern lassen, aber zumindest mit Hilfe der üblichen Anleitungen von Fans im Internet lässt sich meines Erachtens nicht viel mehr herausholen. Daher betrachte ich mein Setup dahingehend als nahe am Optimum. Und dieses ist unglücklicherweise wenig optimal um damit meine kleine (wenig repräsentative) Auswahl von Spielen zu spielen. Ich fürchte also, dieses Thema brauche ich künftig nicht mehr weiterverfolgen.

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.