CPC Rulez
https://cpcrulez.fr/forum/

Protections sur Amstrad CPC
https://cpcrulez.fr/forum/viewtopic.php?f=6&t=223
Page 7 sur 16

Auteur :  Babar [ 06 Nov 2008, 15:26 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Oui, on est d'accord sur l'enlèvement du R et du Halt.

Par contre, il existe des protections qui ne coupent pas les interruptions et qui ne sont pas basées sur R, et qui donnent quand même du fil à retordre.

D'ailleurs, je n'ai pas le souvenir d'autres protections basées sur les interruptions, connaitrais-tu des exemples ? Je n'ai le souvenir que de beaucoup de protections basées sur R avec de nombreuses boucles imbriquées, mais pas de programme qui est ainsi dérouté par les interruptions à l'insu d'une trace sous Dams par exemple.

Longshot a écrit :
Je suis même pas sûr d'ailleurs qu'exécuter ce truc en mode "RUN" sous DAMS dévoile pas le pot aux roses...
C'est quoi ce RUN, c'est le mode trace ? Ca dévoilerait le truc comment ?

Longshot a écrit :
Bon, et le code en #1000, tu l'affiches quand ici ?

Ouh la, attends, tu vas trop vite, laisse-moi digérer cette partie !

Auteur :  Longshot [ 07 Nov 2008, 10:45 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Citer :
je n'ai pas le souvenir d'autres protections basées sur les interruptions, connaitrais-tu des exemples ?

La protection de revolog. :P

Citer :
C'est quoi ce RUN, c'est le mode trace ? Ca dévoilerait le truc comment ?

Je crois que tu peux tracer un programme sous dams, avec T (trace) qui exécute instruction par instruction, R (Run) qui est une trace rapide sans affichage mais contrôlée, et J (Jump) qui exécute direct sans contrôle jusqu'au RET
Le mode Run rend la main au premier RET (je crois qu'il se base par rapport à la pile). Par contre, je ne me rappelle pas du tout si HALT est "simulé" correctement pas DAMS et si les interruptions le sont aussi ou pas....
au pire il suffit de remplacer le HALT par un CALL #38
Cela dit, c'est pas un truc que j'ai bcp utilisé car DAMS ne simule par R correctement par exemple. (et je sais pas si tous les Flags le sont aussi).

Citer :
Ouh la, attends, tu vas trop vite, laisse-moi digérer cette partie !

Laisse les forumeurs prendre un peu d'avance.
Promis on dira rien. :wink:
Quelqu'un aurait LATIS.BAK ? :P

Auteur :  hERMOL [ 07 Nov 2008, 13:04 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Dlfrsilver dois nous uploader son original normalement ... :cow:

Auteur :  dlfrsilver [ 07 Nov 2008, 13:20 ]
Sujet du message :  Re: Protections sur Amstrad CPC

ouep je confirme, j'upload cet après-midi à mon retour du taf :D

et voilà : http://www.yousendit.com/download/Y2o4Z ... amV4dnc9PQ

et le log crée par SAMDISK :

Head 0, 42 tracks:
warning: this disk may not be PC FDC compatible!
250Kbps MFM, 9 sectors, 512 bytes/sector:
0:0 193 198 194 199 195 200 196 201 197
6380: 208 669 674 675 677 675 670 666 660
1:0 193 198 194 199 195 200 196 201 197
6384: 208 666 664 666 662 663 669 674 674
2:0 193 198 194 199 195 200 196 201 197
6329: 205 661 663 664 663 664 665 664 665
3:0 193 198 194 199 195 200 196 201 197
6358: 210 676 679 670 667 662 661 662 663
4:0 193 198 194 199 195 200 196 201 197
6388: 208 663 662 666 672 673 676 677 670
5:0 193 198 194 199 195 200 196 201 197
6355: 206 664 664 669 664 668 664 662 666
6:0 193 198 194 199 195 200 196 201 197
6391: 208 665 662 665 672 674 676 678 672
7:0 193 198 194 199 195 200 196 201 197
6366: 210 675 677 678 671 665 661 660 661
8:0 193 198 194 199 195 200 196 201 197
6391: 208 667 663 664 669 673 675 677 676
9:0 193 198 194 199 195 200 196 201 197
6349: 207 664 663 664 666 663 666 662 663
10:0 193 198 194 199 195 200 196 201 197
6334: 212 670 668 663 661 661 665 663 664
11:0 193 198 194 199 195 200 196 201 197
6340: 206 662 663 662 667 664 667 665 662
12:0 193 198 194 199 195 200 196 201 197
6387: 207 666 669 662 665 668 672 674 675
13:0 193 198 194 199 195 200 196 201 197
6376: 209 675 674 677 679 669 667 662 661
14:0 193 198 194 199 195 200 196 201 197
6330: 209 670 664 660 660 662 662 661 667
15:0 193 198 194 199 195 200 196 201 197
6377: 208 671 675 676 678 673 669 665 660
16:0 193 198 194 199 195 200 196 201 197
6381: 209 663 665 666 662 664 671 674 674
17:0 193 198 194 199 195 200 196 201 197
6326: 206 661 663 665 663 666 664 665 664
18:0 193 198 194 199 195 200 196 201 197
6350: 211 676 677 671 666 662 660 662 664
19:0 193 198 194 199 195 200 196 201 197
6380: 208 662 662 666 672 672 674 674 668
20:0 193 198 194 199 195 200 196 201 197
6350: 207 662 664 668 665 668 663 664 668
21:0 193 198 194 199 195 200 196 201 197
6383: 209 664 662 665 672 673 675 678 670
22:0 193 198 194 199 195 200 196 201 197
6357: 211 675 677 676 671 664 661 659 661
23:0 193 198 194 199 195 200 196 201 197
6322: 207 662 661 662 664 662 666 666 665
24:0 193 198 194 199 195 200 196 201 197
6362: 211 675 676 678 669 665 661 660 661
25:0 193 198 194 199 195 200 196 201 197
6383: 207 667 663 663 666 672 674 676 676
26:0 193 198 194 199 195 200 196 201 197
6334: 205 662 662 662 667 663 668 663 663
27:0 193 198 194 199 195 200 196 201 197
6331: 212 674 670 665 661 660 662 661 660
28:0 193 198 194 199 195 200 196 201 197
6374: 206 664 670 673 675 676 674 669 663
29:0 <blank>
30:0 193 198 194 199 195 200 196 201 197
6380: 206 667 666 663 665 672 675 677 679
250Kbps MFM, 10 sectors, 512 bytes/sector:
31:0 193 198 194 199 195 200 196 201 197 202
6328: 206 580 581 580 581 585 581 586 582 581
250Kbps MFM, 9 sectors, 512 bytes/sector:
32:0 193 198 194 199 195 200 196 201 197
6375: 207 665 667 663 665 669 675 674 676
250Kbps MFM, 10 sectors, 512 bytes/sector:
33:0 203[n203,dc] 193 198 194 199 195 200 196 201 197
6321: 205 608 611 610 609 615 611 615 612 610
250Kbps MFM, 9 sectors, 512 bytes/sector:
34:0 193 198 194 199 195 200 196 201 197
6368: 207 669 675 676 677 675 669 663 661
35:0 193 198 194 199 195 200 196 201 197
6371: 207 667 666 667 663 664 668 674 674
250Kbps MFM, 10 sectors, 512 bytes/sector:
36:0 203[n0] 193 198 194 199 195 200 196 201 197
6316: 204 198 595 596 597 597 596 601 598 601
37:0 203[n0,nd] 193 198 194 199 195 200 196 201 197
6371: 206 610 615 612 609 611 617 620 621 622
250Kbps MFM, 9 sectors, 512 bytes/sector:
38:0 193 198 194 199 195 200 196 201 197
6319: 208 667 665 660 661 660 663 661 665
39:0 193 198 194 199 195 200 196 201 197
6367: 206 670 677 676 679 676 669 665 662
40:0 <blank>
41:0 <blank>

Auteur :  Babar [ 08 Nov 2008, 01:59 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Longshot a écrit :
Citer :
je n'ai pas le souvenir d'autres protections basées sur les interruptions, connaitrais-tu des exemples ?

La protection de revolog. :P

Revelog, ça protège quel jeu, ou quel utilitaire ?

Et pas d'autre exemple ? C'est tout ? Revelog et Hercule II ? Sur des centaines de jeux CPC ?
(c'est vrai que personnellement je ne me souviens pas avoir cracké à l'époque de protections basées sur les interruptions)

Auteur :  hERMOL [ 08 Nov 2008, 05:18 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Citer :
Revelog, ça protège quel jeu, ou quel utilitaire ?


Revelog est une demo, codé par Longshot :eng: que je t'invite à regarder et à écouter de ce pas !!

url : https://cpcrulez.fr/Scene_Demos/8x/ ... ad=Revolog

Auteur :  Longshot [ 10 Nov 2008, 14:34 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Dans mon souvenir, c'était plus compliqué... :P

Décodage de la partie en #1000 vers #4000
LD BC,#78
LD HL,#10A0
LD DE,#4000
KLOUG:
LD A,(HL)
XOR C
LD (DE),A
INC DE
INC HL
INC C
DJNZ KLOUG
RET
(ce décodeur est une interprétation libre...)

Partie en #4000 qui décode un secteur vers #A000
Secteur #C1, track #20 en #A000
LD HL,#A000
LD DE,#200
LD C,#D0
DUBITCHOU:
LD A,(HL)
XOR C
XOR L
XOR E
INC C
INC C
INC C
LD (HL),A
INC HL
DEC DE
LD A,D
OR E
JR NZ,DUBITCHOU
RET

Allez babar...tu y es presque! :)

Auteur :  Babar [ 11 Nov 2008, 00:55 ]
Sujet du message :  Re: Protections sur Amstrad CPC

DEPLOMBAGE D'HERCULE II: étape 3, cracking :
Longshot est allé vite…voici ce que cela donne à ma vitesse, en essayant de cracker le programme.

Application des méthodes classiques de cracking les unes après les autres: :oops:

1) On est d’abord tenté, pour cracker, de remplacer la dernière instruction JP #1000 par un RET, et de lancer la boucle pour obtenir le résultat.
=> cela ne marchera pas car la boucle de XORage utilise comme clef le programme lui-même en #6000 donc toute modification du programme par un pirate faussera le décodage. :shock:

2) Pour éviter cela, on est tenté de dupliquer le programme qui est en #6060 pour le mettre disons en #7060 :
=> cela ne marchera pas car il y a un LD DE,#60C5, PUSH DE, RET donc le programme continuera en #60C5 et on perdra la main en #70C5… :?

3) En changeant le #60C5 par un #70C5 pour garder la main, cela ne marchera pas non plus, car comme l’a dit Longshot, le programme ne passera jamais sur ce RET, car le programme est déjà parti ailleurs… :o

4) Même cas de figure si l’on trace la boucle de décodage avec DAMS, on n’obtiendra aucun résultat… :(

5) La seule solution, c’est de bien connaître l’Amstrad, de sentir le coup fourré sous les instructions LD R,A sans DI, ou le HALT, ou le EX AF,AF’, ou le SP,#40…ce qui incitera à « tracer » les routines d’interruption.
:pir8:


DEPLOMBAGE D'HERCULE II: solution de l'étape 3:
Longshot, tu me diras si y'a un truc que j’ai mal compris !

En fait, le programme de décodage n’est pas exécuté jusqu’au bout…car il s’échappe en plein milieu pour partir ailleurs…(!)

Pour rappel, une interruption est régulièrement déclenchée de façon matérielle (et pas logicielle, ce qui va berner la trace de Dams par exemple) ce qui exécute la commande en #38, où se trouve un appel à une routine dite d’interruption (#B941 sur CPC6128, #B939 sur CPC464) afin de gérer les évènements comme la saisie d’une touche au clavier, etc.

Tout ceci est normal, et normalement la routine d’interruption aurait dû se terminer et retourner à la boucle de décodage. Mais elle ne l’a pas fait. Pourquoi ?

Parce que certains vecteurs d’interruption ont été modifiés, ce qui a dérouté le Z80…
Certes le programme n’a modifié aucun octet des routines d’interruptions, car cela aurait été trop visible (si je poke en #B941 ça met la puce à l’oreille à tout le monde).
Le programme n’a pas non plus modifié les vecteurs d’interruption qui se trouvent entre 0 et #3B, car pareil cela aurait peu discret.
Comment le programme a alors dérouté le Z80 ?

Et bien c’est le LD SP,#40 qui est responsable. SP c’est la pile. Chaque CALL ou PUSH empile des valeurs sur la pile. Or la pile à #40 ne veut pas dire que les valeurs vont s’empiler en #40, puis #42, et #44, etc…mais dans l’autre sens car la pile va de haut en bas : #3F, puis #3D, et #3B.
En gros, c’est le fait d’avoir mis la pile sur les vecteurs d’interruption qui va foutre le boxon…

Pourtant, dans le programme on n’a qu’un seul PUSH DE, donc a priori seuls #3F et #3E vont être modifiés, ce qui ne touchera pas aux vecteurs…? Non, car comme l’a souligné Longshot, l’interruption va forcément empiler l’adresse de l’endroit où elle interrompe le programme tout simplement pour pouvoir y retourner après. Ensuite la routine d’interruption contient elle aussi un CALL ce qui empile 2 octets supplémentaires, au final on atteint les octets #3A et #3B, EN PLEIN dans les vecteurs d’interruption !

En fait, les PUSH, CALL d’interruption et CALL de la routine, vont, en empilant leurs valeurs de retour dans la pile, CREER UN PETIT PROGRAMME en #3B, qui va s’exécuter lors du CALL #3B de la routine d’interruption :
#3B CP C
#3C LD (BC),A (02 de F' selon Longshot; moi j'obtiens 12 en traçant avec WinAPE, curieux)
#3D JR #0004 (18 C5) c’est en effet le PUSH AF de la routine d’interruption qui push ce JR

#04 LD C,C
#05 JP #591


Rq: c’est en fait le Call #3B qui va empiler un octet…justement en #3B !!

Cette astuce qui permet de créer du code sans que l’on s’en aperçoive (via la pile) et pour ensuite exécuter ce code de manière 'invisible' (via les interruptions) est très intéressante. C'est du polymorphisme ?
Avec le fichier hybride binaire & basic du début, j’ai jamais vu une protection aussi originale. D'ailleurs y'a 20 ans, je n'avais pas trouvé le coup des interruptions...

A l’époque je crackais un peu tous les jeux, et il n’y avait que des imbroglios de boucles notamment basées sur R, mais rien sur la pile, et rien sur les interruptions (Longshot a précisé qu’il connaît une autre protection basée sur les interruptions, sa propre protection Revelog…t’as pas de mérite, alors, Longshot ?! ;o)))) Peut-être que la protection de Discologie nous réservera elle aussi de belles surprises. Et pourquoi pas attaquer celle de Revelog après, pour clore ce trio.

A noter que pour que cela fonctionne, il faut que la routine d’interruption appelle un vecteur d’interruption, et cela a été réalisé en mettant le Carry de AF’ à 1. C’est à cela que servaient les instructions un brin bizarres : xor d ; add h ; sla a ; sla a ; srl a ; set 3,a
Elles servaient aussi à positionner A à #18 afin de générer plus tard le code JR #4 qui sera pushé par la routine d'interruption.

…au final, on a un JP #591 qui va aller taper en #1000. Pourtant, on croyait devoir décoder les octets qui sont en #1000 avec la boucle en #60CC, et de plus car ce code ne ressemble à pas grand chose. Si le programme y va, on peut anticiper qu’à l’intérieur se cache en fait une boucle, qui est elle la vraie boucle de décodage (celle en #60CC n’étant qu’un leurre).

Auteur :  Megachur [ 11 Nov 2008, 14:49 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Ca avance -> Bravo !

Allez, la suite, la suite ! :biere:

Auteur :  dlfrsilver [ 11 Nov 2008, 14:57 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Babar a écrit :
DEPLOMBAGE D'HERCULE II: étape 3, cracking :
Longshot est allé vite…voici ce que cela donne à ma vitesse, en essayant de cracker le programme.

Application des méthodes classiques de cracking les unes après les autres: :oops:

1) On est d’abord tenté, pour cracker, de remplacer la dernière instruction JP #1000 par un RET, et de lancer la boucle pour obtenir le résultat.
=> cela ne marchera pas car la boucle de XORage utilise comme clef le programme lui-même en #6000 donc toute modification du programme par un pirate faussera le décodage. :shock:

2) Pour éviter cela, on est tenté de dupliquer le programme qui est en #6060 pour le mettre disons en #7060 :
=> cela ne marchera pas car il y a un LD DE,#60C5, PUSH DE, RET donc le programme continuera en #60C5 et on perdra la main en #70C5… :?

3) En changeant le #60C5 par un #70C5 pour garder la main, cela ne marchera pas non plus, car comme l’a dit Longshot, le programme ne passera jamais sur ce RET, car le programme est déjà parti ailleurs… :o

4) Même cas de figure si l’on trace la boucle de décodage avec DAMS, on n’obtiendra aucun résultat… :(

5) La seule solution, c’est de bien connaître l’Amstrad, de sentir le coup fourré sous les instructions LD R,A sans DI, ou le HALT, ou le EX AF,AF’, ou le SP,#40…ce qui incitera à « tracer » les routines d’interruption.
:pir8:


DEPLOMBAGE D'HERCULE II: solution de l'étape 3:
Longshot, tu me diras si y'a un truc que j’ai mal compris !

En fait, le programme de décodage n’est pas exécuté jusqu’au bout…car il s’échappe en plein milieu pour partir ailleurs…(!)

Pour rappel, une interruption est régulièrement déclenchée de façon matérielle (et pas logicielle, ce qui va berner la trace de Dams par exemple) ce qui exécute la commande en #38, où se trouve un appel à une routine dite d’interruption (#B941 sur CPC6128, #B939 sur CPC464) afin de gérer les évènements comme la saisie d’une touche au clavier, etc.

Tout ceci est normal, et normalement la routine d’interruption aurait dû se terminer et retourner à la boucle de décodage. Mais elle ne l’a pas fait. Pourquoi ?

Parce que certains vecteurs d’interruption ont été modifiés, ce qui a dérouté le Z80…
Certes le programme n’a modifié aucun octet des routines d’interruptions, car cela aurait été trop visible (si je poke en #B941 ça met la puce à l’oreille à tout le monde).
Le programme n’a pas non plus modifié les vecteurs d’interruption qui se trouvent entre 0 et #3B, car pareil cela aurait peu discret.
Comment le programme a alors dérouté le Z80 ?

Et bien c’est le LD SP,#40 qui est responsable. SP c’est la pile. Chaque CALL ou PUSH empile des valeurs sur la pile. Or la pile à #40 ne veut pas dire que les valeurs vont s’empiler en #40, puis #42, et #44, etc…mais dans l’autre sens car la pile va de haut en bas : #3F, puis #3D, et #3B.
En gros, c’est le fait d’avoir mis la pile sur les vecteurs d’interruption qui va foutre le boxon…

Pourtant, dans le programme on n’a qu’un seul PUSH DE, donc a priori seuls #3F et #3E vont être modifiés, ce qui ne touchera pas aux vecteurs…? Non, car comme l’a souligné Longshot, l’interruption va forcément empiler l’adresse de l’endroit où elle interrompe le programme tout simplement pour pouvoir y retourner après. Ensuite la routine d’interruption contient elle aussi un CALL ce qui empile 2 octets supplémentaires, au final on atteint les octets #3A et #3B, EN PLEIN dans les vecteurs d’interruption !

En fait, les PUSH, CALL d’interruption et CALL de la routine, vont, en empilant leurs valeurs de retour dans la pile, CREER UN PETIT PROGRAMME en #3B, qui va s’exécuter lors du CALL #3B de la routine d’interruption :
#3B CP C
#3C LD (BC),A (02 de F' selon Longshot; moi j'obtiens 12 en traçant avec WinAPE, curieux)
#3D JR #0004 (18 C5) c’est en effet le PUSH AF de la routine d’interruption qui push ce JR

#04 LD C,C
#05 JP #591


Rq: c’est en fait le Call #3B qui va empiler un octet…justement en #3B !!

Cette astuce qui permet de créer du code sans que l’on s’en aperçoive (via la pile) et pour ensuite exécuter ce code de manière 'invisible' (via les interruptions) est très intéressante. C'est du polymorphisme ?
Avec le fichier hybride binaire & basic du début, j’ai jamais vu une protection aussi originale. D'ailleurs y'a 20 ans, je n'avais pas trouvé le coup des interruptions...

A l’époque je crackais un peu tous les jeux, et il n’y avait que des imbroglios de boucles notamment basées sur R, mais rien sur la pile, et rien sur les interruptions (Longshot a précisé qu’il connaît une autre protection basée sur les interruptions, sa propre protection Revelog…t’as pas de mérite, alors, Longshot ?! ;o)))) Peut-être que la protection de Discologie nous réservera elle aussi de belles surprises. Et pourquoi pas attaquer celle de Revelog après, pour clore ce trio.

A noter que pour que cela fonctionne, il faut que la routine d’interruption appelle un vecteur d’interruption, et cela a été réalisé en mettant le Carry de AF’ à 1. C’est à cela que servaient les instructions un brin bizarres : xor d ; add h ; sla a ; sla a ; srl a ; set 3,a
Elles servaient aussi à positionner A à #18 afin de générer plus tard le code JR #4 qui sera pushé par la routine d'interruption.

…au final, on a un JP #591 qui va aller taper en #1000. Pourtant, on croyait devoir décoder les octets qui sont en #1000 avec la boucle en #60CC, et de plus car ce code ne ressemble à pas grand chose. Si le programme y va, on peut anticiper qu’à l’intérieur se cache en fait une boucle, qui est elle la vraie boucle de décodage (celle en #60CC n’étant qu’un leurre).


Ok, moi ce que je comprends, c'est que tout émulateur ayant un défaut de timings ne peut pas faire tourner ce programme correctement.

D'ou peut-etre aussi la différence de valeur que tu as trouvé avec winape, différente de celle trouvée
par notre ami Longshot :)

Y a encore du boulot avant que les émulateurs ne sachent faire tourner ces programmes protégés.

en tout cas, j'ai hate de voir le cracking de Discologie :D !

Auteur :  Babar [ 11 Nov 2008, 21:15 ]
Sujet du message :  Re: Protections sur Amstrad CPC

dlfrsilver a écrit :
Ok, moi ce que je comprends, c'est que tout émulateur ayant un défaut de timings ne peut pas faire tourner ce programme correctement.

D'ou peut-etre aussi la différence de valeur que tu as trouvé avec winape, différente de celle trouvée
par notre ami Longshot :)

En fait avec des Breakpoints dans WinAPE, j'ai constaté que WinAPE simule bien la protection, que ce soit le HALT, l'empilement, les vecteurs d'interruption, etc, car on arrive bien à la boucle en #4000.

C'est d'ailleurs facile de comprendre cette protection avec les outils de trace, déboguage, breakpoint de WinAPE...ça aurait été une autre paire de manche à l'époque des années 80.

C'est en #4000 que la protection pense qu'un pirate a modifié le code, et plante volontairement la machine.
Cela est en fait dû au LD (DE),A qui a été pushé, car avec DE=#60C5 cela modifie le programme.

En fait ce LD (DE),A provient du code #12, et d'ailleurs Longshot a trouvé LD (BC),A qui a le code #2...(Longshot a dû utiliser un autre chose émulateur que WinAPE, peux-tu Longshot nous le confiremr stp). Cela veut dire que 2 émulateurs différents trouvent deux octets différents, pas normal ! Plus précisément une différence d'un seul bit, le bit #10.

Ce #12 provient en fait du F de AF, c-a-d l'octet qui contient tous les drapeaux: Z, C, PO, etc...
A et F ont été initialisés par les commandes suivantes:
xor a ; ld bc,#df07 ; out (c),c ; ld hl,#c6e5 ; sub (hl) ; xor d ; add h ; sla a ; sla a ; srl a ; set 3,a
Après cela, F ne devrait pas $etre à #12. La valeur correcte semble être 2 (quoiqu'un 0 aurait été plus logique). Quelqu'un a un bouquin qui explique les impacts sur les drapeaux de chaque commande Z80 ?

Ma conclusion: il doit y avoir un petit bug dans WinAPE sur la gestion de l'une des commandes en orange ci-dessus et de son impact sur les drapeaux de F (si vous connaissez l'auteur de WinAPE, que je trouve génial par ailleurs, on peut lui faire remonter ce petit bug).

Auteur :  Longshot [ 12 Nov 2008, 00:53 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Effectivement, F n'est pas à 02 sur un vrai CPC, mais à 00, ce qui code un nop
Il s'agit d'un bug de l'émulation z80a de winape du flag N
Le bit 1 de F est le flag N
Ce flag passe à 1 si l'opération précédente était une soustraction et à 0 si c'était une addition

#12 n'est pas bon car tu oublies 2 choses dans ta séquence.
Initialiser D et que HL pointe sur la bonne donnée (ce qui risque de ne pas être le cas si la rom haute n'est pas activée). Bref, il faut soustraire #ED de 00 et faire un xor avec #11
Cela dit, un LD (DE),A aurait compliqué la protection puisque cela aurait modifié le code entre #6000 et #61FF, qui sera "checksumé" plus tard...(contrôle=#27)

Citer :
C'est d'ailleurs facile de comprendre cette protection avec les outils de trace, déboguage, breakpoint de WinAPE...ça aurait été une autre paire de manche à l'époque des années 80.

Pas tant que ça quand même.
Le mode Trace de dams permet de simuler la plus grande partie des instructions pour calculer A et F par exemple. A défaut il est facile de les calculer soi même.

Citer :
C'est en #4000 que la protection pense qu'un pirate a modifié le code, et plante volontairement la machine.

Ben non, c'est en #A000. Tu vas un peu trop vite en besogne pour le coup...
Tu n'as pas encore causé de ce qui se trouve en #1000 :shock:
Je l'ai tracé sous dams avec un vrai cpc, comme quoi le mode trace était tout simplement magique...

Citer :
Ok, moi ce que je comprends, c'est que tout émulateur ayant un défaut de timings ne peut pas faire tourner ce programme correctement.

Je ne pense pas que ce soit un problème de timing pour winape, mais plutôt un prb d'émulation fdc pour la protection. Même avec le bug du flag N, l'instruction LD (BC),A provoque juste un octet parasite en 7F8E, mais cela n'empêcherait pas le décodage de se faire correctement.
L'objet du crack c'est quand même de voir ce qui déconne à ce niveau, non ?

Citer :
Longshot a précisé qu’il connaît une autre protection basée sur les interruptions, sa propre protection Revolog…t’as pas de mérite, alors, Longshot ?! ;o))))

La protection latis a un défaut de conception dont nous avons déjà discuté, et qui est lié aux interruptions actives. Mais son principe, c'est que l'auteur a supposé qu'une autre programmeur ne comprendrait pas ce qu'il a codé. Proteus, la protection de Revolog est différente et ne s'appuie pas sur ce principe. Mais pour te répondre, elle est originale car c'est donc la seule à vraiment se servir de R pour décoder, avec les interruptions actives :P . Je ne retrouve pas une version fonctionnelle, mais je vais la recompiler si tu tiens à essayer de la casser (promis je rajoute rien dedans).

Auteur :  dlfrsilver [ 12 Nov 2008, 05:12 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Merci longshot, mais ça confirme ce que je pense de winape.....

L'émulateur qui fait avancer le plus loin Hercule II c'est CPCE. Winape ça donne rien et wincpc pareil.

m'enfin si déjà l'émulation Z80 était précise à 100%.....

Auteur :  Longshot [ 12 Nov 2008, 09:08 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Citer :
Merci longshot, mais ça confirme ce que je pense de winape.....

Je sais pas vraiment ce que tu penses de winape.
Cela dit, il est difficile de condamner un émulateur uniquement sur des prb de compatibilité fdc dans des cas extrêmes.
Car dans la globalité, winape est sans doute actuellement l'émulateur qui respecte le mieux le hardware du cpc à mon avis.

Bon j'vais aller indiquer à R. Wilson le bug du flag, mais finalement ça aurait été pas mal de conserver un moyen simple de tester qu'on est sur un émulateur :evil:
Je suis pas le seul à avoir émis l'idée d'un port "émulateur" pour savoir si on est sur un émulateur ou non, encore faut il que les auteurs des émulateurs jouent le jeu.

Auteur :  dlfrsilver [ 12 Nov 2008, 14:52 ]
Sujet du message :  Re: Protections sur Amstrad CPC

Justement, il se trouve que lors de mes différents tests, Winape est le moins compatible
avec les originaux.

dans l'ordre : CPCE, Wincpc, caprice 32, winape.

J'ai du batailler contre le Richard, en me montrant provoquant à son égard, histoire qu'il
remue son c*l ! Parce qu'il était persuadé que winape est le plus accurate (ce qui n'est pas exact...).

Le FDC est un gros point d'entrée pour les programmes. Les émulateurs ont été crée pour faire
tourner des cracks, et non des originaux. Aujourd'hui on a les outils pour imager les originaux,
résultat on se rend compte que les émulateurs ont des problèmes.

Par exemple, la limite de taille des pistes dotées de secteur de taille 6. On sait aujourd'hui que si certaines images sont si grosses, c'est parce que ce sont des pistes MFM, et qu'elle font
355ko.... Dans le genre y a monty python, l'image DSK fait 500ko !!!

Au final, mon sentiment c'est que les formats spéciaux étaient jusqu'à peu très mal connu.
genre les speedlock dotés de secteurs faibles / weak sectors, jamais supporté avant que je ne
file un coup de patte à Simon Owen, il a mis à jour le format DSK, maintenant plus de protection
sont supportées. et les créateurs d'émulateurs sont obligés de se mettre à la page.
exemple : une piste à secteur de taille 6 à une taille limité de $1800, que nenni, ça monte bien plus
haut que ça. On s'en est rendu compte quand j'ai imagé certains jeux ayant une taille abominable
en DSK. Les dumps ne marchaient pas. En augmentant la taille des pistes, là paf, ça a marché.

Je vais encore faire bouger les choses, histoire de secouer le monde du CPC !!!

Page 7 sur 16 Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/