Protéger les exécutables du reverse engineering?
J'ai réfléchi à la façon de protéger mon code C/C++ du désassemblage et de l'ingénierie inverse. Normalement, je ne tolérerais jamais ce comportement dans mon code; Cependant, le protocole actuel sur lequel je travaille ne doit jamais être inspecté ni compréhensible, pour la sécurité de différentes personnes.
Maintenant, il s’agit d’un nouveau sujet pour moi, et Internet n’est pas vraiment une ressource pour prévention contre le reverse engineering mais représente des tonnes d’informations sur comment procéder au reverse engineering
Certaines des choses auxquelles j'ai pensé jusqu'ici sont:
- Injection de code (appel de fonctions factices avant et après les appels de fonctions réels)
- Obfustication de code (modifie le démontage du binaire)
Écrire mes propres routines de démarrage (plus difficile pour les débogueurs de se lier)
void startup(); int _start() { startup( ); exit (0) } void startup() { /* code here */ }Vérification à l'exécution des débogueurs (et forcer la sortie si elle est détectée)
Trampolines de fonction
void trampoline(void (*fnptr)(), bool ping = false) { if(ping) fnptr(); else trampoline(fnptr, true); }Allocations et désallocations inutiles (la pile change beaucoup)
- Appels factices et trampolines inutiles (des tonnes de sauts en sortie de démontage)
- Tonnes de moulage (pour le démontage obfusqué)
Je veux dire que ce sont quelques-unes des choses auxquelles j'ai pensé, mais elles peuvent toutes être résolues et analysées par les analystes du code, à condition de respecter le bon calendrier. Y a-t-il une autre alternative que j'ai?
Ce que dit Amber est tout à fait juste. Vous pouvez rendre l’ingénierie inverse plus difficile, mais vous ne pouvez jamais l’empêcher. Vous ne devriez jamais faire confiance à "sécurité" reposant sur la prévention de l'ingénierie inverse .
Cela dit, les meilleures techniques anti-reverse engineering que j'ai vues ne visaient pas à dissimuler le code, mais à casser les outils que les gens utilisent habituellement pour comprendre le fonctionnement du code. Trouver des moyens créatifs de casser désassembleurs, débogueurs, etc. est à la fois plus efficace et plus satisfaisant sur le plan intellectuel que de simplement générer des tonnes de code spaghetti horribles. Cela ne fait rien pour bloquer un attaquant déterminé, mais cela augmente la probabilité que J Random Cracker s'éloigne et travaille sur quelque chose de plus facile à la place.
mais ils peuvent tous être contournés et/ou calculés par les analyseurs de code à la bonne heure.
Si vous donnez aux gens un programme qu'ils peuvent exécuter, ils seront également capables de le désosser s'il en a le temps. C'est la nature des programmes. Dès que le fichier binaire est disponible pour quelqu'un qui veut le déchiffrer, vous ne pouvez pas empêcher une éventuelle ingénierie inverse. Après tout, l’ordinateur doit pouvoir le déchiffrer pour pouvoir l’exécuter, et un humain est tout simplement un ordinateur plus lent.
Safe Net Sentinel (anciennement Aladdin). Mises en garde cependant - leur API craint, la documentation craint, et les deux sont excellents par rapport à leurs outils SDK.
J'ai utilisé leur méthode de protection matérielle ( Sentinel HASP HL ) pendant de nombreuses années. Il nécessite une clé USB propriétaire qui sert de "licence" pour le logiciel. Leur SDK chiffre et obscurcit votre exécutable et vos bibliothèques, et vous permet de lier différentes fonctionnalités de votre application aux fonctionnalités gravées dans la clé. Sans une clé USB fournie et activée par le donneur de licence, le logiciel ne peut pas décrypter et ne peut donc pas s'exécuter. La clé utilise même un protocole de communication USB personnalisé (en dehors de mes connaissances, je ne suis pas un pilote de périphérique) pour rendre difficile la création d'une clé virtuelle ou pour altérer la communication entre le gestionnaire d'exécution et la clé. Leur SDK n’est pas très convivial pour les développeurs et il est très pénible d’intégrer l’ajout d’une protection à un processus de construction automatisé (mais possible).
Avant la mise en œuvre de la protection HASP HL, 7 pirates connus avaient retiré les "protections" de dotfuscator du produit. Nous avons ajouté la protection HASP en même temps qu'une mise à jour majeure du logiciel, qui effectue des calculs lourds en vidéo en temps réel. Comme le montre le profilage et l'analyse comparative, la protection HASP HL n'a ralenti les calculs intensifs que d'environ 3%. Depuis la publication de ce logiciel il y a environ 5 ans, aucun nouveau pirate du produit n'a été trouvé. Le logiciel qu'il protège est en forte demande sur son segment de marché et le client est au courant que plusieurs concurrents tentent activement de procéder à une ingénierie inverse (sans succès jusqu'à présent). Nous savons qu'ils ont tenté de solliciter l'aide de quelques groupes en Russie qui proposent un service pour casser la protection des logiciels, car de nombreux messages sur divers groupes de discussion et forums ont inclus les versions les plus récentes du produit protégé.
Récemment, nous avons essayé leur solution de licence logicielle (HASP SL) sur un projet plus petit, assez simple pour fonctionner, si vous êtes déjà familiarisé avec le produit HL. Cela semble fonctionner; aucun incident de piratage n'a été signalé, mais la demande de ce produit est bien moindre.
Bien sûr, aucune protection ne peut être parfaite. Si quelqu'un est suffisamment motivé et a de l'argent à dépenser, je suis sûr que les protections offertes par HASP pourraient être contournées.
Prenons, par exemple, le algorithme AES . C'est un algorithme très très public, et il est TRÈS sécurisé. Pourquoi? Deux raisons: il a été examiné par de nombreuses personnes intelligentes, et la partie "secrète" n'est pas l'algorithme en lui-même - la partie secrète est la clé qui est l'une des entrées de l'algorithme. C'est une bien meilleure approche pour concevoir votre protocole avec un "secret" généré qui ne relève pas de votre code, plutôt que de le rendre secret. Quoi que vous fassiez, le code peut toujours être interprété et (idéalement), le secret généré ne peut être compromis que par une approche massive de la force brute ou par le vol.
Je pense qu'une question intéressante est " Pourquoi voulez-vous obscurcir votre code?" Vous voulez empêcher les attaquants de déchiffrer vos algorithmes? Pour rendre plus difficile la recherche de bogues exploitables dans votre code? Vous n'avez pas besoin d'obscurcir le code si celui-ci était insaisissable en premier lieu. La racine du problème est un logiciel fissurable. Corrigez la racine de votre problème, ne vous contentez pas de l’obscurcir.
En outre, plus vous confondez votre code, plus il vous sera difficile de trouver des problèmes de sécurité. Oui, ce sera difficile pour les pirates, mais vous devez aussi trouver des bogues. Le code devrait être facile à maintenir dans les années à venir et même un code clair bien écrit peut être difficile à maintenir. Ne faites pas pire.
Les meilleures astuces anti-désassembleur, en particulier sur les jeux d'instructions de longueur de mot variable, sont en code assembleur/machine, pas en C. Par exemple
CLC
BCC over
.byte 0x09
over:
Le désassembleur doit résoudre le problème selon lequel une destination de branche est le deuxième octet dans une instruction à plusieurs octets. Un simulateur de jeu d'instructions n'aura pas de problème cependant. Les ramifications vers des adresses calculées, que vous pouvez provoquer à partir de C, rendent également le désassemblage difficile, voire impossible. Le simulateur de jeu d'instructions n'aura aucun problème avec cela. L'utilisation d'un simulateur pour trier les destinations des succursales peut faciliter le processus de désassemblage. Le code compilé est relativement propre et facile pour un désassembleur. Donc, je pense qu'une certaine assemblée est nécessaire.
Je pense que c'était presque le début du Zen of Assembly Language de Michael Abrash, où il a montré une simple astuce anti-désassembleur et anti-débogueur. Le 8088/6 avait une file d'attente de pré-extraction, ce que vous avez fait était une instruction qui modifiait l'instruction suivante ou un couple devant. Si vous exécutez l’instruction modifiée pas à pas, si votre simulateur de jeux d’instructions ne simule pas complètement le matériel, vous exécutez l’instruction modifiée. Sur un matériel réel fonctionnant normalement, la véritable instruction se trouvait déjà dans la file d'attente et l'emplacement de mémoire modifié ne causerait aucun dommage tant que vous n'exécuteriez pas à nouveau cette chaîne d'instructions. Vous pourriez probablement encore utiliser un truc comme celui-ci aujourd'hui, car les processeurs en pipeline récupèrent l'instruction suivante. Ou, si vous savez que le matériel possède une instruction et un cache de données distincts, vous pouvez modifier un nombre d'octets à l'avance si vous alignez correctement ce code dans la ligne de cache. L'octet modifié ne sera pas écrit dans le cache d'instructions, mais dans le cache de données, et un simulateur de jeu d'instructions ne disposant pas de simulateurs de cache appropriés ne fonctionnerait pas correctement. Je pense que les solutions logicielles ne vous mèneront pas très loin.
Ce qui précède est vieux et bien connu, je ne connais pas suffisamment les outils actuels pour savoir s’ils travaillent déjà autour de telles choses. Le code à auto-modification peut/va déclencher le débogueur, mais l'humain peut/va se limiter au problème et ensuite voir le code à auto-modification et le contourner.
Auparavant, il fallait environ 18 mois aux pirates informatiques, par exemple les DVD. Maintenant, ils sont en moyenne autour de 2 jours à 2 semaines (si motivé) (rayon bleu, iphones, etc.). Cela signifie pour moi que si je passe plus de quelques jours en sécurité, je perds probablement mon temps. La seule sécurité réelle que vous obtiendrez est matérielle (par exemple, vos instructions sont cryptées et seul le cœur du processeur situé à l'intérieur de la puce décrypte juste avant son exécution, de manière à ne pas exposer les instructions décryptées). Cela pourrait vous faire gagner des mois au lieu de plusieurs jours.
Lisez également le livre de Kevin Mitnick, The Art of Deception. Une personne comme celle-ci pourrait prendre un téléphone et vous demander, à vous ou à un collègue, de dévoiler les secrets du système, en pensant qu'il s'agissait d'un gestionnaire, d'un autre collègue ou d'un ingénieur en matériel dans une autre partie de la société. Et votre sécurité est détruite. La sécurité ne consiste pas uniquement à gérer la technologie, il faut aussi gérer les humains.
Rendre le code difficile à inverser s'appelle l'obscurcissement de code.
La plupart des techniques que vous mentionnez sont assez faciles à utiliser. Ils se concentrent sur l'ajout de code inutile. Mais le code inutile est facile à détecter et à supprimer, vous laissant avec un programme propre.
Pour que l'obscurcissement soit efficace, vous devez associer le comportement de votre programme aux bits inutiles en cours d'exécution. Par exemple, plutôt que de faire ceci:
a = useless_computation();
a = 42;
faire ceci:
a = complicated_computation_that_uses_many_inputs_but_always_returns_42();
Ou au lieu de faire ceci:
if (running_under_a_debugger()) abort();
a = 42;
Faites ceci (où running_under_a_debugger ne devrait pas être facilement identifiable en tant que fonction qui teste si le code est exécuté sous un débogueur - elle devrait associer des calculs utiles à la détection du débogueur):
a = 42 - running_under_a_debugger();
L'obfuscation efficace n'est pas quelque chose que vous pouvez faire uniquement au stade de la compilation. Quoi que le compilateur puisse faire, un décompilateur peut le faire. Bien sûr, vous pouvez augmenter le fardeau des décompilateurs, mais cela ne va pas aller loin. Les techniques d’obscurcissement efficaces, dans la mesure où elles existent, impliquent l’écriture d’une source obscurcie dès le premier jour. Modifiez automatiquement votre code. Lit ton code avec des sauts calculés, dérivés d'un grand nombre d'entrées. Par exemple, au lieu d'un simple appel
some_function();
pour ce faire, vous devez connaître la disposition exacte attendue des bits dans some_data_structure:
goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;
Si vous êtes sérieux au sujet de l'obscurcissement, ajoutez plusieurs mois à votre planification. L'obscurcissement n'est pas bon marché. Et considérez que, de loin, le meilleur moyen d'éviter que les personnes modifient leur code, c'est de le rendre inutile afin qu'il ne soit pas dérangé. C'est une simple considération économique: ils procéderont à une ingénierie inverse si leur valeur est supérieure au coût; mais augmenter leur coût augmente également votre coût, alors essayez de réduire la valeur pour eux.
Maintenant que je vous ai dit que l'obscurcissement est difficile et coûteux, je vais vous dire que ce n'est pas pour vous quand même . vous écrivez
protocole actuel sur lequel je travaille ne doit jamais être inspecté ou compréhensible, pour la sécurité de différentes personnes
Cela soulève un drapeau rouge. C'est sécurité par obscurité , qui a un très mauvais bilan. Si la sécurité du protocole dépend des personnes ne connaissant pas le protocole, vous avez déjà perd .
Lecture recommandée:
- La bible de sécurité: Ingénierie de la sécurité par Ross Anderson
- La bible obfuscation: Logiciel subreptice par Christian Collberg et Jasvir Nagra
Plusieurs fois, la crainte que votre produit soit inversé est mal placée. Oui, il peut être inversé; mais deviendra-t-il si célèbre sur une courte période de temps, que les pirates trouveront utile de renverser la tendance? it? (ce travail n’est pas une mince activité, pour des lignes de code substantielles).
Si cela devient vraiment un gagne-pain, vous devriez alors avoir assez d'argent pour le protéger en utilisant des moyens légaux comme, brevet et/ou droits d'auteur.
IMHO, prenez les précautions de base que vous allez prendre et libérez-le. Si cela devient un point d'ingénierie inverse qui signifie que vous avez fait du très bon travail, vous trouverez vous-même de meilleurs moyens de le surmonter. Bonne chance.
Prenez une lecture de http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Je suis sûr que d’autres pourraient probablement aussi expliquer pourquoi la sécurité par l’obscurité est une mauvaise chose.
Il devrait être tout à fait possible, en utilisant les techniques cryptographiques modernes, que votre système soit ouvert (je ne le dis pas devrait être ouvert, mais simplement be), et toujours en sécurité totale, tant que l'algorithme cryptographique ne comporte pas de trou (probablement si vous en choisissez un bon), vos clés/mots de passe privés restent privés et vous n'avez pas de trous de sécurité dans votre code (, c’est ce qui devrait vous préoccuper ).
Depuis juillet 2013, on observe un regain d'intérêt pour les obscurcissements cryptographiquement robustes (sous la forme de Indiscernables Habilitations), qui semblent avoir été inspirés par des recherches originales menées par Amit Sahai .
- Sahai, Garg, Gentry, Halevi, Raykova, Waters, Obfuscation de l’indiscernabilité du candidat et chiffrement fonctionnel pour tous les circuits (21 juillet 2013).
- Sahai, Waters, Comment utiliser l’obscurcissement indiscernable: cryptage déniable, etc. .
- Sahai, Barak, Garg, Kalai, Paneth, Protéger l'obfuscation contre les attaques algébriques (4 février 2014).
Vous pouvez trouver des informations distillées dans ceci article de Quanta Magazine et dans cela article de IEEE Spectrum .
Actuellement, la quantité de ressources nécessaires pour utiliser cette technique la rend peu pratique, mais le consensus AFAICT est plutôt optimiste quant à l'avenir.
Je le dis très simplement, mais à tous ceux qui ont l'habitude de rejeter instinctivement la technologie d'obfuscation - c'est différent. S'il s'avère que cela fonctionne réellement et qu'il est pratique , c’est majeur, pas seulement pour l’obscurcissement.
Pour vous informer, lisez la littérature académique sur obscurcissement du code. Christian Collberg de l'Université de l'Arizona est un érudit réputé dans ce domaine; Salil Vadhan de l’Université de Harvard a également fait du bon travail.
Je suis en retard sur cette littérature, mais l’idée essentielle dont je suis conscient est qu’il est impossible d’empêcher un attaquant de voir le code que vous exécuterez, mais vous pouvez l’entourer de code qui est non exécuté, et il faut un temps exponentiel (en utilisant les meilleures techniques connues) de l'attaquant pour découvrir quels fragments de votre code sont exécutés et ceux qui ne le sont pas.
Il y a un article récent appelé " programme d'obscurcissement et programmes ponctuels ". Si vous êtes vraiment sérieux au sujet de protéger votre application. Le document traite en général des résultats d'impossibilité théorique en utilisant un matériel simple et universel.
Si vous ne pouvez vous permettre d’exiger du matériel supplémentaire, il existe également un autre document qui offre l’obfuscation théoriquement la meilleure possible " Sur la meilleure obfuscation possible ", parmi tous les programmes ayant la même fonctionnalité et la même taille. Cependant, l’article montre que la théorie de l’information implique au mieux un effondrement de la hiérarchie polynomiale.
Ces documents devraient au moins vous fournir suffisamment de références bibliographiques pour vous familiariser avec la littérature correspondante si ces résultats ne répondent pas à vos besoins.
Mise à jour: Une nouvelle notion d’obscurcissement, appelée obscurcissement indiscernable, peut atténuer le résultat de l’impossibilité (papier)
Si quelqu'un veut passer le temps d'inverser votre binaire, vous ne pouvez absolument rien faire pour l'arrêter. Vous pouvez faire si modérément plus difficile, mais c'est à peu près tout. Si vous voulez vraiment en savoir plus à ce sujet, procurez-vous une copie de http://www.hex-rays.com/idapro/ et désassemblez quelques fichiers binaires.
Le fait que le processeur ait besoin d'exécuter le code est votre perte. La CPU n'exécute que le code machine ... et les programmeurs peuvent lire le code machine.
Cela étant dit ... vous avez probablement un problème différent qui peut être résolu autrement. Qu'essayez-vous de protéger? En fonction de votre problème, vous pouvez probablement utiliser le cryptage pour protéger votre produit.
Pour pouvoir sélectionner la bonne option, pensez aux aspects suivants:
- Est-il probable que les "nouveaux utilisateurs" ne veuillent pas payer mais utilisent votre logiciel?
- Est-il probable que les clients existants ont besoin de plus de licences que ce dont ils disposent?
- Combien les utilisateurs potentiels sont-ils disposés à payer?
- Voulez-vous attribuer des licences par utilisateur/utilisateur simultané/poste de travail/société?
- Votre logiciel a-t-il besoin de formation/personnalisation pour être utile?
Si la réponse à la question 5 est "oui", alors ne vous inquiétez pas des copies illégales. Ils ne seraient de toute façon pas utiles.
Si la réponse à la question 1 est "oui", réfléchissez d'abord à la tarification (voir question 3).
Si vous répondez "oui" à la question 2, un modèle de "paiement à l'utilisation" pourrait vous convenir.
D'après mon expérience, le paiement à l'utilisation + la personnalisation et la formation constituent la meilleure protection pour votre logiciel, car:
- Les nouveaux utilisateurs sont attirés par le modèle de tarification (peu utilisé -> peu payé)
- Il n'y a presque pas d '"utilisateurs anonymes", car ils ont besoin de formation et de personnalisation.
- Aucune restriction logicielle ne fait fuir les clients potentiels.
- Il y a un flux continu d'argent provenant de clients existants.
- Grâce à une relation commerciale à long terme, vos clients vous transmettent des informations précieuses sur le développement.
Avant de penser à introduire des DRM ou des obscurcissements, vous pourriez penser à ces points et s’ils s’appliquent à votre logiciel.
Pas de dés, vous ne pouvez pas protéger votre code de démonter. Ce que vous pouvez faire est de configurer le serveur pour la logique métier et d'utiliser Webservice pour le fournir à votre application. Bien sûr, ce scénario n'est pas toujours possible.
Je ne pense pas que tout code soit indéchiffrable mais les récompenses doivent être géniales pour que quelqu'un veuille l'essayer.
Cela dit, il y a des choses à faire, telles que:
- Utilisez le niveau d'optimisation le plus élevé possible (l'ingénierie inverse ne consiste pas uniquement à obtenir la séquence d'assemblage, mais également à comprendre le code et à le transférer dans un langage de niveau supérieur, tel que C). Un code hautement optimisé peut être un b --- h à suivre.
- Rendez les structures denses en ne disposant pas de types de données plus importants que nécessaire. Réorganisez les membres de la structure entre les versions officielles du code. Vous pouvez également utiliser des champs de bits réarrangés dans des structures.
- Vous pouvez vérifier la présence de certaines valeurs qui ne doivent pas être modifiées (un message de copyright est un exemple). Si un vecteur d'octets contient "vwxyz", vous pouvez avoir un autre vecteur d'octets contenant "abcde" et comparer les différences. La fonction qui le fait ne devrait pas être transmise aux vecteurs, mais utiliser des pointeurs externes définis dans d'autres modules comme (code pseudo-C) "char * p1 = & string1 [539];" et "char p2 = & string2 [-11731];". Ainsi, il n'y aura pas de pointeurs pointant exactement sur les deux chaînes. Dans le code de comparaison, vous comparez ensuite pour " (p1-539 + i) - * (p2 + 11731 + i) == une certaine valeur ". Le cracker pensera qu'il est prudent de changer string1 car personne ne semble le référencer. Enterrez le test dans un endroit inattendu.
Essayez de pirater vous-même le code de l'Assemblée pour voir ce qui est facile et ce qui est difficile à faire. Vous devriez avoir des idées que vous pouvez expérimenter pour rendre le code plus difficile à inverser et pour le déboguer plus difficile.
Comme beaucoup l'ont déjà dit: sur un processeur normal, vous ne pouvez pas les empêcher de le faire, vous pouvez simplement les retarder. Comme mon ancien professeur de cryptographie me l’avait dit: Vous n’avez pas besoin d’un cryptage parfait, casser le code doit être plus coûteux que le gain. Même chose pour votre obscurcissement.
Mais 3 notes supplémentaires:
Il est possible de rendre l’ingénierie inverse impossible, MAIS (et c’est un très très gros mais), vous ne pouvez pas le faire sur un processeur classique. J'ai également fait beaucoup de développement matériel, et souvent les FPGA sont utilisés. Par exemple. Les Virtex 5 FX ont un processeur PowerPC, et vous pouvez utiliser le APU pour implémenter vos propres codes opération de processeur dans votre matériel. Vous pouvez utiliser cette fonction pour réellement décrypter les incstuctions du PowerPC. inaccessible par l’extérieur ou par un autre logiciel, ni même exécuter la commande dans le matériel.Comme le FPGA a intégré le cryptage AES pour son flux de configuration, vous ne pouvez pas procéder à un reverse engineering (sauf que quelqu'un parvient à rompre AES, mais alors je suppose que nous avons autres problèmes ...). Ainsi, les fournisseurs de matériel IP protègent également leur travail.
Vous parlez de protocole. Vous ne dites pas de quel type de protocole il s'agit, mais lorsqu'il s'agit d'un protocole réseau, vous devez au moins le protéger contre le reniflement du réseau. Cela peut effectivement être fait par cryptage. Mais si vous souhaitez protéger le cryptage/décryptage d'un propriétaire du logiciel, vous êtes de nouveau victime de l'obscurcissement.
Rendez votre programme indéfinissable. Essayez d’utiliser une sorte de détection du débogage et appliquez-la, par exemple. Dans certaines formules, vous pouvez ajouter un contenu de registre de débogage à une constante magique. Il est beaucoup plus difficile de regarder si votre programme est en mode débogage, c’est-à-dire s’il tourne normalement, mais effectue un calcul, une opération ou une opération complètement erronée. Par exemple. Je connais des jeux écologiques, dotés d'une très mauvaise protection contre la copie (je sais que vous ne voulez pas de protection contre la copie, mais c'est la même chose): la version volée a modifié les ressources minées après 30 minutes de jeu et vous n'avez soudainement plus qu'une ressource . Le pirate vient de le craquer (c’est-à-dire de l’ingénierie inverse) - vérifie s’il fonctionne, et Volia l’a publié. De tels changements de comportement sont très difficiles à détecter, en particulier. s'ils n'apparaissent pas instantanément à la détection, mais seulement différés.
Donc, finalement, je suggérerais: estimer le gain des personnes qui procédent à une ingénierie inverse de votre logiciel, traduisez-le en un certain temps (par exemple, en utilisant le salaire indien le moins cher) et faites en sorte que l’ingénierie inverse prenne plus de temps.
Peut-être que votre meilleure alternative est toujours d'utiliser la virtualisation, ce qui introduit un autre niveau d'indirection/obscurcissement nécessaire pour être contourné, mais comme SSpoke l'a indiqué dans sa réponse , cette technique n'est également pas sécurisée à 100%.
Le fait est que vous n'obtiendrez pas la protection ultime, car il n'y en a pas, et si cela se produira, cela ne durera pas longtemps, ce qui signifie que ce n'était pas une protection ultime.
Quel que soit l'homme assemblé, il peut être démonté.
Il est généralement vrai que désassembler (correctement) est souvent (un peu ou plus) une tâche plus ardue, de sorte que votre adversaire doit être plus qualifiés , mais vous pouvez supposer qu’il ya toujours quelqu'un de cette qualité, et c’est une valeur sûre.
Si vous souhaitez protéger quelque chose contre les ER, vous devez au moins connaître les techniques couramment utilisées par les ER.
Ainsi les mots
internet n'est pas vraiment ingénieux pour la prévention contre le reverse engineering, mais illustre des tonnes d'informations sur la façon de faire du reverse engineering.
montrer la mauvaise attitude de votre part. Je ne dis pas que pour utiliser ou intégrer une protection, vous devez savoir comment la supprimer, mais pour l'utiliser à bon escient, vous devez connaître ses faiblesses et ses pièges. Vous devriez le comprendre .
(Il existe des exemples de logiciels utilisant la protection de manière erronée, la rendant pratiquement inexistante. Pour éviter de parler de façon vague, je vais vous donner un exemple brièvement décrit dans Internet: Oxford English Dictionary Second Edition sur CD-ROM v4. Vous pouvez en savoir plus sur Son utilisation de SecuROM dans la page suivante a échoué: Oxford English Dictionary (OED) sur CD-ROM dans un environnement Windows 16, 32 ou 64 bits: installation sur disque dur, bugs, macros de traitement de texte, mise en réseau , polices, etc. )
Tout prend du temps.
Si vous êtes nouveau sur le sujet et que vous ne disposez pas de mois, voire plutôt d'années, pour bien vous lancer dans le domaine des énergies renouvelables, choisissez les solutions proposées par d'autres. Le problème ici est évident, ils sont déjà là, alors vous savez déjà qu’ils ne sont pas sécurisés à 100%, mais créer votre propre protection vous donnerait un faux sentiment d’être protégé, à moins que vous ne connaissiez très bien l’état de la technique ingénierie inverse et protection (mais vous ne le faites pas, du moins pour le moment).
Le but de la protection logicielle est de faire peur aux débutants, de bloquer les RE communes et de mettre un sourire sur le visage de RE expérimentée après son voyage (espérons-le intéressant) au centre de votre application.
En conversation d'affaires, vous pouvez dire que tout est axé sur le report de la concurrence, dans la mesure du possible.
(Consultez la présentation de Nice Silver Needle dans Skype par Philippe Biondi et Fabrice Desclaux sur Black Hat 2006).
Vous savez qu'il y a beaucoup de choses sur les énergies renouvelables, alors commencez à les lire. :)
Comme je l’ai dit à propos de la virtualisation, je vais vous donner un lien vers un exemple de thread de EXETOOLS FORUM : Meilleur logiciel de protection: Themida ou Enigma Protector? . Cela peut vous aider un peu dans les recherches ultérieures.
Le code protégé dans une machine virtuelle semblait impossible au premier abord. Themida Packer
Mais ce n’est plus aussi sûr. Et quelle que soit la manière dont vous compilez votre code, vous pouvez toujours effectuer un dump mémoire de tout exécutable chargé et le désassembler à l’aide d’un désassembleur tel que IDA Pro.
IDA Pro est également livré avec un transformateur astucieux d'assemblage de code source en code C, bien que le code généré ressemble davantage à un fouillis mathématique de pointeur/adresse. Si vous le comparez à l'original, vous pouvez corriger toutes les erreurs et extraire tout ce qui est effacé.
Pour éviter le reverse engineering, vous ne devez pas donner le code aux utilisateurs. Cela dit, je vous recommande d’utiliser une application en ligne ... cependant (puisque vous n’avez donné aucun contexte), cela pourrait être inutile sur le vôtre.
Les techniques classiques de reverse engineering dépendent de la capacité d'un agent intelligent utilisant un désassembleur à répondre aux questions concernant le code. Si vous voulez une sécurité forte, vous devez faire des choses qui empêchent l’agent d’obtenir de telles réponses.
Vous pouvez le faire en vous fiant au programme Halting ("le programme X est-il interrompu?"), Ce qui en général ne peut pas être résolu. L'ajout de programmes difficiles à raisonner dans votre programme rend votre programme difficile à raisonner. Il est plus facile de construire de tels programmes que de les séparer. Vous pouvez également ajouter du code à un programme qui présente divers degrés de difficulté de raisonnement. Un bon candidat est le programme de raisonnement sur les alias ("pointeurs").
Collberg et al. Ont un article ("Fabrication de constructions opaques bon marché, résilientes et furtives") qui traite de ces sujets et définit une variété de prédicats "opaques" pouvant rendre très difficile la raisonnement sur le code:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf
Je n'ai pas vu les méthodes spécifiques de Collberg appliquées au code de production, en particulier les codes sources C ou C++.
L'observateur DashO Java semble utiliser des idées similaires. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/
La sécurité par l'obscurité ne fonctionne pas, comme l'ont démontré des personnes beaucoup plus intelligentes que nous deux. Si vous devez protéger le protocole de communication de vos clients, vous êtes moralement obligé d'utiliser le meilleur code disponible et entièrement examiné par des experts.
C'est pour la situation où les gens peuvent inspecter le code. Si votre application doit être exécutée sur un microprocesseur intégré, vous pouvez en choisir un doté d'une fonction de scellement, ce qui rend impossible l'inspection du code ou l'observation de paramètres autres que triviaux, tels que l'utilisation actuelle pendant son exécution. (C’est, sauf par les techniques d’invasion matérielle, que vous devez soigneusement démonter la puce et utiliser un équipement de pointe pour inspecter les courants de transistors individuels.)
Je suis l'auteur d'un assembleur de reverse engineering pour le x86. Si vous êtes prêt pour une surprise froide, envoyez-moi le résultat de vos meilleurs efforts. (Contactez-moi par le biais de mes sites Web.) Peu de réponses que j'ai trouvées me présenteraient un obstacle de taille. Si vous voulez voir comment fonctionne le code d'ingénierie inverse sophistiqué, vous devriez vraiment étudier les sites Web présentant des défis d'ingénierie inverse.
Votre question pourrait utiliser quelques éclaircissements. Comment comptez-vous garder un protocole secret si le code de l'ordinateur peut être utilisé en ingénierie inverse? Si mon protocole consiste à envoyer un message crypté RSA (même une clé publique), que gagnez-vous en gardant le protocole secret? À toutes fins utiles, un inspecteur serait confronté à une séquence de bits aléatoires.
Groetjes Albert
Contrairement à ce que la plupart des gens disent, sur la base de leur intuition et de leur expérience personnelle, je ne pense pas que l'obfuscation de programme sécurisée du point de vue de la cryptographie soit irréalisable en général.
Voici un exemple de déclaration de programme parfaitement obscurcie pour illustrer mon propos:
printf("1677741794\n");
On ne peut jamais deviner que ce qu’il fait vraiment est
printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);
Il existe un article intéressant sur ce sujet, qui prouve des résultats impossibles. C'est ce qu'on appelle "Sur la (im) possibilité de masquer des programmes" .
Bien que le papier prouve que l’obscurcissement rendant le programme non distinguable de la fonction qu’il implémente est impossible, l’obscurcissement défini de manière plus faible peut encore être possible!
Quelqu'un at-il essayé CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? Ou Themida: http://www.oreans.com/themida_features.php ?
Plus tard, on a l’air plus prometteur.
Première chose à retenir sur le fait de cacher votre code: Tout votre code n'a pas besoin d'être caché.
OBJECTIF FINAL: Mon objectif final pour la plupart des logiciels est de pouvoir vendre différentes licences qui activeront et désactiveront des fonctionnalités spécifiques dans mes programmes.
MEILLEURE TECHNIQUE: Je trouve que la construction d'un système de crochets et de filtres comme WordPress offre, est la meilleure méthode absolue pour essayer de confondre vos adversaires. Cela vous permet de chiffrer certaines associations de déclencheurs sans chiffrer le code.
La raison en est que vous voulez chiffrer le moins de code possible.
CONNAISSEZ VOS CRACKERS: Sachez ceci: La raison principale de la fissuration du code n’est pas due à la distribution malveillante de licences, mais bien à la nécessité de changer votre code et qu’ils n’ont pas vraiment besoin de distribuer des copies gratuites.
MISE EN OEUVRE: Mettez de côté la petite quantité de code que vous allez chiffrer, le reste du code devrait essayer d'être regroupé dans UN fichier pour accroître la complexité et la compréhension.
PREPARATION AU CHIFFREMENT: Vous allez chiffrer en couches avec mon système, ce sera également une procédure très complexe. Créez donc un autre programme qui sera responsable du processus de chiffrement.
STEP ONE: obscurcissez en utilisant des noms en base64 pour tout. Une fois cela fait, base64 le code masqué et enregistrez-le dans un fichier temporaire qui sera utilisé plus tard pour déchiffrer et exécuter ce code. Avoir un sens?
Je vais répéter car vous allez le faire encore et encore. Vous allez créer une chaîne base64 et l'enregistrer dans un autre fichier sous forme de variable qui sera déchiffrée et rendue.
DEUXIÈME ÉTAPE: Vous allez lire ce fichier temporaire en tant que chaîne et le masquer, puis le sauvegarder en base64 et le sauvegarder dans un deuxième fichier temporaire qui sera utilisé pour le déchiffrement et le restituer à la fin. utilisateur.
ÉTAPE TROIS: Répétez l'étape deux autant de fois que vous le souhaitez. Une fois que vous avez fonctionné correctement sans déchiffrer les erreurs, vous allez vouloir créer des mines antipersonnel pour vos adversaires.
LAND MINE ONE: Vous allez vouloir garder le fait que vous êtes averti d'un secret absolu. Installez donc un système de messagerie d'avertissement de sécurité pour tentative de pirate pour la couche 2. Il sera déclenché pour vous permettre de connaître les spécificités de votre adversaire en cas de problème.
LAND MINE DEUX: Dépendances. Vous ne voulez pas que votre adversaire puisse exécuter la couche 1, sans les couches 3, 4 ou 5, ni même le programme réel pour lequel elle a été conçue. Assurez-vous donc que dans la couche un, vous incluez une sorte de script de suppression qui s'active si le programme n'est pas présent ou les autres couches.
Je suis sûr que vous pouvez inventer vos propres mines et vous amuser avec.
A RETENIR: Vous pouvez réellement chiffrer votre code au lieu de le base64 '. De cette façon, un simple base64 ne décryptera pas le programme.
RÉCOMPENSE : Gardez à l’esprit que cela peut en fait être une relation symbiotique entre vous et votre adversaire. Je place toujours un commentaire à l'intérieur de la couche un, le commentaire félicite le pirate et lui donne un code promotionnel à utiliser pour recevoir une récompense en argent de votre part.
Rendre la récompense en espèces significative sans préjudice. Je dis normalement quelque chose comme 500 $. Si votre gars est le premier à déchiffrer le code, payez-lui son argent et devenez son ami. S'il est un de vos amis, il ne distribuera pas votre logiciel. Demandez-lui comment il l'a fait et comment vous pouvez vous améliorer!
BONNE CHANCE!