Hallo Besucher, der Thread wurde 7,1k mal aufgerufen und enthält 23 Antworten

letzter Beitrag von markusC64 am

nibconv67.exe fügt GEOS die TAIL GAPS (Kopierschutz), bei der Umwandlung von D64 zu G64, hinzu

    Was ist nibconv67:

    • Ist ein Windows Programm zum Konvertieren von D64 Image Dateien zu G64 Image Dateien mit gleichzeitiger Wiederherstellung des Kopierschutzes (TAIL GAPS) für GEOS.


    Benutzung von nibconv67:

    • Das Programme nibconv67 wird auf der Kommandozeile (CMD) ausgeführt. Dazu wird die Programmdatei nibconv67.exe am Besten in das Verzeichnis, in dem sich D64 Images befinden, kopiert.
    • nibconv67.exe –a0 <Quell-Image.D64> <Ziel-Image.G64>
    • z.B. nibconv67.exe –a0 GEOS.D64 GEOS.G64
    • Der Parameter -a0 (“Align all tracks to sector 0.”) sollte immer mit angeben werden. Dieser bewirkt, dass in dem G64 Image die 0 Sektoren immer am Beginn jeder Spur (Track) geschrieben werden. Das G64 Image ist damit einfach schicker :)


    Wie ist nibconv67 entstanden:

    • Nibconv67 ist aus dem Programm nibconv.exe entstanden. Das Programm nibconv.exe ist Bestandteil der nibtools (LINK) und wird benutzt um Images von einem Datenformate in ein anderes zu konvertieren. Es wird in erster Line verwendet, um *.nib Dateien (erstellt von der nibread.exe) in emulatorentaugliche *.g64 Dateien zu konvertieren. Es kann jedoch auch D64 Images in G64 Images konvertieren. Das macht im ersten Moment zwar wenig Sinn, ist aber möglich. Bei der Konvertierung von D64 zu G64 werden den Daten aus dem D64 noch Informationen, wie die Lücken (zwischen Sektor Header und Sektor Daten, TAIL GAPS), hinzugefügt und daraus das G64 Images erzeugt. Das normale nibconv erzeugt dabei Standard Lücken, welche mit dem Wert $55 gefüllt werden. Mein nibconv67 hat eine kleine Änderung erhalten, so dass keine Standard Lücken erzeugt werden. Nibconv67 schreibt die GEOS typischen Lücken (TAIL GAPS), welche mit … $55 $67 $55 $55 $67 enden, in alle Sektoren in allen Spuren. Die letzte 67 hat mich zum Namen nibvconv67 inspiriert.
    • Im Anhang sind 28 Folien zur Entstehung zu finden. Die Qualität ist der Uploaddatenmengenbeschränkung geschuldet. Die Folien zeigen den Weg vom Auschecken der nibtools über das Kompilieren der nibtools (mit MS VS) bis hin zur Änderung und dem Erstellen des nibconv67.


    Warum wurde nibconv67 entwickelt:

    • Für den Erhalt von Software, in diesem Fall GEOS 2.0 deutsch für C64 und C128.
    • Es ist leichter D64 Images, als G64 Images zu erstellen.
    • Es existieren alte bereits erstellt D64 Images, welche funktionsfähig gemacht werden können. Ich habe im Internet z.B. ein D64 Images gefunden, welches wohl von einer un-installierten „GEOS 128 2.0 (Disk 2) - Seite B: Write Utilities“ erstellt worden ist. Vielleicht gibt es von solchen Schätzen noch mehr. Immer her damit … :)


    Wofür ist nibconv67 in erster Linie gedacht:

    • Nibconv67 ist vorrangig, für die deutschen 2.0 Versionen von Geos 64, Geos 128, Geos 64 GEORAM, Geos 128 GEORAM zu verwenden. Es könnte jedoch noch weitere Geos Version oder Applikationen geben, bei denen nibconv67 auch funktioniert.
    • Auf folgende Disketten ist nibconv67 anwendbar:
    • ...Systemdisketten Geos 64 2.0 deutsch
    • ......GEOS 64 2.0 (Disk 1) Seite A: Systemdiskette
    • ......GEOS 64 2.0 (Disk 2) Seite A Sicherungssystem
    • ......GEOS 2.0r (DISK 1) SIDE A: 64 SYSTEM
    • ......GEOS 2.0r (DISK 2) SIDE A: 64 BACKUP SYSTEM
    • ...Systemdisketten Geos 128 2.0 deutsch
    • ......GEOS 128 2.0 (Disk 1) Seite A: Systemdiskette
    • ......GEOS 128 2.0 (Disk 2) Seite A: Sicherungssystem
    • ......GEOS 2.0r (DISK 1) SIDE B: 128 SYSTEM
    • ......GEOS 2.0r (DISK 2) SIDE B: 128 BACKUP SYSTEM
    • ...Applikationen Geos 64 2.0 deutsch
    • ......GEOS 64 2.0 (Disk 1) Seite B: Applikationen
    • ......GEOS 64 2.0 (Disk 2) Seite B: Write Utilities
    • ...Applikationen Geos 128 2.0 deutsch
    • ......GEOS 128 2.0 (Disk 1) Seite B: Applikationen
    • ......GEOS 128 2.0 (Disk 2) Seite B: Write Utilities
    • Hinweis: Auch die aufgeführten Applikationsdisketten besitzen den Geos Kopierschutz (TAIL GAPS). Dieser wird aber nur bei der Installation der Applikationen abgefragt. Nach der Installation benötigen die Applikationsdisketten den Geos Kopierschutz (TAIL GAPS) für die Benutzung der Programme nicht mehr und können auch mit simplen Kopierprogrammen kopiert werden. Zu Deinstallation von Applikationen (nur bei GeoWrite, soweit bekannt, möglich), wird jedoch der Geos Kopierschutz (TAIL GAPS) auf den Disketten benötigt.


    Woran erinnert die Vorgehensweise von nibconv67:

    • Ja, genau an die von „Unseen“ beschriebene Holzhammermethode siehe HIER bzw. HIER
    • Im Gegensatz zur harten Vorgehensweise der Holzhammermethode, verwendet nibconv67 eher ein hoch präzises Skalpell, um die Änderungen durchzuführen.
    • Da bei der Umwandlung von einem D64 Image in ein G64 Image die Lücken (zwischen Header und Daten und Daten und Header) erst neu erzeugt werden, kann nibconv67 genau an den richtigen Stellen die Änderungen vornehmen. Die Holzhammermethode, welche auf Suchen und Ersetzen basiert, könnte unter Umständen falsche Daten ändern, da es nicht die genauen Positionen der Lücken kennt.

    Anhänge:

    • nibconv67.zip … enthält das Programm nibconv67.exe, ein Beispiel GEOS.D64 Image, 2 Bilder als Schnellanleitung sowie eine BAT Datei zum exemplarischen Konvertieren des GEOS.DE64 Image
    • Entstehung von nibconv67 Folie 1-8.zip … enthält die Folien 1 bis 8
    • Entstehung von nibconv67 Folie 9-16.zip … enthält die Folien 9 bis 16
    • Entstehung von nibconv67 Folie 17-23.zip … enthält die Folien 17 bis 23
    • Entstehung von nibconv67 Folie 24-28.zip … enthält die Folien 24 bis 28


    EDIT by FXXS: internen Link repariert

    Zitat von ZAK256

    Nibconv67 schreibt die GEOS typischen Lücken (TAIL GAPS), welche mit … $55 $67 $55 $55 $67 enden, in alle Sektoren in allen Spuren.


    Warum in allen Spuren und nicht nur da wo sie auf den Orginaldisks vorhanden sind? Genau das war der Grund, wieso ich meinen Weg als "Holzhammermethode" bezeichnet habe.


    Zitat

    Da bei der Umwandlung von einem D64 Image in ein G64 Image die Lücken (zwischen Header und Daten und Daten und Header) erst neu erzeugt werden, kann nibconv67 genau an den richtigen Stellen die Änderungen vornehmen. Die Holzhammermethode, welche auf Suchen und Ersetzen basiert, könnte unter Umständen falsche Daten ändern, da es nicht die genauen Positionen der Lücken kennt.


    Kannst du mal anhand eines Beispiels demonstrieren, wo in einem GEOS-Systemdisk-G64-Image an einer "falschen" Stelle die Sequenz 55 ff ff ff auftauchen kann?

    Zitat von Unseen

    Warum in allen Spuren und nicht nur da wo sie auf den Orginaldisks vorhanden sind? Genau das war der Grund, wieso ich meinen Weg als "Holzhammermethode" bezeichnet habe.


    Ok, das war erst einmal am einfachsten. Man könnte da noch eine Erweiterung vornehmen.
    Hm, kann es sein, das die Tracks mit den TAIL GAPS nicht auf allen Geos Disketten die gleichen sind? Kannst du mir die entsprechenden Tracks vielleicht sogar nennen?
    Dann müsste man dem nibcon67 noch einen Parameter mit dem entsprechenden Track mitgeben. Etwas aufwendiger, könnte ich aber noch mal in Angriff nehmen. Ist aber für den Benutzer, dann aber auch schwerer zu bedienen.


    Zitat von Unseen

    Kannst du mal anhand eines Beispiels demonstrieren, wo in einem GEOS-Systemdisk-G64-Image an einer "falschen" Stelle die Sequenz 55 ff ff ff auftauchen kann?


    Auf diese Frage habe ich fast schon gewartet :)
    Ich weiß, durch die GCR Kodierung, ist es unmöglich, das die Sequenz 55 FF FF FF an falschen Stellen auftaucht. Somit sind die GCR Daten des G64 Images 100% sicher. Mir ging es eher um den Header einer G64 Image Datei. So sollte es hier im Moment auch kein Problem mit der Sequenz 55 FF FF FF geben, da diese auch hier gar nicht auftauchen sollte/kann. Es könnte aber unter Umständen Änderungen an dem G64 Dateiformat geben, so dass andere zusätzliche Information im Header speichert. Und genau diese könnten unter Umständen betroffen sein.
    Ok, zugegeben sehr gekünsteltes Beispiel :)
    Ich wollte deine Holzhammermethode überhaupt nicht kritisieren! Durch deine Methode (und deinen Auszug aus dem GEOS Kopierschutz plus den Kommentaren) habe ich erst die Funktionsweise des GEOS Kopierschutzes verstanden. Mir geht es nur um den Erhalt von GEOS.

    Macht dies auch die GEOS-Disketten bootfähig?


    Zitat von ZAK256

    Nibconv67 schreibt die GEOS typischen Lücken (TAIL GAPS), welche mit … $55 $67 $55 $55 $67 enden, in alle Sektoren in allen Spuren. Die letzte 67 hat mich zum Namen nibvconv67 inspiriert.

    Wenn das alles ist, könnte man das eigentlich auch direkt im Emulator einbauen. Dann bräuchte man gar kein G64 mehr erstellen.

    Zitat von ZAK256

    Hm, kann es sein, das die Tracks mit den TAIL GAPS nicht auf allen Geos Disketten die gleichen sind? Kannst du mir die entsprechenden Tracks vielleicht sogar nennen?


    Bei den Systemdisketten ist es Track 21, andere GEOS-Disks habe ich nicht analysiert.

    Zitat von Unseen

    Warum in allen Spuren und nicht nur da wo sie auf den Orginaldisks vorhanden sind? Genau das war der Grund, wieso ich meinen Weg als "Holzhammermethode" bezeichnet habe.


    Hm, ich habe nochmal ein paar System- und Applikationsdisketten- Images angesehen, welche wohl von originalen Disketten erstellt (ge-nibbelt) worden sind.
    So z.B. die aus dem Post (LINK) und auch ein paar NIB Images, welche mit dem 8 Bit Search (LINK) zu finden sind.


    Alle diese Images weisen die TAIL GAPS in allen Tracks auf und nicht nur auf einem bestimmten TRACK.


    Vielleicht war die "Holzhammermethode" somit besser als du dachtest.

    Ich fummele gerade mit dem Holzhammer/diesem Tool (bzw. dem Fix von marcusc64) viel rum, und sehe entsprechend viele eigene und besorgte Images durch. Dabei sind mir ein paar Kopierschutz-relevante Eckwerte aufgefallen, die mir vorher nicht bewusst waren. Mag der eine oder andere vielleicht auch ein wenig interessant finden:


    -Bis Geos V1.3 von Februar/März 1987 wird der alte Kopierschutzansatz eingesetzt (Check auf Track 36).


    -Mindestens ab Geos V1.3Ge (also deutsche Fassung) von November/Dezember 1987 wird der neue Ansatz verfolgt ($67er Tail Gaps), ab da funktioniert dieses Tool also erfolgreich.


    -Spätestens ab V1.5 von Mai 1988 ist das auch international der Fall. Bei V2.0 (August 1988) sowieso.

    Sag nicht, Du hast die Deutsche GEOS 1.3 (mit beiden Disketten doppelseitig)? Die fehlt in meiner Sammlung nämlich noch...

    Gut, dann sag' ich's nicht. :)


    (Ist leider nicht "jungfräulich", hat auch ein-zwei read errors auf einem Image, und nur D64. Aber, ja. Gehörte einem Schulfreund, der mir alles überlassen hat als er sein C64-Geraffel nicht mehr wollte. Insofern weiss ich einigermassen verifizierbar, was es ist und wo es herkommt. Keine Flohmarktware oder so. Ist es genehm wenn ich's hier reinhänge?)

    Sehr gerne.
    Wobei das mit den uninstallieren auch ohne solches Programm mit etwas Glück später klappen könnte: Wir bräuchten "nur" einen zweiten Satz mit anderer Seriennummer. Die wenigen Bytes, die bei beiden unterschiedlich sind, müssen es sein - so die Erfahrung mit den Nachfolgern sowie mit sämtlichen Apps, die installiert werden müssen.
    Edit: Ja, bei den 1-2 read errors gibt es auch Unterscheide - aber die Sektoren können wir ignorieren, weil dort dann ja offenbar nichts wesentliches für die Seriennummer ist.

    Danke. Ich hoffe dann mal, dass es möglich ist, für den erwähnten Vergleich später noch einen Satz (zumindest Teilsatz) zu finden.

    Ich bin mal so frei und repariere die Diskette mit den Lesefehlern (Sicherheitssystem), indem ich die beschädigten Sektoren von der Diskette "System" ersetze. Klappt den ersten Test nach einwandfei.


    Weiterhin ein Ergebnis mit der Seriennummer: Die kann in der d64 mit einem Hexeditor ab Offset 190c5 (hex) gepatcht werden (2 Bytes) - jeweils auf den Disks "System" und "Sicherheitssystem". Die Seriennummer ist dort unverschlüsselt.


    Edit: Ändert man mit dem Hexeditor ab den zuvor genannten Offset 3 Bytes jeweils in "00" ab, so ist dem ersten Eindruck nach die Diskette uninstalliert.

    Zitat von GenerationCBM

    -Bis Geos V1.3 von Februar/März 1987 wird der alte Kopierschutzansatz eingesetzt (Check auf Track 36).

    Es gibt davon offensichtlich mehrere Varianten, sprich, was auf Track 36 drauf sein muss. Ich habe hier schon mal zwei Varianten als g64 bei Geos 1.2 (PAL).
    Übrigens: Geos 1.2 wird auch installiert, nur bringt es bei der Installation keine Meldung, so dass der Benutzer nichts von der Installation sieht.

    Zitat von markusC64

    Ich bin mal so frei und repariere die Diskette mit den Lesefehlern (Sicherheitssystem), indem ich die beschädigten Sektoren von der Diskette "System" ersetze. Klappt den ersten Test nach einwandfei.

    Sicher dass das reicht? Geos beschwert sich beim Booten dass ein Block als fehlerhaft markiert ist. Die Diskette bootet auch, wenn man die Error Information im Image einfach löscht ohne die betroffenen Blöcke wirklich zu reparieren.


    Zitat von markusC64

    Es gibt davon offensichtlich mehrere Varianten, sprich, was auf Track 36 drauf sein muss.

    Glaube ich unbesehen. Wissen wir, wo/wann der "Trojaner"-Schutz ausser Dienst gestellt wurde? Geschah das analog zum Wechsel von Track36 auf $67er Tail Gaps?

    Sorry, da ist wohl beim Upload was schiefgegangen - muss eine Datei verwechselt haben. Irren ist menschlich.
    Sicherheitshalber nehme ich jetzt mal die uninstalierte g64, die geht und ist getestet.
    Und ja, das obige Vorgehen reicht wirklich, man muss nur dabei daran denken, am Ende den Block mit der Defektliste im d64 auch zu löschen.
    nibconv wird Dir daraus die d64 wieder machen.


    Zitat von GenerationCBM

    Wissen wir, wo/wann der "Trojaner"-Schutz ausser Dienst gestellt wurde? Geschah das analog zum Wechsel von Track36 auf $67er Tail Gaps?

    Könnten wir bestenfalls herausbekommen, wenn wir internationale Versionen auch sammeln - aber selbst dann ist das nicht trivial, weil man ja den Crack erst lückenhaft machen muss.

    Hab' mich misverständlich ausgedrückt, sorry. Aber die uninstallierte Version zu haben ist auch gut, danke.


    Was ich meinte: wie prüfst du, ob der Fix der beiden Read Errors erfolgreich ist? Naheliegende Blöcke sind schonmal nicht identisch zwischen System und Sicherheitssystem. Woher wissen wir also, dass just diese beiden übertragbar sind? (So auf den ersten Blick würde ich sagen, in dem Bereich liegen Druckertreiber?)


    Geos prüft beim Booten ja nicht den Inhalt dieser Sektoren, sondern das Booten des noch defekten D64 scheitert lediglich, weil die Sektoren als fehlerhaft markiert sind. Löscht man die Fehlerinformation, bootet es auch ohne echte Reparatur.

    Gnaugenommen müsste ich das noch etwas genauer prüfen. Aber die ganze nähere Umgebung ist im Hex-Editor gleich. Die haben offensichtlich die gemeinsamen Dateien der beiden Disketten auf der gleichen Position.


    Für eine genauere Prüfung müsste man jede Datei nach cvt exportieren und die dann vergleichen.

    Zitat von markusC64

    Für eine genauere Prüfung müsste man jede Datei nach cvt exportieren und die dann vergleichen.

    Hab' ich mal gemacht.


    Von den Dateien, die nicht sowieso komplett identisch auf beiden Disketten sind, unterscheiden sich sieben Stück nur minimal in wenigen Bytes oder (Treiber-)Versionen voneinander (geos, mps 1200, oki 120, okimate 10, star nl-10(com), star sg-10 -15, voreinstellung).


    Bleiben noch 13 Dateien, die nicht auf System sondern nur auf Sicherheitssystem sind (hp laserjet, imagewrite, imagewriter II, notizblock, okimate 20, preferences, rboot, rechner, roma_ge, scribe, text-manager, university_ge, wecker). Keine davon scheint mir irgendwie defekt zu sein, auch nicht wenn ich sie mit ihren Entsprechungen auf der Drivers- und der Anwendungsdiskette vergleiche - da sind's auch wiederum nur minimale Byte- und Sprach-Unterschiede. Einzig die Datei "Preferences" hat keine Entsprechung, sondern ist nur auf Sicherheitssystem, kann also nicht verglichen werden. Sieht mir aber auch okay aus.


    Kurz und gut: ich finde nichts, was den als defekt markierten Sektoren in exportierten Dateien entsprechen würde. Glück gehabt und das ist Leer- oder Swapfile-Bereich?

    Danke. Das sind ja mal ausgesprochen gute Nachrichten.


    Irgendeien Ahnung, wie viele Kopierschutzvaranten Geos verwendet hat?


    Das Ziel dieses Threads ist ja, Software - insbesondere Geos - zu erhalten. Wenn die Anzahl der Geos-Kopierschutzvarianten überschaubar ist, könnte man nibconv nochmal erweitern.