L'obscurcissement au niveau du code source est-il plus efficace que les obscurcissements?

Question

Apprendre de ma dernière question , la plupart Les noms de membres semblent être inclus dans la sortie du projet.

En examinant des décompilateurs tels que 9rays , Salamander , Jungle , de nombreuses techniques obscurcissantes semblent déjà avoir été vaincues. Voici une affirmation particulièrement effrayante:

  

Supprime automatiquement les cryptages de chaînes injectés par les obfuscateurs ~ Salamandre

Les manques de code source obscurcis manuels sont-ils plus efficaces que les post-compilations / mi-compilations masquées, "superficielles" par un programme de masquage bien connu (facilement vaincu?)?

Answer 1

L'obstruction du code source va se révéler contre-productive en termes de maintenance.

Si votre projet est si "secret", je suppose que vous avez deux choix:

• Placez le code de propriété 'secret' derrière un service sur un serveur que vous contrôlez

• Codez-le dans un langage donc difficile à décompiler, tel que C / C ++

Answer 2

Peut-être, de manière discutable, mais vous allez détruire la maintenabilité pour le faire.

Est-ce que cela en vaut vraiment la peine?

En réalité, cela revient simplement à la sécurité par l'obscurité , c'est-à-dire qu'il ne s'agit pas de sécurité du tout, mais d'un inconvénient. vous devriez travailler en supposant que toute partie intéressée va décompiler votre code si elle peut y accéder. Cela ne vaut pas la peine que vous vous infligerez de le faire prendre un peu plus de temps aux haxxors diaboliques. Traitez les vrais problèmes de sécurité liés à l'accès.

Answer 3

Comme on le dit, l’obscurcissement consiste à relever la barre. Si vous obfusquez votre montage, vous arrêterez un développeur occasionnel qui est juste curieux mais qui n'arrêtera pas une personne légèrement motivée du reverse engineering.

Si vous souhaitez augmenter encore la barre, de nombreux outils d’obscurcissement vous permettent d’utiliser des caractères non imprimables comme noms de membre. utilisez le réflecteur sur lui-même pour regarder. Cela arrêtera beaucoup plus de gens, je pourrais regarder le code obfusqué pour le comprendre, mais si je ne peux pas le lire, je ne vais pas me laisser aller à le jeter à IL, et à renommer tous les membres manuellement, aucune motivation pour moi de perdre autant de temps.

Cependant, certaines personnes sont motivées. Vous devez donc franchir une nouvelle étape si vos besoins commerciaux l'exigent. Mais peu importe ce que vous ferez si l'ordinateur peut le lire, il y aura quelqu'un qui pourra le lire aussi. L’objectif est de réduire le nombre de personnes qui peuvent le lire ou qui seraient motivées pour le lire.

Il existe également certaines astuces que vous pouvez utiliser pour briser le réflecteur (Obfuscator de PreEmptive brise le réflecteur dans certains cas, mais bien sûr, vous pouvez toujours lire l'IL). J'ai eu une conversation intéressante une fois avec un développeur d'un outil d'obfusction et je ne pourrai pas le rendre juste, mais il avait un moyen de faire complètement éclater le réflecteur en faisant sauter le code de manière dynamique. Par exemple, un moment dans votre fonction a, vous passez alors au milieu de la fonction b. Faites en sorte que PEVerify génère des erreurs afin qu’ils ne l’aient jamais réellement implémenté, mais plutôt génial.

Answer 4

annakata est correct. Tout ce que vous pouvez faire, c’est de rendre plus difficile (et coûteux) le désossage du logiciel par la personne.

Mon entreprise a identifié plusieurs domaines dans lesquels nous voulions rendre le processus d'ingénierie inverse aussi difficile que possible. Par exemple, nos fichiers sont un format binaire que chaque objet de notre hiérarchie est chargé de sauvegarder et de lire la version correcte. Cela signifie pour une personne de lire nos fichiers, elle aurait répliqué toute notre hiérarchie dans le code créé pour lire nos fichiers. En outre, une grande partie des informations contenues dans le fichier Job sont utiles sans le bit correspondant dans les fichiers de normes d’atelier. Ils doivent donc faire le travail deux fois pour comprendre ce que dit le fichier de travail.

Plusieurs domaines critiques (protection du dongle, communication avec nos machines de découpe du métal) résident dans Win32DLL. Ce qui signifie qu'ils devraient connaître l'assemblage et savoir comment créer une DLL qui réplique les signatures d'autres DLL afin de procéder à l'ingénierie inverse de notre logiciel. De plus, notre logiciel de FAO a été conçu de manière à ce qu'il soit hautement interactif avec la machine de découpe (informations échangées en permanence)

Dès que nous avons entendu parler de concurrents essayant de ne traiter que nos machines, ils ont fini par remplacer les composants électroniques par les leurs afin de terminer le travail. Major dollars pour faire cela.

Une partie des mesures que nous avons prises reposait sur notre propre expérience en matière de gestion des machines et des logiciels de la concurrence. Nous avons pris cette expérience et appris à peaufiner notre configuration. Bien sûr, nous avons des limites en ce sens que nous n'allons pas sacrifier la fiabilité ou la maintenance dans le seul but de vaincre l'ingénierie inverse.

Dans votre cas, vous devrez vous demander quelle partie de votre logiciel pourrait intéresser vos concurrents et procéder à partir de là. Si vous êtes un développeur de marché vertical (contrôle de machine, comptabilité spécialisée, etc.), je suggère d'utiliser un dongle USB pour le contrôle de logiciel.

Sinon, utilisez un système de numéro de série et acceptez le fait que des personnes piratent votre logiciel et l'intègrent à votre modèle commercial. Le but d'un schéma de numéros de série est qu'il est relativement peu intrusif et empêche la copie causale et vous donne une chance lointaine de localiser l'origine de la copie.

Answer 5

Le problème, c'est que vous allez sacrifier la lisibilité pour le faire. Si votre projet est si sacré à protéger, je pense qu’il est prudent de supposer deux choses:

1. Le projet est suffisamment important pour que le succès en matière de lisibilité revienne vous mordre à la gorge.
2. Les personnes qui souhaitent procéder à une ingénierie inverse le feront de toute façon. Il vous faudra un peu plus d’intelligence pour déterminer ce que font les choses (au lieu de simplement lire les noms des membres).

Answer 6

Je suis alarmé par le fait que vous envisagez même une obfuscation de code. Ne vous obstruerez pas le code pour vous aussi? Comment comptez-vous y travailler à nouveau? Pour des raisons de maintenabilité, cela ne devrait pas être fait.

Mais considérez ceci: -

Supposons que vous puissiez exécuter un script / une application capable d’ouvrir votre projet et d’obscurcir intelligemment chaque nom de chaîne / variable de votre projet et de le compiler par la suite, alors que votre code original n’a pas été modifié de manière sécurisée.

Voilà une idée.

Answer 7

En réalité, l'obscurcissement au niveau du code est moins sécurisé que ce que les obscurcisseurs peuvent faire. Cela est principalement dû au fait que les obscurcisseurs peuvent tirer parti des détails de l'implémentation CLI stricte qui ne sont pas autorisés par les compilateurs de langage. Par exemple, il est tout à fait légal que tous les champs privés portent le même nom - mais aucun compilateur ne vous permettra de le faire.

Answer 8

vous pouvez utiliser une technique comme celle-ci: http://g.palem.in/SecureAssembly.html en utilisant ceci, vous écrivez en .net mais vous intégrez dans un exécutable c ++ votre exécutable .net,