Beiträge von markusC64 im Thema „GEOS-Kopierschutz“

    Bei 1581: Auf physischen Track 80 (normal gibt es nur Tracks 0 bis 79) als normaler Sektor gespeichert.

    5. Es scheint keinen einzigen Emulator zu geben, der den unter 3 genannten Kopierschutz mit einer 1581 emulieren kann. Wir haben hier den ersten identifizierten Kopierschutz für eine 1581.

    Mal sehen, was raus wird: Bitte melde dich an, um diesen Link zu sehen.

    Da ist übrigens auch eine erweiterte D81, die den zusätzlichen Track hat - um das Problem testen zu können.

    Aber ich habe einen Weg gefunden, die Ultimate davon zu überteugen, dass man eine echte Masterdiskette emuliert. So dass man Masters auf echten Floppies und Bootdisketten erstellen kann.

    C=Mac Falls Du das Testen willst - dann sag mir Bescheid. Ich mache gerade selbst einen ersten Test außerhalb des Emulators. Der aber sehr erfolgversprechend verläuft.

    Vor einem Public Release braucht es aber noch ein paar Tests.

    Wenn beim Booten der Kopierschutz keine Rolle spielt.

    Frage ich mich warum meine G64-Kopie (mit BurstNibbler), nicht mal bootet.

    Zum einen war die Kopie vor der Installation erstellt, zum anderen könnte das Original extra lange Tracks haben, damit Kopierprogramme kürzen müssen und aus Sicht des Herstellers hoffentlich falsch kürzen.

    Sollte dies die U II+ können oder ist dies nicht integriert (D64 oder G64)?

    Ist in beiden (D64 und G64) nicht darstellbar. Aber ich habe einen Weg gefunden, die Ultimate davon zu überteugen, dass man eine echte Masterdiskette emuliert. So dass man Masters auf echten Floppies und Bootdisketten erstellen kann.

    Wenn man nämlich auf die Speedänderung verzichtet, dann ist es in G64 darstellbar. Die Kunst ist es jetzt, das ohne Patch der Diskette hinzubekommen. Hinweis: Es geht, ohne Diskette zu patchen und/oder Ultimate Firmware zu verändern.

    Könnte man BurstNibbler anpassen oder ist dies technisch nicht möglich?

    Der kann keine Ahnung haben, wo die Speed wechselt - somit ist das zum Scheitern verurteilt.

    Endet mit gleichem Fehler....

    Entweder Jiffydos, oder ungünstige Rotationsgeschwindigkeit der Floppy.

    Wobei Jiffydos 1571 ich noch ausprobieren werde - aber die interne Floppy im DCR ist ja nun auch wieder leicht anders... Wer Lust hat, kann solche Kombinationen ja mal im VICE ausprobieren. Masterdisk Image für VICE ist ja nebenan.

    end-checksum

    gcr 00

    gcr 00

    bytes aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab

    Das ist nichts - wenn eine 1541/1571 (und die hat in der Emulation die Diskette beschrieben) den Sektor schreibt, passt das im Gegensatz zum Master nicht bitgenau. "aa" ist "55" einmal geshiftet, das ist die ganz normale Lücke.

    ... immerhin habe ich es jetzt endlich mal geschafft ... nach gefühlt 20 Diskettenwechseln ... eine neue Masterdiskette zu erstellen!

    Was meinst Du, warum ich Masterdisketten grundsätzlich nur mit zwei Floppies erstelle?

    Und diese neu erstellte MasterDisk funktioniert dann auch (damit nochmal eine Masterdisk erstellen)? Das wäre für mich das Kriterium : Funktioniert.

    Ja. Die funktioniert - im Emulator. Die P64 auf eine echte Diskette zum Testen zu übertragen ist sehr schwierig. Ich hatte über Nacht aber eine Idee, wie man das auf echter Floppy testen kann, ohne den Weg über D81 zu gehen.

    Nein ... das kann nicht sein meines Erachtens. Das müsste man alles erstmal an einem Echtsytem verifizieren. Von daher ist deine Aussage b.a.w. *pending*.

    Man kann es in einer gepatchten 1541U2+ Firmware, die sämtliche MFM Controller Zugriffe protokolliert, sehen: Er versucht den Track

    a) Beim Abfragen des Kopierschutzes anzufahren

    b) Beim Aufbringen des Kopierschutzes zu formatieren, hier steigt leider die Ultimate aus, weil D81 den Track nicht hat.

    Wenn ich die Abfrage (a) patche (1 Byte), so dass die auf Track 79 geht und die Daten in dem Sektor hinterlege, dann kommen sämtliche Emulationen über die Abfrage hinweg.

    Ich habe eine Menge rausgefunden über den Wheels-Kopierschutz - bei allen Versionen gleich (C64, C128 V4.1 bis 4.4):

    1. Beim Booten von Wheels kommt keine Kopierschutzabfrage zum Tragen, auch nicht von Master Disks. Das gilt sowohl für 1541/71 als auch 1581.

    2. Der Registriername/nummer steht eigentlich zwei Mal im Image, auf jeder Seite einmal (bei 1581 ist naürlich alles auf einer Diskette ohne umdrehen, die Seitenangabe ist für 1541). In der Datei "MakeSysDisk" auf der Rückseite im Klartext und auf der Vorderseite mit einer Substitutionschiffre in der Datei "system2" bzw. "128system2" (welche sich durch EOR #$FF, LSR A" dekodieren lässt.

    3. Darüber hinaus steht der Registrierungsname auch noch im Kopierschutz, welcher weder mit G64 noch mit D81 darstellbar ist (mit erweitertem D81 aber schon, aber ein solches habe ich noch nirgends gesehen):

    Bei 1541: Auf der Vorderseite auf Track 35 hinter dem Sektor 16 in der Gap mit abweichender Speed 3

    Bei 1581: Auf physischen Track 80 (normal gibt es nur Tracks 0 bis 79) als normaler Sektor gespeichert.

    Dort kommt jeweils die selbe Substitutionschiffre wie oben erwähnt zum Einsatz.

    4. Die unterschiedliche Speed auf Teilen des Tracks 35 kann zweifellos Burstnibbler nicht kopieren. Auch kein anderes mir bekanntes Kopierprogramm, weil es kein Sektor ist, sondern nur Gap. Turbonibbler 4 kann ja abweichend Speeds pro Sektorblock bzw. Headerblock erkennen, aber auch nicht für die Gap.

    5. Es scheint keinen einzigen Emulator zu geben, der den unter 3 genannten Kopierschutz mit einer 1581 emulieren kann. Wir haben hier den ersten identifizierten Kopierschutz für eine 1581.

    6. MakeSysDisk prüft, ob alle 3 Stellen, die die Registerierungsdaten enthalten, übereinstimmen.

    Interessantes Detail:

    Ich habe aus dem großen Geos Buch, 3. Auflage mir mal das Basic-Programm angesehen, welches von Geos 1.2 den Kopierschutz cracken soll.

    Man glaubt es kaum: Man soll erst auf der Kopie der Diskette Platz schaffen, dann Geos Boot umbenennen und dann das Basic Programm laufen lassen.

    Wozu? Um an Ende 1 Byte gepatched zu haben.

    Ein D64 der Originaldiskette mit diesem Patch macht exakt das selbe:

    Offset Original Neu

    00000CD4: 1D A2

    Das wäre auch in reinen Basic 2.0 ganz sicher einfacher gegangen. :smile:

    Allerdings tut es der 1 Byte Patch wirklich :smile:


    Edit: Dagegen ist der Patch aus 64'er 10/87 echt lang, viele Bytes werden gepatched. Jedoch zumindest ohne extra vorher was machen zu müssen.

    Edit 2: Damit das nicht zu einfach ist, hat das Basic Listing auch noch einen Druckfehler im gr. Geos Buch.

    Vom Primzip hast Du ja Recht. Anderseits sind da die Daten ohne Sync drauf. Und jede Menge nichtdienliche Daten dazwischen - damit ein Kopierprogramm, welches die Tracklänge anpassen muss (es ist klar, dass Burstnibbler u. ä. dioe Tracklänge auf die sich aus der Rotationsgeschwindigkeit ergebenden Länge anpassen muss) keine Ahnung hat, was es weglassen darf und was nicht.

    Und noch was ist in die Wagschale zu verfen: Auch bei den Geos US Originalen war Berkeley Softworks recht früh auf "55 67" Gaps gewechselt. "GeoWrite Workshop", der eindeutig noch zu Geos 1.3 gehörte, hat bereits den neueren Kopierschutz. Ein US "GeoFile" haben wir auch mit dem neuen Kopierschutz, ebenso GeoPublish. Es kommen also nur die sehr frühen Applikationen in Betracht, das kann unmöglich eine größere Anzahl sein.

    Beim Geos 1.0 hat Zoomfloppy mit nibread jedenfalls komplett versagt, der resultierende Track 36 war unbrauchbar.

    Außerdem ist meine Intention beim Schreiben des Tools eine andere gewesen: Ich wollte prüfen, ob ich die korrekten Bytes identifiziert habe. Und darüber hinaus, wenn hoffentlich weitere US Datenträger auftauchen, den Track einfach auf eine Kopie zu schreiben und die bekannten 55 67 Gaps aufbringen. Wenn es dann geht, weiß ich mit Minimalaufwand, dass es ein bekannter Kopierschutz ist (inkl. Bytefolge bekannt) und kann mit einem weiteren Versuch den zwischen Tailgaps und Track 36 eingrenzen.

    PS: Ich habe bewusst nicht geschrieben: Es wird auf "7D 67 45" geprüft. Das wird es nämlich nicht. Sondern es wird auf "7D 67" geprüft und das nächste Byte geht in Berechnungen ein, so dass beim falschen Byte vorhersehbar ein Crash folgt...

    Bei weiteren Tests ist mir aufgefallen, dass mein Kopierschutzauftrageprogramm nach einem

    poke 2384,24

    noch besser funktioniert. Natürlich kann man es nach dem Patch per POKE auch wieder abspeichern, wenn man möchte.

    Hintergrund: Das Bytepattern wurde zu oft auf dem Track geschrieben, so dass es nicht draufpasste. Macht eigentlich nicht viel aus, aber an der Stelle, wo er dann aufhört, könnte eine falsche Bytekombination übrigbleiben. Die Chance, dass er ausgerechnet an der Stelle beim Einlesen ist, ist zwar minimal, aber dennoch ist die Optimierung nicht verkehrt.

    Nach längerer Zeit ist mir jezt doch etwas in Sachen Geos 1.2 Kopierschutz über den Weg gelaufen:


    Ich habe versucht, ein Geos 1.2 mit der Upgradediskette, die den 1351 Mäüsen und den 1764 REUs beiliegt, zu updaten. Machen wir es kurz: Viele der Disketten lassen sich so nicht updaten :smile:


    Das Upgrade fragt irgendetwas auf Track 36 ab, welches von der normalen Kopierschutzabfrage nicht erfasst wird. Das bekannte Kopierschutzauftrageprogramm aus dem Anti Cracker Buch von Data Becker trägt zwar einen Kopierschutz auf, der Geos 1.2 überzeugt, aber nicht das Updateprogramm.
    Heraus kommt eine nicht funktionsfähige Diskette.

    Das Rätsel wäre gelöst - hat ja auch lange genug gedauert.

    Geos 1.2 erwartet auf Track 36 bekanntlich die Bytes "2F 53 77". Ein auf Geos 1.3 geupdates Geos 1.2 erwartet ebenfalls "2F 53 77" beim Start von Geos Boot. Beim Start des Kernals wird Track 36 aber nochmals kontrolliert und diesmal werden die Bytes "7D 67 45" erwartet. Dem Anschein nach sind jene Bytes bereits auf einer Geos 1.2 Diskette vorhanden, aber nicht auf einer mittels des Kopierschutzauftrageprogrammes aus dem Anti Cracker Buch von Data Becker erzeugten Kopie.

    Machen wir die Liste vollständig: Geos 1.0 erwartet die Bytes "62 73 77" auf Track 36, einige ältere US Applikationen bei der Installation "B5 DD 77". Weitere abgefragte Bytekombinationen auf Track 36 sind mir (bisher) nicht untergekommen.

    Beigefügtes Programm trägt auf Track 36 alle 4 zuvor genannten Bytekombinationen auf, so dass man einen für Geos Programme universell verwendbaren Track 36 erhält.

    Ja, das ist kein Tippfehler. Die Geos 128 "nicht 2.0, sondern die Erste" hat in den Icons von Desktop und Konfigurueren jeweils die Versionsnummer 1.4 eingeblendet. Ich habe die jetzt nämlich und mache eine deinstallierte Version fertig.

    Somit haben wir die vermisste 1.4 endlich gefunden :smile: :smile:

    Nachtrag: Jetzt, wo wir die Versionsnummer jenes Geos kennen, nenn wir es ab sofort beim Namen: "Geos 128 1.4" zur klaren Unterscheidung von "Geos 128 2.0", denn das Kürzel "Geos 128" könnte ja beide meinen.

    Ein weiteres Detail zum Kopierschutz von Geos:

    In den Versionen Geos 64 2.0, Geos 128 2.0 sowie Geos 128 1.4, nicht jedoch Geos 1.3 ist ein Fehler in der Implementierung vorhanden: Bei der Installation wird die Seriennummer zufällig erzeugt und in die Systemdisk sowie in die Sicherheitssystemdisk eingetragen. Dabei wird die Installationsroutine auf der Systemdisk überschrieben, um eine einfache Deinstallation zu vermeiden. Auf der Sicherheitssystemdisk bleibt die Installationsroutine jedoch intakt, was eine Deinstallation ermöglicht.

    Bei den mir vorliegenden echt jungfräulichen Geosversionen stellt man überdies hinaus fest, dass sich die Sicherheitssystemdisk und die Systemdisk jedoch identisch bis auf den Diskettennamen. Dies kann man sich zunutze machen und einfach 2 Kopien vom Sicherheitssystem erzeugen und eine davon in "System" umbenennen. So bekommt man zusammen mit Bitte melde dich an, um diesen Link zu sehen. jede Systemdisk deinstalliert.

    Ich habe da mal eine kleine Frage zum Geos Kopierschutz:

    In der Wolke habe ich ein (gecracktes) Geos 1.0 gefunden. Ab $C196 scheint dort keine Seriennummernabfrage zu sein... Kann es sein, dass Berkeley Softworks die damals noch nicht hatte?


    Und eine Erklärung, worum GeoMerge so schwer deinstalliert werden kann, möchte ich gerade auch noch geben:
    An der Stelle, wo die Seriennummer steht, wird bei Auslieferung eine 0 eingetragen (unverschlüsselt). Stellt GeoMerge beim Sart fest, dass dort eine 0 steht, so wird ein fest einkodierter Block nachgeladen (außerhalb des Dateisystems, per "B-A" alloziert), eine Prüfsumme gebildet und wenn die passt, der Block ausgeführt. Jener Block beinhaltet die Kopierschutzabfrage.
    Wenn der Kopierschutz passt, wird die Kopierschutzabfrage mit einer Kopie der BAM überschriben.

    Der VLIR-Record, indem die Seriennummer steht, wird bei GeoMerge aber nicht einfach gepatched (das wäre zu einfach), sondern komplett neu gespeichert - so dass dafür neue freie Sektoren gesucht werden. Dabei gehen die schönen Tailgaps vom Kopierschutz kaputt.

    Beim Deinstallieren muss man also 4 Dinge erledigen:
    1. Seriennummer auf 0 setzen.
    2. Wiederherstellung des Blockes mit der Kopierschutzabfrage
    3. Falls jener Block nicht belegt ist (kann durch VALIDATE freigegeben sein), per B-A allozieren.
    4. Tailgaps wieder neu aufbringen.

    Der Punkt 4 ist der, der quasi die Erstellung eines Deinstallers für den C64 / C128 verhindert.

    Nach längerer Zeit ist mir jezt doch etwas in Sachen Geos 1.2 Kopierschutz über den Weg gelaufen:

    Ich habe versucht, ein Geos 1.2 mit der Upgradediskette, die den 1351 Mäüsen und den 1764 REUs beiliegt, zu updaten. Machen wir es kurz: Viele der Disketten lassen sich so nicht updaten :smile:

    Das Upgrade fragt irgendetwas auf Track 36 ab, welches von der normalen Kopierschutzabfrage nicht erfasst wird. Das bekannte Kopierschutzauftrageprogramm aus dem Anti Cracker Buch von Data Becker trägt zwar einen Kopierschutz auf, der Geos 1.2 überzeugt, aber nicht das Updateprogramm.
    Heraus kommt eine nicht funktionsfähige Diskette.

    Und noch besser: Während des Upgrades wird der Kopierschutz auf Track 36 geupdated, so dass er danach sowohl für Geos 1.2 als auch für Geos 1.3 (US) passt. Man kann weiterhn den Disketteninhalt sicherheitskopieren, wie man es von Geos 1.2 kennt. Und so auch zwischen Geos 1.2 und 1.3 wechsel (indem man den pasenden Inhalt draufkopiert, ohne den Kopierschutz auf Track 36 anzurühren).