Tu... Tu m'étonne !
Bien joué pour le coup !!!

_________________
Cent Pour Cent

Ouh la, je me rends compte que l'on s'était arrêté à l'étape 6 du cracking de la protection d'HERCULE II, après avoir passé la quasi totalité de la protection logicielle avec sa création polymorphique cachée de bouts de programme par l'empilement des interruptions hardware, et lancement de ce code par aspiration lors d'une interruption, avec aussi du code hybride binaire et basique 2 en 1, des boucles discrètes noyées dans du code qui semblait sans queue ni tête avec des instructions qui font planter les émulateurs actuels, etc.
On s'était bien amusés !

Et on en était au niveau du petit programme qui testait la bonne structure de la protection physique, visiblement 5 pistes de protection !

DEPLOMBAGE D'HERCULE II: étape 6 avec le programme en #A000 qui sert à tester la protection physique:
1) Lit la piste #25 et ça doit donner #40, 5, 1 (pour les 3 octets de résultat du FDC)
2) Lit la piste #24 et ça doit donner #40, #34, #20 et il doit y avoir #E5 en #250ème position
3) Lit la piste #21 et il doit y avoir #4E en #110ème position
4) Lit la piste #22 et il doit y avoir #E5 en #2A0ème position
5) Lit la piste #23 et il ne doit PAS y avoir #4E en #2A0ème position

Ce serait bien de pouvoir reprendre le sujet et le terminer, il y a certainement des choses croustillantes dans ces 5 pistes, tout en sachant que la protection n'a a priori pas nécessité d'appareil autre que le lecteur standard de l'Amstrad. D'autant qu'il fallait une protection complexe puisque HERCULE II était un copieur capable de copier tous les jeux au risque d'être capable de se copier lui-même !
Cela aiderait aussi à comprendre pourquoi aucun émulateur n'arrive à émuler ces structures de piste, afin d'améliorer la création de SDK image de la disquette d'Hercule II.

Y a-t-il encore ICI des lecteurs intéressés par ce sujet ?! hERMOL, Longshot, dlfrsilver, Supersly, Megachur, JMD, Markerror, MIC,...?!

si tu as un HFE, IPF propre de l'original, je peux jeter un oeil à la chose?

Vu tes points 2,3,4 et 5 ça ressemble à de la protection GAP, j'ai justement fait un POC de copie d'un jeu à protection GAP à partir d'un CPC y a quelques semaines

là je regarde le DSK d'un site concurrent, d'après ce que tu dis, il manquera des infos à la lecture si le loader va fouiner dans la GAP exemple la piste 34 il n'y a pas d'extra info sur les secteurs

Pour sur que ça m'intéresse Vas-y poursuis !

Note que depuis tes posts, CPCEC a vachement avancé côté FDC, il support 99% des logiciels, seuls 1% font de la résistance. C'est à dire 5-6 logiciels pas plus

_________________
SPS Community Expert (SPS CE) / SPS France

Je me rappelle avoir lu un vieux Tilt ou Esat Software expliquait que leurs copieurs ne permettait pas de copier leurs logiciels. Mais en 1990, je ne suis pas certain que l'Amstrad fut encore dans leur pensées pour cette interview.
Perso Hercule je n'ai jamais utilisé, je le trouvais à des années lumière de Discology. Par contre certains protections n'étaient conçues que pour faire échouer Discology, je pense aux jeux Infogrames et un logiciel anglais comme Procopy permettait de les dupliquer dans problème.
Je n'ai jamais accroché à Discomagic dont on me disait le plus grand bien, j'avais 2 drives (5P1/4 puis 3P1/2) et Discology était le plus pratique dans cette configuration. Mais qui au moins existe en ROM.

C'est quoi un HFE et un IPF ? (parce que les seules abréviations que j'ai apprises récemment c'est FCK PTN mais c'est pas les mêmes lettres )
Mais j'ai tendance à penser que ce n'est pas fondamental car à mon avis la protection physique de Hercule II n'est copiable par aucun copieur, ni DSK-able.

Il faut que je retrouve mes notes qui devraient me permettre de vous décrire la structure de ces 5 pistes, hopefully.
Cela nous permettra de recréer des originaux CPC sur disquette, puisque le concepteur de la protection LATIS nous avait dit que la protection physique était réalisée avec un simple Amstrad classique (et pas avec du matériel externe).

HFE c'est le format que lisent les lecteurs SD de type HxC. Les goteks pouvant lire les DSK. Mes HFE je les obtiens en convertissant un DSK au moyen d'un outils mais j'imagine le format plus complet que le DSK à la base.

IPF c'est une image raw nickelle obtenue par un kryoflux.

Que l'on me corrige si j'ai oublié un truc ou écrit des bêtises.

HFE/IPF/RAW sont des images du disque sous formes de pistes "physiques", tu peux quasi tout faire avec (les KBI-19 par ex avec des ID secteurs à l'intérieur de données secteur)
Le seul truc qui existe ptêtre pas encore (officiellement) c'est les subtilités type weak, strong, random bits et la variation de densité sur la même piste
Vu ta description de la protection, on n'est pas du tout à ce niveau de finesse requise

EDIT: j'avais oublié qu'on m'avait envoyé le HFE en douce dernièrement, faut juste que j'trouve un peu de temps, je vous tiens au jus
EDIT2: Ah nan c'est la version Plus, plus probablement un crack...
EDIT3: dump kryoflux récupéré

HFE/IPF/RAW...ça sonne super intéressant !

Dans les années 2000, face aux difficultés des émulateurs à gérer les protections physiques Amstrad, j'avais recommandé de faire évoluer le format DSK en y mettant en fait tout ce dont a besoin une protection physique, à savoir:

1) Le contenu de chaque secteur lu par READ SECTOR
1a) en mémorisant les octets de résultat du FDC (on aura un exemple avec la protection de Hercule II il me semble)
1b) en lisant chaque secteur deux fois, et stocker son 2ème contenu s'il est différent du 1er (protection KBI)
2) Le contenu de la piste lue par READ TRACK

J'ai vaguement l'impression que HFE/IPF/RAW vont en ce sens...j'aimerais bien trouver du temps pour creuser le truc afin que l'on soit à 100% sur les protections physiques CPC.

Hello,

Le format eDSK contient la plupart des infos que tu préconisais. C'est pour ça qu'en le tordant un peu, on arrive à lui faire tout digérer...

HFE et IPS ont une philosophie plus saine (mon humble avis) et plus générique : Grosso modo, ça permet de retranscrire la piste au format MFM. Si l'on ajoute une manière de supporter les weaks bits, c'est parfait.
Raw c'est encore pire : on stocke uniquement la piste MFM, et plusieurs fois (5 révolutions de manière classique)

Pour retranscrire n'importe quoi, il resterait (à mon sens) à ajouter un support :
- De taille de piste, en bit, qui ne soit pas un multiple de 16 (cas du HXC)
- De permettre, en plus des weak bits (bits changeant aléatoirement), d'avoir des bits dont la présence est aléatoire (et le contenu aussi ) => Permet de retranscrire plus précisément le contenu d'un weak sector, par exemple.

En complément :

Le HFE est juste une suite de bits MFM propre de préférence avec une vue piste.
La v3 supporte des randoms bits : cf RAND_OPCODE dans https://sourceforge.net/p/hxcfloppyemu/code/HEAD/tree/HxCFloppyEmulator/libhxcfe/trunk/sources/loaders/hfe_loader/hfev3_loader.c#l408
ce qui ressemble à des weakbits recalculés alors qu'on aurait pu tout simplement dumpé les rawsbits avec les erreurs MFM qui permette au séparateur de données de les générés tout seul !

Le HFE de mémoire par contre, ne permet pas d'avoir une longueur des bits de la piste non aligné et complet (8bits) sur le dernier octet de la piste MFM...Quelques rares protections peuvent utiliser en lisant plus que la longueur de la piste ce qui décale ensuite les données lues avant les bits de synchro et permet un checksum différent si on a copié en alignant à l'octet ce qui ferra perdre ces quelques bits supplémentaires...
pour moi la protection ultime ou presque !

Le IPF est refait d'après le master en réinterpretant les bits MFM en vue piste.
Donc, il faut d'abord analyser comment le disk était tracé/avait été conçu à l'époque... Et les outils n'étant pas en open source, la partie AMSTRAD est passée après les autres (AMIGa, ATARI, IBM, etc.) et a donc très peu évoluée... Elle ne reconnait donc que certaines 'protections' pour l'instant, mais cela ne serait rester en l'état -> un jour peut-être !
A signaler, qu'on peut quand même générer des IPFs 'non officiels' en mode rawbits qui permettent d'avoir l'équivalent du HFE v3, c'est à dire une vue propre d'une piste MFM en bits...Lone a fait un outil permettant ce type de génération 'non officielles' mais tout à fait fonctionnelles !

Dernier format évoqué le CT-RAW qui est lié au dump d'une disquette (généralement 5 révolutions capturées par piste) et qui si la disquette n'a pas de défaut, retranscrit parfaitement la piste en bits mais qui peut varier légèrement notamment sur certaines grosses pistes... Bref, c'est ce que le lecteur a lu en mode 'lire piste complète en bits MFM'

Il y a également le format SCP qui est dédié au dump 'brut'...

je crois que sur ce forum tu trouveras nos discussions de y'a quelques années pour faire évoluer le format eDSK en format tDSK (t comme track avec une vue piste donc), très proche du HFE mais en restant sur le principe des CHUNKS de ce format !

Ca sonne bien, tout ceci semble avoir bien progressé ces 10 dernières années !
Faudra que j'installe le nouveau CPCE.

Bon, donc la balle est dans mon camp, il faut que je retrouve mes notes sur la protection physique de ces 5 pistes, de mémoire ça joue sur une multitude de petits secteurs de taille 0 (128Ko) qui sont recombinés de manière différente d'une piste à l'autre ce qui fait que si on applique un algo de copie, ce dernier appliquera la même méthode pour les 2 pistes et la copie ne sera donc pas bonne. Je crois qu'il y avait aussi des secteurs écrits ou surtout pas écrit, car de mémoire cela générait des valeurs différentes à la lecture.
Je crois savoir où sont mes notes, va falloir les déchiffrer maintenant...

(et hERMOL, Longshot, Supersly, JMD, Markerror, et MIC, ils sont plus là ?)

À partir du Kryoflux j'ai fait un HFE fonctionnel du coup j'explore un peu la piste en mode ReadTrack

Il y a des vérifications de longueur de GAP (7, 30 et 82 sur les pistes 31,33,34), tantôt ça valide un maximum, tantôt un minimum
Ça valide aussi qu'ils n'ont pas été écrits quand il lit les données du second secteur en se synchronisant sur le premier via le readtrack

Le truc que je n'ai pas encore élucidé c'est l'ID secteur foireux perdu au début de la piste 37, il faudrait que j'améliore mon outil de visualisation de flux...

déterrage de topic

ce sont certaines protections en secteurs weaks (hexagone non?), si t'enlèves la disquette pendant la lecture d'un secteur, le FDC va renvoyer une suite de zéro jusqu'à la fin du secteur demandé (comme la protection ne demande qu'un secteur et qu'il ne teste pas le retour, il se rend pas compte que t'as éjecté la disquette), donc si tu fais le "grille-pain" au bon moment, il va lire le secteur weak (qui n'est pas weak car copié) une première fois puis le même secteur en foirant sa lecture, quand il va comparer les données, il y aura des différences et il est content.

La méthode du grille-pain aura son petit succès sur la Playstation avec des CD gravés, quelques années plus tard, pour les mêmes raisons

ps: Je déterre pour donner ces informations sur ce qui se passe lors de l'éjection
Le FDC va continuer à renvoyer des données (des zéros) jusqu'à ce qu'il atteigne la taille du secteur à lire
Si on lui a demandé de lire 10 secteurs mais qu'on éjecte pendant le 3è, il ne lira pas les suivants et l'ID contiendra celui du dernier secteur lu (pas le suivant!)
On aura aussi ET0_DRIVE_UNPLUGGED de monté (ET0 |= 8)