Discussion :

[nikoko34]

Bonjour,
Je souhaite utiliser dans une appli VB.Net une classe dont les méthodes ne doivent pas être visualisées.

Première idée : crypter au préalable le fichier comportant cette classe et, via le CodeDomProvider et sa méthode CompileAssemblyFromSource, exploiter les méthodes de cette classe en passant en paramètre la string décryptée (après chargement en mémoire du fichier crypté et décryptage de la chaîne chargée). Au passage merci à developpez.com pour les tutos !).
Problème : un outil comme Reflector permettrait de voir le contenu de ces méthodes à l'exécution...

Deuxième idée : utiliser une DLL générée sous Delphi (mais peu importe le langage finalement du moment qu'elle est native).
Je ne rencontre aucun soucis lorsque la DLL est chargée via le DllImport. Par contre, il me semble qu'un bon outil pourrait visualiser le contenu des méthodes compilées dans la DLL (ceci dit, je n'en ai pas l'absolue certitude...)

J'ai donc cherché à mélanger les deux idées à savoir crypter la dll native, et appeler les méthodes s'y trouvant après avoir lu et décrypté le fichier.

Et là, ça coince... car le DLLImport ne fait pas l'affaire et le codeDom non plus !

Quelqu'un a t'il une idée pour contourner ce problème à savoir appeler les méthodes d'une DLLNative qui ne serait pas dans un fichier mais uniquement en mémoire ?

Merci par avance de vos réponses...

[Piotrek]

Salut

A un moment ou a un autre, on pourra jouer de la reflexion sur ton assembly et voir ce qu'il y a dedans.

Il y a une methode qui s'appelle l'obfuscation, elle consiste non pas a crypter le code mais a le rendre difficilement lisible (renommage de variables, labyrinthe d'appels...) Il y en a un dans VS (edition non express)
Autre obfuscateurs commerciaux:
http://lgmorand.developpez.com/dotnet/smartassembly/
http://morpheus.developpez.com/xenocode/

Si vraiement il y a trop peu de code et que l'obfuscation ne se revele pas efficace, la solution est de coder une DLL dans un langage non .Net (C++ nature, VB6...) et de l'appeler depuis ton appli .Net

[nikoko34]

Salut et merci de ta réponse.
Je connais bien l'obfuscation (je suis en train de développer mon propre soft là dessus) et je compte bien l'appliquer en plus du cryptage (j'dois être parano de la sécurité )
C'est bien pour résoudre cette problématique d'assembly que je souhaite utiliser des dll natives (pas de soucis pour le faire) et cryptées (c'est là que le bas blesse !)

[SaumonAgile]

Ce n'est plus de la parano, c'est du gaspillage de ressources.
De toute façon, il n'y a pas de sécurité parfaite, à moins que ton application gère les codes pour les sous-marins nucléaires, je ne vois pas trop l'intérêt de faire plus que déplacer le code dans une dll non managée.

Après tu peux aussi embaucher un porte-flingue de la mafia russe, lui fournir un steelcase (avec un cd contenant ton application) menoté à son poignet, l'envoyer chez le client en utilisant un itinéraire déterminé pendant le trajet. Il est évident que le cd se détruit automatiquement si la mallette n'est pas ouverte avec la bonne empreinte retinienne et vocale. Il se détruit aussi dans le cas où le numéro de série du lecteur CD n'est pas préalablement enregistré dans le programme. Le cd se détruit automatiquement lors de l'éjection du lecteur pour éviter d'être réutilisé.
Avec ça, tu devrais être à l'abri pour quelque temps, ton application qui gère tes divx est protégée (autant que faire se peut).

A oui et n'oublie pas de faire exécuter ton client après pour ne pas qu'il divulgue des informations sur ton programme.

[Piotrek]

Quelqu'un a t'il une idée pour contourner ce problème à savoir appeler les méthodes d'une DLLNative qui ne serait pas dans un fichier mais uniquement en mémoire ?

Normalement il y a deux moyens pour les Dlls managees en memoire:
- La reflexion (codedom) ()
- L'implementation d'une Interface commune entre l'appli et la dll en memoire

La derniere solution est peut etre possible pour des dlls non managees

[nikoko34]

Normalement il y a deux moyens pour les Dlls managees en memoire:
- La reflexion (codedom) ()
- L'implementation d'une Interface commune entre l'appli et la dll en memoire

La derniere solution est peut etre possible pour des dlls non managees

Ah que voilà, môssieur Piotrek une piste interessante de travail que je vais de ce pas explorer (sinon, je ferai appel au porte flingue ) !
Il est clair, môssieur SaumonAgile que la sécurité absolue n'existe pas mais ce qui m'interesse avant tout, c'est d'appliquer la maxime "il n'y a pas de problème, il n'y a que des solutions", autrement dit, de mettre au point une solution originale/atypique qui puisse contrer le hacker de base (et juste celui là) pour faire face à une problématique de confidencialité d'algorithme.

Et puis y'a aussi l'apétit de connaissance et d'exploration de cette jungle de classe et de méthodes qu'est devenue le framework 2

Ceci dit, pour mettre en place cette solution, je ne connais actuellement que les méthodes GetMethods et GetTypes qui s'appliquent à une assembly...donc à des dll managées.
Je vais chercher un peu plus chez l'ami (?) MSDN...