Comment faire un bon anti-fissure de protection?
Je vais commencer par dire je sais qu'il est impossible de prévenir votre logiciel de rétro-ingénierie.
Mais, quand je prends un coup d'oeil à crackmes.de, il y a des crackmes avec une difficulté de grade 8 et 9 (sur une échelle de 1 à 10). Ces crackmes se sont fissurés par le génie des cerveaux, qui écrivent un tutoriel sur la façon de se fissurer. Quelques fois, ces tutoriels sont de+ de 13 pages!
Quand j'essaie de faire un crackme, ils fissure dans 10 minutes. Suivi par un "how-to-crack" tutoriel avec une longueur de 20 lignes.
Donc les questions sont:
- Comment puis-je faire un relativement bon anti-fissure de protection.
- Techniques qui dois-je utiliser?
- Comment puis-je l'apprendre?
- ...
- "Comment puis-je l'apprendre? "- commencez par la recherche pour des questions similaires.
- Même la DEA ne peut pas faire efficace anti-fissure de protection. Ce qui vous fait penser que vous pouvez? 🙂
- C'est un très vaste, très vague question. En ce qui concerne votre logiciel souhaitez-vous protéger?
- Ce n'est pas un doublon, vous pouvez faire beaucoup de anticracking qui n'a même pas se rapportent à faire une application plus difficile de le décompiler.
- encore, il y a beaucoup de dupes, cela devient demandé quelques fois/semaine ici. J'ai juste pris le plus proche que j'ai pu trouver dans le "Connexes" de la liste.
- Lire les tutoriels pour le haut niveau crackmes et d'appliquer des techniques similaires.
- Juste une remarque: Crackmes se spécialisent dans la "dissimulation" ou "autoprotection" alors que ces applications sont conçues pour les affaires. Si vous souhaitez utiliser ces "sécurité" méthodes de limiter vous-même. Par exemple une fonction comme "facile à installer et à déployer" joue contre les "anti-copie" de la sécurité. Comme l'a dit Dan, cela dépend de ce que vous souhaitez protéger/protéger.
Vous devez vous connecter pour publier un commentaire.
Avertissement: je travaille pour un logiciel de protection de fournisseur d'outils (Wibu-Systems).
L'arrêt de la fissuration est tout ce que nous faisons et tout ce que nous avons fait depuis 1989. Nous avons donc bien comprendre comment SW obtient craqué et comment l'éviter. Ligne du bas: seulement avec un matériel sécurisé dongle, mise en œuvre correctement, pouvez-vous garantir contre la fissuration.
Plus forte anti-fissuration repose sur le chiffrement (ou symétrique à clé publique). Le chiffrement peut être très forte, mais moins que la clé de stockage/production est tout aussi fort, il peut être attaqué. Beaucoup d'autres méthodes sont possibles, même avec un bon cryptage, sauf si vous savez ce que vous faites. Un logiciel seule solution pour stocker la clé dans un endroit accessible facilement trouvé ou vulnérables à un man-in-the-middle attack. La même chose est vraie avec des clés stockées sur un serveur web. Même avec un bon cryptage et sécurisée de stockage de clés, sauf si vous pouvez détecter les débogueurs le cracker pouvez simplement prendre un instantané de la mémoire et de générer un exe à partir de cela. Si vous avez besoin de ne jamais complètement décrypter en mémoire à tout moment et avoir un peu de code pour le débogueur de détection. L'Obfuscation, le code mort, etc, ne ralentit pas pour longtemps, car ils ne craque pas par commencer au début et travailler votre code. Ils sont beaucoup plus intelligents que cela. Il suffit de regarder certains de la fissuration des vidéos sur le net pour voir comment trouver la sécurité le code de la détection et de la fissure à partir de là.
Brève promotion éhontée: Notre système matériel n'a JAMAIS été fissuré. Nous avons un important client qui l'utilise uniquement pour les anti-rétro-ingénierie. Donc, nous savons qu'il peut être fait.
Langues comme Java et C# sont trop haut niveau et ne fournissent aucune des structures efficaces contre la fissuration. Vous pourrait rendre difficile pour les script kiddies par dissimulation, mais si votre produit en vaut la peine, il sera cassé de toute façon.
Je serait à son tour cette tour légèrement et penser:
(1) la mise en place simple(ish) des mesures afin que votre programme n'est pas trivial de hack, donc par exemple en Java:
Cependant, plus l'effort d'aller vous, les plus graves, les pirates vont le voir comme un "défi". Vous avez vraiment veulent juste s'assurer que, disons, un moyen 1ère année de licence d'informatique élève ne peut pas pirater votre programme en quelques heures.
(2) de mettre de plus en plus subtiles droit d'auteur/paternité marqueurs (par exemple, les métadonnées dans les images, peut-être subtilement intégrer une fenêtre qui apparaîtra dans 1 an pour toutes les copies qui n'ont pas à se connecter et s'authentifier avec votre serveur...) que les pirates pourraient pas la peine de chercher/désactiver parce que leur piraté le programme fonctionne tel qu'il est.
(3) il suffit de donner votre programme à l'écart dans les pays où vous n'avez pas réellement une chance de faire un profit et ne vous inquiétez pas trop-si quoi que ce soit, c'est une forme de marketing viral. Rappelez-vous que dans de nombreux pays, ce que nous voyons dans le UK/US que le "piratage" de nos Choses Précieuses est ouvertement tolérée par le gouvernement/l'application de la loi; ne basez pas votre modèle d'affaires autour de l'application du droit d'auteur qui n'existe pas.
J'ai un assez populaire app (que je ne vais pas préciser ici, pour éviter les craquelins curiosité, bien sûr) et souffert avec les versions craqué quelques fois dans le passé, fait qui vraiment m'a causé beaucoup de maux de tête.
Après des mois de la difficulté avec beaucoup d'anti-fissuration des techniques, depuis 2009, j'ai pu établir une méthode qui s'est avérée efficace, au moins dans mon cas : mon application n'a pas été fissuré depuis.
Ma méthode consiste à utiliser une combinaison de trois implémentations :
1 - Beaucoup de contrôles dans le code source (taille, CRC, de la date et ainsi de suite : utilisez votre créativité. Par exemple, si mon appli détecte des outils comme OllyDbg être exécuté, il va forcer la machine à l'arrêt)
2 - CodeVirtualizer virutalization dans les fonctions sensibles dans le code source
3 - EXE cryptage
Aucune de ces sont vraiment efficaces seul : vérifications peuvent être transmis par un débogueur, la virtualisation peut être inversée et EXE de chiffrement peut être déchiffré.
Mais quand vous avez utilisé tout à fait, ils vont provoquer de fortes douleurs à tout cracker.
Il n'est pas parfait, même : si de nombreux contrôles qui rend l'application plus lente et les EXE chiffrer peut conduire à des faux positifs dans certains logiciels anti-virus.
Même si il n'y a rien comme de ne pas craquer 😉
Bonne chance.
Personnellement je suis fan de vérification côté serveur.
Il peut être aussi simple que l'authentification de l'application ou de l'utilisateur chaque fois qu'il exécute. Cependant qui peut être facilement craqué. Ou ranger une partie de code côté serveur et qui serait requere beaucoup plus de travail.
Cependant votre programme requere connexion internet doit avoir et vous aurez les frais de serveur. Mais que la seule façon de le faire assez bien protégé. Toute application autonome sera fissuré relativement rapide.
Plus logique que vous passer à côté serveur plus difficile à résoudre qu'il va obtenir. Mais il le fera si elle en vaut la peine. Même les grandes entreprises comme Blizzrd ne peut pas empêcher la theyr côté serveur inversé conçu.
J'suivantes:
Créer dans la maison une clé nommée KEY1 avec N octets au hasard.
Vendre à l'utilisateur un "numéro de Licence" avec le Logiciel. Prendre note de son nom et son prénom et dites-lui que ces données sont nécessaires pour activer le Logiciel, aussi une connexion Internet.
Télécharger dans les prochaines 24 heures pour votre serveur le "numéro de Licence", et le nom et le prénom aussi la KEY3 = (KEY1 XOR hash_N_bytes(License_number, nom et prénom) )
Le programme d'installation demande un "Licese_number" et le nom et prénom, puis il envoie ces données vers le serveur et télécharge la clé nommée "CLE3" si ces données correspondent à un valide vendre.
Ensuite le programme d'installation fait KEY1 = CLE3 XOR hash_N_bytes(License_number, nom et prénom)
Le programme d'installation vérifie KEY1 à l'aide d'un "Hash" de 16 bits. L'application est chiffré avec la KEY1 clé. Puis il déchiffre l'application avec la clé et c'est prêt.
À la fois le programme d'installation et l'application doit avoir un CRC le contenu de la case.
Pu vérifier en cours de débogage.
Les deux pourraient avoir chiffré les parties de code pendant l'exécution.
Que pensez-vous de cette méthode?