[VB2005] Utilisation de DLL native cryptée

Version imprimable

27/07/2007, 10h56
nikoko34

[VB2005] Utilisation de DLL native cryptée

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...:aie: 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...
27/07/2007, 12h17
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
27/07/2007, 12h28
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é :mouarf: )
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 !)
27/07/2007, 12h39
SaumonAgile

Ce n'est plus de la parano, c'est du gaspillage de ressources. :D
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.

:dehors:
27/07/2007, 12h52
Piotrek

Citation:

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) (:aie:)
- 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
27/07/2007, 14h15
nikoko34

Citation:

Envoyé par Piotrek

Normalement il y a deux moyens pour les Dlls managees en memoire:
- La reflexion (codedom) (:aie:)
- 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 8-) ) !
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 :mouarf:

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...
30/07/2007, 14h47
nikoko34

Bien bien...
L'ami MSDN ne m'a pas été d'une grande utilité...
Une DLL native semble ne pas pouvoir être lue autrement que par une lecture directe du fichier.

Par contre, une classe dotnet encryptée qui est décryptée et compilée via la méthode CompileAssemblyFromSource, en précisant les paramètres :
- GenerateExecutable = False
- GenerateInMemory = True
génère en mémoire une DLL (dont le nom est une suite aléatoire de 8 caractères alphanumériques) que Reflector ne voit pas (enfin, que je n'ai pas réussi à voir sous Reflector :mrgreen: ) et qu'un outil comme Process Explorer ne voit pas non plus.

Alors que demander de plus !!!
30/07/2007, 16h24
smyley

whaou, CompileAssemblyFromSource ?? donc ça veux dire qu'à un moment il y aura dans une variable de ton programe managé tout le code source de ta dll ?? c'est trop beau pour être vrai, il suffirai donc d'un outil de debug ou d'un profiler pour exécuter pas à pas ton programme et donc avoir à un moment tout le code de ta dll ? :aie:
30/07/2007, 16h42
SaumonAgile

Citation:

Envoyé par smyley

whaou, CompileAssemblyFromSource ?? donc ça veux dire qu'à un moment il y aura dans une variable de ton programe managé tout le code source de ta dll ?? c'est trop beau pour être vrai, il suffirai donc d'un outil de debug ou d'un profiler pour exécuter pas à pas ton programme et donc avoir à un moment tout le code de ta dll ? :aie:

Chuuuuuttt, c'est un programme ultra-sécurisé, il ne faut pas le dire ;)
31/07/2007, 11h51
nikoko34

Merci Smyley pour ce rappel.
A force de focaliser sur le fait de rendre des fichiers illisibles, j'en oublie la perméabilité des analyses de la mémoire.

Il est vrai que je ne connais pas le pouvoir/les possibilités de ces outils de débogage mais si l'appel à la fonction de décryptage se fait en paramètre du compileassemblyfromsource, sans donc passer par une variable, on limiterait les dégats...

Il va de soi aussi que le code source serait obfusqué...:cfou:
31/07/2007, 13h16
smyley

Citation:

Envoyé par nikoko34

mais si l'appel à la fonction de décryptage se fait en paramètre du compileassemblyfromsource, sans donc passer par une variable, on limiterait les dégats...

Non, on serai désespéré, car celà ne changerai rien, il y aura toujours à un moment sur la pile tout le code de ton programme de 1, et de 2, dans le code source de CompileAssemblyFromSource, rien ne te dit que M$ n'utilise pas une variable pour stoquer le code ( et d'ailleurs, c'est le cas )...

Citation:

Envoyé par nikoko34

Il va de soi aussi que le code source serait obfusqué...:cfou:

Je savais qu'on pouvais obfusquer des dlls, mais les fichiers sources ... et même si on le peut, dans ce cas, pourquoi ne pas tout simplement utiliser les dlls normallement, mais en les obfusquant avant la distribution de ton programme ? ( j'ai l'impression qu'on te la déjà dit plus haut ... ) car en ajoutant un CompileAssemblyFromSource, tu ne protèges pas ton programme, tu évites juste au cracker d'avoir à chercher le code source avec Reflector ... de plus, la dll compilée serai elle aussi accessible pour un cracker un peut plus expérimenté ( quoique si on peut injecter du code dans le programme, on pourrai lui demander d'analyser la dll crée ... ça me donne des idées :aie: ).

Si tu veux une bonne protection et que tu ne crois pas à l'obfusquation, fait les parties critiques de ton programme en C++ et/ou investit dans un "vrai" logiciel de protection .. celà ne sert à rien de se casser pas la tête à crypter les dlls, vu qu'au final en mémoire t'aura toujours la "vrai" dlls, non cryptée ... a moins que tu soit capable de crypter chaque instruction du programme et ne la décrypter que quand nécéssaire pour la recrypter après, mais est-ce vraiment nécéssaire ( et possible ) ?
01/08/2007, 10h02
nikoko34

Citation:

Je savais qu'on pouvais obfusquer des dlls, mais les fichiers sources ... et même si on le peut, dans ce cas, pourquoi ne pas tout simplement utiliser les dlls normallement, mais en les obfusquant avant la distribution de ton programme ? ( j'ai l'impression qu'on te la déjà dit plus haut ... )

Je n'ai aucun soucis avec l'obfuscation comme dit plus haut. Il suffit juste de le faire de façon suffisament poussée (et pas que par remplacement des noms de variables ce qui ne cache rien de l'algorithme).

Ma problématique initiale était surtout de savoir si on pouvait décrypter une DLL de type C++ ce qui ne semble pas possible du fait du mode de chargement de ce type de DLL (par nom de fichier devant se trouver à priori soit dans le répertoire projet soit dans system32).

J'en profite (même si on papotte avec le tag résolu depuis plusieurs jours et qu'on s'éloigne un peu de VB.NET) pour poser une question qui est la cause de mes craintes de sécurité (je n'ai pas trouvé ce thème de discussion dans le forum) : est ce que l'on connaît le degré de lisibilité des DLL natives ?
Avec un simple éditeur en hexadécimal, j'ai noté que l'on peut lire les noms des méthodes qui y sont définies (en tout cas pour Delphi).
Je suppose que celà dépend pas mal du langage à l'origine de la DLL

D'autre part, avez-vous connaissances de logiciels ayant pour finalité la décompilation de DLL natives
01/08/2007, 15h42
smyley

Citation:

Envoyé par nikoko34

est ce que l'on connaît le degré de lisibilité des DLL natives ?

Je ne crois pas que celà se mesure ... :aie: . Enfin bon, le truc, c'est que pour un gars qui fait du C# toute ça vie ( moi par exemple :roll: ), une dll native c'est illisible, mais pour un gars qui fait de l'Assembleur depuis 10 ans une dll native c'est comme un bouquin avec des notes et tout, c'est à dire qu'il n'aura vraiment aucun problème à savoir ce que la dll fait.

Citation:

Envoyé par nikoko34

Avec un simple éditeur en hexadécimal, j'ai noté que l'on peut lire les noms des méthodes qui y sont définies (en tout cas pour Delphi).

Les dlls de Delphi je les trouves un peut spéciales, elles ont un tas de données qui n'existent que pour les binnaires fait avec Delphi mais à la base, pour tous les langages natifs tu aura forcément le nom des functions importées et exportés ( par exemple, MessageBoxA ) et aussi les dlls utilisées ( user32.dll ).

Citation:

Envoyé par nikoko34

D'autre part, avez-vous connaissances de logiciels ayant pour finalité la décompilation de DLL natives

WinDasm peut être ? :roll: il existe certains décompilateurs qui arrivent même à traduire les dlls en code "C", mais là je ne m'y connais pas vraiment ...