Le cas de l'obscurcissement du code?

Quelles sont les principales raisons pour écrire du code obfusqué, en termes d'avantage réel pour les personnes qui développent le code, et pour l'entreprise qui exécute ce code (si le code en question est en fait du code commercial)? Existe-t-il des cas documentés (disponibles en ligne à certains endroits) décrivant quand l'obfuscation a fait plus de bien que de mal? Existe-t-il des exemples bien connus où, par exemple, il a été prouvé que l'obscurcissement retarde de manière significative un tiers malveillant à accéder au code? Il semble que, tout comme remonter les fenêtres de votre voiture n'empêche pas les gens de les casser et de voler votre chaîne hi-fi, masquer votre code garde simplement les personnes honnêtes honnêtes.

=========

Contexte:

Ceci est une tentative de contester volontairement mes hypothèses sur ce sujet.

Je suis résolument contre l'utilisation de 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 accélère le chargement (tout le monde a un réel avantage fonctionnel), mais je n'arrive pas à trouver une seule raison pour laquelle l'obfuscation de code est un obstacle pour découvrir ce que fait une section de code / algorithme , est réellement efficace pour n'importe quel but.

Avec l'open source devenu 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 de votre côté pour lutter contre le vol.

BTW, si la raison pour laquelle quelqu'un écrit du code obfusqué est "sécurité du travail", alors je licencierais tout programmeur reconnu comme étant systématiquement, et utilisant délibérément l'obfuscation dans le seul but d'aider à garder son emploi, à moins de pouvoir raisonnablement démontrer qu'il y avantage commercial. C'est tellement complètement anti-équipe que c'est ridicule, et désigne quelqu'un qui est plus soucieux de garder son travail par des pratiques peu judicieuses, puis de le garder parce qu'ils écrivent un logiciel génial.

Je ne fais que mentionner ce cas particulier car, même si je me rends bien compte que les gens plaisantent généralement, je voudrais dissuader toute réponse dont l’objectif fondamental est que l’obscurcissement pour la seule sécurité de l’emploi est une bonne idée.

Un cas d'utilisation très intéressant pour l'obscurcissement est la recherche de l'origine des copies illicites. En supposant que l'obscurcissement soit une opération relativement peu coûteuse, l'auteur d'origine peut fournir à chaque client des versions de l'application obscurcies différemment. S'il trouve une copie illicite, il 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 du "traître traquer" . Je ne sais pas du tout si c'est commun ¹ , ou même si c'est une bonne idée, mais je l'ai déjà vu appliqué dans la pratique sous les paramètres suivants:

• Marché national hautement concurrentiel avec seulement deux fournisseurs,
• Environ 50 déploiements ont couvert le marché,
• Le temps de développement moyen pour les deux applications était de deux ans (plus ou moins),
• Le temps d'obfuscation moyen pour notre application était de deux heures,
• La durée de vie des deux applications devait être d'environ dix ans.

La raison en était bien sûr la sécurité par l'obscurité au départ et elle a évolué à un moment donné dans le schéma susmentionné ² . Les deux fournisseurs avaient accès au code binaire l'un de l'autre, légalement, et je pense qu'il est évident que des tentatives de décompilation de la part 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 sur un marché extrêmement rentable et de niche, mais nos produits étaient finalement plus similaires que jamais, et tout avantage concurrentiel était obtenu par d'autres moyens moins obscurs.

Je ne peux pas vraiment développer 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 système de traçage (le cas échéant) et (b) une partie de mon implication avec le projet était sous une NDA.

Un autre cas d'utilisation valable pour l'obscurcissement peut être le cas où vous êtes légalement obligé de soumettre votre code à un tiers :

Si votre entreprise travaille pour des sociétés de technologie ou est impliquée dans des affaires impliquant un 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 organismes de réglementation utilisent une règle des "50%". Le code source soumis est masqué afin qu'il ne puisse pas être utilisé tel quel.

IANAL, et le lien est plus pertinent pour les copies papier de code que pour le code de travail réel; il est donc possible que cela ne soit plus du tout pertinent.

Maintenant, comme Javascript est l'exemple canonique de l'obscurcissement, il existe un effet secondaire qui n'est pas couramment pris en compte et qui cache un code malveillant dans le code Javascript obscurci. Bien qu'il y ait des avantages indéniables à réduire le javascript à ³ javascript, je ne vois pas l'intérêt d'obscurcir et je suis heureux que Douglas Crockford soit d'accord avec moi :

Enfin, il y a la question de la confidentialité du code. C'est une cause perdue. Aucune transformation ne peut empêcher un pirate informatique déterminé de comprendre votre programme. Cela s’avère être vrai pour tous les programmes dans toutes les langues, c’est tout simplement plus vrai avec JavaScript car il est livré sous forme source. L'avantage d'intimité fourni par obscurcissement est une illusion. Si vous ne voulez pas que les gens voient vos programmes, débranchez votre serveur.

En ce qui concerne l'obscurcissement pour "la sécurité de l'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 aussi loin que de tirer le coupable au début, mais les récidivistes méritent assurément une bonne fessée, du moins.

En conclusion, l’obscurcissement est un exemple typique de sécurité par le biais de l’obscurité, son seul mérite évident est son effet dissuasif et rien de plus. Je ne connais pas encore de cas d'utilisation créatifs ⁴ , mais en général, les avantages sont, au mieux, minimes.

_{¹ Après avoir écrit ceci, j'ai découvert cette réponse qui décrit fondamentalement le même schéma, il est donc peut-être plus courant que je ne le pensais.
² Bien que la stéganographie soit toujours une sécurité à travers l'obscurité.
³ Minification ~ suppression des espaces et raccourcissement des jetons, pas d’obscurcissement intentionnel.
⁴ Le concours international de code C obscurci compte-t-il?}

L'obscurcissement du code est motivé par le fait qu'il impose à une tierce partie de déterminer le type / le fonctionnement du code.

Cependant, cela ne signifie PAS qu'un développeur doit jamais écrire du code obscurci.

Vous voyez, c’est ce qui manque à votre question, selon moi: 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 fichiers source principaux dans le contrôle de version.

L'obscurcissement du code devrait être une étape de post-traitement lors de la compilation dans votre version de production. Il existe de nombreux produits tiers pour le faire aussi, il n'y a donc presque aucune raison de le faire en interne.

Par exemple: Dotfuscator

L'IEEE a rédigé un document sur l' efficacité de l'obscurcissement de code

Les résultats montrent que le fait de renommer un identifiant diminue considérablement l'efficacité des attaques, doublant au moins le temps nécessaire pour mener à bien une attaque (même dans le pire des cas, c'est-à-dire contre le meilleur attaquant). En outre, l’obscurcissement réduit l’écart entre les attaquants débutants et expérimentés, ce qui le rend moins ef fi cient et rend les systèmes plus faciles à attaquer plus évidents par rapport à ceux qui sont intrinsèquement plus difficiles à casser.

L'accent est à moi.

J'ai participé à l'élaboration d'un MMORPG. Cela impliquait la logique du serveur et la logique du client. Au cours des nombreuses années de développement du projet, chaque fois que nous avons pris en compte l'interface entre le client et le serveur, il était de règle que le client devait toujours être traité par le serveur, en supposant qu'il ait été piraté. En d'autres termes, le serveur devait être écrit de telle sorte qu'aucune réponse du client ne puisse provoquer l'échec du serveur ou permettre au client de tricher. Pourtant, on savait depuis le début que les pirates informatiques trouveraient inévitablement des failles dans le système et les exploiteraient pour tromper. Et après un moment ils l'ont fait.

Bien sûr, avant d’expédier le client dans le grand monde, nous nous sommes assurés de l’obscurcir. Nous croyons que l'obfuscation a eu les effets suivants:

1. Cela a dissuadé les pirates informatiques non experts d'essayer même.
2. Cela a retardé les pirates experts dans la réalisation de tout piratage.
3. Il a réduit le nombre de piratages réalisés par des pirates experts.
4. Cela limitait l'efficacité des hacks.
5. Plus important encore: cela a poussé les pirates informatiques à effectuer davantage de tests avec leurs clients piratés contre nos serveurs avant de procéder à un piratage fonctionnel, ce qui augmentait les chances de les découvrir 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.

So, due to all of the above, I believe obfuscation had an overall positive effect in our game, and by extension, obfuscation can have an overall positive effect in any piece of software which is liable to get hacked. (For example, software containing copy protection measures.)

Les effets de l'obfuscation sur l'entretien étaient pratiquement nuls. Il y avait quelques endroits où des programmeurs inexpérimentés faisaient des suppositions sur les noms d'identificateurs (ils utilisaient la réflexion), mais une fois que ceux-ci ont été résolus, tout s'est bien passé. L'étape d'obscurcissement fait désormais partie intégrante de l'étape de construction générale de la version de production du jeu. La plupart d'entre nous, développeurs, n'avons jamais eu à s'en soucier ou à y faire quoi que ce soit. 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 d'identifiants obfusqués en identifiants appropriés) produite par l'obfuscateur afin de traduire les journaux pour nous à la volée. ils ont même dû voir des identifiants obfusqués lors des examens post mortem à partir des journaux recueillis sur le terrain.

Lire et comprendre (et évidemment écrire) du code obscurci peut être un défi mental intéressant. Cela dépasse probablement le cadre de ce que vous demandiez, mais des exemples tels que IOCCC peuvent être à la fois source d'amusement et d'horreur.