Discussion :

[pierre.chatelier]

Bonjour,

Je me pose une question relative à la sécurité des assemblies.
Actuellement, je travaille avec plusieurs assemblies (1 exe + des DLLs), dépendants les uns des autres (de façon arborescente je vous rassure).
J'utilise la signature d'assemblies pour garantir l'intégrité des DLLs, elles ne peuvent être changées à l'insu de l'exe.
Mais qu'est-ce qui empêcherait quelqu'un, par exemple, de prendre ces DLLs, et des les utiliser pour lui sans les modifier ? En fait, le code peut être utilisé très facilement, il n'est pas protégé ?
À première vue, ce n'est pas choquant. Depuis des années, une bibliothèque peut être linkée par n'importe qui... par contre, sans documentation on ne s'en sortait pas. Alors que là, les assembly auto-descriptifs permettent de lister classes, méthodes, types, avec une facilité déconcertante.
Bref, je me demande si l'on peut appliquer un traitement aux assemblies pour vérifier, par exemple, l'identité de l'assembly appelant (GetCallingAssembly...)

Exemple : j'ai deux assemblies, A et B; et B est dépendant de A (il l'inclut dans le projet; recompiler A entraîne la recompilation de B)
Problème : pour connaître l'identité de B, il faut le compiler; donc il faut compiler A avant. Et une fois connue l'identité de B, il faudrait modifier A pour l'y inclure, donc recompiler B, ce qui ferait changer son identité...

Il y a une technique, ou pas ?

+
Chacha

[Graffito]

Obfuscator ?

[pierre.chatelier]

Obfuscator ?

Alors je n'ai pas essayé pour plusieurs raison :
-je ne l'ai pas (j'utilise Visual Studio Express)
-je ne suis pas sur que çà marche avec mes Assemblies mixtes (requis pour s'interfacer facilement avec des libs comme QuickTime, openSSL...) : je suis en C++ managed /clr pas pure.
-ça ne résout pas vraiment le problème, c'est un peu une "fausse solution". Enfin... dans mon idée où on pourrait utiliser la signature d'assemblies, non pas pour empêcher l'exploration des classes, mais pour empêcher leur chargement.

[tomlev]

Obfuscator ?

ça ne touche pas aux interfaces publiques de l'assembly (noms des classes et membres publics), donc ça ne change rien au problème... c'est juste qu'en décompilant le code, avec Reflector par exemple, ça ne donnera rien de lisible

[Graffito]

ça ne touche pas aux interfaces publiques de l'assembly (noms des classes et membres publics),

Est-ce vrai pour tous les types d'obfuscator ?
Voir : http://www.codewall.net/

[pierre.chatelier]

Finalement, je me rends compte que je n'ai pas encore résolu proprement une première difficulté : comment intercepter le chargement d'un assembly ? Vu qu'une DLL ne peut pas avoir d'entry point...
Je pourrais m'en sortir avec un object C++ statique, donc construit automatiquement, et dans le contructeur duquel je peux donc mettre du code, mais c'est un peu tiré par les cheveux. N'y-t-il pas une méthode statique de la class Assembly, ou d'un class loader, que l'on pourrait surcharger, et qui serait appelée automatiquement ?

+
Chacha

[dev01]

Salut.

A ma connaissance il n'y a rien de prévu au niveau du load des assembly.

Par contre la technique la plus simple c'est de passer par une licence comme pour un composant. Voir la classe License et ses dérivés

[tomlev]

Est-ce vrai pour tous les types d'obfuscator ?

Oui, forcément : si les noms des classes publiques et de leurs membres publics sont changés, plus personne ne peut les utiliser (à moins de faire référence aux noms obfusqués... bon courage )

[tomlev]

A ma connaissance il n'y a rien de prévu au niveau du load des assembly.

AppDomain.AssemblyLoad

Mais bon, évidemment ça ne fonctionne que pour l'AppDomain courant...

[smyley]

Par contre la technique la plus simple c'est de passer par une licence comme pour un composant. Voir la classe License et ses dérivés

C'est fiable ce truc ? tout à l'air de tenir sur la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

license = LicenseManager.Validate(GetType(MyControl), Me)

qui pourra donc être vue dans Reflector et pour ce qui est des StongName (qui sont peut être utilisés) j'ai déjà vu sur CodeProject un article sur comment le retirer ...

[dev01]

C'est fiable ce truc ? tout à l'air de tenir sur la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

license = LicenseManager.Validate(GetType(MyControl), Me)

qui pourra donc être vue dans Reflector et pour ce qui est des StongName (qui sont peut être utilisés) j'ai déjà vu sur CodeProject un article sur comment le retirer ...

Honnêtement? je l'ai jamais utilisé

Mais les 3/4 des compos payant l'utilise et couplé à dotfuscator ça devrait largement tenir le coup.