| ★ APPLICATIONS ★ COURS DE BIDOUILLAGE ★ INITIATION - PROTECTIONS LOGICIELLES (IV) ★ |
| Protection Logiciel n°45 (Amstrad Cent Pour Cent) | Applications Cours De Bidouillage |
Pour qu'un logiciel shareware ou du commerce vous rapporte un tantinet de monnaie, il faut au minimum qu'il ne soit pas dupliqué par le premier copieur venu. Mais cela n'est pas tout, encore faut-il bien organiser la protection au sein du système et du programme, pour qu'elle ne soit pas trop vulnérable. Voici quelques conseils en tout genre pour mieux vous protéger. Imaginez une disquette incopiable, dans un format que même Discologie 38.2 ne saurait reproduire. Un produit quelconque sur une telle disquette serait-il réellement en sécurité? Non et cinquante fois non. Révisez vos leçons. Si le code permettant de vérifier la protection n'est pas lui aussi protégé par quelques plombages puissants, le format d'enfer de la disquette ne sera qu'un leurre inutile et seulement bon à rebuter les inconditionnels des copieurs. N'importe quel petit bidouilleur malin saura taper dans le code et enlever le petit morceau de programme qui plante le produit. OU PROTEGER QUOI ? De préférence, il faudra protéger les parties sensibles du programme par des sommes de contrôle et des comparaisons de zones. Pour ne pas que tout saute tout de suite, il ne faut pas appeler la protection par un CALL, mais recopier le programme de protection çà et là dans le code, pour que le pirate fasse un maximum de manipulations avant de déplomber totalement le logiciel. Pour brouiller les pistes et pour que les recherches de protections soient les plus ardues possibles, n'hésitez pas à coder la partie vérification. Créez ainsi deux routines; la première décodera le sous-programme de vérification, puis l'appellera. La seconde le recodera après son appel pour ne laisser aucune trace. Le programme de codage basé sur un XOR, ou quelques décalages, devra générer différentes versions de camou flage pour qu'une recherche numérique soit, elle aussi, inefficace. POUSSER LE VICE Pour que les outils mémoire ne soient pas facilement utilisables, régénérez les vecteurs système et remplissez de zéros les zones de mémoire non utilisées par le programme. Vérifiez quelques centaines d'octets plus loin que ces zones sont bien vierges. Lors de l'initialisation de votre logiciel, faites un maximum de CALLs imbriqués. Cela embrouille considérablement les pirates et peut faire déborder la pile si elle est déjà utilisée par un programme résident. N'hésitez pas à utiliser des routines de scanning sous interruption pour vérifier si telle ou telle routine clef n'est pas contournée. A la limite de la folie, faites des routines de calcul de sommes de contrôle pour vérifier que chaque page de 256 octets meublant la mémoire est bien telle que vous l'avez écrite. Le cas échéant, faites des sommes de contrôle sur ces checksums. N'oubliez pas que tout ce que vous avez fait, un pirate peut le défaire. Les pirates qui veulent protéger leurs œuvres vont jusqu'à utiliser des timings. De cette manière, si le moindre octet de code est modifié, la machine plante. Bref, une protection est le contraire de ce qu'on ne doit pas faire dans la vie et se limite en une phrase: faites aux autres ce que vous n'aimez pas qu'on vous fasse. J'espère que ces quelques lignes vous auront donné des idées plus que malignes. CATALOGUE CAMOUFLE Pour ceux qui ne se sentent pas la force de réaliser des protections de folie comme celles citées ci-dessus, il est possible de dresser des pièges système. Comme vous le savez, le CP/M n'est capable de s'en sortir que si les programmes et données qu'il manipule sont organisés dans des fichiers à son format. Le fait d'éparpiller des données sur le disque ou de cacher des fichiers dans des catalogues parsemés sur la face de la disquette rend les copies de fichiers totalement aberrantes. Vous pouvez ainsi rendre irréutilisables vos programmes en embrouillant le petit pirate avec des pokes et des appels étranges et incompréhensibles pour un non-initié. Il va sans dire que de tels procédés ne seront pas à l'abri de la copie intégrale de disquette. En revanche, toute copie de fichiers ou tentative de détournement ou de réutilisation de codes sera retardée, voire compromise. Ne restons pas sur notre faim et voyons quelques exemples. DES INFORMATIONS NON FICHEES Le truc le plus bête est de sauvegarder des programmes sur des secteurs qui n'appartiennent à aucun fichier. Le chargement de ces informations devra donc se faire en passant par des lectures de secteurs. Une copie de fichiers ou une sauvegarde quelconque de fichier sur la disquette risquera de compromettre le fonctionnement du logiciel entier. En poussant un peu, la ruse encore plus folle est de loger des petits bouts de programme en langage machine à la fin des blocs d'un fichier. Pour l'exemple, une zone de données de 1 000 octets laissera 24 octets de libre dans un bloc de 1 024 octets. Vous pouvez vous servir de ce bout pour Y coller n'importe quelle routine assembleur. Appeler une routine machine dans le buffer disque, sans qu'on ait chargé autre chose qu'un programme en Basic, en déconcertera plus d'un et le mettra aux fraises. J'ai même vu des fous dessiner une page écran autour d'une petite routine. Le fait de faire un CALL au beau milieu de l'écran se révélait complètement ébouriffant. Surtout que l'adresse de la routine était finement calculée puis stockée dans HL, et son corps, en dehors de quelques pokes fort à propos, faisait du n'importe quoi sur mesure. Vous passerez de longues heures pour vérifier les calculs de l'adresse, autant encore pour essayer de déchiffrer une routine piège-couillon, pour vous apercevoir que tout était bon du premier coup. J'ai perdu 32 768 cheveux ce jour-là ( Poum aussi, mais les siens n'ont pas repoussé ). LES CATALOGUES FANTOMES Eh oui, ce n'est pas de la magie. Notre CPC est bien capable de faire naviguer des informations sur la disquette. Il est possible de déplacer le catalogue. On peut aussi changer sa taille mais, malheureusement, on ne peut changer sa structure. Dans la longue liste des variables utilisées par le système au sujet du lecteur de disquette, il en existe quatre qui vont nous être d'un grand secours. Les voici dans leur ordre d'apparition:
Avant tout, il faut savoir que le système est très prudent. Il faut qu'il vérifie tout et qu'il réinstalle sans cesse. des valeurs qu'il aime utiliser. Si nous pokons 95 en &A897 et 224 en &A899, nous devrions avoir un catalogue long de trois blocs, donc de 96 entrées. Que nenni, le système regardera la disquette, et une fois la commande CAT lancée, nous nous apercevons que ce que nous avons fait est vain et que les valeurs par défaut sont revenues. Quelques PEEK le prouvent. Serions nous perdus? LE POKE BONHEUR Non, nous n'avons pas été menés à notre perte par le système. Les programmeurs de l'Amsdos ont fait des miracles et nous permettent de forcer le système à nous écouter. Le fait de poker 255 en &A8A8 le supplie de laisser nos valeurs tranquilles, ce qu'il fait, tombant sous le charme de tant de bits tendus. Cela fait, nous pouvons poker ce que nous voulons, où nous voulons. .-----.-------.-------. |
|  |
 | Page précédente : Protection Logiciel n°44 |
|
Il faut donc protéger la routine de vérification de format. Pour cela, un second sous-programme est chargé de vérifier l'intégralité de la routine de vérification. Ce dernier doit aussi être surveillé, car s'il est contourné, sa routine protégée pourra l'être aussi. Bref, à tout endroit du programme, en n'importe quelle circonstance, il faut penser à aller voir du côté de la protection ou de sa routine.
