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. 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. Quelqu'un aurait LATIS.BAK ? |
Auteur : | hERMOL [ 07 Nov 2008, 13:04 ] |
Sujet du message : | Re: Protections sur Amstrad CPC |
Dlfrsilver dois nous uploader son original normalement ... |
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 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. 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 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é... 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: 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. 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… 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. 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 ! |
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: 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. 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… 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. 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 ! |
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 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 . 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 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/ |