Einen 40 Jahre alten Kopierschutz-Dongle aushebeln

• Ein Fallbeispiel, bei dem ein Parallelport-Dongle, den ein RPG-II-Compiler für die Buchhaltung aus den 1990er-Jahren verlangte, analysiert und sein Verhalten nachgebildet wurde
• Die Originalsoftware läuft in einer DOS-Konsole unter Windows 98 und funktioniert ohne den Dongle nicht
• Nach der Übertragung des Disk-Images in einen Emulator zeigte die Analyse, dass in ausführbaren Dateien wie RPGC.EXE und SEU.EXE dieselbe Kopierschutz-Routine eingebettet ist
• Durch Assembler-Analyse wurde bestätigt, dass die Routine immer denselben Konstantenwert (7606h) zurückgibt; mit einem 4-Byte-Patch ließ sich die Dongle-Prüfung umgehen
• Dadurch kann der RPG-II-Compiler von Software West auch ohne Dongle ausgeführt werden – ein bedeutender Erfolg im Hinblick auf die Bewahrung klassischer Software

---

Uralte Buchhaltungssoftware und die Entdeckung des Dongles

• Eine 40 Jahre lang genutzte RPG-basierte Buchhaltungssoftware war noch immer auf einem Windows-98-PC im Einsatz
  • RPG ist eine Sprache für Midrange-Computer wie IBM System/3, System/32 und AS/400 und wurde später auf MS-DOS portiert
• Das Programm verlangte beim Start einen Hardware-Dongle als Kopierschutz am Parallelport
  • Auf dem Dongle waren noch schwach „Stamford, CT“ und das Logo von „Software Security Inc.“ zu erkennen
  • Das Wort „RUNTIME“ war aufgedruckt; seine Bedeutung wurde erst später in der Analyse klar

Analyse des Disk-Images und Aufbau des RPG-Compilers

• Das Disk-Image des Windows-98-Systems wurde extrahiert und in einem Emulator ausgeführt
  • Es wurden zwei Versionen des RPG-II-Compilers (von Software West Inc.) sowie der vollständige RPG-Quellcode der Buchhaltungssoftware gefunden
  • Das System bestand aus mehreren RPG-Modulen und einem menübasierten System aus DOS-Batch-Dateien
• Der Compiler selbst führte die Dongle-Prüfung durch und fügte dieselbe Schutzroutine auch in die erzeugten ausführbaren Dateien ein

Reverse Engineering der Parallelport-Kommunikationsroutine

• SEU.EXE wurde mit dem Reko-Disassembler analysiert
  • Zunächst waren keine in-/out-Befehle zu sehen, sie wurden jedoch in einem anderen Segment (0800h) gefunden
  • Die betreffende Routine liest die Parallelport-Adresse aus dem BIOS-Datenbereich und sendet bzw. empfängt Daten über den LPT1-Port
  • Das Ergebnis wird im Register BX gespeichert; es gibt keinen Eingabewert, und die Routine liefert immer dasselbe Ergebnis zurück

Herleitung des Konstantenwerts und Patch

• Am Ende der Routine wurde bestätigt, dass der Wert von BH fest auf 76h gesetzt ist
  • Nur der Wert von BL blieb unbekannt; der Bereich 0–255 wurde per Brute Force durchsucht
  • Die richtige Kombination war BL=06h, also BX=7606h
• Die ersten 4 Bytes der Routine wurden durch MOV BX,7606h und RETF ersetzt, um die Dongle-Prüfung zu umgehen
  • Danach startete das Programm sofort, und dieselbe Änderung konnte auch auf andere ausführbare Dateien mit derselben Routine angewendet werden

Ergebnis und Bedeutung

• In allen Komponenten des RPG-II-Compilers wurde derselbe Kopierschutz-Code gefunden, sodass eine einheitliche Anpassung möglich war
• Der Dongle war so aufgebaut, dass er lediglich einen Konstantenwert zurückgibt und sich daher mit nur einem 4-Byte-Patch deaktivieren ließ
• Der modifizierte Compiler funktioniert auch ohne Dongle einwandfrei; nach Entfernung personenbezogener Daten soll er künftig als historisches Software-Archiv veröffentlicht werden
• Da zu Software West Inc. online kaum noch Materialien existieren, hofft der Autor auf weiteren Kontakt mit dem ursprünglichen Hersteller

[GN⁺]

Hacker-News-Kommentare

• Frühere Software-Schutzmechanismen waren wirklich extrem simpel
  Ich hatte einmal eine Windows-3.11-Upgrade-Diskette, deren Installer fehlschlug, wenn keine frühere Version installiert war.
  Die Lösung war einfach, eine leere Textdatei zu erstellen und sie als win.com zu speichern. Der Installer scannte die ganze Festplatte und suchte nur nach dieser Datei.
  Tatsächlich enthielt die Upgrade-Diskette die vollständige Installation. Damals war wirklich alles sehr simpel.

  • Als ich klein war, kaufte mein Vater die Upgrade-Version von Windows 3.1. Auf der Packung stand, ein Upgrade von „Version 3.0 oder niedriger“ sei möglich, tatsächlich wurde aber nur 3.x erkannt.
    Am Ende besorgten wir uns von einem Freund eine 3.x-Version und installierten damit — ich fand das moralisch vertretbar, weil es nicht der Werbung entsprach.
    Ein Foto des Produkts gibt es in diesem eBay-Link.

• Ich entwickle Software für das Bauingenieurwesen (mes100.com).
  Es gibt noch heute Nutzer, die Hardware-Dongles bevorzugen. Sie fühlen sich wohler, wenn sie ein physisches Gerät in der Hand haben.
  Da wir unbefristete Lizenzen verkaufen, ist es problematisch, wenn ein Dongle kaputtgeht und es keine Ersatzteile mehr gibt. Cloud-Lizenzen mögen sie nicht, aber sie ermöglichen umsatz auf Abonnementbasis.
  Trotzdem kursieren gecrackte Versionen online, egal wie sehr man sich bemüht. Uns fehlen die Mittel für rechtliche Schritte, daher ist Schutz unverzichtbar.

  • Ein Grund für die Vorliebe für solche Dongles sind Air-Gap-Umgebungen. Dort, wo sensible Konstruktionsdaten verarbeitet werden — etwa beim Militär oder in der Kernenergie — ist eine Verbindung zu externen Netzwerken unmöglich.
    Andere mögen einfach die Autonomie, nicht von Servern Dritter abhängig zu sein.
  • Es hieß, in stark regulierten Branchen ändere sich alles nur langsam und es gebe daher wenig Anreiz für Upgrades — dann stellt sich aber die Frage, warum Nutzer überhaupt weiterzahlen sollten.
  • Mein Vater nutzte für ein Bauingenieurprogramm namens „Cosmos“ ebenfalls so einen Dongle. Ich erinnere mich noch gut daran, wie nervig es war, wenn er manchmal nicht erkannt wurde.
  • Aus Sicht der Nutzer ist die Haltung „nicht ersetzen, solange es nicht kaputt ist“ völlig rational.
    Deshalb ist das SaaS-Modell für Nutzer fast ein Desaster. Ich mag Raubkopien nicht, aber SaaS mag ich genauso wenig.

• Früher waren Cracks viel einfacher.
  Oft reichte es, einfach JE oder JNE in JMP zu ändern, um den Schutz zu umgehen.
  Der entscheidende Punkt war, herauszufinden, wo der Schutzcode sitzt und wie er funktioniert.

  • Solch einfacher Schutz entsteht aus mehreren Gründen.
    Erstens arbeiten Entwickler viel länger mit dem Code als wir, daher machen zu komplexe Schutzmechanismen Bugfixes schwieriger.
    Zweitens muss ein Hacker nur ein paar Tricks kennen, während der Entwickler alle diese Tricks abwehren muss.
    Drittens ist Schutzfunktionalität eine undankbare Aufgabe, die keinen Ruhm bringt, daher fehlt oft die Motivation.
  • Ich habe einmal Demo-Software in einem Debugger geöffnet, und im Memory-Dump stand der Aktivierungscode als String einfach im Klartext.
    Ich gab ihn ein und die Software wurde sofort aktiviert. Später habe ich sie dann regulär gekauft.
  • Ich habe einmal den ProLok-„laser protection“-Schutz von dBASE III geknackt.
    Die Diskette wurde per Laser signiert, aber selbst ein Teenager, der Assembler lesen konnte, konnte das leicht umgehen.
    Man konnte sie sogar kopieren, indem man die Diskette einfach mit einer Nadel ankratzte. Am Ende war das ein Fall, in dem Marketing der Technik voraus war.

• In den 80ern schrieb ich RPG-II-Code und half in den 90ern bei der Migration in eine S/36-Emulationsumgebung.
  Wir nutzten ein Produkt der Firma California Software Products, und es funktionierte ziemlich gut, sodass das Unternehmen bis zur Rente des Gründers weiterbestand.

• Zur Aussage „Ist dieser Kopierschutz nicht viel zu simpel?“: Ich denke, für die damalige Zeit war das angemessenes Engineering.
  Mit Emulatoren und Decompilern ließ sich das vielleicht in ein paar Tagen lösen, aber damals gab es oft nicht einmal solche Werkzeuge.

  • Wichtig ist die Zielgruppe. Wenn man normale Unternehmen in nichttechnischen Branchen aufhalten will, muss man keine professionellen Reverse Engineers stoppen.
  • Decompiler konnten den Schutzcode nicht analysieren.
    90 % der Software aus dieser Zeit waren wirklich so simpel. Es ist nicht so, dass man etwas Komplexeres übersehen hätte.
  • Um das Jahr 2000 herum machte ich bei einem kleinen Telekommunikationsanbieter in Buenos Aires ähnliche Hacking-Arbeiten. Der Schwierigkeitsgrad entsprach meist dem, was der OP beschrieben hat.
  • Auch unsere IT-Firma schützt Dinge, indem sie verdächtige Dateien bitweise verschiebt und daraus eine Magic Number gewinnt. Es muss nicht kompliziert sein.

• Als Kind habe ich einmal ein Ultima-Spiel gecrackt.
  Ich wollte nicht ständig wieder die Floppy einlegen müssen. Der Code entschlüsselte sich selbst und las die Startadresse aus einem bestimmten Sektor der Diskette.
  Dieser Sektor ließ sich mit normalen Kopiertools nicht duplizieren, aber ich löste das Problem, indem ich den Header der ausführbaren Datei änderte.

• Anfang der 90er wartete ich ein selbst entwickeltes Lizenzverlängerungssystem der Zentrale einer Franchise-Kette.
  Es musste jeden Monat per Floppy erneuert werden, und die Zentrale sperrte mitunter nach Belieben Filialen, die ihr nicht gefielen.
  Schließlich schlossen sich mehrere Filialen zusammen und klagten, und ich erstellte einen DOS-basierten Lizenzgenerator, damit jede Filiale telefonisch einen Code bekommen und ihre Lizenz verlängern konnte.
  Nach Ende des Prozesses verteilte ich einen Patch, der die Lizenzprüfung vollständig entfernte. Irgendwann möchte ich das in DOSBox noch einmal laufen lassen.

• Es war interessant zu lesen, dass Windows 95 noch immer produktiv eingesetzt wird.
  Anders als bei den schillernden AI-Trends verläuft technologischer Wandel in den langweiligen Bereichen der Industrie nur langsam.

  • Ich habe noch 2014 ein Unternehmen gesehen, das Windows 95 virtualisiert betrieb. Es handelte sich um alte medizinische Software, die erstaunlich stabil war.
  • Den Screenshots nach zu urteilen sieht das Programm nach DOS-Software aus. Windows wurde vermutlich einfach nur für Dateifreigaben verwendet.
  • Win95 ist erst 30 Jahre alt und läuft auf mancher modernen Hardware noch immer.
    Es gibt sogar noch Systeme, die in einem PDP-11-Emulator laufen.

• Beeindruckend ist, dass diese Software und Hardware in manchen Unternehmen noch immer im Einsatz sind.
  Deshalb könnte die Veröffentlichung einer gecrackten Version ein rechtliches Risiko darstellen.
  Unternehmen zahlen viel Geld, um alte Systeme am Laufen zu halten, und so bleibt diese Vendor-Lock-in-Situation bestehen.
  Falls Patente oder geistige Eigentumsrechte noch gültig sind, sollte man das vor einer Veröffentlichung unbedingt prüfen.

• Ein Hardware-Dongle, der einfach nur eine feste Zahl zurückgibt — das ist wirklich ein sehr einfacher Schutzmechanismus.
  Aber damals reichte das eben aus. Selbst heutige Unternehmenssoftware nutzt oft kaum mehr als Lizenzschlüssel.
  Im Grunde war das die 80er-Jahre-Version des Konzepts: „Wenn es signalisiert, dass eine Rechnung existiert, wird schon bezahlt.“