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

Kannst du das D64 mal anhängen, oder sagen wo auf der Wolke man das findet?

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.

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

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.

Zitat von GenerationCBM

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.

Genau so gehts.... spricht da ein Cracker von damals™?

Zitat von ZeroZero

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... )

Zitat von mrr19121970

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...

Zitat von mrr19121970

gibt es tools für sowas ?

Der VICE Monitor kann das von ganz alleine.

Zitat von mrr19121970

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

Der Windows Taschenrechner calc.exe im Programmierer-Modus

Zitat von GenerationCBM

-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

Zitat von GenerationCBM

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

Zitat von mrr19121970

wieder mal was neues gelernt

Dito. Und selbst wenn einem irgendwas altbekanntes begegnet, ist es weitere Fingerübung und Erfahrungssammlung.

Zitat von mrr19121970

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:
https://blog.didierstevens.com/programs/xorsearch/

Hier übrigens mein jmp $06c6 Ansatz:

Zitat von KiWi

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.

Zitat von KiWi

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.

Ja da hast Du recht. Wenn da der Floppy-Kopf ne Woche in der Gegend rumgefahren wird muss die ganze Routine raus.

Ich könnte mir eh vorstellen das da noch mehr Abfragen auf der Diskette versteckt sind. Das Multi-Menü war ja der erste Punkt wo @mrr19121970 nen Fehler gefunden hat. Wer weiss was da noch so alles schlummert.

Zitat von mrr19121970

Wo ist es,

In ein paar Blöcken am Stück auf Track 18 mittig hinten.
Mein jmp-Patch ist z.B. in T18S12.

Zitat von mrr19121970

und warum funktionert LOAD "MULTIMENU",8,1 nicht ?

Weil es keinen Eintrag dieses Namens im Directory gibt.