Le cas de l'obfuscation du code?
Quelles sont les principales raisons d'écrire du code obscurci, en termes d'avantages réels pour les personnes qui développent le code et l'entreprise qui exécute ce code (si le code en question est en fait du code commercial)? Y a-t-il des cas documentés (disponibles en ligne dans certains endroits) qui décrivent quand l'obfuscation a fait plus de bien que de mal? Y a-t-il des exemples bien connus où, par exemple, il a été prouvé que l'obfuscation retarde de manière significative un tiers malveillant pour atteindre le code? Il semble que, tout comme enrouler les vitres de votre voiture n'empêchera pas les gens de les briser et de voler votre chaîne stéréo, brouiller votre code garde les honnêtes gens honnêtes.
=========
Contexte:
Il s'agit d'une tentative de contester délibérément mes hypothèses sur ce sujet.
Je suis contre l'idée d'utiliser l'obscurcissement de code en général, mais je suis curieux de savoir s'il me manque quelque chose. Je comprends pourquoi, dans des cas comme JavaScript, la minification aide les choses à se charger plus rapidement et tout (il y a là un réel avantage fonctionnel), mais je n'arrive pas à trouver une seule raison pour laquelle l'obscurcissement du code, dans le but d'être un obstacle à la découverte de ce qu'une section de code/algorithme fait, est en fait efficace à quelque fin que ce soit.
L'open source étant très populaire, la question semble être "partager le code, ou le garder propriétaire?" En ce qui concerne le code commercial, je peux comprendre pourquoi vous ne pouvez pas tout partager, et vous avez la loi à vos côtés pour lutter contre le vol.
BTW, si la raison pour laquelle quelqu'un écrit du code obscurci est la "sécurité de l'emploi", alors je licencierais tout programmeur qui serait cohérent et utiliserait l'obscurcissement à dessein dans le seul but d'aider à garder leur travail, sauf s'ils pourrait raisonnablement montrer qu'il avait un certain avantage commercial. C'est tellement anti-équipe que c'est ridicule, et pointe vers quelqu'un qui est plus soucieux de garder son travail à travers des pratiques malavisées, puis de le garder parce qu'il écrit un logiciel génial.
Je ne mentionne que ce cas spécifique parce que, bien que je réalise que les gens plaisantent généralement, j'aimerais dissuader toutes les réponses dont l'idée principale est que l'obscurcissement pour la sécurité de l'emploi est une bonne idée.
Un cas d'utilisation très intéressant pour l'obscurcissement est de retracer l'origine des copies illicites. En supposant que l'obscurcissement soit une opération relativement bon marché, l'auteur d'origine peut fournir à chaque client des versions de l'application différentes, si une copie illicite est trouvée, l'auteur peut comparer les versions fournies et retracer la source du piratage.
C'est une forme de stéganographie , inspirée et en variante des schémas cryptographiques "traçage de traçage" . Je ne sais pas si c'est courant1, ou même si c'est une bonne idée, mais je l'ai vu appliqué en pratique sous les paramètres suivants:
- Marché national très compétitif avec seulement deux fournisseurs,
- Une cinquantaine de déploiements ont couvert le marché,
- Le temps de développement moyen pour les deux applications était de quelques années (plus ou moins),
- Le temps moyen d'obfuscation pour notre application était de quelques heures,
- La durée de vie des deux applications devrait être d'environ dix ans.
La justification était bien sûr la sécurité par l'obscurité au départ, et elle a évolué au niveau du schéma susmentionné à un moment donné2. Les deux fournisseurs ont eu accès au code binaire de l'autre, légalement, et je pense qu'il est évident que des tentatives de décompilation des deux étaient attendues. L'obfuscation n'a rien fait en termes de sécurité, à long terme. Les deux fournisseurs avaient des équipes très motivées et talentueuses, travaillant dans un marché de niche extrêmement rentable, à la fin nos produits étaient plus similaires qu'improbables, et tout avantage concurrentiel a été obtenu par d'autres moyens moins obscurs.
Je ne peux pas vraiment m'étendre, car (a) c'était très tôt dans ma carrière et je n'ai pas eu un aperçu clair des décisions de conception ou des résultats du schéma de traçage (le cas échéant) et (b) une partie de mon implication avec le projet était sous un NDA.
Un autre cas d'utilisation valable pour l'obscurcissement pourrait être lorsque vous êtes en quelque sorte légalement obligé de soumettre votre code à un tiers :
Si votre entreprise travaille dans le domaine de la propriété intellectuelle pour des sociétés de technologie ou est impliquée dans des cas impliquant du code source de logiciel, vous pouvez être obligé de soumettre le code source de votre client à l'USPTO, à un tribunal ou à un tiers.
Le code source étant considéré comme un secret commercial, la plupart des agences de régulation utilisent une règle de "50%". Le code source soumis est masqué de sorte qu'il ne peut pas être utilisé tel quel.
IANAL, et le lien est plus pertinent pour les copies papier du code que pour le code de travail réel, donc cela pourrait être complètement hors de propos.
Maintenant, comme Javascript est l'exemple canonique de l'obscurcissement, il y a un effet secondaire qui n'est pas couramment considéré, et qui cache le code malveillant dans Javascript obscurci. Bien qu'il y ait des avantages certains à minifier3 Javascript, je ne vois aucun intérêt dans l'obscurcissement réel et je suis heureux Douglas Crockford est d'accord avec moi :
Enfin, il y a la question de la confidentialité du code. C'est une cause perdue. Aucune transformation n'empêchera un pirate informatique déterminé de comprendre votre programme. Cela s'avère vrai pour tous les programmes dans toutes les langues, c'est juste plus évidemment vrai avec JavaScript car il est fourni sous forme source. L'avantage de confidentialité offert par l'obscurcissement est une illusion. Si vous ne voulez pas que les gens voient vos programmes, débranchez votre serveur.
Quant à l'obscurcissement pour la "sécurité d'emploi", c'est un comportement qui ne devrait jamais passer l'examen du code, et s'il est identifié, il ne devrait pas être toléré. Je n'irais pas jusqu'à renvoyer le coupable au début, mais les récidivistes méritent certainement une bonne fessée, au moins.
En conclusion, l'obscurcissement est un exemple typique de sécurité par l'obscurité, c'est seulement un mérite évident comme moyen de dissuasion et rien de plus. Il peut y avoir des cas d'utilisation créatifs4 Je ne sais pas, mais en général les avantages sont minimes, au mieux.
1 Après avoir écrit ceci, j'ai découvert cette réponse qui décrit essentiellement le même schéma, donc il pourrait être plus courant que je le pense.
2 Bien que la stéganographie soit toujours une sécurité par l'obscurité.
3 Minification ~ suppression des espaces blancs et raccourcissement des jetons, pas d'obscurcissement intentionnel.
4 Le Concours international de code C obscurci compte-t-il?
Le cas de l'obscurcissement du code est qu'il soulève la barre pour qu'un tiers détermine ce que/comment le code fonctionne.
Cependant, cela [~ # ~] et non [~ # ~] signifie qu'un développeur devrait jamais écrire du code obscurci.
Vous voyez, c'est le bit qui, je pense, manque à votre question: l'obscurcissement de code (tout comme la minification JavaScript) n'a pas besoin - et ne devrait pas - être fait manuellement par le développeur. De même, cela ne doit pas non plus être stocké en tant que vos fichiers source principaux dans le contrôle de version.
L'obfuscation du code doit se produire comme une étape de post-traitement lors de la compilation dans votre build de production. Il existe également de nombreux produits tiers pour le faire, il n'y a donc presque aucune raison de le faire en interne.
Par exemple: Dotfuscator
L'IEEE a un document sur le efficacité de l'obscurcissement du code
Les résultats montrent que le changement de nom de l'identi fi cateur diminue de façon signi fi cative l'ef fi cacité des attaques, doublant au moins le temps nécessaire pour terminer une attaque réussie (même dans le pire des cas, c'est-à-dire, contre le meilleur attaquant). De plus, l'obscurcissement réduit l'écart entre les attaquants novices et qualifiés, ce qui rend ces derniers moins ef fi caces et rend les systèmes plus faciles à attaquer en clair plus semblables à ceux qui sont intrinsèquement plus difficiles à briser.
Je souligne.
J'ai participé au développement d'un MMORPG. Cela impliquait la logique du serveur et la logique du client. Tout au long du développement de plusieurs années du projet, chaque fois que nous avons considéré l'interface entre le client et le serveur, la règle était que le client devait être traité par le serveur à tout moment sous la présomption qu'il avait été piraté. En d'autres termes, le serveur devait être écrit de manière à ce qu'aucune réponse du client ne puisse provoquer une défaillance du serveur ou permettre au client de tricher. Pourtant, on savait depuis le début que les pirates trouveraient inévitablement des trous dans le système et les exploiteraient pour tricher. Et après un certain temps, ils l'ont fait.
Bien sûr, avant d'expédier le client dans le grand monde, nous nous sommes assurés de le masquer. Nous pensons que l'obfuscation a eu les effets suivants:
- Cela a dissuadé les pirates informatiques non experts de tenter le coup.
- Cela a retardé les pirates experts dans la réalisation de tous les hacks.
- Il a réduit le nombre de hacks réalisés par des pirates experts.
- Cela a limité l'efficacité des hacks.
- Plus important encore: cela a amené les pirates à effectuer plus de tests avec leurs clients piratés contre nos serveurs avant de réaliser un piratage fonctionnel, ce qui a augmenté les chances que nous les découvrions en recherchant une activité irrégulière dans les journaux du serveur.
Les comptes de jeu des pirates découverts ont été résiliés sans remboursement, ce qui a rendu l'activité de piratage plus coûteuse et moins attrayante.
Donc, en raison de tout ce qui précède, je pense que l'obfuscation a eu un effet globalement positif dans notre jeu, et par extension, l'obfuscation peut avoir un effet globalement positif sur n'importe quel logiciel susceptible d'être piraté. (Par exemple, un logiciel contenant des mesures de protection contre la copie.)
Les effets de l’obscurcissement sur l’entretien étaient quasi nuls. Il y avait quelques endroits où certains programmeurs inexpérimentés faisaient des hypothèses sur les noms des identifiants (ils utilisaient la réflexion), mais une fois ceux-ci triés, tout allait bien. L'étape d'obscurcissement vient de faire partie de l'étape de construction globale de la version de production du jeu, de sorte que la plupart d'entre nous, les développeurs, n'ont jamais eu à s'en soucier ou à avoir quoi que ce soit à voir avec cela. Nous avions déjà un outil pour afficher les journaux du jeu, nous avons donc modifié l'outil pour utiliser la table d'association (mappage des identifiants obscurcis aux identifiants appropriés) produite par l'obfuscateur afin de traduire les journaux pour nous à la volée, donc nous n'avons jamais a même dû voir des identifiants obscurcis lors d'examens post-mortem basés sur des journaux collectés sur le terrain.
Lire et comprendre (et évidemment écrire) du code obscurci peut être un défi mental intéressant. Cela sort probablement du cadre de ce que vous demandiez, mais des exemples comme IOCCC peuvent être une source d'amusement et d'horreur.