Le problème avec l'Obfuscation / Protection côté client est que l'attaquant gagnera toujours.Votre code s'exécute sur son PC afin qu'il puisse tout intercepter et tout manipuler à la fin.Dans le cas spécifique de .NET, il peut être judicieux d'appliquer de base obfuscation pour supprimer les noms de fonctions par exemple, mais les outils gratuits sont parfaitement adaptés pour cela.

Pour répondre à votre question un peu plus spécifique: la plupart des obfuscators commerciaux font les mêmes choses que les libres. pour Confuser / ConfuserEx, les deux sont open source et offrent une meilleure protection que la plupart des produits commerciaux.

Soyons clairs: l'obfuscation n'est pas là pour être une forme de sécurité sujette à examen. Il tombera dès que quelqu'un essaiera de contourner l'obfuscation et rendra les choses plus difficiles pour l'attaquant.

Le but de l'obscurcissement est de dissuader les attaquants potentiels d'entrer dans le système sans beaucoup d'efforts, ce qui peut les empêcher d'envisager d'attaquer votre système.

Vous devriez vous demander si cela est utile ou non. Si c'est le cas, implémentez bien sûr l'obscurcissement, mais ne l'utilisez pas comme seul niveau de sécurité.

L'obscurcissement en vaut-il la peine? Oui, bien sûr, cela en vaut la peine. Toute couche supplémentaire qui n'interfère pas avec une autre couche en vaut toujours la peine. Cela dissuadera la personne moyenne et tiendra la majorité des gens, ou serait des enfants de script, à distance ....

Mais

Les outils commerciaux que je dirais ne le sont pas à avancé pourrait en fait entraver votre développement, l'utilisation d'un logiciel sur mesure que j'ai essayé a pris beaucoup de temps pour s'assurer que le code fonctionnait correctement sous cette nouvelle forme car il était essentiellement codé et chiffré en base64.

rappelez-vous ceci en ce qui concerne la sécurité: si votre logiciel ou produit vaut 1 million de dollars, il en coûte 1 million et 1 pour le casser, vous ne pouvez jamais rendre quelque chose d'assez sûr. obscurcir ne le rendra jamais sûr, mais il ne fait pas de mal d'utiliser des outils gratuits.

L'obscurcissement n'est évidemment pas une sécurité de haut niveau, mais je ne publierais jamais de code sans obscurcissement car il peut cacher des informations importantes (les informations importantes que cela peut protéger sont des conventions de dénomination évidentes donnant les objectifs des fonctions et le fonctionnement de votre application , ce n'est qu'un simple moyen de dissuasion et non une solution). Cela en vaut toujours la peine.

Bien que vous payiez pour un outil? Cela ne vaut peut-être pas la peine.

Non. L'obfuscation n'en vaut pas la peine. Si vous obscurcissez vos programmes, ils seront détectés comme des faux positifs par les antivirus tout le temps . Cela vous causera bien plus de maux de tête que quelques pertes de ventes.

La seule exception serait si vous aviez un logiciel extrêmement précieux - mais si vous n’expédiez pas de clé électronique matérielle, votre logiciel ne l’est pas si précieux qu'il a besoin d'être obscurci.

Beaucoup de gens ont déjà mentionné que l'obscurcissement ne faisait qu'augmenter le temps pendant lequel la source d'une application peut être régénérée; cela fonctionne comme un moyen de dissuasion.

Cependant, selon les techniques d'obscurcissement, la taille de l'exécutable résultant peut être considérablement réduite. Certains outils d'obscurcissement peuvent même améliorer les performances de votre application en supprimant toutes les instructions qui ne devraient pas être exécutées.

Dans l'ensemble, j'utiliserais toujours un obfuscateur, mais pas à des fins de sécurité.

Obfuscation! = Sécurité

Si vous écrivez des services Web ou un autre code qui s'exécute sur vos serveurs sécurisés, il n'est pas nécessaire de masquer.

Si vous déployez du code côté client, vous souhaiterez peut-être obscurcir pour qu'il soit plus difficile pour quelqu'un de faire de l'ingénierie inverse de votre code afin qu'il ne puisse pas le voler ou s'en attribuer le mérite.

C'est très facile à décompiler. Code net utilisant ILDASM ou un autre outil. Ainsi, les entreprises peuvent obscurcir pour qu'il soit plus difficile pour quelqu'un de regarder sous les couvertures pour acquérir des connaissances sur le système ou même l'exploiter. Mais c'est toujours un code exploitable qui peut être mis dans un environnement de développement, débogué et examiné localement.

Une fois, j'ai eu un patron qui était paranoïaque à propos d'autres sociétés qui volaient la propriété intellectuelle du code source de l'entreprise, alors il a mandaté le camouflage. Une chose avec les obfuscators est qu'il existe des pratiques de codage qui produiront des bogues après que le code soit obscurci, alors soyez conscient de cela.

Cela en vaut-il la peine? Cela dépend de votre point de vue. C'était important pour mon patron. Pour l'équipe de développement, c'était juste un autre rouage dans le processus de construction qui causait parfois des bogues inattendus, donc nous n'y voyions pas beaucoup de valeur. Cela n'apportait certainement plus de sécurité.

Une chose que je mentionnerai également, pour le support et le dépannage, le code obscurci est plus difficile à diagnostiquer. Les journaux que le système produira seront également obscurcis, vous avez donc besoin d'une carte pour prendre les journaux obscurcis et les transformer en noms de contrôle de source d'origine, etc. Donc, il n'est pas possible de regarder les journaux, des étapes supplémentaires sont nécessaires .

Non. L'obfuscation établit simplement un délai variable. Cela peut arrêter les skiddies et ceux qui ne s'en soucient pas assez pour terminer le travail, mais ce n'est pas le vrai problème. S'il y a une faiblesse dans votre programme, il devient une perte de temps d'essayer de le balayer sous le tapis plutôt que de le réparer en premier lieu.

Investir le temps que vous auriez utilisé pour obscurcir correctement votre code trouver et corriger les vulnérabilités fera un meilleur travail pour empêcher les utilisateurs malveillants, qu'ils soient skiddies ou professionnels.

Si vous voulez une protection contre la falsification d'assemblage ou l'accès au code source, alors un obfuscateur commercial ou même gratuit vous sera grandement bénéfique, juste avant d'en utiliser un, regardez autour de vous pour voir s'il y a un désobfuscateur là-bas, qui vous aidera évaluer la «sécurité» d'Obfuscator. Si c'est une version commerciale, cherchez toujours un essai pour la tester avec votre application, j'ai eu quelques obfuscators gâcher l'exécutable, principalement à cause du "code spaghetti" qu'ils produisent et des proxys et tout ça. Et si vous prévoyez d'accéder à l'assembly à partir du code au moment de l'exécution, je ne pense pas que cela fonctionnera bien pour vous. Néanmoins, étant donné qu'il est facile d'extraire le code source intact d'un exécutable .NET, les obfuscators sont un moyen très utile de rendre plus difficile l'accès des attaquants au code source.

N'oubliez pas de ne jamais mettre de données sensibles sur un programme, même si vous l'avez caché! Stockez toujours les données sensibles telles que les informations de base de données, les clés de chiffrement / déchiffrement côté serveur!

De mon point de vue, cela n'en vaut pas la peine.

1. S'ils veulent vraiment voir comment cela fonctionne, ils le feront. Bien sûr, vous pouvez empêcher les "innocents" de renifler, mais quiconque a des motifs et des moyens l'emportera.
2. Comme quelqu'un l'a souligné, l'obscurcissement a ses propres problèmes de développement (un autre niveau de complexité / rapport d'erreur votre SDLC actuel).
3. Avec le passage à SoA, tout ce qui est propriétaire / secret commercial doit de toute façon être déplacé en interne. Plus vous pouvez garder la logique sous votre propre contrôle (sur vos serveurs loin du client), plus vous avez l'assurance qu'il ne sera pas copié / volé.
4. Passez plus de temps à investir dans votre prochaine version et moins sur la protection de ce qui est déjà fait. Vous ne gardez pas les clients en protégeant l'IP actuelle des copieurs, vous les gardez en étant évolutifs.
5. D'un autre point de vue, regardez les projets open source; ils distribuent facilement leur code source et maintiennent toujours la traction et la reconnaissance / adoption de l'industrie.

C'est à vous, mais juste mon 0,02 $.

Je suis d'accord pour dire qu'en ce qui concerne la sécurité, java obfucation ressemble plus à un verrou qu'à un verrou; cela n'arrêtera pas un attaquant déterminé mais peut décourager les amateurs.

Cela dépend également de l'obfuscateur. Il est certainement possible de réécrire du code de manière à ce qu'il ne puisse pas être décompilé en Java clair, en utilisant des modèles d'instruction / bytecode qui n'ont pas d'équivalent Java. (Vous pourriez même être en mesure de faire une certaine optimisation, bien que la plupart de cela soit stuvf le compilateur JIT fera probablement de toute façon.) Mais encore une fois, si l'attaquant sait comment travailler avec des bytecodes directement au niveau "assembleur", tout fait est de les ralentir et de les faire travailler plus dur.

Et parfois c'est suffisant pour les faire attaquer une cible plus facile.

Mais tant que votre code ne fonctionne pas physiquement encapsulation protégée (sur laquelle je pense qu'IBM a au moins un brevet) - ou s'exécutant ailleurs sur une machine sécurisée, ce qui est effectivement la même chose - vous ne pouvez pas complètement empêcher les gens de le lire.

La valeur de l'obscurcissement ou de la protection dépend de plusieurs facteurs.

En vaut-elle la peine?

Lorsque nous cherchons à protéger un logiciel, nous devons d'abord répondre à une nombre de questions:

1. Quelle est la probabilité que cela se produise?
2. Quelle est la valeur pour quelqu'un d'autre de votre algorithme et de vos données?
3. Qu'est-ce le coût pour eux d'acheter une licence pour utiliser votre logiciel?
4. Quel est le coût pour eux de répliquer votre algorithme et vos données?
5. Quel est le coût pour eux de l'ingénierie inverse de votre algorithme et données?
6. Quel est le coût pour vous de la protection de votre algorithme et de vos données?

Si ceux-ci produisent un impératif économique important pour protéger votre algorithme / vos données, vous devrait envisager de le faire. Par exemple, si la valeur du service et le coût pour les clients sont tous deux élevés, mais que le coût de l'ingénierie inverse de votre code est bien inférieur au coût de développement eux-mêmes, alors les gens peuvent essayer.

Donc, cela mène à votre question

• Comment sécurisez-vous votre algorithme et vos données?

Découragement

Obfuscation

L'option que vous suggérez, obscurcir le code, perturbe les aspects économiques ci-dessus - elle essaie d'augmenter considérablement le coût pour eux (5 ci-dessus) sans en augmenter beaucoup le coût (6). Les recherches menées par le Centre des fonctionnalités chiffrées ont mené à des recherches intéressantes à ce sujet. Le problème est que, comme avec le cryptage de DVD, il est voué à l'échec s'il y a suffisamment de différence entre 3, 4 et 5, alors quelqu'un finira par le faire.

Détection

Une autre option pourrait être une forme de stéganographie, qui vous permet d'identifier qui a déchiffré vos données et commencé à les distribuer. Par exemple, si vous avez 100 valeurs flottantes différentes dans vos données et qu'une erreur de 1 bit dans le LSB de chacune de ces valeurs ne poserait pas de problème avec votre application, encodez un (à chaque client) dans ces bits. Le problème est que si quelqu'un a accès à plusieurs copies des données de votre application, il serait évident que cela diffère, ce qui facilite l'identification du message caché.

Protection

SaaS - Logiciel en tant que service

Une option plus sûre pourrait être de fournir la partie critique de votre logiciel en tant que service, plutôt que de l'inclure dans votre application.

Conceptuellement, votre application collecterait toutes les données nécessaires à l'exécution de votre algorithme, la mettrait en package sous forme de requête à un serveur (contrôlé par vous) dans le cloud , votre service calculera ensuite vos résultats et le renvoyer au client, qui l'affichera.

Cela garde toutes vos données et algorithmes exclusifs et confidentiels dans un domaine que vous contrôlez complètement, et supprime toute possibilité qu'un client extrait l'un ou l'autre.

L'inconvénient évident est que les clients sont liés à votre prestation de services, sont à la merci de vos serveurs et de leur connexion Internet. Malheureusement, de nombreuses personnes s'opposent au SaaS pour exactement ces raisons. Sur le plan positif, ils sont toujours à jour avec les correctifs de bogues, et votre cluster de calcul sera probablement plus performant que le PC sur lequel ils exécutent l'interface utilisateur.

Ce serait un énorme pas en avant pour prendre cependant, et pourrait avoir un coût énorme 6 ci-dessus, mais c'est l'un des rares moyens de garder votre algorithme et vos données complètement sécurisés .

Dongles de protection logicielle

Bien que les dongles de protection logicielle traditionnels protègent contre le piratage de logiciels, ils ne protègent pas contre les algorithmes et les données de votre code en cours d'extraction.

Les nouveaux dongles de portage de code (tels que SenseLock ^† ) semble cependant pouvoir faire ce que vous voulez. Avec ces appareils, vous retirez le code de votre application et le portez vers le processeur de clé de sécurité sécurisée. Comme avec le SaaS, votre application regrouperait les données, les transmettrait au dongle (probablement un périphérique USB connecté à votre ordinateur) et relirait les résultats.

Contrairement au SaaS, la bande passante des données ne serait probablement pas un problème, mais les performances de votre application peuvent être limitées par les performances de votre SDP.

^{† C'était le premier exemple que j'ai pu trouver avec une recherche Google.}

Plateforme de confiance

Une autre option, qui pourrait devenir viable à l'avenir, consiste à utiliser un module de plateforme de confiance et une technologie d'exécution de confiance pour sécuriser les zones du code. Chaque fois qu'un client installe votre logiciel, il vous fournira une empreinte digitale de son matériel et vous lui fournissez une clé de déverrouillage pour ce système spécifique.

Cette clé permettrait alors de déchiffrer le code et exécuté dans l'environnement de confiance, où le code et les données cryptés seraient inaccessibles en dehors de la plate-forme de confiance. Si quoi que ce soit dans l'environnement de confiance changeait, cela invaliderait la clé et cette fonctionnalité serait perdue.

Pour le client, cela présente l'avantage que ses données restent locales et qu'il n'a pas besoin d'acheter un nouveau dongle pour améliorer les performances, mais il a le potentiel de créer une exigence d'assistance continue et la probabilité que vos clients soient frustrés par les obstacles qu'ils ont dû franchir pour utiliser les logiciels qu'ils ont achetés et payés - vous perdre de la bonne volonté.

Conclusion

Vous seul pouvez répondre si les aspects économiques du découragement ou de la protection conviennent à votre situation. Mais plus vous optez pour une protection, plus elle sera chère, et donc plus vous devrez risquer de la perdre pour la justifier.