Solution gratuites pour protéger un code C# ?

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,

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

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

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

Citation:

---

Envoyé par SaumonAgile

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

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?

:dehors:

Citation:

---

Envoyé par black_code

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...

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 :)

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 ;)

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)

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,

Citation:

---

Envoyé par black_code

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é.

Citation:

---

Envoyé par shwin

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

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 ...

Citation:

---

Envoyé par sperot51

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! :yaisse2:

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!

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 ...

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!:king:)

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

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) 8-)

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

Citation:

---

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 :)

Citation:

---

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.

Dans mon cas je cherche aussi à sécurisé ma connexion à mon serveur. j'ai pour le moment mit le code en dur pour tester.
Vous parliez de web services, dans mon cas je ne pourrai pas héberger un web service car mon serveur est sous linux (à moins qu on puisse le faire et que je ne le sache pas)


Alors j'aimerai savoir quels sont les moyens pour sécurisé sa connexion à son serveur?



Cordialement

Avec un système de sessions :)

Après identification du mdp, la bdd(ou autre) renvoie une clé de session temporaire à l'application qui utilise cette dernière pour se connecter au serveur.

Citation:

---

Envoyé par Louis-Guillaume Morand

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

---

Hashtable en anglais mais Table de hachage en français! (wikipedia confirme) Donc haché et pas hashé! Même s'il est vrai on est loi de la boucherie. Oui c'est hors-sujet mais il fallait que je le dise! :)

Bonjour je viens de lire vos posts, comme tout le monde je suis d'accord avec les uns et pas d'accord avec les autres...
Je bosse depuis des mois sur un projet dont la commercialisation débutera la semaine prochaine inchallah... J'ai mis un système d'activation par fichier de licence ainsi qu'une clé pour décrypter le fichier de licence qui contient des ressources nécessaire pour les fonctionnalités avancé du logiciel...
Quand j'ai découvert Reflector! C'était le cauchemard! N'importe qui peut exporter le code source de mon programme, enlever le code de sécurité, régénérer et mettre disponible pour tout le monde!...
En fait y a pas une protection à 100% mais juste le temps de commercialiser le produit càd gagner du temps le temps de vendre quelques licences.
J'ai utilisé Eazfuscator.NET (gratuit) pour obfusquer l'exécutable, ayant une expérience du monde du cracking, je suis satisfait du résultat à 50% car même si j'ai développé en C++ je ne serai satisfait qu'à 75%. J'ai vérifié le code source exporté par Reflector après obscursissement par Eazfuscator.NET, les chaines de caractères sont cryptés, il me faudra des heures et des heures pour corriger les noms des classes et membres en enlevant les caractères superflus non acceptés par le compilateur, analyser le code et donner des noms ayant un sens aux différents classes, membres et variables, etc.
PS: Pour ne pas avoir des réponses hors-sujet, je tiens à signaler que j'ai fait une auto-formation du cracking A TITRE ÉDUCATIF pas plus!

pour nous l'obfuscation n'est pas une solution, vu qu'en cas d'exception, on enregistre la pile d'appel et on reflectionne sur la classe qu'a planté, ca serait plus très drole pour relire les fichier de log :D

Tu peux STP donner plus d'explication?
merci :)

on met des try catch partout (sub function property)
donc pas de fenetre "l'appli plante, continuer ou quitter ?"
et dans chaque catch, on appelle une sub avec en paramètre ex, this, et tous les parametres de la sub (ou fct ...) (dans les membres partagés on envoie que ex vu que this n'est pas dispo)

cette sub de tracage d'erreur, on créé un fichier avec toutes les infos (aussi possible par mail ou dans base de données)

deja avec ex on a .stacktrace (pile d'appel jusqu'à l'erreur)
on connait aussi le type d'erreur et le message qui va avec

et au passage
- on récupère la pile d'appel totale (cheminement depuis le début de l'action)
- on fait de la reflection sur tous les objets passés pour connaitre la valeur des variables et propriétés, qu'elles soient publiques ou privées, donc sur this et tous les autres paramètres du membre qui plante

et sur chaque valeur de membre on reflectionne à nouveau etc...


c'est très pratique pour débugger une appli
on a des controles complexes donc ca permet de retrouver par exemple une requete qui a planté, l'état d'une connexion etc....

et donc pour en revenir à l'obfuscation il me semble que ca change les noms de tous les membres
et donc savoir que aajehzakj a appelé jfrekfkle avec la variable gftncpa en paramètre
c'est quand meme moins pratique que de savoir que AfficheValeur a appelé FormateValeur avec en paramètre TexboxInfo3

et si les .pdb sont présents ca affiche même les numéro de ligne dans la pile d'appel

Merci pour les infos sperot51 :)
Oui je suis tout à fait d'accord avec toi, mais, mon objectif d'utilisation de l'obfuscation c'est de gagner du temps avant que quelqu'un ne trouve la faille et me coupe les vivres :D
Je sais pas si Reflector est le top des désassembleur mais l'obfuscation l'empêche d'analyser mon code source et le déplacement instantané vers la définition d'une classe par simple clique, etc.
Ce qui me préoccupe c'est pas qu'on crack mon prog mais qu'on obtient une version quasiment identique au projet avec tous les codes source et les ressources... Je sais que n'importe quel programmeur peut reproduire mon programme mais c'est comme ça! Au moins il doit fournir l'effort pour le reproduire et non pas <<comme on dit chez nous>> fournit sur une assiette d'or!
Merci :)