Discussion :

[black_code]

Bonjour,

Je me suis mis il n'ya pas très longtemps dans le développement sous C# (je ne suis un développeur à la base). Actuellement je travail sur un petit utilitaire codé en utilisant C# mais après recherches sur le web j'ai découvert qu'on utilisant reflector, tout le code source de mon utilitaire est visible clairement et simplement sur l’interface.
J’ai essayé d’obfusquer le code avec skater .net mais franchement il n’y a que les variables qui sont obfusquées (sachant qu’avec un simple système de liens on retrouve le cheminement malgré cette obfuscation)

1- Y'a t-il une solution (gratuite) pour obfusquer totalement le code C#?
2- Y'a t-il une solution (gratuite) pour compiler en natif un code C# ?
3- Y'a t-il un moyen (gratuit) pour protéger son code (ou au pire rendre difficile le reverse engineering) sur le code C#?

Les solutions payantes sont la pour les entreprise et pas vraiment abordable pour le développeur (amateur) X ou Y.

Merci par avance de votre retour.
Cordialement,

[tomlev]

Dotfuscator Community Edition est gratuit, mais limité...
cf. le comparatif ici :
http://msdn.microsoft.com/fr-fr/libr...40(VS.80).aspx

[black_code]

j'ai essayé Dotfuscator mais le problème c'est que le but principal de la version community est de seulement renommer les identificateurs ce qui n'offre pas vraiment une sécurité au code source.

Cdt

[SaumonAgile]

Que cherches tu à faire en protégeant le code source ?

[black_code]

Que cherches tu à faire en protégeant le code source ?

comme j'ai dit dans le point (3), un reverse engineering est toujours possible, je cherche à rendre difficile ce reverse engineering (à défaut de le rendre impossible) pour protéger au maximum le code source :
- proteger les fonctions de traitements dans le code
- protéger les sécurités intégrées dans le code (password, ...).

il y en a tellement...

cdt

[TheCaribouX]

J'en connais qui n'utilisent pas d'outils supplémentaires mais qui savent rendre un code illisible sans problème...

il suffirait pas de faire appel à des incompétants?

[SaumonAgile]

comme j'ai dis dans le point (3), un reverse engineering est toujours possible, je cherche à rendre difficile ce reverse engineering (à défaut de le rendre impossible) pour protéger au maximum le code source :
- proteger les fonctions de traitements dans le code
- protéger les sécurités intégrées dans le code (password, ...).

il y en a tellement...

cdt

C'est bien ce qu'il me semblait, il y a en général deux raisons de masquer le code source :
- on a mis des informations sensibles dans le code,
- le code est tellement sale qu'on ne veut pas que cela se sache.

Dans les deux cas, l'offuscation ne résoud rien. La solution est soit de stocker les données sensibles dans des conteneurs adaptés, soit d'apprendre à coder proprement.

Tout le reste n'est pas une raison valable, la sécurité par l'obscurité n'est qu'illusoire.

Une dernière chose, si tu cherches à protéger des regards des choses faites intelligemment, c'est comme si Picasso avait passé une couche de noir sur tous ses tableaux pour que personne ne puisse s'en inspirer...

[Louis-Guillaume Morand]

il reste une raison (qu'il a cité)
- proteger les fonctions de traitements dans le code

le calcul de pricing ou certains calculs financiers très particuliers que ce soit dans un banque ou dans tout type de société qui vend les chiffres qui ressortent de ces calculs méritent de crypter le code. quelques lignes de code ou un algo sont parfois le coeur de métier d'une entreprise, son savoir-faire


donc maintenant, si ce logiciel, tu veux le vendre alors sa protection aura un coût. si tu le distribue gratuitement, laisse le code visible, il servira à d'autre. altruisme, quand tu nous tient


Maintenant c'est sûr que l'obfuscation ca ne protègera jamais à 100% mais certains obfuscateurs (comme smartassembly font un truc sympatoche) et je pense qu'il faut vraiment être motivé pour vouloir tout reverser. Maintenant, c'est tout aussi illusoire que quand tu dis que ton réseau ou meme le réseau d'une banque est sécurisé, pourtant, tu est content qu'ils investissent dedans

[SaumonAgile]

My 2 cents :

Pour protéger le savoir-faire, il y a les brevets. Tu protèges la "méthode de calcul" et pas l'implémentation du calcul.
Pour protéger les "secrets" de fabrication d'une voiture, tu ne mets pas des serrures partout, tu déposes un brevet, et tu laisses le concret visible.

Sinon pour en revenir au problème, on voit très souvent les parties critiques implémentées en C++ au lieu de C# pour éviter le reverse-engineering.

Je ne connais pas d'outil gratuit pour faire ce genre de chose, si tu tiens vraiment à protéger la source, il va falloir mettre la main au portefeuille

[Pol63]

des solutions gratuites je crois qu'il n'y en a pas
mais payantes surement, j'ai entendu parler d'un fabricant de dongle sur lequel on met l'appli et un exe à part s'occuperait d'accéder au dongle de manière crypté pour lancer l'appli (ou un truc dans le genre)

[black_code]

Merci a vous pour vos réponses

Deux choses :


1- il faut faire de son mieux pour protéger ce qui doit l'être, cela ne veux pas dire qu'il faut juste ce limiter à cela, il faut breveter et tout le reste

P.S : Pour protéger les "secrets" de fabrication d'une voiture, tu ne mets pas des serrures partout, tu déposes un brevet

Demande alors à Microsoft ou à Apple ou a d'autres de mettre le code source des OS en ligne et de seulement se limiter aux bervets ...


2- Le but du post est de savoir s'il y'a des méthodes ou pas pour protéger un code et non de faire le procès du code à modifier (sale pas sale, super génial, ...)

Merci messieurs pour vos idées et vos réponses


Cordialement,

[shwin]

Demande alors à Microsoft ou à Apple ou a d'autres de mettre le code source des OS en ligne et de seulement se limiter aux bervets ...

Les dll qui sont en c# de microsoft ne sont pas obfusqué. Obfusqué du code est seulement une illusion de sécurité.

[tomlev]

Les dll qui sont en c# de microsoft ne sont pas obfusqué. Obfusqué du code est seulement une illusion de sécurité.

En effet... et même des librairies payantes (DevExpress par exemple) ne sont pas obfusquées.
Pour ce qui est des OS, vu qu'ils sont en code natif et non managé, l'obfuscation n'est pas vraiment utile, vu que le code machine est déjà difficilement lisible

[Pol63]

il y a aussi une appli fourni par microsoft qui compile un programme .net en langage natif (donc plus rapide) mais je crois qu'il faut quand meme avoir le programme .net pas loin, mais c'est à tester, on sait jamais, sur un malentendu ca peut marcher
malheureusement je sais plus son nom ...

[seth78]

il y a aussi une appli fourni par microsoft qui compile un programme .net en langage natif (donc plus rapide) mais je crois qu'il faut quand meme avoir le programme .net pas loin, mais c'est à tester, on sait jamais, sur un malentendu ca peut marcher
malheureusement je sais plus son nom ...

Je suppose que tu pense à ngen.exe qui est un programme livré avec le framework .NET? Si c'est le cas, c'est raté pour la sécurité. En effet ngen.exe crée une image native de ton assembly mais c'est pour l'installer dans le GAC. En fait ca remplace la compilation JIT et ca le rend plus rapide. Et pour le lancer ? Tu utilise l'executable! Cet executable que tu peux passer dans Reflector!

Bon sinon comment sécuriser une assembly? Je suis bien d'accord avec tous ceux qui ont argué que l'ofuscation ne sert à rien. Franchement si tu a envie de faire du reverse engeneering tu peux! Ce n'est qu'une question de temps. Mais cependant de très bonnes propositions ont été formulées! Si le problème est de cacher des fonctions sensibles, un petit code natif C/C++ et hop DllImport etc, etc.
Pour les mots de passe... Mais qui utilise encore des mots de passe en dur ? Une connection à une base de donnée, un Web Service sécurisé, un certificat, ... ca c'est l'avenir! Donc pas de raison d'ofusquer!

[Pol63]

l'exe généré par ngen, il doit etre trouvable ...


sinon pour une connexion à une base de données, le mot de passe est à priori obligé d'être dans le programme ... et donc lisible je pense
et s'il est crypté dans un fichier à côté, le code pour le décrypter est dans l'exe aussi ...

[seth78]

Et bien non, car la comparaison se fait sur le serveur web (pour le cas du web service) et donc n'est pas accessible dans le code de l'exe. Pour la base de donnée simple, c'est vrai.. à moins de haché les mot de passe. Auquel cas on pourra accèder au mot de passe haché mais (si le mot de passe n'est pas trivial) on ne pourra pas le retrouver! (et c'est faisable même en dure! super!)

[Pol63]

oui mais si le mot de passe est haché, le code .net pour accéder à la base avec le mot de passe haché est là, donc ca reste réutilisable je pense

[seth78]

Ouais c'est vrai c'est pas la meilleure des solutions! Mais y'a des solutions quand même si on veut vraiment faire des programmes sécuritaire en .NET, sans ofusquation (le web service c'est pas mal je trouve)

[Louis-Guillaume Morand]

hashé et non haché, c'est pas des steaks...(ok elle est nulle mais j'ai le droit )

Et bien non, car la comparaison se fait sur le serveur web (pour le cas du web service) et donc n'est pas accessible dans le code de l'exe.

euh.. et ton appli, il faut bien qu'elle accède au WS. et si elle le fait de manière non sécurisé (sans pwd, puisqu'il est dans le WS) alors n'importe qui peut interroger le WS. ce qui est encore pire.


pour les hash, surtout si c'est du mD5, ca fait des années que les tables rainbow peuvent les cracker et avec les dual core d'aujourd'hui, ca met pas longtemps

le code .net pour accéder à la base avec le mot de passe haché est là,

oui et c'est pour quoi, on n'accède pas à une base avec le code hashé. c'est pas la DB qui fait l'authentification ou alors si c'est avec un compte DB, comme mysql server, c'est un pwd decrypté qu'on envoit et on revient au même problème.