DEPLOMBAGE D'HERCULE II: solution de l'étape 2:

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:

Bravo , beau taf, ca deviens très intéressant tout ca

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:


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 "?" :

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

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

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

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 ?

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.

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

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.

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.


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 ?