Discussion :

[noftal]

Bonjour,

Mon appli comporte un gestion de licence et donc un module de vérification de la validité des clés de licence saaisies.
La vulnérabilité n'est pas tant dans la capacité de certains à trouver des clés mais à remplacer l'instruction fatidique :

Code :

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

IF licenceOK Then Debloquefonctionnalités

par

Code :

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

If True then DebloqueFonctionnalités

A priori, la seule parade que je vois (parade simple) consiste à obfusquer le code.

Cependant, je me rappelle avoir lu sur ce forum un propos (de wallace1 je crois) qui incitait à ne pas trop systématiser cette méthode pour des applis simple.
L'idée du propos était de dire que le jeu n'en vaut la chandelle que si l'appli attire (ou est supposé attirer) les convoitises.
Certes, mais l'idée de l'obfuscation que je me fais c'est que "ça ne coute rien" donc pourquoi rechigner à y avoir recours ? En effet, même VS2010 possède une fonction Dtofuscation.
Donc je voulais connaître les arguments de deux qui pensent que l'obfuscation comporte des inconvénients. Lesquels ?

[Pol63]

ca empêche l'utilisation de la reflection
c'est une méthode permettant de travailler avec des noms de membres pour faire des choses plus souples, ou pour coder plus rapidement
au lieu de

Code :

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

1
2
if valeurNom.StartsWith("Prop1") then instance.prop1 = valeur
if valeurNom.StartsWith("Prop2") then instance.prop2 = valeur

on peut alors faire

Code :

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

instance.gettype.Getproperty(valeurNom).setvalue(valeur) ' ! syntaxe pas totalement exacte

ca n'est pas pratique non plus pour du débuggage, en général on enregistre les erreurs (provenant des catch) pour corriger les bugs et donc la pile des appels de l'erreur
et donc entre

à huighze.jhuinxoz
à njuvtu.nj15euv

et

à EnregistrementBase.Sauvegarde
à Form1.ButtonSave_Click

je te laisse deviner ce qui est le plus utile pour débugger


et il y a des logiciels de décompilation qui recréé carrément les fichiers .vb et autres .sln
donc quelqu'un qui veut trouver où ca bloque finira par trouver en mettant pause pendant l'exécution, ca sera juste plus long à trouver où ca se passe

[_Ez3kiel]

Pol63 a presque tout dit, je rajoute juste qu'également certains programmes 'obfuscés' sont bloqués par l'anti-virus.

[wallace1]

Bonjour à tous,

Pour ma part je suis partiellement d'accord avec ce qui vient d'être dit !

L'obfuscation/deobfuscation DotNet est un domaine que j'affectionne tout particulièrement car il a fait l'objet d'une étude laborieuse pour mon dernier projet : http://wallace87000.upd.fr/DotNetPatcher.exe !

Concernant le mariage de l'obfuscation et de la reflection c'est indéniable, c'est incompatible ! Il faut aussi mentionner une incompatibilité liée à la globalization dont les applications multilingues en sont souvent dotées !

Il faudrait être un bon débutant et surtout se tirer une bonne balle dans le pieds pour considérer qu'utiliser l'obfuscation au niveau du code source est une solution pérenne et optimisé dans le cycle de développement d'un projet !
Nombreux sont ceux qui préfèrent utiliser l'obfuscation depuis le binaire compilé.

Je ne suis pas d'accord avec les décompilateurs de codes sources !
Au jour d'aujourd'hui il n'existe aucun décompilateur DotNet qui recréé correctement la source depuis le binaire compilé : Reflector, Spices, ...
Je ne vous ferais pas de cours sur la décompilation depuis l'IL mais il faudrait encore de nombreuses heures pour reconstruire la source après décompilation, ce qui veut dire que les cracker ne travaillent pas en se basant sur ce type de décompilation mais en se basant sur les limitation de protection que proposent le langage lui-même !

Ne vous y méprenez pas l'obfuscation en DotNet ne sert pas à protéger un code source mais bien à en rendre d'autant plus difficile la compréhension grace :

- au renommage des méthodes et attributs
- injection de junk code (IL, membres, classes,...)
- ......
...........

L'obfuscation en elle même n'est pas forcément à l'origine de la détection en tant que faux-positif aux yeux des AV !
Si, lors du dev d'un projet on rajoute une routine qui charge un assembly en mémoire lors de l'exécution du binaire compilé alors là l'AV risque de faire la gueule !! Pourtant ce n'est pas une technique d'obfucation mais les AV excluent systématiquement ce type de signature dans le code considérée comme une faille de sécurité.
Dans les obfuscateurs, il faut éviter essentiellement les options suivantes qui rendent le programme favorable à cette remontée :

- Packer
- Anti-Tamper
- Anti-Debug
- Invalid Metadatas
- Compression

Enfin comme tu me cites plus haut Noftal, on ne sécurise pas une application avec un langage DotNet, on rends la source un peu plus compliqué à comprendre. Mais si c'est un programme est largement convoité alors il ne faudra pas longtemps pour les plus aguérrits afin de mettre un terme à ce qui les empêche de comprendre ton code source !

Si tu as d'autres questions sur le sujet n'hésites pas.

PS : si tu as uniquement cette modification à apporter dans ton programme je te suggère de coder toi-même un système visant à rendre difficile la compréhension de ce bout de code.

Cdlt.

A+

[noftal]

Merci wallace pour ton propos largement documenté.
CEpendant ta dernière phrase me laisse perplexe.
Si je comprends bien, tu n'as rien contre l'obfuscation mais dans le même temps tu me conseilles de créer ma propre méthode pour "obfusquer" le bout de code fatidique

Code :

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

IF LicenseOk Then DebloqueFonctionnalités

Moi, j'aurais tendance à dire que le plus simple pour un débutant comme moi, c'est d'utiliser les outils qui existent. Et je pense à DotFuscator puisque j'ai compris qu'il est quelque part disponible dans VS2010. Alors à moins que je sous-estime la complexité de la mise en oeuvre de cet outil, cela me paraît plus simple que de "compliquer mon code", d'autant que, à moins de l'alourdir artificiellement (et donc le ralentir) je ne vois pas trop comment faire.

Si par exemple, les "Fonctionnalités" évoquées dans mon exemple sont lancées par un bouton, il suffira à un hacker de se positionner sur l'event Button.click pour voir ce que fait le code et suivre celui-ci jusqu'à trouver l'instruction "fatidique". Et nécessairement, il sait qu'il n'aura pas des km de code à parcourir avant de tomber dessus.
Je dis des bêtises ?

[wallace1]

Comme je le disais plus haut le cracker ne se retrouve pas dans un environnement de développement pour identifier le comportement de ton binaire.
Il existe tout bonnement des outils comme CFF Explorer, Reflector ... et bien d'autres pour analyser en profondeur ce qui a été modifié sur la structure de la partie PE et/ou Stub DotNet.

C'est malheureux à dire mais DotFuscator de VS reste la protection la plus vulnérable car cmme je le disais également plus haut : pour un cracker le meilleur des jeux qu'il soit c'est d'inverser un processus de protection et qui plus ai d'un éditeur connu c'est encore mieux. Je veux dire par là que si tu utilises le tant réputé doeobfuscateur De4Dot de l'éditeur "0xd4d" (https://bitbucket.org/0xd4d/de4dot/overview) il faut 2 seconde avec ce paramètre en ligne de commande :

Code :

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

-v --one-file "%YourFilePath%"

pour retrouver un binaire cleaned !
Voici la liste qu'il prends en charge :

Agile.NET (aka CliSecure)
Babel.NET
CodeFort
CodeVeil
CodeWall
CryptoObfuscator
DeepSea Obfuscator
Dotfuscator
.NET Reactor
Eazfuscator.NET
Goliath.NET
ILProtector
MaxtoCode
MPRESS
Rummage
Skater.NET
SmartAssembly
Spices.Net
Xenocode

Et s'il te prenait l'envie de vouloir utiliser d'autres obfuscteur connu alors l'outil suivant : NetDeob de l'éditeur "UbbeLol" (http://netdeob0.codeplex.com/), prends en charge le reste :

Phoenix Protector ( http://www.ntcore.com/phoenix.php )
Manco Obfuscator ( http://www.mancosoftware.com/licensing/index.htm )
CodeWall ( http://www.codewall.net/ )
NetZ .NET Packer ( http://madebits.com/netz/ )
Rpx .NET Packer ( http://rpx.codeplex.com/ )
Mpress .NET Packer ( http://www.matcode.com/mpress.htm )
ExePack .NET Packer ( http://exepack.codeplex.com/ )
Sixxpack .NET Packer ( Don't know source )
Rummage Obfuscator ( http://www.aldaray.com/Rummage )
Obfusasm Obfuscator ( http://www.devextras.com/obfuscation/ )
Confuser 1.7 ( Unfinished, http://confuser.codeplex.com/ )

Donc l'idéal de nos jours pour garantir ne protection digne de ce nom c'est de le faire soi-même mais en la gardant privée pas comme DotNetPatcher qui a été un prétexte pour moi de mener une étude approfondie sur le sujet (comme tu peux le lire). C'est l'étude que j'aime dans un projet (et le codage par la suite bien sure ^_^).


A+