Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
[cryptographie] Ne pas crypter le début d'un programme pour décrypter la suite
Bonjour,
Voila j'ai un petit probleme je cherche a fair un programme qui s'auto decrypte, le debut du programme permettra de décrypter la suite pour son execution, le tout en c++ mais je sais pas comment m'y prendre sans faire deux programme différent, j'aimerais qu'il soit en un morceau.
Merci.
Salut,
Déjà, pourquoi diantre voudrais tu crypter le programme
Crypter les données utilisées par ton programme n'est il pas suffisant
A méditer: La solution la plus simple est toujours la moins compliquée
Pour le rendre sur ! Que les personnes ne puissent pas le décompiler par exemple..
Vaste couille!!!Envoyé par Ninored
Déjà, tu dois te dire que, à l'exécution, ton programme devra, de toutes manières, être présentée d'une certaine manière (présenter un code binaire exécutable compréhensible par ton processeur).
Quoi que tu fasses par ailleurs, un "simple" éditeur hexa décimal et un "simple" traducteur de certaines valeur en mnémonique (adda sera toujours représenté de la même manière pour un processeur donné), suffiront à n'importe qui connaissant un minimum l'assembleur pour arriver à "chipoter" dans ton programme s'il le souhaite
Et comme il te sera pour le moins difficile de faire en sorte de décrypter la partie cryptée en "just in time" (car cela reviendrait, en gros, à refaire quelque chose de fort proche d'un compilateur
De plus, le système d'exploitation refusera généralement que tu ailles "chipoter" au niveau de la mémoire propre à l'application (tu peux modifier certains éléments de la mémoire, mais une grosse partie est protégée et toute tentative de modification de cette partie protégée a de fortes chances de se traduire au final par une erreur de segmentation)
La seule solution qu'il te resterait est donc de crypter l'ensemble de ton exécutable.
Mais cela signifie que tu aurais besoin d'un autre exécutable pour effectuer le décryptage afin de charger le programme réel en mémoire.
Et, du coup, on en arrive au même point: le code binaire exécutable est de nouveau accessible
Enfin, il faut savoir qu'il existe, effectivement, différents systèmes qui tentent d'essayer de protéger les programmes contre le piratage, qu'il s'agisse de protection incluses dans le media de support, de système basé sur une connexion internet ou autre (les éditeurs de jeux sont très friands de ce genre de système) mais...:
Non, décidément, avant de t'attaquer à ce genre de sujet, tu devrais te concentrer d'avantage sur
- La plupart de ces systèmes sont généralement payant (et horriblement cher!), ce qui fait qu'il faut avoir la certitude d'avoir un nombre de vente suffisant pour assurer ce sur cout
- Ces systèmes ont tendance à pourrir la vie de ceux qui acquièrent légalement le droit d'utiliser l'application (qui n'a jamais ralé de ne plus pouvoir utiliser une application parce que son CD était griffé
- Aucun système n'a prouvé sa réelle efficacité à 100 %: Tout au mieux, cela retarde "un tout petit peu" les véritables pirates qui considèrent, justement, comme un défi de faire sauter les protections les plus avancées
- le fait de fournir une application efficace et résistante au "test du singe"
- le fait de sécuriser les communications (s'il y en a), les sauvegardes et les chargements (au minimum en t'assurant que les données sont bien sauvgegardées / rechargée)
- le fait de sécuriser tes requêtes SQL (s'il y en a): l'erreur à ne surtout pas faire est d'envoyer une requête du genre de SELECT * from users where user=$user and pwd= $pwd
- j'oublie surement un ou deux points
Je sais que c'est plutot difficile mais dans ce cas est-il possible de combiner les deux executable ? Car en envoyer deux est trop encombrant.
Tu peux faire en sorte de créer une archive si tu le veux.
Les bibliothèque de gestion d'archives sont nombreuses, selon le système d'exploitation utilisé(cela va de zip à gzip / tar/ et autres).
Tu peux aussi envisager de coder "en dur" la partie cryptée comme des données d'un exécutable et de créer un fichier temporaire qui corresponde à l'exécutable décrypté, mais, en toute honnêteté, je crois très sincèrement que tu te fais du mal pour rien
N'oublie pas non plus que toute algorithme de cryptage se doit d'être inversable (si tu n'arrives pas à décrypter ce qui est crypté, ca ne te sert à rien
J'aime bien l'idée de coder en "dur" la partier cacher mdrnon quand meme pas mais dans se cas pour les archives est-il possible de n'envoyer qu'un seul fichier (je veut dire par la de metter l'archive "dans" l'exe) ?
Ce n'est, a priori, pas impossible, mais tu vas, je te le répète encore une fois, te faire beaucoup de mal pour vraiment pas grand chose.
Car cela signifie qu'il faut:
Rien n'est, a proprement parler, totalement impossible en informatique: il y a toujours moyen de trouver une solution aussi tire-bouchonnée soit elle.
- un exécutable compilé et fonctionnel
- que tu crypte cet exécutable compilé
- que tu crées une archive avec l'exécutable crypté et les autres informations nécessaires
- que tu crées un autre exécutable qui sera capable de faire tout le chemin inverse
- Si tu veux vraiment éviter que l'on n'utilise les fichiers extrait, que tu veilles à effacer les fichiers temporaires qui auront été générés lors de l'extraction et du décryptage une fois que ton application est terminée
Mais il faut te dire que cela va dans les deux sens : si tu choisi une solution tire-bouchonnée, tu trouveras, de toutes façons, toujours quelqu'un qui trouvera le moyen d'inverser le processus (or, je te le répète aussi: pour que cela puisse aller, il faut que le processus soit inversable).
Pour que l'investissement nécessaire à la mise en place d'une solution "de haut vol" comme celle là vaille la peine, il y a vraiment intérêt à ce que les algorithmes utilisés, la technologie mise en oeuvre par ton application et la qualité de l'application en elle-même présentent une TRES FORTE valeur ajoutée.
Crois tu, sincèrement, que ton application présente de tels algorithmes / technologies et qu'elle soit de si bonne qualité
Ce qu'il faut comprendre, c'est que, si tu as les moyens, rien ne t'empêche d'installer un coffre à 200 000 € dans ton salon ou dans ta chambre.
Mais, si c'est pour y mettre deux pales copies industrielles de grands peintre et trois bijoux de pacotille, est ce que cela vaut vraiment la peine
Die,
+1, d'autant plus que même les coffres à 200 000 € ne sont pas inviolables.
Et c'est encore plus vrai en informatique : si une solution fiable existait, on peut partir du principe que les grands éditeurs l'utiliseraient. Il suffit de voir le nombre de versions piratées, quel que soit le logiciel considéré ...
Donc, pour Ninored, inutile de te fatiguer la cervelle : soit ton logiciel n'intéresse personne, ou presque, et tu es à peu près tranquille côté copies illégales, soit il est suffisamment intéressant pour quelques dizaines de personnes, et il sera cracké, quoi que tu fasses.
Comme les autres.
Mais admettons que ca vaille le coup d'avoir une protection (ca ne vaut pas le coup) ta methode n'est pas bonne je pense. A priori c'est faisable en faisant deux executables, puis en cryptant celui qui dois l'etre, puis en les embarquant dans un packer comme http://upx.sourceforge.net/ Mais c'est pas garanti que ca marche (ca va etre difficile pour pas grand chose).
Personellement je ne me foulerai pas mais j'aurais quand meme mis un minimum de cryptage a savoir juste mettre les donnees dans un zip a mot de passe ou un truc dans le genre. L'idee est de bloquer simplement le non-cracker mais de ne pas faire plus d'effort que ca. En fait meme comme ca c'est trop d'efforts je trouve.
Si tu veux vraiment proteger ton appli, il y a des methodes plus efficace que le cryptage:
1. refaire l'appli utilisable uniquement depuis un browser web;
2. faire en sorte d'avoir des mises a jour une fois par jour et l'appli ne peut pas tourner si elle n'a pas fais sa mise a jour;
En gros, c'es tres tres tres contraignant.
Merci de vos conseilles, donc la solution de fusionner les deux executables (crypté/décrypteur) est trop fastidieuse pour que cela en vaille la peine donc la meilleur solution est de créer deux executables distinct (ou une autre methode)... Après n'y a t-il pas d'autres moyens de rendre la tache plus compliquer pour les hackers, j'ai remarqué une chose dans le langage AutoIt c'est qu'il y avais un obufscator mais je n'en n'ai pas vraiment trouvé pour le c++ ?
Les obfuscator ne sont utiles que lorsque le code source est "accessible" à l'utilisateur.
C'est donc utile (et encore) pour tout ce qui est langage de script s'effectuant chez le client (php est un langage de script, mais le client n'en verra normalement jamais la première ligne
C++ est un langage compilé, c'est à dire que le code est déjà transformé en un ensemble d'instructions que le processeur sera en mesure de comprendre.
C'est le seul niveau auquel il ne soit plus possible d'envisager d'obfusquer le code, par qu'il est indispensable que le processeur continue à comprendre les instructions et à les effectuer dans le bon ordre.
Il est, bien sur, tout à fait possible de rendre un code totalement incompréhensible dans n'importe quel langage de programmation, mais, de manière générale, la seule personne que tu vas embêter en le faisant, c'est toi même car un code est beaucoup plus souvent lu (par son développeur) qu'il n'est écrit ou modifié et, si tu rend ton code difficile à lire, il le sera aussi (et surtout) pour toi-même, car c'est toi la première personne qui devra te relire.
Maintenant, il faut aussi voir ce que tu entends par "rendre ton programme plus sur".
Si tu veux parler d'empêcher un cracker de faire sauter une restriction ou une autre suite à l'absence de licence, je ne peux que te rappeler que les éditeurs d'applications diverses se sont cassé les dents sur ce problèmes depuis plus de trente ans et n'ont encore trouvé aucune parade efficace à 100%
Si l'idée est d'empêcher le joueur de "tricher" quand il joue seul de son coté (l'empêcher d'avoir 99 vies ou 999 999 999 pièces d'or), il n'y a strictement aucune solution à long terme: tôt ou tard, l'information se trouvera sous cette forme (ou sous une forme qui représente l'information) en mémoire, et tout ce que tu auras pu faire pour la cacher pourra être "suivi" par celui qui essaye de modifier cette valeur.
Si l'idée est d'empêcher l'utilisateur de "pirater" le serveur utilisé par ton application, il faut commencer par:
Tout cela n'a strictement rien à voir avec un quelconque cryptage (quoi que les informations en elles-même puissent être cryptées / décryptées aussi bien au niveau du client que du serveur), et tout manque à ce niveau ne pourra jamais être comblé par un quelconque tour de passe passe a posteriori.
- sécuriser la transmission d'information en elle meme
- considérer tout ce que l'utilisateur peut envoyer au serveur comme "suspect" (et donc nécessitant une vérification au niveau du serveur)
- sécuriser tout ce qui correspond à la recherche d'information au niveau du serveur (essentiellement en vérifiant les informations reçues de l'utilisateur avant de les utiliser pour la recherche)
- s'assurer que tu ne transmets à chaque fois que les informations utiles et nécessaires à l'utilisateur
- j'en passe et de meilleures
Tu veux rendre ton application plus sur
Si le but est de limiter que les cracker ne rendent ton jeu publique alors que normalement il est payant, il y a des strategies pyschologiques bien plus efficaces (au dela de forcer le joueur a jouer en ligne, ce qui resouds presque immediatement le probleme, voir les indications de koala pour les serveur):
1. vendre le jeu pas cher (cela dis ca depends de la valeur du jeu que tu veux attribuer; le jeu que je suis en train de faire ne peut pas utiliser ce genre de solution parceque c'est un jeu de niche);
2. des qu'une version est craquee et dispo sur la baie des pirates, poste pour expliquer que le jeu est normalement payant mais que tu ne peux rien faire si on ne te paye pas, mais par contre explique bien que tu es pas une grosse boite et qu'il te faut manger, mais sinon c'est pas grave - ca te feras grossir d'un coup ta communaute et donc le pourcentage de gens qui vont acheter ton jeu au final;
3. faire en sorte que la qualitee du jeu se degrade au fur et a mesure si le jeu est cracke; l'idee etant que le cracker ne vas pas voir que le jeu sais qu'il est cracke sans jouer au jeu de A a Z - ca marche mais attention parceque la plupart du temps les joueurs ne comprendrons pas que c'est parceque c'est une version cracke qu'ils ont des trucs bizarre qu'il se passe, alors soit tu le dis des le depart, ce qui detruit la protection, soit tu pars du principe que ta protection va en faire fuire;
4. ajouter un message cache dans le binaire qui dis en gros qu'il y a une recompense a ceux qui t'enverrons des explications sur les trous de securite du jeu - c'est pas mal, mais ca suppose que tu ais du temps a consacrer a boucher ces trous plus tard, a voir si ca vaut le coup, mais a 98% des cas non. (si c'est un trou sur un serveur de jeu multi, ca vaut carrement le coup)
5. faire des updates tres regulieres et pas compatibles - ca marche tres bien si tu peux te le permettre, mais c'est rare qu'on puisse;
6. Faire en sorte que si la version est crackee et que le jeu a ete joue pendant plusieurs heures, genre 5-6 (et donc qu'a priori l'utilisateur aime bien le jeu), le jeu affiche un message qui est une petite lettre de l'auteur du jeu, qui explique qu'apparament le joueur aime le jeu et donc ca serait bien si il considerait de payer le jeu vu que ca vaut le coup, si il peut - et aussi il faut expliquer que le developpeur veut vivre du jeu et qu'il vaut mieu le payer si on veut qu'il soit en mesure de faire d'autres jeux. C'est apparamment tres efficace, d'apres les quelques essais faits par, par exemple, ID Software lorsqu'ils ont sorti doom je crois. Dans tous les cas, l'idee est que si la peronne aime vraiment le jeu et peut se le payer, il y a de fortes chances qu'elle le fera (si ton systeme de payement est pas contraignant et le jeu n'est pas demeusurement cher, evidemment).
Il y a d'autres variantes de ces methodes mais le but c'est juste de faire realiser au joueur que si il trouve que ce que tu fais a de la valeur, il vaudrait mieu qu'il le paye si il en veut encore. Note aussi que si tu as une communaute assez grandes, tu peux te faire enregistrer sur Steam via GreenLight ce qui te feras pas mal de ventes et apres tu pourras ignorer le cracking tant que ca t'empeche pas d'avancer.
Dans tous les cas, pose toi la question: est-ce que ca vaut le coup de passer plusieurs mois sur une protection qui sera killee en quelques heures?
Si la securitee est absolument necessaire, fait un jeu client-serveur dont tu es le seul detenteur de serveur.
Exactement, les protections retardent juste (souvent de quelques jours seulement) le moment ou l'appli sera crackée et dispo sur la baie.
De plus, meilleure sera la protection, et plus il y aura de gens motivés pour la cracker, ça peut être vu comme un défi ce genre de trucs.
Les applis client serveurs sont de base plus sûre car le client n'a pas accès à l'ensemble du code, mais rien n'est infaillible. Il suffit de voir les MMO pour ça, des groupes de passionnés re-codent entièrement des serveurs par exemple (avec plus ou moins de réussite en fonction des jeux).
La sensibilisation des joueurs sur le fait que c'est ton job, et ce qui te permet de manger marchera, imo, bien mieux.
Je vous remercient tous de vos conseilles très utils je me tournerais donc sur une securité du type client server avec un fichier a mettre a jours tout les jours pour que le jeux puisse marcher. Merci encore de vos conseilles.
Ca ne sera pas suffisant, il faut que des fonctions du jeu soient mises a jour, sinon le jeu peut juste etre modifier pour ignorer l'update.
Ou alors fais en sorte que le jeu se joue essentiellement sur le serveur.
Bon courage
Je m'en doute ^^ je trouverais un moyen dans le genre merci
Répondre avec citation
Partager