Protéger l'exécutable de la rétroingénierie?

mais ils peuvent tous être travaillés et / ou compris par les analyseurs de code à condition que le cadre de temps approprié.

Si vous donnez aux gens un programme qu'ils sont en mesure d'exécuter, puis ils seront également en mesure de rétro-conception donné assez de temps. C'est la nature des programmes. Dès que le binaire est disponible pour quelqu'un qui veut le déchiffrer, vous ne pouvez pas empêcher la rétro-ingénierie éventuelle. Après tout, l'ordinateur doit être capable de déchiffrer pour l'exécuter, et un humain est simplement un ordinateur plus lent.

Safe Net Sentinel (anciennement Aladdin). Des mises en garde cependant - leur API craint, la documentation craint, et les deux sont géniaux en comparaison de leurs outils SDK.

j'ai utilisé leur méthode de protection matérielle ( Sentinel HASP HL ) depuis de nombreuses années. Il nécessite une clé USB propriétaire fob qui agit comme la "licence" pour le logiciel. Leur SDK crypte et obscurcit votre exécutable & libraries, et vous permet de lier différentes fonctionnalités dans votre application pour les fonctionnalités gravées dans la clé. Sans clé USB fournie et activée par le donneur de licence, le Logiciel ne peut pas déchiffrer et ne fonctionnera donc pas. La clé utilise même un protocole de communication USB personnalisé (en dehors de mon domaine de connaissance, Je ne suis pas un pilote de périphérique) pour rendre difficile la construction d'une clé virtuelle, ou altérer la communication entre le wrapper d'exécution et la clé. Leur SDK n'est pas très convivial pour les développeurs, et est assez douloureux à intégrer ajout d'une protection avec un processus de construction automatisé (mais possible).

avant que nous mettions en œuvre la protection HASP HL, il y avait 7 pirates connus qui avaient dépouillé le dotfuscator 'protections' du produit. Nous avons ajouté la protection HASP en même temps qu'une mise à jour majeure du logiciel, qui effectue de lourds calculs sur vidéo en temps réel. Comme le meilleur que je puisse dire à partir du profilage et de benchmarking, la protection HASP HL a seulement ralenti les calculs intensifs par environ 3%. Depuis que ce logiciel est sorti il y a environ 5 ans, aucun nouveau pirate du produit n'a été trouvé. Les logiciels qu'il protège d'une forte demande dans son segment de marché, et le client est conscient que plusieurs concurrents activement à désosser (sans succès jusqu'à présent). Nous savons qu'ils ont essayé de solliciter l'aide de quelques groupes en Russie qui font la publicité d'un service pour briser la protection du Logiciel, comme de nombreux messages sur divers groupes de discussion et forums ont inclus les nouvelles versions de le produit protégé.

récemment, nous avons essayé leur solution de licence de logiciel (HASP SL) sur un projet plus petit, qui était assez simple pour obtenir de travailler si vous êtes déjà familier avec le produit HL. Il semble fonctionner; il n'y a pas eu d'incidents de piratage signalés, mais ce produit est beaucoup moins en demande..

bien sûr, aucune protection ne peut être parfaite. Si quelqu'un est suffisamment motivé et a de l'argent à brûler, je suis sûr que les protections le prix offert par HASP pourrait être contourné.

prendre, par exemple, l'algorithme AES . C'est une très, très algorithme publique, et il est TRÈS sécurisé. Pourquoi? Deux raisons: Il a été examiné par beaucoup de gens intelligents, et le "secret" n'est pas de l'algorithme lui-même - le secret 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 est en dehors de votre code, plutôt que de rendre le code lui-même secret. Le code peut toujours être interprété peu importe ce que vous faites, et (idéalement) le secret généré ne peut être mis en péril 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 que les attaquants aient du mal à déchiffrer vos algorithmes? Pour qu'il leur soit plus difficile de trouver des bogues exploitables dans votre code? Vous n'auriez pas besoin de brouiller le code si le code était inviolable. Le la racine du problème est le logiciel fissurable. Résolvez la racine de votre problème, ne l'obscurcissez pas.

de plus, plus votre code est confus, plus il vous sera difficile de trouver des bogues de sécurité. Oui, ce sera dur pour les hackers, mais vous devez trouver des insectes aussi. Le Code devrait être facile à maintenir dans des années, et même un code clair et bien écrit peut être difficile à maintenir. Ne pas faire pire.

les meilleures astuces anti-démontage, en particulier sur les jeux d'instructions à longueur de mot variable, sont en code assembleur / machine, et non en C. par exemple

CLC
BCC over
.byte 0x09
over:

le démonteur doit résoudre le problème qu'une destination de branchement est le deuxième octet dans une instruction à plusieurs octets. Un simulateur de jeu d'instructions n'aura cependant aucun problème. Le branchement à des adresses calculées, que vous pouvez causer à partir de C, rend également le démontage difficile à impossible. Simulateur de jeu d'Instruction n'aura aucun problème avec elle. L'utilisation d'un simulateur pour trier les destinations de branche pour vous peut aider le processus de démontage. Le code compilé est relativement propre et facile à démonter. Je pense donc qu'une certaine Assemblée est nécessaire.

je pense que C'était près du début du Zen de Michael Abrash du langage de montage où il a montré un simple anti-démontage et anti-débogueur astuce. Le 8088/6 avait une file d'attente préfetch ce que vous avez fait était avoir une instruction cela a modifié la prochaine instruction ou un couple à l'avance. Si vous exécutez l'instruction modifiée, si votre simulateur de jeu d'instructions ne simule pas complètement le matériel, vous exécutez l'instruction modifiée. Sur le matériel réel tournant normalement, l'instruction réelle serait déjà dans la file d'attente et l'emplacement mémoire modifié ne causerait aucun dommage tant que vous n'exécuterez pas cette chaîne d'instructions à nouveau. Vous pourriez probablement toujours utiliser un truc comme ça aujourd'hui les processeurs pipelinés récupèrent l'instruction suivante. Ou si vous savez que le matériel a une instruction et un cache de données séparés, vous pouvez modifier un certain nombre d'octets à l'avance si vous alignez ce code dans la ligne de cache correctement, le byte modifié ne sera pas écrit par le cache d'instruction mais par le cache de données, et un simulateur de jeu d'instructions qui n'a pas de simulateurs de cache appropriés ne pourrait pas s'exécuter correctement. Je pense que les solutions logicielles ne vous mèneront pas très loin.

les ci-dessus sont vieux et bien connus, Je ne sais pas assez sur les outils actuels pour savoir s'ils travaillent déjà autour de telles choses. Le code auto-modificateur peut / va déclencher le débogueur, mais l'humain peut/va restreindre le problème et voir ensuite le code auto-modificateur et travailler autour de lui.

avant, les hackers mettaient environ 18 mois à trouver quelque chose, des DVD par exemple. Maintenant ils sont en moyenne d'environ 2 jours à 2 semaines (si motivé) (bleu ray, iphone, etc). Cela signifie pour moi que si je passe plus de quelques jours à la sécurité, je perds probablement mon temps. La seule sécurité réelle que vous obtiendrez est par le matériel (par exemple vos instructions sont cryptées et seulement le noyau du processeur bien à l'intérieur de la puce décrypte juste avant l'exécution, d'une manière qu'il ne peut pas exposer les instructions décryptées). Ça pourrait te faire gagner des mois au lieu de jours.

lisez aussi le livre de Kevin Mitnick, The Art of Deception. Une personne comme cela pourrait prendre un téléphone et avoir vous ou un collègue distribuer les secrets au système pensant qu'il est un directeur ou un autre collègue ou ingénieur en matériel dans une autre partie de l'entreprise. Et votre sécurité est soufflé. La sécurité, ce n'est pas seulement gérer la technologie, c'est aussi gérer les humains.

rend le code difficile à rétro-ingénieur est appelé code obfuscation.

la Plupart des techniques que vous mentionnez sont assez facile à contourner. Ils se concentrent sur l'ajout d'un code inutile. Mais le code inutile est facile à détecter et enlever, vous laissant avec un programme propre.

pour un brouillage efficace, vous devez faire dépendre le comportement de votre programme de l'exécution de bits inutiles. Par exemple, plutôt que de le faire:

a = useless_computation();
a = 42;

faites 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;

(où running_under_a_debugger ne devrait pas être facilement identifiable comme une fonction qui teste si le code est en cours d'exécution sous un débogueur - il devrait mélanger utile calculs avec le débogueur de détection):

a = 42 - running_under_a_debugger();

un brouillage efficace n'est pas quelque chose que l'on peut faire purement au stade de la compilation. Quoi que le compilateur puisse faire, un decompiler peut le faire. Bien sûr, vous pouvez augmenter le fardeau sur les décomposeurs, mais il ne va pas aller loin. Les techniques efficaces de brouillage, dans la mesure où elles existent, impliquent l'écriture d'une source brouillée dès le premier jour. Faites en sorte que votre code s'auto-modifie. Litière votre 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();

cela, où que vous arriver à la connaissance exacte de la mise en page souhaitée 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 ne vient pas bon marché. Et ne considèrent que de loin la meilleure façon d'éviter les gens rétro-ingénierie de votre code est de le rendre inutile afin qu'ils ne se donnent pas la peine. C'est une simple considération économique: ils vont rétro-concevoir si la valeur pour eux est plus grand que le coût; mais augmenter leur coût augmente aussi beaucoup votre coût, donc essayer d'abaisser la valeur pour eux.

Maintenant que je vous ai dit que obfuscation est difficile et cher, je vais vous dire ce n'est pas pour vous de toute façon . Vous écrivez

le protocole actuel sur lequel j'ai travaillé ne doit jamais être inspecté ou compréhensible, pour la sécurité de diverses personnes

qui sonne le glas. C'est sécurité par obscurité , qui a un très mauvais dossier. Si l' la sécurité du protocole dépend des personnes qui ne connaissent pas le protocole, vous avez déjà perdu .

lecture recommandée:

• La sécurité de la bible: Ingénierie de la Sécurité par Ross Anderson
• L'obscurcissement de la bible: Clandestine logiciel par Christian Collberg et Jasvir Nagra

souvent, la peur de votre produit obtenu par rétro-ingénierie est mal placée. Oui, il peut être modifié à l'envers, mais deviendra-t-il si célèbre sur une courte période de temps, que les pirates trouveront sa valeur pour inverser engg. il ? (ce travail n'est pas une petite activité de temps, pour des lignes de code importantes).

si elle devient vraiment une source d'argent, alors vous devriez avoir recueilli assez d'argent pour la protéger en utilisant les moyens légaux comme, brevets et / ou droits d'auteur .

IMHO, prenez les précautions de base que vous allez prendre et relâchez-le. Si cela devient un point d'ingénierie inverse qui signifie que vous avez fait un très bon travail, vous trouverez vous-même de meilleurs moyens de le surmonter. Bonne chance.

lisez http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Je suis sûr que d'autres pourraient probablement aussi donner une meilleure source de pourquoi la sécurité par l'obscurité est une mauvaise chose.

il devrait être tout à fait possible, en utilisant des techniques cryptographiques modernes, d'avoir votre système être ouvert (Je ne le dis pas devrait être ouvert, juste qu'il pourrait être), et encore avoir la sécurité totale, aussi longtemps que le l'algorithme cryptographique n'a pas de trou (probablement pas 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 ( ce est ce qui devrait vous inquiéter).

depuis juillet 2013, il y a un regain d'intérêt pour l'obfuscation cryptographique robuste (sous la forme de Indistinguishability Obfuscation ) qui semble avoir poussé de la recherche originale de Amit Sahai .

• Sahai, Garg, Gentry, Halevi, Raykova, Eaux, Candidat De L'Indécidabilité De La Dissimulation De L' et cryptage fonctionnel pour tous les circuits (21 juillet 2013).
• Sahai, Eaux, Comment Utiliser Indécidabilité de la Dissimulation de l': Contestable de Chiffrement, et Plus .
• Sahai, De Barak, De Garg, Kalai, Paneth, La Protection De L'Obfuscation Contre Les Attaques Algébriques (4 Février 2014).

Vous pouvez trouver certains distillée d'informations dans ce Quanta article du Magazine et que IEEE Spectrum article .

actuellement, la quantité de ressources nécessaires pour faire usage de cette technique la rend impraticable, mais AFAICT le consensus est plutôt optimiste quant à l'avenir.

je dis cela très désinvolte, mais à tous ceux qui sont habitués à rejeter instinctivement la technologie de l'obscurcissement -- c'est différent. S'il est prouvé qu'il fonctionne vraiment et rendu pratique, c'est en effet majeur, et pas seulement pour l'obscurcissement.

si quelqu'un veut passer le temps d'inverser votre binaire, alors il n'y a absolument rien que vous pouvez faire pour les arrêter. Vous pouvez faire si modérément plus difficile, mais c'est tout. Si vous voulez vraiment en savoir plus à ce sujet puis obtenir une copie de http://www.hex-rays.com/idapro / et démonter quelques binaires.

le fait que le CPU doit exécuter le code est votre perte. Le CPU n'exécute que le code machine... et les programmeurs peuvent lire le code machine.

cela dit... vous avez probablement un autre problème qui peut être résolu d'une autre manière. Qu'essayez-vous de protéger? Selon votre problème, vous pouvez utiliser le chiffrement pour protéger votre produit.

pour vous informer, lisez la littérature académique sur code obfuscation . Christian Collberg de L'Université de L'Arizona est un chercheur 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 que je connais est que vous ne pouvez pas empêcher un attaquant de voir le code que vous allez exécuter, mais vous pouvez l'entourer avec du code qui est pas exécuté, et il en coûte à un attaquant un temps exponentiel (en utilisant les techniques les plus connues) pour découvrir quels fragments de votre code sont exécutés et lesquels ne le sont pas.

il existe un article récent intitulé Program obfuscation and one-time programs ". Si vous êtes vraiment sérieux au sujet de protéger votre application. Le papier en général va autour des résultats d'impossibilité théorique par l'utilisation de matériel simple et universel.

si vous ne pouvez pas vous permettre d'avoir besoin de matériel supplémentaire, alors il ya aussi un autre papier qui donne la théorie meilleure-possible obfuscation " sur la meilleure-possible obfuscation ", parmi tous les programmes avec la même fonctionnalité et la même taille. Toutefois, le document montre que l'information-la meilleure théorie possible implique un effondrement de la hiérarchie polynomiale.

ces articles devraient au moins vous donner suffisamment de pistes bibliographiques pour marcher dans la littérature connexe si ces résultats ne fonctionne pas pour vos besoins.

mise à jour: une nouvelle notion d'obfuscation, appelée obfuscation indiscernable, peut atténuer les impossibilité résultat (papier)

Pas de dés, vous ne pouvez pas protéger votre code d'démonter. Ce que vous pouvez faire est de configurer le serveur pour la logique métier et l'utilisation d'un webservice à fournir pour votre application. Bien sûr, ce scénario n'est pas toujours possible.

pour pouvoir sélectionner la bonne option, vous devez penser aux aspects suivants:

1. est-il probable que les "nouveaux utilisateurs" ne veulent pas payer mais utiliser votre logiciel?
2. est-il probable que les clients actuels aient besoin de plus de licences qu'ils n'en ont?
3. combien les utilisateurs potentiels sont-ils prêts à payer?
4. voulez-vous donner des licences par utilisateur / utilisateurs concurrents / station de travail / entreprise?
5. votre logiciel a-t-il besoin de formation / de personnalisation pour être utile?

si la réponse à la question 5 est" oui", alors ne vous inquiétez pas pour les copies illégales. Ils ne seraient pas utiles de toute façon.

si la réponse à la question 1 est "oui", pensez d'abord à la tarification (voir question 3).

si vous répondez "oui" à la question 2, alors un modèle de "paiement à l'utilisation" pourrait: approprié pour Vous.

de mon expérience, paiement à l'utilisation + personnalisation et formation est la meilleure protection pour votre logiciel, parce que:

• les nouveaux utilisateurs sont attirés par le modèle de tarification (peu d'utilisation -> peu de rémunération)
• il n'y a presque pas d '"utilisateurs anonymes", car ils ont besoin de formation et de personnalisation.
• aucune restriction logicielle n'effraie les clients potentiels.
• Il ya un flux continu d'argent à partir de l'existant client.
• vous obtenez des commentaires précieux pour le développement de vos clients, en raison d'une relation d'affaires à long terme.

avant de penser à introduire DRM ou obfuscation, vous pourriez penser à ces points et s'ils sont applicables à votre logiciel.

code protégé dans une machine virtuelle semblait impossible de rétroingénierie au début. Themida Packer

mais ce n'est plus aussi sûr.. Et peu importe comment vous emballez votre code, vous pouvez toujours faire un dump de mémoire de n'importe quel exécutable chargé et le démonter avec n'importe quel démonteur comme IDA Pro.

IDA Pro est également livré avec un code de montage nifty à C source code transformer bien que le code généré aura l'air plus comme un désordre mathématique pointeur / adresse.. si vous le comparez à l'original, vous pouvez corriger toutes les erreurs et enlever n'importe quoi.

peut-être que votre meilleure alternative est encore d'utiliser la virtualisation, ce qui introduit un autre niveau d'indirecte/obfuscation nécessaire pour BY bypass, mais comme SSpoke a dit dans sa réponse , cette technique n'est pas non plus 100% sécurisé.

le point est que vous n'obtiendrez pas la protection ultime, parce qu'il n'y a pas de telle chose, et si jamais elle le sera, elle ne durera pas longtemps, ce qui signifie que ce n'était pas la protection ultime en premier lieu.

tout homme assemblant, peut être démonté.

il est généralement vrai que le (bon) démontage est souvent (un peu ou plus) tâche plus difficile, de sorte que votre adversaire doit être plus habile , mais vous pouvez supposer qu'il ya toujours quelqu'un d'une telle qualité, et c'est un pari sûr.

si vous voulez protéger quelque chose contre la REs, vous devez savoir au moins techniques courantes utilisées par la rés.

ainsi s'écrit

internet n'est pas vraiment ingénieux pour la prévention contre l'inversion de l'ingénierie, mais plutôt dépeint des tonnes d'informations sur comment désosser

montrez votre mauvaise attitude. Je ne dis pas que pour utiliser ou intégrer une protection, vous devez savoir comment la briser, mais pour l'utiliser à bon escient, vous devez connaître ses faiblesses et ses Pièges. Vous devriez comprendre it.

(il existe des exemples de logiciels qui utilisent la protection d'une manière erronée, ce qui rend cette protection pratiquement inexistante. Pour éviter de parler vaguement, je vais vous donner un exemple brièvement décrit dans internet: Oxford English Dictionary Second Edition sur CD-ROM v4. Vous pouvez lire sur son utilisation échouée de SecuROM à la page suivante: Oxford English Dictionary (OED) sur CD-ROM dans un environnement Windows de 16, 32 ou 64 bits: disque dur installation, bugs, traitement de texte macros, réseau, polices, et ainsi de suite )

tout prend du temps.

si vous êtes nouveau dans le sujet et que vous n'avez pas de mois ou plutôt des années pour vous lancer correctement dans le domaine de la réforme, alors allez avec les solutions disponibles faites par d'autres. Le problème ici est évident, ils sont déjà là, donc vous savez déjà qu'ils ne sont pas 100% sûr, mais faire votre propre nouvelle protection vous donnerait seulement un faux sentiment d'être protégé, à moins que vous ne connaissiez vraiment bien l'état de l'art dans la rétroingénierie et la protection (mais vous ne le savez pas, au moins à ce moment-ci).

le but de la protection logicielle est d'effrayer les débutants, de faire décrocher la rés commune, et de mettre un sourire sur le visage de la ré assaisonnée après son voyage (si tout va bien intéressant) au centre de votre application.

dans business talk, vous pouvez dire que tout est à propos de retarder la concurrence, d'autant que c'est possible.

(jetez un oeil à la présentation agréable aiguille D'argent dans le Skype de Philippe Biondi et Fabrice Desclaux montré sur le chapeau noir 2006).

vous savez qu'il y a beaucoup de choses à propos de RE là-bas, alors commencez à le lire. :)

j'ai dit à propos de la virtualisation, donc je vais vous donner un lien vers un fil exemplaire du FORUM EXETOOLS : Meilleur logiciel protector: Themida ou Enigma Protector? . Il peut vous aider un peu dans d'autres recherches.

Je ne pense pas que n'importe quel code est unhackable mais les récompenses doivent être grandes pour quelqu'un pour vouloir le tenter.

ayant dit qu'il y a des choses que vous devez faire comme:

• utiliser le niveau d'optimisation le plus élevé possible (la rétro-ingénierie ne consiste pas seulement à obtenir la séquence d'assemblage, il s'agit aussi de comprendre le code et de le transférer dans un langage de niveau supérieur tel que C). Code hautement optimisé peut être un b - - - h à suivre.
• rendre les structures denses en n'ayant pas de types de données plus grands que nécessaire. Réarranger les membres de la structure entre les versions officielles du code. Les champs de bits réarrangés dans les structures sont aussi quelque chose que vous pouvez utiliser.
• vous pouvez vérifier la présence de certaines valeurs qui ne devraient pas être modifiées (un message de copyright est un exemple). Si un vecteur byte contient "vwxyz", vous pouvez avoir un autre vecteur byte contenant" abcde " et comparer les différences. Fonction il ne faut pas passer des pointeurs vers les vecteurs, mais utiliser des pointeurs externes définis dans d'autres modules comme (pseudo-code C) "char *p1=&string1[539];" et "char p2=&string2[-11731];". De cette façon, il n'y aura pas de pointeurs pointant exactement sur les deux chaînes. Dans le code de comparaison vous comparez alors pour " (p1-539+i)-*(p2+11731+i)==une certaine valeur". Le pirate va pense qu'il est sûr de changer string1 parce que personne ne semble faire référence. Enterrez le test dans quelque inattendu lieu.

essayez de hacker vous-même le code d'assemblage pour voir ce qui est facile et ce qui est difficile à faire. Des idées devraient apparaître que vous pouvez expérimenter pour rendre le code plus difficile à réinventer et pour rendre le débogage plus difficile.

comme beaucoup l'ont déjà dit: sur un CPU régulier, vous ne pouvez pas les empêcher de faire, vous pouvez simplement les retarder. Comme mon ancien professeur de crypto m'a dit: Vous n'avez pas besoin de cryptage parfait, briser le code doit être juste plus cher que le gain. De même pour votre obscurcissement.

mais 3 notes supplémentaires:

1. il est possible de rendre la rétroingénierie impossible, mais (et c'est un très très grand mais), vous ne pouvez pas le faire sur un cpu classique. J'ai également fait beaucoup de développement matériel, et souvent FPGA sont utilisés. Par exemple: les Virtex 5 FX ont un processeur PowerPC sur eux, et vous pouvez utiliser L'APU pour implémenter vos propres opcodes CPU sur votre matériel. Vous pouvez utiliser cette facilité pour vraiment décrypter les instructions pour le PowerPC, qui n'est pas accessible par l'extérieur ou un autre logiciel, ou même exécuter la commande dans le matériel. Comme la FPGA a intégré le cryptage AES pour sa configuration bitstream, vous ne pouvez pas inverser l'ingénieur (sauf que quelqu'un réussit à briser AES, mais alors je suppose que nous avons d'autres problèmes...). De cette façon, les fournisseurs de matériel IP protègent également leur travail.

2. vous parlez selon le protocole. Vous ne dites pas quel type de protocole il s'agit, mais quand il s'agit d'un protocole réseau, vous devez au moins le protéger contre l'reniflement du réseau. Ce que vous pouvez en effet faire par chiffrement. Mais si vous voulez protéger le fr/déchiffrement à partir d'un propriétaire du logiciel, vous êtes de retour à la obscurcissement.

3. Faire rendre votre programm undebuggable/unrunnable. Essayez d'utiliser une sorte de détection du débogage et appliquez-la, par exemple dans une formula oder, en ajoutant un contenu de registre de débogage à une constante magique. Il est beaucoup plus difficile si votre programme regarde en mode debug est s'il tourne normalement, mais fait un calcul complètement erroné, opération, ou autre. Par exemple: Je sais que certains jeux eco, qui avait une protection contre la copie très désagréable (je sais que vous ne voulez pas copyprotection, but it is similar): la version volée a modifié les ressources minées après 30 minutes de jeu, et soudainement vous n'avez eu qu'une seule ressource. Le pirate vient de le craquer (c'est - à-dire qu'il l'a créé par rétro-ingénierie) - il a vérifié s'il fonctionnait, et volia l'a libéré. De tels changements de comportement sont très difficiles à détecter, en particulier. si elles n'apparaissent pas instantanément à la détection, mais seulement retardée.

donc enfin je suggérerais: Estimer quel est le gain de les gens inversent l'ingénierie de votre logiciel, traduisez cela en un certain temps (par exemple en utilisant le salaire indien le moins cher) et faire l'ingénierie inverse afin de temps coûtant qu'il est plus grand.

pour éviter la rétro-ingénierie, vous ne devez pas donner le code aux utilisateurs. Cela dit, je recommande l'utilisation d'une application en ligne...cependant (puisque vous n'avez pas donné de contexte) qui pourrait être inutile sur le vôtre.

contrairement à ce que la plupart des gens disent, en se basant sur leur intuition et leur expérience personnelle, Je ne pense pas que l'obfuscation cryptographique de programme se soit avérée impossible en général.

ceci est un exemple d'une déclaration de programme parfaitement obscurcie pour démontrer mon point:

printf("1677741794\n");

On ne peut jamais deviner que ce qu'il fait vraiment est

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

il y a un document intéressant sur ce sujet, qui prouve certains impossibilité résultats. Il est appelé "sur la possibilité (Im)de brouiller les programmes" .

bien que le papier prouve que l'obfuscation rendant le programme non distinguable de la fonction qu'il met en œuvre est impossible, l'obfuscation définie d'une manière plus faible peut encore être possible!

la sécurité par l'obscurité ne fonctionne pas comme l'ont démontré des gens beaucoup plus intelligents que de nous deux. Si vous devez protéger le protocole de communication de vos clients, alors vous êtes moralement obligé d'utiliser le meilleur code qui soit au grand jour et entièrement examiné par les experts.

Ceci est pour la situation où les gens peuvent inspecter le code. Si votre application doit fonctionner sur un microprocesseur intégré, vous pouvez choisir un qui dispose d'une installation de scellage, qui rend impossible d'inspecter le code ou d'observer plus que des paramètres triviaux comme l'utilisation courante pendant qu'il court. (C'est, sauf par des techniques d'Invasion de matériel, où vous démantelez soigneusement la puce et utilisez un équipement de pointe pour inspecter les courants sur les transistors individuels.)

je suis l'auteur d'un monteur de rétro-ingénierie pour le x86. Si vous êtes prêt pour un rhume surprise, m'envoyer le résultat de vos efforts. (Me contacter via mes sites web.) Uns que j'ai vu dans les réponses présentent un important obstacle pour moi. Si vous voulez voir comment le code de rétroingénierie sophistiqué fonctionne, vous devriez vraiment étudier les sites Web avec inverser les défis de l'ingénierie.

votre question aurait besoin d'être clarifiée. Comment comptez-vous garder un protocole secret si le le code informatique se prête-t-il à la rétro-ingénierie? Si mon protocole consiste à envoyer un message crypté RSA (même une clé publique), qu'est-ce que vous gagnez à garder le protocole secret? Pour tous fins pratiques, un inspecteur serait confronté à une séquence de bits aléatoires.

Groetjes Albert

les techniques traditionnelles de rétro-ingénierie dépendent de la capacité d'un agent intelligent utilisant un désassembleur à répondre aux questions sur le code. Si vous voulez une sécurité forte, vous devez faire à des choses qui empêchent provably l'agent d'obtenir de telles réponses.

vous pouvez faire cela en comptant sur le programme D'arrêt ("est-ce que le programme x s'arrête?") qui, en général, ne peuvent être résolus. Ajouter des programmes qui sont difficiles à raisonner à votre programme, rend votre programme difficile à raison d'environ. Il est plus facile de construire de tels programmes que de les déchirer. Vous pouvez également ajouter du code au programme qui a divers degrés de difficulté pour raisonner; un grand candidat est le programme de raisonnement sur les alias ("pointeurs").

Collberg et al ont un papier ("Manufacturing Cheap, Resilient and Stealful Opaque Constructs") qui traite de ces sujets et définit une variété de prédicats "opaques" qui peuvent rendre très difficile à raisonner 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 pas C ou C++ code source.

La DashO Java obfuscator semble utiliser les mêmes idées. http://www.cs.arizona.edu / ~ collberg / enseignement/620/2008/tâches/outils / DashO /

première chose à retenir sur la dissimulation de votre CODE : tout votre code n'a pas besoin d'être caché.

the END GOAL : mon objectif final pour la plupart des logiciels est la possibilité de vendre différentes licences qui activeront et désactiveront des fonctionnalités spécifiques dans mes programmes.

meilleure TECHNIQUE : je trouve que la construction dans un système de crochets et de filtres comme WordPress offre, est le meilleure méthode en essayant de confondre vos adversaires. Cela vous permet de chiffrer certaines associations de déclenchement sans réellement chiffrer le code.

si vous faites cela, c'est parce que vous voulez chiffrer le moins de code possible.

KNOW YOUR CRACKERS : sachez ceci: la raison principale pour cracking code n'est pas à cause de la distribution malveillante de licence, c'est en fait parce que besoin de changer votre ils n'ont pas vraiment besoin de distribuer des copies gratuites.

GETTING STARTED : mettez de côté la petite quantité de code que vous allez chiffrer, le reste du code devrait essayer et être coincé dans un fichier pour augmenter la complexité et la compréhension.

se préparer à crypter : vous allez crypter en couches avec mon système, il va également être une procédure très complexe afin de construire un autre programme qui sera responsable du processus de chiffrement.

première étape : obscurcir en utilisant des noms de base64 pour tout. Une fois fait, base64 le code obscurci et le sauvegarder dans un fichier temporaire qui sera plus tard utilisé pour décrypter et exécuter ce code. Un sens?

je répète puisque vous le ferez encore et encore. Vous allez créer une chaîne base64 et l'enregistrer dans un autre fichier comme une variable qui sera décrypté et le rendu.

deuxième étape : vous allez lire dans ce fichier temporaire comme une chaîne de caractères et l'obscurcir, puis base64 et enregistrer dans un second fichier temp qui sera utilisé pour décrypter et le rendre pour l'utilisateur final.

troisième étape : répétez l'étape deux autant de fois que vous le souhaitez. Une fois que vous avez ce fonctionnement correctement sans erreurs de décryptage, alors vous allez vouloir commencer à construire dans les mines terrestres pour vos adversaires.

LAND MINE ONE : vous allez vouloir garder le fait que vous êtes notifié un secret absolu. Donc, construire dans un cracker tentative de sécurité système de courrier d'avertissement pour la couche 2. Cela vous permettra de connaître les détails de votre adversaire si quelque chose se passe mal.

LAND MINE TWO : dépendances. Vous ne voulez pas que votre adversaire soit capable d'exécuter la première couche, sans la couche 3 ou 4 ou 5, ou même le programme il a été conçu. Alors assurez-vous que dans le premier calque vous incluez une sorte de script de mise à mort qui s'activera si le programme n'est pas présent, ou les autres calques.

je suis sûr que vous pouvez trouver vos propres mines, amusez-vous avec.

chose à retenir : vous pouvez en fait chiffrer votre code au lieu de base64'ing. De cette façon, une simple base64 ne décryptera pas le programme.

REWARD : 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 leur donne un code promo à utiliser afin de recevoir une récompense en espèces de votre part.

faire de la récompense en espèces significative sans préjudice impliqué. D'habitude, je dis quelque chose comme 500$. Si votre gars est le premier à déchiffrer le code, alors payez-lui son argent. et de devenir son ami. Si c'est un de vos amis, il ne distribuera pas votre logiciel. Demandez-lui comment il a fait et comment vous pouvez l'améliorer!

BONNE CHANCE!

est-ce que Quelqu'un a 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 promissing.