Das Anti-Cracker-Buch

Das Anti-Cracker-Buch
	Sprache	deutsch
	Autor(en)	Ralf Gelfand, Jacques Felt, Michael Strauch, Drako Krsnik
	Verlag	Data Becker
	Jahr	1988
	ISBN	ISBN 3-89011-253-6
	Neupreis	DM 39.-
	Datenträger
	Seitenzahl	379
	letzte Auflage	2., unveränderte Auflage 1988
	Genre	Kopierschutz
	Information

Buchrückseite

DAS STEHT DRIN:
Vom Einsteiger bis zum Softwarehaus - dieses Buch zeigt, wie man seine Programme optimal schützt. Dabei werden Programm- und Kopierschutzverfahren vom einfachen List-Schutz bis zur Überprüfung eines kompletten Tracks gezeigt. Und: Die Autoren sind nicht bei bekannten Schutzmechanismen der neuesten Generation stehengeblieben, sondern haben neue entwickelt, für die es bisher keine Kopiermöglichkeiten gibt. Das Buch zeigt nicht nur die Verfahren, sondern liefert auch gleich fertige Lösungen für C64 und C128 zum Abtippen. Aus dem Inhalt:

• Basic-Programme schützen (List-Schutz, Änderungs-Schutz, Password, RESTORE/RESET-Schutz, SYS-Bluff, Compiler-Schutz)
• Alle Tricks des Autostart (Tastaturpuffer, Sprungvektoren, Stack, Interrupt, Adreßverschiebung beim Laden)
• Prüfsummen und Selbstzerstörung (XOR-Codierung, Timer-Codierung, Einzelschrittcodierung, ASCII-Codierung)
• Illegale Opcodes
• Cassettenkopierschutz (EOF, Cassettenpuffer, Autostart, Schnelladeverfahren, komplettes Kopierschutzsystem)
• Directory-Schutz (versteckter Filename, "blinde" Blöcke, der Nullen-Trick, geteiltes Directory, gelöschte Files)
• Grundlagen des Kopierschutzes
• Alle Tricks der Formatierung, (Track 35-41, einzelne Tracks, doppelte Tracks, Header-Parameter ändern, zerstörte Sektoren, gleiche Sektoren auf einem Track)
• Halftracks, der Track mit den Nullen, kompletten Track prüfen
• Alle Tricks der SYNC-Markierungen (Killertracks, überlange SYNC-Markierungen, 3000-SYNC-Schutz, Daten ohne SYNC-Markierungen)
• Der Disketten-Killer (nur Ausschalten der Floppy hilft)
• Alle Tricks der Knack-Module und wie man sich dagegen schützt
• Was Software-Häuser über Cracker wissen sollten

UND GESCHRIEBEN HABEN DIESES BUCH:
Jacques Felt und Darko Krsnik sind Hardware- und Assemblerspezialisten. Ralf Gelfand ist absoluter Floppy-Experte. Er hat schon Kopierschutzverfahren für den professionellen Einsatz entwickelt. Von Michael Strauch stammt das Kapitel über die Datasette, die er bis zum letzten Byte kennt.

Inhaltsverzeichnis (2. Auflage)

1. Einleitung

2. BASIC-Programmschutz
2.1 Listschutz
2.1.1 Der Listschutz mit "SHIFT-L"
2.1.2 List-Schutz mit Steuerzeichen
2.1.3 List-Schutz über Sprungverktoren
2.1.4 Nur Zeilennummern
2.1.5 Simuliertes Programmende
2.1.6 Der Linke(r)-Trick
2.1.7 Der Sys-Bluff
2.2 Änderungsschutz
2.2.1 Abfrage des BASIC-Endes
2.2.2 Änderungsschutz durch übergröße Zeilennummer
2.3 RESET- und RUN-STOP/RESTORE-Schutz
2.4 Warum eigentlich Compilieren?
2.4.1 Warum der Compilercode keinen absoluten Schutz bildet!

3. Programmschutz für Profis
3.1 Autostart
3.1.1 Warum eigentlich Autostart?
3.1.2 Der einfachste Autostart
3.1.3 Autostart im Tastaturpuffer
3.1.4 Autostart über Sprungvektoren
3.1.5 Stapel-Autostart
3.1.6 Autostart während des Ladens
3.1.7 Autostart über Interrupt
3.1.8 Autostart über die CIAs
3.1.9 Autostart mit Adreßverschiebung
3.2 Prüfsummen und Selbstzerstörung
3.3 Codierung von Programmen
3.3.1 Verwendung der EXOR-Verknüpfung
3.3.2 Codierung mit verstecktem Einsprung
3.3.3 Codierung mit Timer
3.3.4 Einzelschritt-Dekodierung
3.3.5 Codierung über ASCII-Code
3.4 Die Illegal-Codes
3.4.1 Erklärung der Illegal-Codes
3.4.2 Anwendung der Illegal-Codes
3.4.3 Taktzyklen der Illegal-Codes
3.5 Dongle als Programmschutz
3.5.1 Wie arbeitet ein Dongle?
3.5.2 Eine einfache Dongle-Abfrage
3.5.3 Dongle mit IC
3.6 Password-Abfrage

4. Directory-Schutz
4.1 Versteckter Filename
4.2 Verstecken der Filenamen durch Steuerzeichen
4.3 Der "blinde" Block
4.4 Der Trick mit den Nullen
4.5 Das geteilte Directory
4.6 Die Tarnung des Filetyps
4.7 Gelöschte Files

5. Kopierschutz mit der Datasette
5.1 Sinn und Unsinn eines Kassettenkopierschutzes
5.2 Laden und Abspeichern von Programmen und Daten
5.2.1 Was man von BASIC aus machen kann
5.2.2 Laden und Speichern in Maschinensprache
5.3 Autostart als Kopierschutz
5.3.1 Eingriffe in die LOAD/SAVE-Routine
5.3.2 Selbststartende Programme
5.4 Der Kassettenpuffer
5.5 Entwicklung eines eigenen Aufzeichnungsformats
5.5.1 Direkte Ansteuerung der Datasetten-Funktionen
5.5.2 Signalerzeugung auf dem Band als Kopierschutz
5.5.3 Ein neues Auszeichnungsformat am Beispiel des "KKS"
5.5.4 Wichtige Betriebssystemadressen und -routinen

6. Diskettenkopierschutz
6.1 Unser "Handwerkszeug"
6.1.2 Das Disketten-Aufzeichnungsverfahren
6.1.3 Einführung in die Lese- und Schreibtechnik
6.1.4 Registerbeschreibung der VIA 2
6.2 Die Formatroutine
6.2.1 Formatieren eines einzelnen Tracks
6.2.2 Formatieren der Spuren 36 bis 41
6.2.3 Doppelte Spuren
6.2.4 Änderung der Headerparameter: Read-Errors
6.2.5 Das Arbeiten mit zerstörten Blöcken
6.2.6 Gleiche Blöcke auf einem Track
6.3 Halftracks
6.4 Mit Nullen beschriebene Spuren
6.5 Überprüfen eines kompletten Tracks
6.6 SYNC-Manipulationen
6.6.1 Killertracks
6.6.2 Verlängerte SYNC-Markierungen
6.6.3 Der 3000-SYNC-Schutz
6.6.4 Daten ohne SYNC-Markierung
6.7 Der "Disketten-Killer"

7. Wie man sich gegen Knackmodule schützt
7.1 Einleitung
7.2 Vorläufer der Knackmodule
7.2 Knackmodule neueren Datums
7.3 Knackmodule: Zukunftsaussichten

8. Gerüchteküche
8.1 Der rechnerzerstörende Kopierschutz
8.2 Viren

9. Allgemeine Tips

10. Komplettlösung

11. Was ein Software-Haus über "Cracker" wissen sollte

12. Kopierschutz auf dem C128
12.1 Übereinstimmungen und Unterschiede zum C64

Index

Leseprobe

(S.115, aus Kapitel 3.4.2: "Anwendung der Illegal Opcodes")

Der [...] einzig wesentliche Vorteil [bei der Verwendung von Illegal Opcodes] besteht darin, daß die Illegal Opcodes von einem normalen Disassembler nicht gelesen und in Befehlsworte "übersetzt" werden können. Dadurch wird das Lesen der Programme erheblich erschwert. Verfügt man nicht über die oben abgebildeten Tabellen, wird dieses sogar zu einer unüberwindlichen Hürde. Wollen Sie also wichtige Teile Ihres Programms vor Fremdzugriffen schützen, bieten die Illegal-Opcodes eine große Hilfe.

Es ist zum Beispiel äußerst sinnvoll, die Abfrage des Kopierschutzes auf Diskette durch Illegal Opcodes zu verstecken. Ein weiteres Beispiel bezieht sich auf die Decodierung von Programmen. Hier könnte man die Decodierroutine für das Hauptprogramm nochmals codieren. Dieses erfordert dann eine weitere, jedoch sehr kurze Decodierroutine, die mit Hilfe der Illegal Opcodes geschrieben werden kann. Ist der Einsprung des Programms nicht bekannt, so ist es nahezu unmöglich, überhaupt eine Codier- bzw. Decodierroutine zu entdecken. Es ist also auch nicht möglich, das Programm zu decodieren und dann zu verändern.

Beschreibung

Das Buch vermittelt die technischen Hintergründe zu den vorgestellten Verfahren. Wer jedoch einfach nur eigene Programme gegen Kopieren schützen will, ohne sich mit den Details zu beschäftigen, kann das Buch auch sinnvoll verwenden, da die meisten Schutzprogramme auch als einfach zu benutzende "BASIC-Loader" präsentiert werden. Und auch zum Knacken von Programmen erhält man natürlich wertvolle Hinweise, auch wenn das die Autoren sicherlich nicht direkt beabsichtigt hatten.

1. Einleitung

In der Einleitung weisen die Autoren bereits darauf hin, dass man einen Kopierschutz prinzipiell auf zwei Arten aushebeln kann: Entweder versucht man, das Programm mit einem geeigneten Kopierprogramm zu vervielfältigen, oder man entfernt die Abfrage des Schutzes. So unterscheiden die Autoren zwischen Programmschutz (soll Entfernen der Kopierschutzabfrage verhindern) und dem Kopierschutz, wobei letzterer nochmal in Datasette und Diskette aufgeteilt wird.

Knackmodule bilden eine weitere, damals offenbar neuartige Vorgehensweise, die später im Buch behandelt wird.

2. BASIC-Programmschutz

Im Kapitel BASIC-Programmschutz geht es dann erstmal um den List-Schutz. Dabei gibt es mehrere Verfahren, mit denen man die Eigenheiten der LIST-Implementierung im C64 ausnutzt, um ein BASIC-Programm unsichtbar zu machen. Die Autoren weisen bereits darauf hin, dass mehrere Verfahren mit einem System wie SpeedDOS (das eine veränderte LIST-Routine verwendet) nicht funktionieren. Allgemein muss man einfach verstehen, dass auch ein "geschütztes" BASIC-Programm praktisch unverändert im Speicher liegt und nur durch Tricks unsichtbar ist, bis jemand, der den Trick kennt, es wieder sichtbar macht. Natürlich kann man theoretisch auch ein BASIC-Programm durch absichtlich komplizierte Programmierung nahezu unlesbar machen; die Autoren des Buches weisen in Abschnitt 2.4 Warum eigentlich Compilieren? aber auf ein besseres und einfacheres Verfahren hin.

Zunächst geht es aber um den Änderungsschutz. Wenn also doch jemand den LIST-Schutz knackt, dann sollte er trotzdem nicht in der Lage sein, die Kopierschutzabfrage auszubauen. Man kann dazu im eigenen Programm irgendwo versteckt mit zwei PEEK-Befehlen das Ende des BASIC-Programms abfragen und mit den selbst ermittelten Werten, die man fest im Programm gespeichert hat, vergleichen. Weichen die Werte ab, hat jemand das Programm verändert und das Programm kann sich zum Beispiel selbst beenden. Wer sich näher damit beschäftigt, stellt fest, dass man ein bisschen herumbasteln muss, wenn man bestimmte Verfahren kombinieren will. Der List-Schutz "Nur Zeilennummern" - laut den Autoren das beste reine Listschutzverfahren - verändert nämlich die Programmgröße, die man vielleicht bei einem Änderungsschutz abfragen will. Man kann also die Vergleichswerte erst ins Programm eintragen, wenn der List-Schutz "Nur Zeilennummern" bereits eingebaut ist - nur kann man dann ja keine Änderungen mehr vornehmen, weil das Programm durch den List-Schutz unsichtbar ist. Man schreibt sich die Werte also auf ein Blatt Papier, trägt sie ins ungeschützte Programm ein und muss das Programm abermals schützen... Nicht sooo schwer, aber interessant, dass die Autoren auf solche Dinge gar nicht hinweisen.

Der zweite Änderungsschutz ist ganz trickreich. Es wird eine neue erste Zeilennummer größer als 64000 generiert (eigentlich nicht erlaubt), die dadurch nicht gelöscht werden kann. Die nachfolgenden Programmzeilen können dadurch nicht mehr bearbeitet/verändert/gelöscht werden (jedenfalls nicht mit dem normalen BASIC-Interpreter des C64). Damit das Programm funktioniert, wird nach Start des Programms über ein Maschinenprogramm die Zeilennummer auf 1 gesetzt, da sonst Sprungziele im Programm nicht erkannt würden. Bei Ende oder Abbruch des Programms wird über einen Interrupt-Vektor ein zweites Maschinenprogramm ausgeführt, das die Zeilennummer wieder zurücksetzt.

Der Abschnitt RESET- und RUN-STOP/RESTORE-Schutz erklärt die CBM80-Kennung und gibt ein Programmbeispiel dafür. Angesichts von Knackmodulen ist es aber weitgehend witzlos, zu versuchen, ein RESET zu verhindern.

In den Abschnitten 2.4 Warum eigentlich Compilieren? und 2.4.1 Warum der Compilercode keinen absoluten Schutz bildet! geht es dann endlich um die BASIC-Compiler. Mehrmals im Buch weisen die Autoren darauf hin, dass der P-Code, den einige Compiler produzieren (Compiler, die reinen Maschinencode produzieren, eignen sich nicht gut zum Schützen von Programmen), extrem verschachtelt und schwer zu verstehen ist, dass er sich gut zum Schützen eigener Programme eignet, obwohl er eigentlich nur zur Beschleunigung der Programmausführung gedacht war. Leider wird P-Code im Buch nicht mit Beispielen, sondern nur theoretisch erklärt, es wird auch kein Compiler mitgeliefert und es wird auch kein geeigneter Compiler namentlich erwähnt. Es wird nur allgemein gesagt, dass es zu einigen Compilern so genannte Re-Compiler (nach heutiger Terminologie: "Decompiler") gibt, die den P-Code wieder in lesbares BASIC zurückverwandeln; das solle man bei der Wahl eines Compilers entsprechend berücksichtigen.

3. Programmschutz für Profis

Erstmal geht es hier um den Autostart, d.h. ein Programm startet automatisch direkt nach dem Laden. Was man heute als selbstverständlich hinnimmt, war beim C64 nicht zwangsläufig so. Hat man selbst ein Programm geschrieben und mit SAVE gespeichert, war es nach dem Laden zunächst einfach so im Speicher und musste mit RUN vom Anwender zur Ausführung gebracht werden. Ein Autostart musste also erstmal programmiert werden. Vorteil des Autostart beim Schützen eines Programms ist, dass nach dem Laden das Programm nicht einfach zur Begutachtung/Analyse im Speicher bereitliegt.

Der grundsätzliche Trick ist, Speicherbereiche außerhalb des eigentlichen Programms mitzuspeichern, so etwa die Sprungvektoren, die normalerweise auf Betriebssystem-Funktionen zeigen, die man aber auch auf eigene Funktionen zeigen lassen kann. Mit dem Befehl LOAD"PROGRAMMNAME",8,1 (statt nur ,8) wird das Programm dann in den Speicherbereich geladen, aus dem heraus es zuvor auch gespeichert worden war, somit werden beim Ladevorgang auch die veränderten Sprungvektoren übernommen. Lässt man nun z.B. den Vektor für die Eingabeschleife auf das eigene Programm zeigen, startet es automatisch nach dem Laden.

Natürlich kann man auch andere Vektoren passend modifizieren. Man kann auf diese Weise den LIST-Befehl unbrauchbar machen, den SAVE-Befehl verhindern usw.

Die Autoren zeigen nachfolgend jedenfalls verschiedene Verfahren für den Autostart, immer in der Hoffnung, dass die Verfahren so trickreich sind, dass ein Cracker sie nicht durchschaut.

Dann folgt das Thema Prüfsummen und Selbstzerstörung. Letztlich geht es auch hier wieder um einen Änderungsschutz und es wird gezeigt, wie man eine Prüfsumme berechnet und überprüft, und wie sich das Programm bei einem Prüfsummenfehler selbst aus dem Speicher löschen kann. Wie man so etwas am besten vorm Cracker versteckt, wird an dieser Stelle im Buch nicht behandelt.

Codierung von Programmen: Hier wird gezeigt, wie man Assembler-Programme verschlüsseln kann. Beispiele mit trickreichem, schwer zu durchschauendem Programmaufbau, Nutzung des Timers, um nicht immer mit dem gleichen Byte zu verschlüsseln (wobei u.a. sogar der Video-Controller zeitweilig deaktiviert werden muss, damit er das Timing nicht stört), Einzelschritt-Dekodierung, damit der Cracker nicht einfach nach der Entschlüsselung das Programm ansehen kann und sogar die Nutzung einer angepassten ASCII-Variante zur Dekodierung verdeutlichen, dass man ruhig mal kreativ sein darf, wenn es darum geht, einen Cracker zu verwirren.

Natürlich dürfen auch die Illegal Opcodes nicht fehlen: eigentlich zufällige Nebenprodukte der normalen, offiziellen Assemblerbefehle, weswegen ein normaler Disassembler damit nichts anfangen kann und nur drei Fragezeichen (???) anzeigt, obwohl diese Illegal Opcodes anstandslos ausgeführt werden. Leider drücken sich die Autoren etwas missverständlich aus: Es sei hier noch erwähnt, daß die illegalen Opcodes nur unbeabsichtigte Nebenprodukte des eigentlichen Befehlssatzes sind und aus diesem Grund auch nicht bei jedem Computer die gleiche Wirkung erzielen. - was etwa so klingt, als hätte derselbe Illegal Opcode auf dem einen C64 eine andere Wirkung als auf dem anderen C64. Was aber natürlich nicht der Fall ist, denn sonst hätte man sich die Erklärung der Illegal Opcodes in dem Buch ja auch sparen können. Ansonsten sind die Illegal Opcodes alle tabellarisch aufgeführt, mit Adressierung, Wirkung und sogar den Taktzyklen. Ebenso ein Beispiel, wie man ein kleines Programm Schritt für Schritt durch Einfügen von Illegal Opcodes immer schwerer lesbar machen kann. Insgesamt ist es bei massivem Einsatz von Illegal Opcodes für einen Cracker schwer, überhaupt zu erkennen, was zum Programm gehört und was Daten (oder gar zufälliger Datenmüll) ist.

Auch Dongles werden erklärt, eine Technik, die es vom Prinzip her auch heute noch gibt (heute wären das z.B. USB-Kopierschutzstecker). Also ein kleiner Stecker, der zusätzlich zur Programmdiskette mitgeliefert wird und in den Control-Port des Computers eingesteckt wird und ohne den das Programm nicht funktioniert. Sogar ein kleiner Schaltplan für ein "Dongle mit AND-Gatter" wird abgedruckt. Hier muss man beim Basteln selbst Hand anlegen, aber die Mühe lohnt sich, denn (Zitat aus dem Buch): Der Aufwand, der für den Nachbau eines Dongles erforderlich ist, überschreitet meistens die Arbeitsbereitschaft und vor allem das Fachwissen der Raubkopierer. So kann das Dongle unter Umständen einen idealen Kopierschutz darstellen. Natürlich bleibt auch hier wieder die Herausforderung, die Dongle-Abfrage vorm Cracker zu verstecken.

Der Abschnitt Password-Abfrage gehört eigentlich nicht so richtig zum Thema Kopierschutz und ist auch nur mäßig interessant. Beim Thema "Abfrage einer Tastenkombination" erfährt man aber immerhin ein paar nette Details zum Thema Tastaturabfrage.

4. Directory-Schutz

Dieses Kapitel versucht etwas Ähnliches wie die List-Schutz-Verfahren aus dem zweiten Kapitel, nämlich das Directory für die C64-LIST-Routine unsichtbar zu machen. Dementsprechend funktionieren die meisten Verfahren auch wieder nicht mit SpeedDOS. In jedem Fall sollte man einen Directory-Schutz nur als zusätzliche Hürde ansehen, sich aber nicht darauf verlassen. Thematisch etwas unpassend wird am Ende des Kapitels als allgemeiner Tipp nochmals auf den Compilerschutz verwiesen.

5. Kopierschutz mit der Datasette

Generell wird verdeutlicht, dass jemand mit zwei Kassettenrekordern ganz einfach eine Kopie anfertigen kann; dies lasse sich nicht verhindern. Für eine brauchbare Kopie müssten aber auch Aussteuerung und Tonkopfeinstellung exakt eingestellt sein, und trotzdem wird jede weitere Kopie in der Qualität nachlassen. Wenn sich also auch hier und da eine einzelne Kopie einer Kassette nicht verhindern lässt: Wer aber sein Programm vor einer schnellen und ausgedehnten Verbreitung auf dem schwarzen Markt schützen will, für den bietet die Datasette mehr Kopierschutzmöglichkeiten als eine Diskettenstation. - behaupten zumindest die Autoren. Denn die Aussage steht im Widerspruch zu der Diskussion von Knackmodulen in einem späteren Kapitel.

Jedenfalls werden auch hier verschiedene Verfahren vorgestellt, die in der Entwicklung eines eigenen Aufzeichnungsformats gipfeln. Als Beispiel zeigen die Autoren, wie sie ein eigenes neues Aufzeichnungsformat namens "KKS" (Kassetten-Kopierschutz-System) entwickeln. Damit bekommt man das Wissen an die Hand, um bei Bedarf ein eigenes Format entwickeln zu können, dessen Details keiner kennt und das sich somit nicht ohne weiteres kopieren lässt.

6. Diskettenkopierschutz

Im Grunde nutzt man dabei Eigenheiten und Schwächen des Diskettenlaufwerks aus, um einen Kopierschutz zu verwirklichen. Dabei fängt das Buch mit den allgemeinen Grundlagen zum Laufwerk, zum Disketten-Aufzeichnungsverfahren und zur Formatroutine an, ohne die der Leser die technischen Hintergründe zu den Kopierschutzverfahren nicht verstehen könnte.

So erstellt man mit einer eigenen Formatroutine z.B. eigentlich nicht vorgesehene Tracks (36 bis 41), die von normalen Kopierprogrammen gar nicht berücksichtigt werden. Man vergibt Tracknummern doppelt, um Kopierprogramme zu verwirren. Man erzeugt absichtlich Unregelmäßigkeiten im Disketten-Aufzeichnungsverfahren, wodurch das Kopierprogramm aus dem Tritt kommt usw.

Erstaunlich ist das Verfahren "Halftracks". Aus historischen Gründen unterstützt der Lesekopf im 1541-Laufwerk 80 Halbspuren (Halftracks), der Schreibkopf aber nur 40 "ganze" Spuren. Manche Softwarehersteller nahmen nun ein anderes Laufwerk, um drei Halbspuren nebeneinander unabhängig voneinander mit Daten zu beschreiben. Diese können auch gelesen, vom 1541-Laufwerk aber nicht geschrieben werden, weil der Schreibkopf zu breit ist und somit beim Schreiben immer eine nebenan liegende Halbspur überschreibt. Hier haben sich die Autoren des Buches einen Trick einfallen lassen, um auch mit der 1541 ähnliche Halbspuren schreiben zu können: Mit dem richtigen Timing wird innerhalb einer Disketten-Drehung der Schreibkopf schnell nacheinander auf drei verschiedene nebeneinander liegende Halbspuren gefahren und es werden Daten geschrieben. Zwar nicht ganz so perfekt wie mit einem anderen Laufwerk, aber schwierig genug für Kopierprogramme zu duplizieren.

Am Schluss des Kapitels wird noch schnell eine Befehlszeile gezeigt, mit der man den Inhalt der Diskette zerstören kann, falls die Kopierschutzabfrage festgestellt hat, dass es sich um eine Kopie handelt.

7. Wie man sich gegen Knackmodule schützt

Dann kommen die Knackmodule an die Reihe. Hier versucht man nicht, den Datenträger (Diskette oder Kassette) zu kopieren. Man versucht auch nicht, die Kopierschutzabfrage auszubauen. Stattdessen lädt man das Programm ganz normal, wartet, bis das Programm seinen Kopierschutz abgefragt hat, unterbricht es dann und speichert die benutzten Teile des Speichers ab, dann schnell noch die richtige Einsprungadresse ermitteln, und das Programm läuft wieder. Mit Knackmodulen wird dieser Vorgang automatisiert. Es gibt kaum einen wirksamen Schutz gegen moderne Knackmodule. Im Grunde geben die Autoren zu, dass es das Beste ist, den Diskettenkopierschutz nicht nur einmal ganz am Anfang, sondern immer wieder mal auch bei laufendem Programm abzufragen. Ist das nicht möglich, weil z.B. nur eine Datendiskette benutzt wird, sollte man einige Bytes im Arbeitsspeicher des Diskettenlaufwerks ablegen und periodisch abfragen (unter der Annahme, dass Knackmodule das Floppy-RAM nicht mit abspeichern).

Wer also Datasettenprogramme schützen will, steht etwas dumm da, obwohl im Datasetten-Kapitel noch von den großartigen Möglichkeiten gegenüber der Diskette geschwärmt wurde. Die Autoren zeigen aber zumindest noch speicherinterne Tricks: Register, die sich nicht auf normalem Weg auslesen lassen, und zwar die Stimme 3 des Soundchips und die Alarmzeiten der Echtzeituhren (CIA). Wenn man diese versteckt auf bestimmte Werte setzt und diese dann abfragt, kann man feststellen, dass eine Kopie vorliegt, falls die Werte falsch sind. Die Autoren geben aber zu, dass zukünftige Knackmodule diese Tricks vermutlich werden umgehen können (einschließlich Speichern des Floppy-RAM) und dass der sicherste Schutz die mehrfache Abfrage der Originaldiskette ist.

8. Gerüchteküche

Aus damals aktuellem Anlass (ein Mitarbeiter von Data Becker, dem Verlag, von dem auch das vorliegende Buch stammt, hatte öffentlich angedroht, Raubkopien von zukünftigen Data-Becker-Programmen würden womöglich den Computer des Raubkopierers zerstören) gehen die Autoren der Frage nach, ob das rein mit Software überhaupt möglich wäre. Kurzum: Nein. Es wurden verschiedene Wege ausprobiert (Kurzschluss erzeugen bei der CPU, den CIAs oder den I/O-Chips der Floppy; mechanische Überbeanspruchung des Steppermotors der Floppy), aber nichts konnte einen dauerhaften Schaden an der Hardware erzeugen. Nebenbei wird aber ein interessanter Punkt gestreift, der im Buch sonst nirgendwo Erwähnung findet:

Natürlich war diese Drohung ohne jede Grundlage. Man stelle sich vor: Ein ehrlicher Anwender kauft sich ein Programm, das aufgrund einer Fehlbedienung oder einer ungenau justierten Diskettenstation seinen Kopierschutz nicht erkennt und deshalb dem Rechner ein jähes Ende bereitet. Der Hersteller des Programms sähe einer Flut von Schadenersatzklagen entgegen. - Dass ein ungenau justiertes Diskettenlaufwerk bei einer Kopierschutz-Abfrage Probleme bereiten kann, während es im sonstigen Betrieb gut funktioniert, ist eigentlich eine Basis-Information, die man sich eher am Anfang des Buches oder am Anfang des Kapitels über den Diskettenkopierschutz gewünscht hätte und nicht nur als beiläufige Bemerkung in einem eigentlich fachfremden Kapitel.

Zum Schluss des Kapitels wird noch kurz auf die theoretische Möglichkeit, aber auch praktische Nutzlosigkeit von Viren auf dem C64 eingegangen.

9. Allgemeine Tips

Eine kurze und etwas wahllose Zusammenstellung von Tipps, die teilweise nur wiederholen, teilweise aber auch durchaus neu sind, z.B. Tipps gegen den Einsatz von Single-Step-Simulatoren.

10. Komplettlösung

Ein kleines Programm wird beispielhaft von den Autoren geschützt, einmal ein kleines BASIC-Programmgerüst für Datasette, dann ein kleines Maschinenprogramm für Diskette, um mal einen Gesamtüberblick über das gesamte Vorgehen beim Schützen von Programmen zu bekommen.

11. Was ein Software-Haus über "Cracker" wissen sollte

Unterschieden wird zwischen dem "Möchtegern-Knacker", dem "Durchschnitts-Knacker" und dem "eingefleischten Freak". Beschrieben werden kurz die typischen Vorgehensweisen der verschiedenen Gruppen, damit man seine Schutzmaßnahmen daran ausrichten kann.

Ein interessanter Punkt, der vorher im Buch nicht erwähnt worden war, ist, dass es sinnvoll ist, nicht nur abzufragen: Ist der Kopierschutz noch vorhanden? (Ja/Nein), sondern vom Kopierschutz Daten/Werte abzufragen, die man dann im Programm verwendet. Dadurch wird es auch erschwert, eine nicht funktionierende Kopie doch noch zum Laufen zu bringen, wenn man das Original nicht mehr hat und somit nicht mehr nachvollziehen kann, welcher Wert an einer bestimmten Stelle von der Originaldiskette gelesen werden würde.

Und ein weiterer wichtiger Punkt, der im Buch aber nicht direkt erwähnt wird, ist: Man muss den Anwender bei einer gescheiterten Kopierschutzabfrage nicht einmal darauf hinweisen, dass die Kopie als solche erkannt wurde. Taktisch gesehen wäre es eher ein naives Vorgehen, jetzt eine Bildschirmmeldung einzublenden: "Sie benutzen eine Raubkopie! Programm wird beendet!" (oder so ähnlich). Und zwar einfach deswegen, weil ein Cracker dies bei der Analyse des Programmcodes klar als Sackgasse identifizieren kann. Tatsächlich haben einige Spieler dumm aus der Wäsche geschaut, wenn sie ihre kopierten Spiele nicht zu Ende spielen konnten. Beispiel gefällig?

Eine Spielszene aus Karateka.

Ein Beispiel von vielen: Das Spiel Karateka, kurz vorm Endgegner.

Wenn dieses Federvieh ohne Unterlass angreift, so dass der Spieler gar keine Chance hat und die Spielfigur gleich stirbt, dann sind zuvor die Kopierschutzabfragen gescheitert. Der Spieler dürfte spätestens nach einigen Versuchen merken, dass er unmöglich gewinnen kann, aber bei der Analyse des bloßen Programmcodes ist das keineswegs offensichtlich (Der Nachteil dieser Vorgehensweise ist natürlich, dass der Spieler möglicherweise gar nicht weiß, dass er wegen des Kopierschutzes nicht weiterkommt und somit trotzdem nicht angeregt wird, das Original zu kaufen.). Dies ist eine von neun möglichen Kopierschutzroutinen im C64-Spiel Karateka.

12. Kopierschutz auf dem C128

Hier werden die Kopierschutzverfahren, die im Buch behandelt worden sind, wenn möglich, auf den C128 übertragen (im C128-Modus - der CP/M-Modus wird komplett ignoriert). Schutzprogramme werden ggf. in angepasster Form abgedruckt. Die Datasette wird beim C128 als zu unpopulär angesehen, um mehr dazu zu schreiben. Beim Diskettenkopierschutz wird die 1571-Floppy einfach vor der Kopierschutzabfrage in den 1541-Modus geschaltet und danach wieder zurück. Ob es für den C128 ganz neue Kopierschutzverfahren gibt, die beim C64 gar nicht möglich wären, auf diese Frage gehen die Autoren allerdings nicht ein.

Meinung

Mathias: "Für mich war dieses Buch damals hochinteressant. Dabei habe ich mich gar nicht mit Cracken beschäftigt, auch habe ich nie schützenswerte Programme geschrieben. Somit habe ich auch nur wenige der abgedruckten Programme tatsächlich ausprobiert, sondern die Abläufe mehr theoretisch nachvollzogen. Man könnte sagen, das Lesen dieses Buches hat mich angeregt, mich zum ersten Mal im Leben überhaupt mit den Techniken und Strategien des Kopierschutzes zu beschäftigen... Im Grunde sogar noch allgemeiner: wie jemand versuchen kann, seine Absichten im Programmcode zu verschleiern - und wie man ihm dennoch auf die Schliche kommen kann. Jedenfalls fand ich es schon damals erstaunlich, mit welcher Kreativität und technischem Detailverständnis die Softwarehersteller versucht haben, das Kopieren zu erschweren, welchen Aufwand sie getrieben haben (wenngleich mit geringem Erfolg). Interessant fand ich übrigens die folgende Bemerkung, die ich zu dem Buch im Internet gefunden habe: naja das anti cracker buch kam aber sehr früh raus....die wirklich schwierigen sachen stehen da gar nicht drin. - Nun ja, vielleicht hat dieser Mensch recht. Es kann auch sein, dass spätere Knackmodule oder Diskettenkopierprogramme wie Turbonibbler/Burst Nibbler irgendwann so ausgereift waren, dass man diesen kopierschutzmäßig nichts mehr entgegensetzen konnte. Aber interessant fand ich das Buch damals allemal."

ThunderBlade: "Ein Bekannter von mir besaß das Buch, er hatte das 'Anti' im Titel mit schwarzem Edding übermalt. Ja, er war Cracker und natürlich hocherfreut über dieses Buch, denn es erklärte ja viele Schutztechniken und damit war auch klar, wie man sie als Cracker erkennt und aushebelt. Ich hab mir das Buch später selbst auch besorgt und muss sagen: Es war wirklich toll geschrieben und faszinierend. In der Praxis natürlich eher wenig zu gebrauchen, da die meisten Schutzmethoden sehr simpel zu umgehen waren, aber Laien konnte man damit natürlich noch beeindrucken. Erst im hinteren Teil des Buches kamen ein paar wirklich gute Sachen, z.B. die Geschichte mit der Alarmzeit in der CIA, die ein Freezer nicht auslesen kann: Man setzte früh im Programm die Uhrzeit auf 3 Uhr und den Alarm auf z.B. 3:10 Uhr. Ging dieser Alarm später nicht los (irgendein Bit wurde gesetzt), wusste man, dass gefreezt und der Speicherinhalt abgespeichert wurde, um das Programm später wieder zu starten. Man konnte reagieren, z.B. mit einem merkwürdigen Absturz. Das war schon lustig. Tolle Zeit damals..."

Weblinks

• Katalog der Deutschen Nationalbibliothek: 3-89011-253-6
• Thema: Suche Infos über Kopierschutz-Methoden auf Forum64.de; ein Forenteilnehmer äußert sich skeptisch über das "Anti-Cracker-Buch".
• Volltext auf archive.org

Dieser Artikel wurde Artikel des Monats.