Posts by frank128

    zum Thema Transcopy Versionen

    vcfed.org


    Lemmings / 1st rivision / Weak bit Copy Protection on Track 0-0

    Lemmings / 2nd rivision / Weak bit Copy Protection on Track 0-0

    Lemmings / 3rd rivision / Weak bit Copy Protection on Track 0-0


    Quote

    Rob Northern Copylock: Uses weak bits and calculates the entropy expected. Encrypts the actual executable and stores a 32-bit decryption number on a bad sector

    Quote

    I have Lemmings both 5.25" and 3.5" Lemmings have copy protected on Track 0-4 with weak beat method.


    Quote

    3.5" version of Lemmings can be dumped as td0 disk image to run PCE (IBM PC Emulator). I use teledisk 2.15 to dump on real DOS (6.22 or under) Lemmings can't be copied to other disk without Trans Copy Option Board. But it can be run on PCE emulator with TD0 format. PCE supports copy protected track / sector via INT-13 emulaton.


    Quote

    Sorry to bump this slightly old thread, but I'm currently trying to image lemmings with the softwares you listed (teledisk, anadisk and fda6.1) and I can't get it to work, I keep getting "Please insert Lemmings disk in drive A or B" error meaning the copy wasn't good.


    Ziemlich konfus das Thema

    Mit Option Board Deluxe, Kryoflux, SuperCard und einem normalen FDC auf der einen Seite stehen diverse Floppy Disk Drives (5,25", 3,5", DD, HD) auf der anderen Seite. Bisher hatte bei mir jedes System (mehr oder weniger) seine eigenen Floppy Drives. Das ist so nicht mehr tragbar. Daher suche ich eine Möglichkeit, Disk Drives und Controller flexibel zu kombinieren.


    Kleinster gemeinsamer Nenner wäre hier der 34-Pin Anschluss, wenn man 8" Laufwerke außen vor lässt. Ich könnte externe Drive-Boxes mit je zwei Floppy Drives und eigener Stromversorgung und mit einer 43pin Buchse (oder Stecker) versehen. Diese könnte ich dann flexibel mit dem PC (normaler FDC, Option Board) , KryoFlux oder Superdisk verbinden.


    Macht das Sinn? Was muss man wegen der Kabellänge und der Terminierung beachten?

    Das Gerücht mit der Sabotage der eigenen Software durch Centralpoint ist mir bekannt. Interessant wäre hier, ob die Verschlimmbesserung nur TransCopy, oder auch die Firmware auf dem Option Board Deluxe betrifft.


    Zu meiner konkreten Situation: Die Lemmings 3,5" DD 720 KByte Floppy mit 80 Spuren kann Transcopy erst ab der Version 5.X lesen. Somit fallen leider alle älteren TransCopy Versionen unterhalb der Version 5.0 unter den Tisch. Neben der Version 5.4 habe ich nur noch eine Version 5.2 finden können. Was ich in diesem Thread erfragen will, sind mögliche Optionen, "Weak Bits" auf der Original Floppy durch einen direkten Vergleich mit einer Kopie nachweisen zu können.


    Mittlerweile bezweifele ich, dass man über normale BIOS 13 calls (Vergleich auf sich ändernde Bits/Bytes) auf diese "Weak Bits" stößt. Die Abfrage läuft vermutlich direkt über den FDC.

    Ich versuche schon seit 2015 (natürlich mit großen Pausen) den Weak Bits basierenden Kopierschutz von DOS Game "Lemmings" (PSYGNOSIS 1991) zu analysieren. Bekannt ist, dass es sich hier um einen Weak Bits Kopierschutz im Track 0:0 handelt. Dabei gab es für mich zwei Wege der Analyse - erstens das Debugging des Programms mit der Suche nach dem Programmcode der die Weak Bits Erkennung durchführt, und zweitens die Analyse des Datenträgers selbst. Beim Punkt 1 komme ich erst mal nicht weiter (und soll auch Off-Topic für diesen Thread sein). Was mich derzeit interessiert (und on-topic für diesen Thread) ist, wie (Methoden) und mit welchen Tools erkenne ich diese weak bits. Das Kopieren der Originalfloppy mit Transcopy und dem Option Board Deluxe war nicht erfolgreich. Lemmings akzeptiert die kopierte Disk nicht. Details dazu gibt es schon in den von mir erwähnten Threads - ist somit auch off-topic.

    Ich habe eine Originaldiskette, die eine "weak bits" Protection im Track 0 (Head 0) enthält. Ich habe ein Assembler Programm geschrieben, daß die durch den DOSBox Debugger identifizierten BIOS INT13 Aufrufe auf der Original Hardware/Software durchführt und auswertet. Und das im Vergleich Originaldiskette und TransCopy Kopie. Ich konnte keinen Unterschied identifizieren. Dabei habe ich u.a. parallel Original und Kopie (zwei Laufwerke) mit den gleichen Calls traktiert und den Inhalt der Lesepuffer verglichen. Um Weak Bits zu identifizieren habe ich die Sektoren (1-12) der Originaldiskette von Track 0 (wo angeblich die Weak Bits sein sollen) mehrfach hintereinander eingelesen - es werden vom BIOS immer die gleichen Daten zurückgeliefert (was gegen "weak bits" im DATA-Block spricht), und auch der Fehler Status der abnormen Sektoren

    • Sektor 10 : 256 Bytes (04-requested sector not found)
    • Sektor 11-12 : 512 Bytes pro Sektor mit Bad CRC

    bleibt immer der gleiche (was gegen weak bits im ID-Block sprechen könnte).

    Der Track Editor des Option Board Deluxe zeigt zwar den Inhalt der Tracks in einer DATA und CLOCK Ansicht an, diese kann man leider nicht abspeichern. Unterschiede (Original/Copy) könnte man über das TransCopy Image Format identifizieren, nur ist mir der Aufbau des Formates unbekannt. Alternativ könnte man mit KryoFlux und dem KryoFlux Stream File (Original/Kopie) Unterschiede erkennen. Aber hier habe ich keine Erfahrungen. Hier würde ich mich über Vorschläge freuen.

    Der Track Editor des Option Borad Deluxe ist an sich ganz nett, unterstützt MFM und GCR, kann aber im Gegensatz zu TransCopy (gleiches Package) nicht gut mit 3,5" Disks umgehen. 1,44 MB Disketten kann der Track Editor noch nicht einmal anzeigen. Der primäre Fokus des Track Editors sind wohl 5,25" Floppies. Gibt es alternative Tools?


    Wo ich so etwas wie "weak bits" erkannt habe (mehrfach den gleichen Track mit dem Track Editor eingelesen und nach Unterschieden Ausschau gehalten) ist außerhalb der ID und DATA Blocks der Sektoren. Aber die wechselnden Bytes in diesen Bereichen sind wohl normal, zumal auch außerhalb der Synchronisierung?

    Was habt ihr immer wieder mit Computer kontrollieren. Sitzt ihr da gebannt vorm Monitor und lauscht, was das Betriebsystem gerade macht? Ich mein, das BS ist da, damit ich meine Programme starten kann und gut ist. Was soll ich da noch nebenbei kontrollieren? :nixwiss:

    Das hat auch was mit Demokratie und Unabhängigkeit von Staat und Monopolisten zu tun. Linux ist ein weitgehend transparentes Gemeinschaftsprojekt. Wem Bequemlichkeit über alles stellt, landet beim Web-Terminal, wo alles (inklusive seiner Daten) in der „Cloud“ liegt, und auf das Regierungen und Institutionen („Bedarfsträger) jederzeit Zugriff haben und den Zugriff des Nutzers auf seine Daten jederzeit sperren können.

    Wer Wert auf einen „persönlichen“ Computer legt, den er selber weitestgehend kontrolliert, kommt (spätestens nach Windows 10 mit seinem diktatorischen „Software as a Service“ Konzept) an Linux nicht vorbei. Für die Technik affinen Nutzer im Forum64 sollte Linux keine unüberwindbare Hürde sein, sondern eine lohnenswerte Herausforderung.

    Nur um diesen Thread abzuschließen. Der DOSBox Debugger hilft zwar, verschleierte BIOS calls zu identifizieren (im Fall Lemmings BIOS INT13 Function 0 [Reset Disk System] und Funktion 2 [Read Sectors]), hilft aber bei Disketten bezogenen Kopierschutzsystemen nicht, da Disketten im DOSBox Emulator nur im normalen IMG Format eingebunden werden können. Somit bleiben weak bits & Co außen vor.

    Ich habe ein Assembler Programm geschrieben, daß die durch den DODBox Debugger identifizierten BIOS INT13 Function 0 [Reset Disk System] und Funktion 2 [Read Sectors]) calls auf der Original Hardware durchführt und auswertet. Und das im Vergleich Originaldiskette und Transcopy Kopie. Ich konnte leider keinen Unterschied identifizieren. Dabei habe ich u.a. parallel Original und Kopie (zwei Laufwerke) mit den gleichen Calls traktiert und den Inhalt der Lesepuffer verglichen. Um Weak Bits zu identifizieren habe ich die Sektoren (1-12) von Track 0 (wo angeblich die Weak Bits sein sollen) mehrfach hintereinander eingelesen - es werden immer die gleichen Daten zurückgeliefert (was gegen weak bits im DATA-Block spricht), und auch der Fehler Status der abnormen Sektoren

    • Sektor 10 : 256 Bytes (04-requested sector not found)
    • Sektor 11-12 : 512 Bytes pro Sektor mit Bad CRC

    bleibt immer der gleiche (was gegen weak bits im ID-Block spricht). Ich vermute die BIOS 13h calls sich nur die Türwächter für die eigentliche weak bit Abfrage.

    Mich interessiert diese "Hacking Investigation" sehr. Von daher:


    https://www.dosbox.com/wiki/MOUNT#Mounting_a_floppy_drive


    Sieht so aus als könnte man Floppies auch direkt in die DosBox mounten falls eins vorhanden. Ich habe das mal mit meinem Floppy probiert und es geht scheinbar ohne Probleme. Leider habe ich keine Methode um zu prüfen ob ich auch low-level access zum Floppy habe.

    Einen low-level access zur kopiergeschützten Floppy kann man hier ausschließen. Zumal Du vermutlich ein USB Floppy Drive mit einem Windows System als DOSBox Host nutzt.


    Im Commodore Bereich mit VICE ist soetwas (zumindest theoretisch) möglich. VICE kann mit G64 Images umgehen und man kann zusammen mit XUM1541/XU1541 auch echte IEC Drives an den Emulator anschließen. Letzteres ist aber leider instabil und der Developer Support für dieses Feature hält sich in Grenzen.

    Nur um diesen Thread abzuschließen. Der DOSBox Debugger hilft zwar, verschleierte BIOS calls zu identifizieren (im Fall Lemmings BIOS INT13 Function 0 [Reset Disk System] und Funktion 2 [Read Sectors]), hilft aber bei Disketten bezogenen Kopierschutzsystemen nicht, da Disketten im DOSBox Emulator nur im normalen IMG Format eingebunden werden können. Somit bleiben weak bits & Co außen vor.

    Habe DOSBox auf Linux Mint (mit Einschränkungen) zum Laufen gebracht. Der Debug Output ist auch nicht gerade ausführlich.



    03B0-03BF ---- MDA (Monochrome Display Adapter based on 6845)


    Diverse BIOS:Disk calls (Vermute INT13) - hier sitzt wohl die Kopierschutzabfrage. Was "CPU:Write" auf die Adressen f1063,f1065-f106a bewirken, müsste ich noch klären. Die Änderungen der Interrupt Vektoren hat der DOSBox Debugger nicht geloggt. Leider gibt es zu den BIOS:Disk calls keine Aufrufparameter. :( DOSBox emuliert ja auch keinen FDD Controller. Und interaktiv lässt sich der DOSBox Debugger auf meinem Linux Mint System wegen Keyboard Problemen nicht sinnvoll bedienen.

    Mit dem mir vertrauten Turbo Debugger komme ich so nicht weiter.

    Normaler TD oder TD386 inkl. dem zugehörigen Treiber?


    Normaler TD, den TD386 (habe ich irgendwo im Internet gefunden), den ich wegen der erweiterten Hardware Breakpoint Optionen (I/O access) nutzen wollte, konnte/wollte nicht mit meinem TD zusammenarbeiten - wohl falsche Version.


    Das mit der DOSBox auf Linux macht mehr Aufwand, als gedacht - kein einfaches Github clone & compile - und die vorkompilierten dosbox-debug_0.74-2-3* Pakete passen wegen der Abhängigkeiten nicht.

    Ich glaube, ich mache in dieser Sache erst mal eine Pause.

    Von INT3 ist der Turbo Debugger abhängig.

    Vielleicht solltest du dir einen Debugger suchen, der sich nicht durch solche Kleinigkeiten aus dem Tritt bringen lässt?


    Da fällt mir dann nur noch ein, das Programm in der DOSBox laufen zu lassen und den DOSBox Debugger zu nutzen. Mit dem mir vertrauten Turbo Debugger komme ich so nicht weiter. Die Compilierung der DOSBox mit der Debug Option auf Linux ist auf meiner ToDo Liste.