Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Damien Pinauldt
> Bonjour,
De même,
Les methodes d'obfuscation de code .NET proposé par Visual Studio 2005 sont-elles efficaces contre le reverse engineering ?
Oui ! Enfin, dans une certaine mesure. D'abord, il paraît évident que ce qui est publique (par rapport à l'assembly) ne PEUT PAS être caché. Imaginez un vendeur de bibliothèque disant 'Pour utiliser mon composant, instanciez un "Äç1", puis appellez sa méthode "a()"'...
Cela concerne tous les obfuscateurs, d'ailleurs.
Dans le cas nominal, on passe la moulinette, et le résultat est illisible avec le reflector (qui détecte qu'il y a eu obfuscation), sans modification sensible de la vitesse de l'application.
Il reste, que comme avec l'assembleur généré à partir de C++ ou autre, il est toujours théoriquement possible de reproduire un comportement, et peut-être même de le comprendre. Mais c'est toujours pareil : pour faire ça, il faut disposer de tellement de temps et de compétences, qu'il est plus simple de refaire de zéro - même si l'algo est critique.
Il y a quand même quelques détails à garder en tête : par exemple, il ne faut pas compter sérieusement sur un obfuscateur pour masquer une instruction du genre 'static readonly string CLEFSECRETE ="MotDePasse";', soyons sérieux...
Enfin, en comparant l'obfuscateur de Studio à d'autres, il apparaît qu'il fait dans l'ensemble du bon boulot. Il complique parfois les déploiements, les tests unitaires ou d'autres trucs du genre, mais ça va. Les autres proposent en plus des optimisations, en taille ou en RAM, mais je ne suis pas convaincu.
Enfin, il faudrait comparer avec ce qui se fait en Java, mais là j'y connais rien...
Pour finir, je dirais "C'est bon dans 99% des cas" !
> Bonjour,
De même,
Les methodes d'obfuscation de code .NET proposé par Visual Studio 2005
sont-elles
efficaces contre le reverse engineering ?
Oui !
Enfin, dans une certaine mesure.
D'abord, il paraît évident que ce qui est publique (par rapport à
l'assembly) ne PEUT PAS être caché.
Imaginez un vendeur de bibliothèque disant 'Pour utiliser mon composant,
instanciez un "Äç1", puis appellez sa méthode "a()"'...
Cela concerne tous les obfuscateurs, d'ailleurs.
Dans le cas nominal, on passe la moulinette, et le résultat est
illisible avec le reflector (qui détecte qu'il y a eu obfuscation), sans
modification sensible de la vitesse de l'application.
Il reste, que comme avec l'assembleur généré à partir de C++ ou autre,
il est toujours théoriquement possible de reproduire un comportement, et
peut-être même de le comprendre. Mais c'est toujours pareil : pour faire
ça, il faut disposer de tellement de temps et de compétences, qu'il est
plus simple de refaire de zéro - même si l'algo est critique.
Il y a quand même quelques détails à garder en tête : par exemple, il ne
faut pas compter sérieusement sur un obfuscateur pour masquer une
instruction du genre
'static readonly string CLEFSECRETE ="MotDePasse";', soyons sérieux...
Enfin, en comparant l'obfuscateur de Studio à d'autres, il apparaît
qu'il fait dans l'ensemble du bon boulot. Il complique parfois les
déploiements, les tests unitaires ou d'autres trucs du genre, mais ça va.
Les autres proposent en plus des optimisations, en taille ou en RAM,
mais je ne suis pas convaincu.
Enfin, il faudrait comparer avec ce qui se fait en Java, mais là j'y
connais rien...
Pour finir, je dirais "C'est bon dans 99% des cas" !
Les methodes d'obfuscation de code .NET proposé par Visual Studio 2005 sont-elles efficaces contre le reverse engineering ?
Oui ! Enfin, dans une certaine mesure. D'abord, il paraît évident que ce qui est publique (par rapport à l'assembly) ne PEUT PAS être caché. Imaginez un vendeur de bibliothèque disant 'Pour utiliser mon composant, instanciez un "Äç1", puis appellez sa méthode "a()"'...
Cela concerne tous les obfuscateurs, d'ailleurs.
Dans le cas nominal, on passe la moulinette, et le résultat est illisible avec le reflector (qui détecte qu'il y a eu obfuscation), sans modification sensible de la vitesse de l'application.
Il reste, que comme avec l'assembleur généré à partir de C++ ou autre, il est toujours théoriquement possible de reproduire un comportement, et peut-être même de le comprendre. Mais c'est toujours pareil : pour faire ça, il faut disposer de tellement de temps et de compétences, qu'il est plus simple de refaire de zéro - même si l'algo est critique.
Il y a quand même quelques détails à garder en tête : par exemple, il ne faut pas compter sérieusement sur un obfuscateur pour masquer une instruction du genre 'static readonly string CLEFSECRETE ="MotDePasse";', soyons sérieux...
Enfin, en comparant l'obfuscateur de Studio à d'autres, il apparaît qu'il fait dans l'ensemble du bon boulot. Il complique parfois les déploiements, les tests unitaires ou d'autres trucs du genre, mais ça va. Les autres proposent en plus des optimisations, en taille ou en RAM, mais je ne suis pas convaincu.
Enfin, il faudrait comparer avec ce qui se fait en Java, mais là j'y connais rien...
Pour finir, je dirais "C'est bon dans 99% des cas" !
Delf
Olivier avait soumis l'idée :
Les methodes d'obfuscation de code .NET proposé par Visual Studio 2005 sont-elles efficaces contre le reverse engineering ?
D'ailleurs, comment y accède -t-on à ces fonctionnalités ?
On m'a par ailleurs dit qu'il était possible de générer des binaires natifs... j'ai rien trouvé sous Team Suite 2005...
Merci.
-- Delf
Olivier avait soumis l'idée :
Les methodes d'obfuscation de code .NET proposé par Visual Studio 2005
sont-elles
efficaces contre le reverse engineering ?
D'ailleurs, comment y accède -t-on à ces fonctionnalités ?
On m'a par ailleurs dit qu'il était possible de générer des binaires
natifs... j'ai rien trouvé sous Team Suite 2005...
