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 !
Inscription : 28 Août 2008, 23:41 Message(s) : 261
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 ?
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)
Inscription : 28 Août 2008, 23:41 Message(s) : 261
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
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).
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
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 !
_________________ SPS Community Expert (SPS CE) / SPS France
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).
Inscription : 28 Août 2008, 23:41 Message(s) : 261
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).
Inscription : 28 Août 2008, 23:41 Message(s) : 261
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.
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
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 !!!
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 1 invité
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum