Kopierschutz Bei Expert Cartridge Utility Disk v4.1.d64 (F64 Wolke)

  • Kopierschutz Bei Expert Cartridge Utility Disk v4.1.d64 (F64 Wolke)

    Kann jemand helfen ?

    Expert Cartridge Utility Disk v4.1.d64 scheint kopierschutz zu haben.

    Von freeze menu:



    M wählen, lädet "etwas" (erste frage was wird hier geladen - datei ??). Diese menu erscheint:



    beim wählen von alle optionen sucht auf der disk und springt zurück ins menu. In VICE mit:

    DEV 8:
    BREAK 0348

    sehe ich:

    Quellcode

    1. * = $0300
    2. JMP j0324
    3. LDA #<p0712
    4. STA a06 ;Track and sector for buffer 0
    5. LDA #>p0712
    6. STA a07
    7. LDA #$E0
    8. LDX #$00
    9. JSR eD57D
    10. DEC a0298 ;Flag: Work return
    11. JSR eD599 ;$D599 Verify execution
    12. CMP #$02
    13. BCC b031F
    14. JMP eE60A ;$E60A Prepare error number and message
    15. b031F LDA #$73
    16. JMP eE6C1 ;$E6C1 Print error on track 00,00 to error buffer
    17. j0324 LDA #$04
    18. STA a31
    19. JSR eF510 ;$F510 Read block header
    20. LDA a1C00 ;PB, control port B
    21. AND #$9F
    22. STA a1C00 ;PB, control port B
    23. LDX #$00
    24. b0335 BIT a1C00 ;PB, control port B
    25. BMI b0335
    26. b033A INX
    27. BIT a1C00 ;PB, control port B
    28. BPL b033A
    29. CPX #$14
    30. LDA a1C01 ;PA, port A ( to and from read/write head)
    31. CLV
    32. LDY #$00
    33. BCC b034D
    34. JMP eF4D4
    35. b034D LDA #$F4
    36. LDA #$03
    37. JMP eF969 ;$F969 Error entry disk controller
    Alles anzeigen








    wenn ich BCC b034D auf NOP NOP ändern, den komme ich in die weitere menu:





    Wie kann ich diese crack permanent in D64 reinbringen ?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von mrr19121970 ()

  • Quellcode

    1. LDA #$12
    2. LDX #$03
    3. STA a03D0
    4. STX a03D7
    5. LDA #$00
    6. STA a05
    7. LDX #$CA
    8. JSR e03B3
    9. LDX #$D1
    10. JSR e03B3
    11. LDA #$01
    12. LDX #$08
    13. LDY #$60
    14. JSR ROM_SETLFSj ;$FE00 (jmp) - set file parameters
    15. LDX #$13
    16. LDY #$03
    17. JSR ROM_SETNAMj ;$FDF9 (jmp) - set file name
    18. JSR eF3D5
    19. LDA aBA
    20. JMP e0251
    21. LDA #$07
    22. LDY #$03
    23. JSR ROM_SETNAMj ;$FDF9 (jmp) - set file name
    24. LDA #$0F
    25. LDX #$08
    26. TAY
    27. JSR ROM_SETLFSj ;$FE00 (jmp) - set file parameters
    28. JSR ROM_OPENj ;$F34A (jmp) - open log.file after SETLFS,SETNAM
    29. LDA #$0F
    30. JMP ROM_CLOSEj ;$F291 (jmp) - close a logical file
    Alles anzeigen
    Diese code @ $8583, scheint ein program names "MULTIMENU" (pointer $0307) zu laden.
  • Noch nicht tief reingesehen, aber:

    -Bei $0568 ist ein Buchstabenblock, das sind die Abfragetasten für das Multi-Menu (BMFPCSUH - Backup, Monitor, Picture Formatter, etc.)

    -Bei $0668 ist die finale Abfrageschleife ("Load Module (Y/N)"), cmp #$0d und cmp #$59 für Return oder Y (Yes) geht weiter mit beq $0678, ansonsten zurück raus per jmp $0520

    -Ab $0678 wird U0>M0 übertragen und der tatsächliche Check durchgeführt, mit $ffa5 (input byte from serial), das Resultat abgeholt, in $02 abgelegt, und verglichen (cmp #$37, beq $06c6, jmp ($0318)), bei check fail also flach raus über NMI.

    -Biegt man das beq in ein bne um (oder patcht das sonstwie), geht's erfolgreich weiter bei $06c6 wo dann das ausgewählte Modul geladen wird

    Fragt der da etwa einen künstlichen DOS Error ab, der eigentlich im D64 funktionieren sollte? (Wenn nein müsste das Programm wohl entpackt, gepatcht und neu in das D64 geschrieben werden.) Wenn ja sieht der D64-Fehlerblock mindestens mal ungut aus. Da ist zwar ein Fehler #21 (No Sync) in T18S08 (und Track 18 wird beim Check ja ausführlich gelesen), aber erstens ist der falsch im Fehlerblock eingetragen (mit $15, also 21 - das ist die Fehlernummer, im Fehlerblock soll aber der Fehlercode stehen, das wäre für Fehler 21 also $03), und zweitens sollten eigentlich alle anderen Blöcke im Normalfall mit Code $01 (No Error) dort markiert sein. Hier haben aber nur T18S00 und T18S04 eine $01, der Rest ist $00 - keine Ahnung welche Diskimage-Software sowas produzieren würde...

    Edit:
    Ändert man die beiden beq $0678 in der finalen Modulabfrage in beq $06c6, wird die Schutzabfrage anscheinend in der Tat vollständig und ohne Nebenwirkungen übersprungen und gleich mit dem Laden des ausgewählten Moduls angefangen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von GenerationCBM ()

  • Und hier das code, aber find ich immer noch nicht auf D64:

    Quellcode

    1. b0678 LDA #$0B
    2. STA $D011 ;VIC Control Register 1
    3. JSR s0775
    4. b0680 LDA f0788,Y
    5. BEQ b068B
    6. JSR ROM_CIOUT ;$FFA8 - output byte to SERIAL
    7. INY
    8. BNE b0680
    9. b068B JSR ROM_UNLSN ;$FFAE - unlisten all SERIAL devices
    10. LDX #$90
    11. LDY #$07
    12. LDA #$04
    13. STA a93
    14. JSR s0720
    15. LDA #$03
    16. JSR ROM_CIOUT ;$FFA8 - output byte to SERIAL
    17. JSR ROM_CIOUT ;$FFA8 - output byte to SERIAL
    18. JSR ROM_UNLSN ;$FFAE - unlisten all SERIAL devices
    19. LDA aBA
    20. JSR ROM_TALK ;$FFB4 - make SERIAL device talk
    21. LDA #$6F
    22. JSR ROM_TKSA ;$FF96 - send secondary addr after talk
    23. JSR ROM_ACPTR ;$FFA5 - input byte from SERIAL
    24. STA a02
    25. b06B3 JSR ROM_ACPTR ;$FFA5 - input byte from SERIAL
    26. CMP #$0D
    27. BNE b06B3
    28. JSR ROM_UNTLK ;$FFAB - untalk all SERIAL devices
    29. LDA a02
    30. CMP #$37
    31. BEQ b06C6
    32. JMP (p0318) ;NMI
    Alles anzeigen


    06c1 BEQ $06C6 <---- COPY PROTECTION OK
    06c3 JUMP ($0318) : IE JUMP $0c25 RETURN TO MAIN MENU

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von mrr19121970 ()

  • 2 mal EOR, deswegen kann ich nichts finden

    Quellcode

    1. b9BB4 LDA #$FD
    2. AND a90
    3. STA a90
    4. JSR ROM_ACPTRj ;$EE13 (jmp) - input byte from SERIAL
    5. EOR a08
    6. EOR a09
    7. STA (p08),Y
    8. INC a08
    9. BNE b9BCF
    10. INC a09
    11. LDA a09
    12. CMP #<span class="redactor-ie-paste"></span>8
    13. BEQ b9BD3
    14. b9BCF BIT a90
    15. BVC b9BB4
    16. b9BD3 JSR ROM_UNTLKj ;$EDEF (jmp) - untalk all SERIAL devices
    17. JSR eF642
    18. JMP e05C0
    Alles anzeigen
  • Da du ja weisst das die Routine bei $06c1 im Speicher liegt, muss sie also irgend eine Schleife da hin kopiert haben.

    Legst Du im VICE einen Watchdog drauf:

    W store $06c1

    Dann findest Du die eigentliche Kopierroutine:

    .C:19a9 A0 00 LDY #$00
    .C:19ab 8C 11 D0 STY $D011
    .C:19ae 84 08 STY $08
    .C:19b0 A9 04 LDA #$04
    .C:19b2 85 09 STA $09
    .C:19b4 A9 FD LDA #$FD
    .C:19b6 25 90 AND $90
    .C:19b8 85 90 STA $90
    .C:19ba 20 13 EE JSR $EE13
    .C:19bd 45 08 EOR $08
    .C:19bf 45 09 EOR $09
    .C:19c1 91 08 STA ($08),Y
    .C:19c3 E6 08 INC $08
    .C:19c5 D0 08 BNE $19CF
    .C:19c7 E6 09 INC $09
    .C:19c9 A5 09 LDA $09
    .C:19cb C9 08 CMP #$08
    .C:19cd F0 04 BEQ $19D3


    Und was macht die ?

    Einen EOR $08 und EOR $09 mit dem eigenen Adresspointer ($0400-$0800).

    Daher findest Du die Routine auch nicht im .d64 weil sie Verschlüsselt ist.

    .C:06c1 F0 03 BEQ $06C6
    .C:06c3 6C 18 03 JMP ($0318)

    Also:
    $F0 EOR C1 06 = $37
    $03 EOR C2 06 = $C7
    $6C EOR C3 06 = $A9
    $18 EOR C4 06 = $DA
    $03 EOR C5 06 = $C0

    Findest Du im .d64

    000171C0: 9C 16 45 1E BA 70 F1 37 C7 A9 DA C0 B8 68 FF 6D

    Machst Du also aus deinem BEQ ein BNE = D0 03 / XOR 06 XOR C1 = $17

    000171C0: 9C 16 45 1E BA 70 F1 17 C7 A9 DA C0 B8 68 FF 6D

    Fertig ->> Expert Cartridge Utility Disk v4.1cracked.d64
    10 SIN
    20 GOTO HELL

    www.SX-64.de
  • Ich persönlich würde einfach in $0678 ein jmp $06c6 setzen, dann ist der Kopierschutz wenigstens kaputt. :)

    Ist immer besser, wenn möglich eine Schutzroutine garnicht erst ausführen zu lassen anstatt lediglich die Logik umzukehren.
  • ZeroZero schrieb:

    Genau so gehts.... spricht da ein Cracker von damals™?
    Aber nein aber nein. Bloss ein lamer Autodidakt von heute. Gibt Sachen die ich nicht kann und keinen Nerv finde, mich reinzuarbeiten. Aber grunsätzlich ist das ja kein Hexenwerk.

    (Bloss Hexwerk, harr... :party2: )


    mrr19121970 schrieb:

    weil ich habe etwas (unbekanntes) mit ein paar bytes überschrieben
    Das Risiko hast du natürlich immer irgendwie wenn du in solcherlei fremden Code rumfuckelst, "schlechte Cracks" die kaputt sind oder nur halb funktionieren gab's ja auch schon immer. Aber ist ja nicht weiter schlimm, wir reden hier ja nicht von Steuersoftware für ein Kernkraftwerk...
  • mrr19121970 schrieb:

    gibt es tools für sowas ?

    Der VICE Monitor kann das von ganz alleine.

    mrr19121970 schrieb:

    ich kenne xor.pw/ aber viellicht gibt es etwas besser ?

    Der Windows Taschenrechner calc.exe im Programmierer-Modus


    GenerationCBM schrieb:

    -Biegt man das beq in ein bne um (oder patcht das sonstwie), geht's erfolgreich weiter bei $06c6 wo dann das ausgewählte Modul geladen wird

    Ja, 1 Byte patch :thumbsup:

    GenerationCBM schrieb:

    Ich persönlich würde einfach in $0678 ein jmp $06c6 setzen, dann ist der Kopierschutz wenigstens kaputt.
    Warum wieder anders Überlegt ? Das BEQ patchen war schon richtig weil: Funktioniert genau so wie der Code ablaufen soll ohne das man großartig patchen muss. Der fehlende Kopierschutz auf der Diskette wird sich nicht von Geisterhand wieder herbeizaubern und das BNE neutralisteren.

    Immer ein Bit übrig behalten :bgdev
    10 SIN
    20 GOTO HELL

    www.SX-64.de
  • mrr19121970 schrieb:

    wieder mal was neues gelernt
    Dito. Und selbst wenn einem irgendwas altbekanntes begegnet, ist es weitere Fingerübung und Erfahrungssammlung.

    mrr19121970 schrieb:

    ich kenne xor.pw/ aber viellicht gibt es etwas besser ?
    XOR mache ich immer "von Hand" Byte für Byte im Hexeditor oder per Taschenrechner.

    Manchmal ist "rumsuchen" aber auch eine ganz gute Methode, um z.B. eine XOR-Maske zu finden. Dafür ist sowas z.B. ganz gut, gerade bei sowas kleinem wie Disk-Images:
    blog.didierstevens.com/programs/xorsearch/

    Hier übrigens mein jmp $06c6 Ansatz:
    Dateien
  • KiWi schrieb:

    Warum wieder anders Überlegt ?
    Ach das ist immer subjektive Abwägung zwischen möglichst wenig verändern und möglichst effektiv patchen. Mein persönlicher Antrieb ist ja, D64-Images meiner eigenen Originale lauffähig zu machen. Öfters mache ich mir dann zwei Fassungen, eine mit möglichst kleinem Patch (1 Byte ftw), und eine schmerzbefreite mit möglichst sinnvollem Umbau. Ein "richtiger" Crack sähe natürlich nochmal anders aus. Aber macht halt auch Spass so'n bisschen im Code rumzuwerkeln, und jeder Jeck ist bekanntlich anders.

    Aber ehrlich gesagt sieht mir dieses Image auch nicht so völlig original aus, deswegen bin ich da vielleicht von vornherein unvorsichtiger gepolt.


    KiWi schrieb:

    Das BEQ patchen war schon richtig weil: Funktioniert genau so wie der Code ablaufen soll ohne das man großartig patchen muss. Der fehlende Kopierschutz auf der Diskette wird sich nicht von Geisterhand wieder herbeizaubern und das BNE neutralisteren.
    Ich find's immer klüger, so eine Routine erst garnicht zu Wort kommen zu lassen. Spart Zeit, spart Floppykopfbewegung, usw... ist in diesem Fall jetzt nicht so kritisch, aber es gibt ja auch den einen oder anderen Kopierschutz, der gewaltig rauf und runter rödelt und headbumpt, gerade wenn er seine Signatur nicht findet, und das muss ja nicht sein. Auch mit Tracks jenseits von 35 kann es da blöde Probleme in Emulatoren und auf echter Hardware geben wenn die Tracks angesteuert werden aber garnicht da sind, etc.pp.