Hello, Guest the thread was called12k times and contains 116 replays

last post from Stephan Scheuer at the

Kopierschutzverfahren gelüftet

  • Das hatte ich vor etwa 8 Monaten in einer ersteigerten Diskbox gefunden. Da diese Software sehr selten ist, habe ich diese gleich archiviert und decompiliert.

    So hat jeder was davon, und so wie du, erinnern sich einige sogar noch an diese und jenes Program und schwelgt in Erinnerungen.:)

    Dann danke fürs Retten!!!!

    Wer weiß, vielleicht war das die Disketten-box meines Lehrers :D


    Jetzt kommt für mich der Hammer. Der Lizenznehmer der Disketten war mein Direktor!!!

  • Ich will den ja nicht selber schreiben, sondern nur nach C# umsetzen.

    "tlr" hat den Decompiler doch schon für den PC umgesetzt. Der hat zwar auch so seine Probleme mit Extensions, wie die C64 Vorlage auch, aber "normaler" BASIC Code lässt sich damit wunderbar decompilieren.

    Ja super! Das kannte ich noch gar nicht!

  • Das ist wirklich eine tolle Arbeit, die ihr da leistet - auch technisch sehr interessant, auch wenn ich da nicht sooo tief drin stecke. Zudem fange ich nach nem Dachbodenfund eines C64 auch erst langsam wieder mit der Materie an.
    Da ich diese Programme früher benutzt habe, wollte ich mal wieder reinschnuppern über den Emulator. Und dadurch habe ich eine ganz andere Frage: hat wer nen Scan der Handbücher der Französisch Programme vom C64? Konkret geht es mir nämlich um die Tastenbelegung für die französischen Akzente. Ich weiß, dass es wie beim Amiga (da hab ich Originale und auch Handbücher) über F-Tasten geht. Aber die Cedille (das Häkchen unter dem c) bekomme ich nicht hin.

  • Eines von denen:
    Etudes_Francaises_Echanges_Edition_Longue_1_1988_Heureka_Teachware

    Etudes_Francaises_Echanges_Edition_Longue_2_1988_Heureka_Teachware

    Etudes_Francaises_Echanges_Edition_Longue_3_1988_Heureka_Teachware

    Etudes_Francaises_Echanges_Edition_Longue_4_1988_Heureka_Teachware

    Ich denke, die Tastenbelegung dürfte bei allen gleich sein.

  • Austro-Comp RT-Code Sprungtabelle ganz unten dokumentiert. Die nächsten Dokumentierungen werden die Zeropage Adressen sein.

    Die jetzigen Kommentare habe ich einer dokumentierten C64 Zeropage Liste entnommen, die so natürlich fast alle nicht stimmen.:)

  • Wer hat noch HEUREKA-Teachware Sachen in seinem Fundus?


    Bitte mal nachschauen ... ich hätte das GEO plus - Das konstruktive Geometrieprogramm noch komplett in OVP. Lauffähig natürlich mit intaktem Kopierschutz ... ;).

    Habe gerade genau das gleiche bei mir gefunden: GEO plus mit Box, Handbuch, Diskette (ohne Probleme lesbar, gerade getestet).


    Dazu noch: C64 Basic - Lernspiele für Einsteiger - nur die Originaldiskette. Kein Buch, keine Box, kein nix … ebenfalls fehlerfrei getestet.


    Falls da jemand Interesse hat, einfach melden. ;)

  • Built Jul 5 2015 18:09:57

    'c:/c64/nibtools/05072015/nibread.exe GEOPLUSA.NIB '



    18.0: (2)

    CID: 'OS'

    FID: 'OS'



    1.0: (3) 7703 (7703)

    2.0: (3) 7702 (7702)

    3.0: (3) 7702 (7702)

    4.0: (3) 7703 (7703)

    5.0: (3) 7702 (7702)

    6.0: (3) 7703 (7703)

    7.0: (3) 7703 (7703)

    8.0: (3) 7702 (7702)

    9.0: (3) 7703 (7703)

    10.0: (3) 7704 (7704)

    11.0: (3) 7704 (7704)

    12.0: (3) 7703 (7703)

    13.0: (3) 7703 (7703)

    14.0: (3) 7703 (7703)

    15.0: (3) 7702 (7702)

    16.0: (3) 7703 (7703)

    17.0: (3) 7703 (7703)

    18.0: (2) 7172 (7172)

    19.0: (2) 7171 (7171)

    20.0: (2) 7171 (7171)

    21.0: (2) 7172 (7172)

    22.0: (2) 7171 (7171)

    23.0: (2) 7171 (7171)

    24.0: (2) 7172 (7172)

    25.0: (1) 6709 (6709)

    26.0: (1) 6709 (6709)

    27.0: (1) 6709 (6709)

    28.0: (1) 6709 (6709)

    29.0: (1) 6709 (6709)

    30.0: (1) 6709 (6709)

    31.0: (0) 6239 (6239)

    32.0: (0) 6239 (6239)

    33.0: (0) 6239 (6239)

    34.0: (0) 6239 (6239)

    35.0: (0) 6239 (6239)

    36.0: (1 NOSYNC!) 0 [Unformatted Track] (0)

    37.0: (1 NOSYNC!) 0 [Unformatted Track] (0)

    38.0: (1 NOSYNC!) 0 [Unformatted Track] (0)

    39.0: (1 NOSYNC!) 0 [Unformatted Track] (0)

    40.0: (1 NOSYNC!) 0 [Unformatted Track] (0)

    41.0: (1 NOSYNC!) 0 [Unformatted Track] (0)


    *WOW!* :thumbsup:

  • Hallo,


    Hier nochmal die Anleitung zum patchen von Heureka geschützten G64 images.
    Im Kern ist es die gleiche Anleitung, die ich schon im Wiki veröffentlicht habe, nur in deutsch.


    Zunächst noch einmal kurz was den Heureka Kopierschutz ausmacht:

    Auf einer Spur zwischen 2 und 7 (ich nehme hier mal 2) sind auf der Diskette ein oder mehrere Sektoren, die mit einer etwas langsameren Geschwindigkeit geschrieben wurden.

    Auf Spur 31 der Diskette sind ein oder mehrere Sektoren, die mit einer etwas schnelleren Geschwindigkeit geschrieben wurden.

    Wenn man die Diskette normal ausliest, dann fällt das nicht weiter auf, da die 1541 soviel Toleranz hat, dass sie diese Sektoren ohne Fehler lesen kann.


    Aber die Gesamtlänge von Spur 2 ist etwas länger als normal und die von Spur 31 ist etwas kürzer als normal.

    Das wird vom Kopierschutz über die Zeit ausgemessen.


    Zum herausfinden, welche die untere Spur ist (zwischen 2 und 7) einfach das Programm laden und schauen, wo es hängen bleibt, bzw. prüft.

    (In Vice wird die Spur unten rechts angezeigt).


    Nun stellt sich damit die Frage, wie kann ich in einem G64 die Spur kürzer oder länger machen?


    Die 1541 kennt 4 verschiedene Schreib/Lesegeschwindigkeiten, die sogenannten Speed Zones.
    Speed Zone 3 ist die langsamste und Speed Zone 0 die schnellste.
    Das G64 Format erlaubt es die Speed Zone pro Spur, aber auch für jedes Byte auf einer Spur zu setzen.


    Idee:
    Ich könnte man für eine längere Spur einfach für ein paar Bytes eine langsamere Speed Zone einstellen und für eine kürzere Spur entsprechend eine schnellere Speed Zone.

    Geht nicht weil:

    - Spur 2 soll länger werden, liegt aber schon in der langsamsten Speed Zone

    - Spur 31 soll kürzer werden, liegt aber schon in der schnellsten Speed Zone

    - Die langsamere bzw. schnellere Geschwindigkeit mit der die Sektoren bei Heureka geschrieben wurden entsprechen keiner Speed Zone, die die 1541 kennt.

    - Wenn ich etwas an der Speed Zone innerhalb der Spur ändern würde, dann würde die 1541 das dort nicht mehr lesen können.

    - Kein Emulator unterstützt das Feature des G64 Formats, dass man innerhalb einer Spur die Speed Zone für einzelne Bytes anders definiert.


    d.h. wir sind auf die Standard Geschwindigkeit der Spur festgelegt.

    Stephan hat nun herausgefunden, wie lang die Spuren in einem G64 image sein müssen, damit die Kopierschutzprüfung sie als OK bewertet.


    Das sind für Spur 2 0x1EEF Bytes und für Spur 31 0x1710 Bytes. Ich habe da snochmal mit einer Heureka Diskette ausprobiert und für Spur 2 muss die Länge zwischen

    0x1EE1 und 0x1EF6 liegen (Emulator mit 300 rpm für 1541), Spur 31 muss einfach nur kürzer als 0x1753 Bytes sein.


    Die normale Spurlänge für Spur 2 ist in einem G64 in etwa bei ~0x1DF0, es fehlen also so 200 bis 250 Bytes.

    Nun können wir ausnutzen, dass wir ein Image und einen Emulator haben, denn im Prinzip können wir die Spur im Image ja beliebig lang machen.

    Bei 300 rpm dreht die Diskette einmal pro 200 ms. Wenn nun Spur 2 im Emulator 205 ms benötigt, dann geht erstmal nichts kaputt.


    Normal besteht eine Spur aus:


    SYNC

    Headerdaten

    Lückenbytes

    SYNC

    Sektordaten

    Lückenbytes


    Wir können nun bei den Lückenbytes ansetzen und dort einfach mehr Lückenbytes daraus machen.


    Schauen wir mal in ein G64 rein, dort stehen am Anfang die Positionen im Image, wo die Daten zu den Spuren anfangen:


    Spur 2 fängt also bei 0x26EA an.


    Schauen wir dort, finden wir als erste zwei Bytes die aktuelle Spurlänge in Bytes:


    Unsere aktuelle Spurlänge ist also 0x1E23.


    Um 0x1EEF zu erreichen benötigen wir also 0x1EEF - 0x1E23 = 0xCC = 204 bytes mehr.


    Nun fügen sich die Bytes direkt im G64 schwer ein, daher konvertieren wir das G64 zu einer editierbaren Textdatei mit G64Conv.

    (von MarkusC64 https://github.com/markusC64/g64conv )

    mit "g64conv image.g64 image.txt".


    image.txt öffnen wir im Texteditor und suchen nach "track 3", so dass wir am Ende von Track 2 stehen.

    Was sehen wir?

    Im Prinzip das gleiche Muster, was ich oben beschrieben habe:

    SYNC

    Headerdaten

    Lückenbytes

    SYNC

    Sektordaten

    Lückenbytes

    Nun können wir bei den hinteren Lückenbytes noch 204 hinzufügen:


    Zum prüfen, konvertieren wir das image zurück: "g64conv image.txt test.g64"

    Dann benutzen wir das gleiche Vorgehen wie oben, um die Spurlänge von Spur 2 zu ermitteln. Dort sollte nun EF 1E stehen, falls wir uns nicht verzählt haben.

    Damit wäre Spur 2 OK.


    Was machen wir nun mit Spur 31?

    Nach dergleichen Methode wie oben ist bei mir im G64 die Spur 31 bei 0x04441E und ist 0x1869 Bytes lang.

    Wenn wir wenigsten eine Länge von 0x1753 haben wollen, dann müssen wir 0x1869 - 0x1753 = 0x02A5 = 116 Bytes entfernen.


    Das ist ganz schön viel und die Spur ist voll mit Daten, die wir nicht einfach rausnehmen können.


    Pragmatisch angesetzt, können wir nur die Lückenbytes entfernen und hoffen, dass die Spur am Ende kürzer als 0x1753 ist.

    Also suchen wir "track 32" und beginnen rückwärts alle Lückenbytes mit ";" auszukommentieren, bis wir den Spuranfang erreichen.


    Das ist ein wenig Editierarbeit.


    Nun speichern wir und konvertieren den Text zurück zu einem G64: "g64conv image.txt test.g64"

    Wahrscheinlich meckert nun g64conv, dass die Anzahl der Bits in Spur 31 nicht durch 8 teilbar ist.

    Also gehen wir nochmal ans Ende von Spur 31 (einfach "track 32") suchen.

    Und fügen am Ende von Spur 31 noch "bits 111111" ein. (Hier exemplarisch 6, müssen eben soviele sein, dass die Gesamtzahl der Bits für Spur 31 durch 8 teilbar ist)

    Wenn das stimmt, dann bekommen wir wieder ein G64.

    Aus Interesse können wir nochmal die Methode von oben nutzen und uns die neue Länge von Spur 31 anschauen. Bei meinem Image ist sie nun 0x16C6 und damit kleiner als 0x1753.


    Damit haben wir ein lauffähiges G64 Images des Heureka geschützten Programms.
    Wir mussten keinen Programmcode patchen, sondern nur das Image etwas anpassen.


    Done.


    Ich habe nun im Wiki alle G64 Images der Original Kryofluxstreams entsprechend angepasst, so dass diese im Emulator wieder laufen.


    Danke nochmals Stephan für die notwendige Analyse der Heureka Abfrage und der Timing bzw. Längenwerte. Ohne Dich hätten wir das nicht hinbekommen.

  • Done.

    Im Prinzip sind es nur die Prüftracks, die gemessen werden. Timing-Messung der Länge der beiden Tracks (1 Umdrehung; ggf. mehrfaches Anfahren des S/L-Kopfes).


    Beispiele:


    Titel Prüftracks P-Tr Tr P-Tr

    ---------------------------------

    ALI 1001 02 <-18-> 31

    ALI V4.0 02 <-18-> 31

    Modern course Gym 1 02 <-18-> 31

    Modern course Gym 4 02 <-18-> 31

    Modern course Gym 5 02 <-18-> 31

    Modern course Gym 6 02 <-18-> 31

    Let's Go 2 04 <-18-> 31

    Let's Go 3 05 <-18-> 31

    Let's Go 5 07 <-18-> 31

    Green Line 1 03 <-18-> 31

    Green Line 2 04 <-18-> 31

    Green Line 3 05 <-18-> 31

    Green Line 4 06 <-18-> 31

    Orange Line 1 03 <-18-> 31

    Orange Line 2 04 <-18-> 31

    Red Line 1 03 <-18-> 31

    Red Line 3 05 <-18-> 31

    Neue Rechenmax 02 <-18-> 31

    Etudes Francaises 2 02 <-18-> 31

    Edition Longue 1 02 <-18-> 31

    Edition Longue 2 02 <-18-> 31

    Edition Longue 3 02 <-18-> 31

    Edition Longue 4 02 <-18-> 31

    Edition Courte 1 03 <-18-> 31

    Bruchtrainer 5./6. 02 <-18-> 31

    Geo-plus 02 <-18-> 31

    OPTI-MA 02 <-18-> 31

    Storytime I 02 <-18-> 31

    Storytime II 02 <-18-> 31

    ---------------------------------


    Prüftrack 31 ist kritisch, wenn man den auf $1700 Länge stark kürzt. Dann fliegt nämlich der letzte Sektor 16 auf dem Track 31 hinten als fehlerhaft (READ ERROR) raus.


    Den einstelligen Prüftrack füllt man mit der exakten Anzahl an Filler Bytes am Ende auf: $1EEF - $1EXX = XXX Bytes


    Den Prüftrack 31 kürzt man < $1753 in den Header Gap (never read) in jedem Sektor (16 x 9 Bytes -> was nicht ausreicht) und in den Füllbytes ... Hauptsache dann < $1753 Tracklänge, so dass der letzte Sektor 16 auf Track 31 korrekt auf den Track draufpasst.

  • Danke!:)


    Ich hatte vor Jahren versucht, "ALI 1001" zu kopieren. Ohne Erfolg, egal welches Kopierprogramm ich nutzte. Erst als ich es geschafft hatte, "Learning English - Green Line 1" zu decompilieren,

    verstand ich den Kopierschutz und auch, warum es mit einer 1541 unmöglich ist, diesen zu reproduzieren.


    Nun kann man diese Methode nutzen, um möglichst alles von Heureka-Teachware für die Nachwelt zu sichern.:)

  • Ich habe mit der "Learning English Modern Course 1" ein seltsames Ergebnis. Ich habe gerade éinen (nicht meinen) Kryofluxdump nach P64 gewandelt. Da ist eigentlich kaum etwas dabei - beides sind Fluxbasierte Formate - es geht im Wesentlichen darum, exakte eine Rotation abzupassen und das dann die Flux unter Anpassung der Clockfrequenz ins P64 zu schreiben.


    Die erste Frage, die sich stellt ist immer: Ist die P64 korrekt? Hm, die Beta von g64conv, die ich erstellt habe, bekommt den gesamten Disketteninhalt ohne Fehler gelesen in dem Sinne, dass ein g64 ohne Fehler erstellt wird, also alle Sektoren ok. [Edit: Demnach habe ich die Rotation exakt getroffen!]


    Beim selben P64 meint Vice, Lesefehler zu haben. Das ist aus zwei Gründen unlogisch: Zum einen ist die Diskette unverändert nach P64 umgesetzt worden. Zum anderen kann g64conv alles lesen.


    Kann es sein, dass die P64 Emulation noch "Luft nach oben" hat?

    Ok, ein schnelles Suchen mit ripgrep meint, VICE benutze dazu die Funktion "P64PulseStreamConvertToGCRWithLogic" aus der P64 Library aus dem Micro 64 in einer inzwischen erweiterten Version (doppelseitiges P64). Und "micro64disktool" liefert interessanterweise die selben Lesefehler.


    Demnach die Vermutung: Kann es sein, dass die dortige Inpertretation der Flux noch Luft nach oben hat?


    Edit: Ich kann natürlich gerne das P64 zur Verfügung stellen, wenn es hilft.

  • Ich gebe mir gerade mal selbst die Antwort: P64 Support in VICE hat Bugs. An der Stelle, wo die gespeicherte Rotation aufhört und die neue natlos anfangen sollte, passieren Bitfehler. Liegt dort eine GAP, ist das ohne Folgen. Ansonsten hat man halt einen Lesefehler.

  • Am Beispiel „Learning English, Modern Course 1“ habe ich das mit einer nichtöffentlichen Alpha von g64conv analysiert - hier ein Auszug aus Track 31:


    Man sieht sehr deutlich, dass Track 31 Sektor 10 sehr viel langsamer geschrieben worden ist als der Sektor 9 davor. Bei der Speedzone wäre ein Wert von 4 µs theoretisch optimal.

    Bei Track 2 sind mehr Speedwerte verändert worden - ich führe den für den Kopierschutz relevanten hier auf mit einem Vergleichswert:


    Hier wäre ein Wert von 3,25µs der ideale Wert.


    Sektor 9 hat 3,32µs pro Bit (hier nicht aufgeführt)

    Sektor 10 hat bspw. 3.54µs pro Bit(hier nicht aufgeführt)

    Sektor 11 hat 3,17 µs pro Bit

    Sektor 12 hat 3,17µs pro Bit.

    Sektor 13 dagegen wieder 3,30µs pro Bit (hier nicht aufgeführt) - alles gemessen.


    Edit: Mit g64conv messe ich die Dauer der 10 bzw. 325 Rawbytes. Also nicht die Gaps, sondern nur der eigentliche Block (Block kann dabei Headerblock oder Datenblock sein, daher auch die 2 Größen).