1) il faut d'abord déprotéger le fichier LATIS.BAS qui a été protégé par un save,P
2) ensuite il faut recaler manuellement les longueurs des lignes Basic en dumpant la mémoire avec DAMS par exemple. Cela ne suffit pas car il y a des lignes parasites qu'il faut sauter (faut tatonner, c'est loin d'être évident...et long)
3) les lignes 42 et 55 sont là pour charrier le pirate qui ferait un dump du Basic
4) la ligne 84 est là pour tromper le pirate qui ferait un dump du Basic, en effet ce code machine n'est jamais exécuté
5) le load "latis.bin" en ligne 172 est lui aussi une fausse piste pour égarer le pirate qui ferait un dump du Basic, car il n'est jamais exécuté. En fait dans le basic en 160 il y a deux pokes qui transforment le BIN en BAK, c'est donc bien le fichier latis.bak qui est chargé de #6060 à #6100
6) en 185 le binaire en #6060 est xoré par une boucle Basic, dont la clef est en #170 c-a-d le programme Basic lui-même, il ne faut donc pas oublier de recharger le Basic dans sa version originale avec les mauvais numéros de ligne (eh oui!)
Bref, 6 petits pièges en 1...
Voici le Basic après une difficile remise en état des longueurs de ligne:
Code :
10 ' PROTECTION L.A.T.I.S 20 ' (C) COPYRIGHT 1986 - Cyril B A R T O L O et Joel A R M E N G A U D 25 ' (C) COPYRIGHT 1986 -- E.S.A.T SOFTWARE 30 ' ALL RIGHTS RESERVED -- TOUS DROITS RESERVES 42 ' FOR N=&170 TO &2C0:IF PEEK(N)>&1F THEN ?CHR$(PEEK(N)); 55 ' NEXT 71 A=PEEK(&AC00):A=A+PEEK(&AC01):A=A+PEEK(&AC02) 84 DATA F3,F1,ED,5E,7,27,ED,47,E0,AE,57,1,14,19,ED,78,82,ED,47,21,0,70,ED,B3,C9 92 FOR N=1 TO 25:READ A$:POKE &BEFF+N,VAL("&"+A$):NEXT 106 IF PEEK(&B1C8)>2 THEN 160 109 ON PEEK(0) GOTO 115,123,160 115 BORDER 0:INK 0,0:INK 1,15:PEN 1:PAPER 0 123 NOM$="PROTECTION L.A.T.I.S" 149 LOCATE ABS(PEEK(&B1C8)*20-10)+10-LEN(NOM$)/2,25:PRINT CHR$(22)CHR$(1)NOM$CHR$(22)CHR$(0) 160 POKE &4CB,&41:POKE &4CC,&4B 172 MEMORY &5E00:LOAD "LATIS.BIN" 185 A=&170:FOR N=&6060 TO &6100:POKE N,PEEK(N) XOR PEEK(A):A=A+2:NEXT 200 FOR N=0 TO 15:INK N,0:NEXT:CALL &6060
DEPLOMBAGE D'HERCULE II: étape 3, le fichier binaire LATIS.BAK
(pour le xorer il fallait recharger le Basic dans sa version protégée avec les fausses longueurs..Mais aussi ne pas oublier les deux pokes qui changent le BIN en BAK !!)
Avec un peu de rigueur, on obtient çà:
5E90-5FFF: des octets sans queue ni tête 6000-605F: PROTECTION LATIS V1/2.0 (C) ...(etc, que de l'Ascii...) 6060-6078: que des 0 (un brin curieux, mais bon). Rappel: le Basic exécute le code en #6060. 6079: le code ci-dessous:
Code :
xor a ld r,a ld iy,(#bd17) ld hl,#0040 ld d,h ld e,l inc de ld bc,#5e4e ld (hl),h ldir ld hl,#5e90 ld de,#1000 ld bc,#0170 ldir ld bc,#7f86 out (c),c ld bc,#df07 out (c),c ld hl,#c6e5 sub (hl) ld bc,#7f8e out (c),c push af xor d add h sla a sla a srl a set 3,a ex af,af' pop af ex af,af' ld sp,#0040 ld de,l60c5 push de ld r,a halt ret ld b,l ld d,(hl) l60c5: ld b,l l60c6: ld hl,#6000 ld de,#1000 l60cc: ld a,r xor (hl) ex de,hl xor (hl) ex de,hl ld (de),a inc hl inc de ld a,h cp #62 jr nz,l60cc djnz l60c6 jp #1000
Vwali, je regarde...et je vous laisse regarder en parallèle...
Voici mes premiers commentaires, si vous avez une idée pour les lignes avec un "?" :
Code :
xor a ld r,a mise a 0 du rafraichissement, sans DI cela m'étonne... ld iy,(#bd17) y'a kwa en bd17 ? De toutes facons, iy ne semble pas utilise apres... ld hl,#0040 ld d,h ld e,l inc de ld bc,#5e4e ld (hl),h ldir vide la memoire jusqu'a 5E8F ld hl,#5e90 ld de,#1000 ld bc,#0170 ldir copie la partie sans queue ni tete en #1000, ce sera a priori la suite de la protection (a deproteger) ld bc,#7f86 ? out (c),c ? ld bc,#df07 ? out (c),c ? ld hl,#c6e5 ? sub (hl) ? ld bc,#7f8e ? out (c),c ? push af xor d add h sla a ? sla a ? srl a ? set 3,a ? ex af,af' ? pop af ex af,af' ? ld sp,#0040 ld de,l60c5 push de pour le RET ci-dessous ld r,a initialise R, toujours sans DI, ca devient inquietant... halt une maniere de demarrer la clef R du rafraichissement a une valeur connue ? ret va ci-dessous en l60c5 ld b,l lettre E, pour quoi faire ? ld d,(hl) lettre V, pour quoi faire ? l60c5: ld b,l l60c6: ld hl,#6000 le progr binaire est la clef de codage ld de,#1000 en #1000 le programme a decoder, puis a executer l60cc: ld a,r le Rafraichissement fait partie du decodage xor (hl) xor par la clef "Programme Binaire" ex de,hl xor (hl) xor le programme a decoder ex de,hl ld (de),a inc hl inc de ld a,h cp #62 decode une longueur de #200 jr nz,l60cc boucle djnz l60c6 boucle #E5 fois si j'ai bien suivi jp #1000 execute le pogramme en #1000
Inscription : 28 Août 2008, 23:41 Message(s) : 257
J't'aide un peu... Il faut que tu cherches à comprendre ce qui est fait au niveau hardware Déjà, rapidement : un LD R,A suivi d'un HALT sans synchro préalable qui est sensé amené sur un décodage avec R est IMPOSSIBLE. Donc ce code n'est pas exécuté.
Remplissons tes points d'interrogation ld bc,#7f86 ; connecte la rom haute / deconnecte rom basse out (c),c ; ld bc,#df07 ; selectionne la rom disque (07) en rom haute out (c),c ; ld hl,#c6e5 ; la rom disque étant similaire sur tous les cpc tu as BB sub (hl) ; ce qui donne #13 mais surtout Carry=1 puisque A=0 au début ld bc,#7f8e ; déconnecte roms haute et basse (et mode 2) out (c),c ; push af ; Sauvegarde de C=1 (AF=#1313) xor d ; D=#11 A=#02 add h ; H=#C6 A=#C8 sla a ; sla a ; A=#20 srl a ; A=#10 set 3,a ; A=#18 ex af,af' ; A'=#18 pop af ; A=#13 et Carry=1 ex af,af' ; A'=#13 A=#18 (F' avec Carry=1)
Ensuite tu as ld sp,#0040 ld de,l60c5 push de ld r,a halt ret
Les interruptions basic fonctionnent encore... Il est évident, à ce stade que le halt, qui attend l'interruption basic, ne va pas revenir exécuter le ret.
On remarque aussi déjà ici que la protection peut déjà planter si jamais une malheureuse interruption se produit dès que AF' est modifié, ce qui était vraiment pas malin comme je l'ai déjà dit. Entre le EX AF,AF' et le HALT, vaut mieux qu'une interruption se produise pas (AF' serait modifié....)
La pile se trouve en #40. Les différents PUSH & CALL vont générer du "code" Le "push de" va mettre [3F]=#60 et [3E]=#C5 Le halt va attendre une interruption qui va placer l'adresse du ret (je suppose 60C2) en [3C]=C2 [3B]=60 L'interruption a lieu en #38, qui va en #B941 comme chacun le sait ( )
En #B941, tu as DI EX AF,AF' ; le carry revient parmi les siens... JR C,#B978 ; ... En #B978 EX AF,AF' ; le syst récupère l'autre valeur calculée avec les décalages POP HL ; Dépile l'adresse de retour de l'interruption (#60C2) PUSH AF; empile à la place la valeur calculée (#1802) Donc [3C]=02 et [3D]=18 (instruction JR) SET 2,C ; Redéconnecte la rom basse OUT (C),C CALL #3B Ce CALL #3B se produit en #B97F, et donc l'adresse de retour est #B982 Ce qui empile encore [3A]=82 et [3B]=B9 (instruction CP C ) Le call en #3B appelle donc un code généré par le call en écrasant le #C9 (RET) qui s'y trouve normalement avec #B9 #3B CP C #3C LD (BC),A (02 de F') #3D JR #0004 (18 C5) BC contenant 7F8E, il y a un octet 02 qui est venu s'y coller... En #0004 LD C,C suivi de JP #591 (adresse du reset en rom) Sauf qu'on est en ram...
Donc ce qui a été mis en #1000 à partir de #5E90 va s'exécuter...
Code que tu n'as pas donné et qui doit pas être si incompréhensible que ça
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
d'ailleurs la protection physique d'Hercule 2 ne marche sur aucun émulateur (winape comme d'hab le moins compatible, suivi de wincpc, et CPCE qui le fait avancer le plus loin )
_________________ SPS Community Expert (SPS CE) / SPS France
dlfrsilver, pour la protection physique, on devrait pas tarder à arriver, dans notre cracking, au test de la protection...et en complément j'essaierai de bien zyeuter mon original pour vous la décrire. A première vue, y'a l'air d'y avoir bcp de chevauchements de secteurs de tailles différentes, et ce ne serait pas étonnant que le modèle DSK ou eDSK ne les supporte pas, ce qui ne remettrait pas en cause la qualité des émulateurs...mais peut-être simplement le modèle DSK...à suivre...
Longshot, tu es impressionnant ! Au fait, c'est quoi qui t'a mis la puce à l'oreille, le HALT, le EX AF,AF', le LD SP,#40 ? (c'était celle-là que tu avais crackée dans les années 80, ou c'était celle du hercule I ?)
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Justement à propos du format DSK, j'ai fait bouger les lignes dernièrement, le standard DSK a été upgradé par Simon Owen, le père de l'outil SAMDISK.
Même avec le support des nouveaux DSK, qui est plus complet pour supporter les protections, les émulateurs ne suivent pas.
Pour te dire, winape me chante la marseillaise à l'envers quand je tente de lui faire lire le DSK original d'Hercule II....
C'est un problème de support FDC et rien de plus et ptet une histoire de bug z80....
Même le nécromancien que j'ai dumpé dernièrement, n'est pas supporté, toutes les pistes même la piste 0 sont protégées contre la copie
L'émulation FDC est encore loin d'être 'accurate'...... d'ailleurs même dans sa dernière version, j'arrive toujours pas à faire marcher super skweek sur winape....la protection continue toujours de faire chier...alors que sur les autres émus ça marche !
Je referme la parenthèse...
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 28 Août 2008, 23:41 Message(s) : 257
Citer :
Longshot, tu es impressionnant !
D'habitude, on me dit ça à oilpé
Plus sérieusement... Dès le moment ou tu vois que R n'est pas synchronisé, la boucle de décodage n'a aucun sens. Il est donc certain qu'on n'exécute pas le code décrypté de cette manière. (Il aurait été plus malin pour l'auteur de pas impliquer R à ce niveau, car c'est un indice gros comme une maison) Donc la seule manière de sortir du code, c'est une interruption. Et vu qu'il fait un halt, c'est à ce niveau qu'il faut chercher comment l'interruption système est "pervertie" (mais il y a bien un bug possible si une interruption tombe "naturellement" avant son halt )
Je ne sais plus du tout si cette version était la même que pour hercule 1 Mais bon ça casse quand même pas des briques...(brique, maison )
Bon tu l'affiches quand la partie en #1000 sur #170 ?
...Même avec le support des nouveaux DSK, qui est plus complet pour supporter les protections, les émulateurs ne suivent pas...
Finalement il est tout à fait possible en effet que la limitation soit au niveau des émulateurs comme au niveaux du modèle DSK.
Sur le fond on est peut-être en phase tous les deux, voir par exemple mon post http://cpcrulez.fr/forum/viewtopic.php?f=8&t=374 qui n'a malheureusement pas déchaîné les foules...le projet me paraissait pourtant, certes ambitieux, mais réalisable.
Bref, et pour la marseillaise à l'envers j'espère que j'apporterai de l'eau au moulin dans quelques semaines avec le 'crack' de la protection physique d'Hercule II, pour voir si c'est la faute au DSK ou aux émulateurs.
...mais il y a bien un bug possible si une interruption tombe "naturellement" avant son halt
Intéressant, le Carry à 1 orienterait alors l'interruption vers un Reset ?
Pour en calculer la probabilité, sait-on:
1) Combien de temps en millisecondes prennent les instructions ld sp,#0040 ld de,l60c5 push de 2) tous les combien de millisecondes y a-t-il une interruption en #38 ?
Inscription : 28 Août 2008, 23:41 Message(s) : 257
Il n'est pas dit que cela concerne la période couverte par ces 3 instructions seulement. Tant que le dernier CALL #3B (qui modifie ce qui est en #3B) n'est pas fait via le bit C=1, le ret en #3B est toujours là.
Cependant, si une interruption a lieu entre le 1er EX AF,AF et le 2ème EX AF,AF , alors F' va être modifié par l'interruption si cette dernière rend la main (ce qui reste à voir, car même si C vaut 0, la rom basse est off) et donc ça peut avoir des conséquences...
Après le 2ème EX AF,AF et le LD SP,#40, si une interruption tombe, C=1, mais comme le code n'est pas modifié, l'interruption rend la main. Sauf que F' est modifié (sans compter le POP HL dans l'interruption), ce qui implique que la 2eme interruption (halt) crashe.
Si l'interruption tombe après le PUSH DE, tout dépend si la protection a besoin ensuite de HL (ce que tu sauras plus tard). Car le POP HL de l'interruption doit dépiler normalement 60C2 et pas une adresse avant...
Si on considère la section du second EX AF,AF et le LD R,A comme critique, l'ensemble prend 14 microsecondes. Un frame prend 19968 usec sur un cpc. Soit 19968/6=3328 usec entre 2 interruptions. Donc tu as environ 1 chance sur 3328-14 que ta période de 14 usec tombe sur une interruption.
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Citer :
Finalement il est tout à fait possible en effet que la limitation soit au niveau des émulateurs comme au niveaux du modèle DSK.
Sur le fond on est peut-être en phase tous les deux, voir par exemple mon post http://cpcrulez.fr/forum/viewtopic.php?f=8&t=374 qui n'a malheureusement pas déchaîné les foules...le projet me paraissait pourtant, certes ambitieux, mais réalisable.
Bref, et pour la marseillaise à l'envers j'espère que j'apporterai de l'eau au moulin dans quelques semaines avec le 'crack' de la protection physique d'Hercule II, pour voir si c'est la faute au DSK ou aux émulateurs.
Ce sont les émulateurs les fautifs. J'ai soumis à simon owen le jeu préhistorik, le dump est bon, mais la protection côté FDC n'est pas émulée..... il a dit qu'il en parlerait à R. Wilson.
Idem pour les protections par data marks dans les zones GAP, problème avec l'ancien système DSK, mais surtout aucun support FDC dans les émulateurs (winape raconte encore des conneries à la lecture de certains jeux dont la protection est pourtant émulée... pfff.... si seulement il avait pas la certitude que winape c'est le meilleur sur le marché hein... il chercherait un peu plus à améliorer le truc CQFD).
Il est certain qu'une fois normalisé, hercule II fonctionnera sur tout les émulateurs, puisque ce sont les opérations spéciales des protections qui font merder... c'est pas réinventer la roue que de dire ça
_________________ SPS Community Expert (SPS CE) / SPS France
...de pas impliquer R à ce niveau, car c'est un indice gros comme une maison
Oui mais admettons que l'on cherche à améliorer la protection: si on ne met pas de R, nulle part, alors on a une simple boucle en XOR qui ne décodera rien. Le Cracker va bien voir qu'il y a un os. Donc il va creuser, et c'est plutôt le HALT qui va lui mettre la puce à l'oreille...quoique, à toi Longshot ça te parle, mais un HALT ça n'attend jamais qu'une interruption, et les interruptions sont nécessaires à la vie du CPC, donc c'est pas si affolant que çà...on peut penser (à tort) que le HALT est là pour synchroniser le R ?!
Je pense que c'est plutôt le LD SP,#40 qui met sur la voie...quand on sait que les interruptions sont en #38, mais ça fait quand même ~8 octets, donc ça m'a pas frappé à première vue...
Au final, je pense que tu as raison, ce serait peut-être plus sioux d'enlever le R, mais je proposerais alors d'enlever aussi le HALT et le remplacer par une boucle suffisamment longue qui attend donc que l'interruption se déclenche...plus discrètement...d'ailleurs c'est ce que j'ai (un DJNZ double) dans mes notes sur mon calepin de cracking de 1988 pour Hercule II, il a dû y avoir plusieurs versions de la protection.
Voici ce que j'ai dans mes vieilles notes (référencé par le mot "CALEPIN") par opposition au programme que l'on a ci-dessus ("ICI"):
xor a ld r,a ld iy,(#bd17) ld hl,#0040 ld d,h ld e,l inc de ld bc,#5e4f ld (hl),0 ldir ld hl,#5e90 ld de,#1000 ld bc,#0170 ldir ICI: ld bc,#7f86 out (c),c CALEPIN: exx, res 3,c out (c),c exx ld bc,#df07 out (c),c ld hl,#c6e5 ICI: sub (hl) ld bc,#7f8e out (c),c CALEPIN: sbc a,(hl) exx set 3,c out (c),c exx push af ICI: xor d add h sla a sla a srl a set 3,a CALEPIN: add a,l xor c rrd srl a ld e,a ld a,#18 ex af,af' pop af ICI: ex af,af' ici comme l'a fait remarquer Longshot l'instruction est placée 14 ms trop tôt ! ld sp,#0040 ICI: ld de,#60c5 push de CALEPIN: ld bc,#60c5 push bc CALEPIN: ex af,af' LONGSHOT, cela prouve que tu avais entièrement raison, puisque dans cette version l'ex af,af' est mis à la fin, après le push #60c5 et le LD SP !! ICI: ld r,a halt ret CALEPIN: ld c,#ff ld b,#ff inc hl djnz_sur_inc_hl dec bc ld b,c djnz_sur_ld_b,#ff ret la double boucle en djnz est donc pour éviter la présence d'un HALT, peu discrète...
Dans cette version plus discrète (non, non, je ne cherche pas d'excuses en prétextant que la version que j'avais essayée de cracker en 1988 était plus difficile ) sans R et sans HALT, il reste quand même le LD SP,#40...l'initialiser par un POP SP (ça existe ?) aurait été plus discret.
Inscription : 28 Août 2008, 23:41 Message(s) : 257
Si tu veux "améliorer" la protection, la boucle d'attente est plus judicieuse.
Mais ce qui implique qu'on sait que le code est dérouté via l'interruption, c'est : a) que R n'est pas synchronisé. b) les interruptions "système" sont autorisées c) c'est une protection
Donc 'avec des si' , tu pourrais synchroniser R de manière moins farfelue. R est initialisé à 0 à un instant T qui est à N usec de la prochaine interruption (qu'attend le HALT), R évoluant pendant le HALT, et l'interruption système risquant en plus de le modifier aléatoirement. Donc R est totalement aléatoire.
Citer :
quoique, à toi Longshot ça te parle, mais un HALT ça n'attend jamais qu'une interruption, et les interruptions sont nécessaires à la vie du CPC, donc c'est pas si affolant que çà...on peut penser (à tort) que le HALT est là pour synchroniser le R ?!
Je crois que ça parle à la quasi totalité des codeurs de la scène. Les interruptions ne sont pas nécessaires pour un programme cpc. Lorsque tu avais l'habitude de cracker des protections, la première chose qui était faite dans 100% des cas, c'était de détruire le système, et donc de couper les interruptions avec un DI (ou modifier #38). C'était d'autant plus vrai que beaucoup de jeux n'utilisaient pas du tout le système. Tomber sur une protection qui laisse les interruptions système, c'est quand même signer son intention. Ca signifie que l'auteur de la protection est soit idiot, soit qu'il a fait exprès. Avec l'avertissement prétentieux au lancement, tu peux choisir les 2 options. Une plus grande humilité aurait donc contribué à rendre la protection plus difficile.
Enfin, tout programmeur cpc sait que modifier les registres secondaires (notamment af') lorsque le système est 'opérationnel' est dangereux....
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...
Bon, et le code en #1000, tu l'affiches quand ici ? Tu vas pas y passer la saint glin glin ?
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 20 invité(s)
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