DotPeek déserialize pas correctement dll

Question

J'ai décompilé DLL par dotPeek 1.4 pour voir ce qui se passe à l'intérieur, mais il y a quelque chose strage C# code (s'il vous plaît regarder les pièces jointes). Il y a

• Var declaretion sans nom var
• Je pense que certains var sont des nombres, ils n'ont pas le nom

Pourquoi ce code a été généré? Est-ce que dll pourrait être protégé contre la décompilation ou dll a été publié en tant que realease?

Le même problème existe quand je décompiler par la version d'essai de réflecteur

Answer 1

Premièrement, vous enfreignez le contrat de licence en essayant de désosser leur code.

f. Démontage. Vous ne pouvez pas désosser, décompiler, désassembler ou de toute autre manière essayer d'accéder à l'information concernant la construction du produit.

Ceci est dû au fait que .NET permet d'avoir beaucoup plus que a-z dans les noms de variables. Vous pouvez lire à ce sujet dans la section MSDN sur Identifiers (C#). Visual Studio n'aimera pas les variables et se plaindra, mais elles sont parfaitement valides dans IL (tout en n'étant pas valide en C#). Regarder avec d'autres outils ou jeter en hexadécimal, vous pouvez voir les variables ont été obscurcies et sont des choses comme   qui est en fait le caractère ACK^F suivi par le caractère «Début de texte» qui ressemble à l'espace caractère mais n'est pas le caractère d'espace. Les autres caractères utilisés incluent le caractère de retour arrière.

L'IL pour le code ci-dessus va être quelque chose comme

.field private static initonly string '\u0001' 
.field private static initonly string '\u0002' 
.field private static initonly string '\u0003' 
.field private static initonly string '\u0004' 
.field private static initonly string '\u0005' 
.field private static initonly string '\b' 
.field private static initonly string '\u0002\u2000' 
.field private static initonly string '\u0003\u2000' 
.field private static initonly string '\u0005\u2000' 
.field private static initonly string '\b\u2000' 

Vous avez l'idée.

Je voudrais savoir ce qu'ils ont spécifiquement utilisé pour obscurcir ce code (parce que ça a l'air amusant!).Le code a été clairement généré avec quelque chose comme http://reflexil.net/ qui permet à la DLL compilée de conserver des indications sur le nom de la variable (mais les transforme en absurdités), c'est pourquoi le décompilateur affiche tous les noms étranges (le décompilateur pense qu'il est cleaver en conservant les noms des variables mentionné dans la DLL).

Answer 2

Il n'y a vraiment aucune raison un décompilateur générerait champ vide et les noms de variables, peu importe comment obfuscation ou optimisé l'assemblage est. Les champs et les signatures de méthode font partie des métadonnées d'assemblage qui ne peuvent pas être supprimées. Les noms peuvent être partis dans un assemblage obfusqué, mais le type devrait toujours être là et le décompilateur devrait être capable de générer de nouveaux noms.

Peut-être que ce décompilateur n'est pas très bon? Un obfuscator "intelligent" peut faire quelque chose de drôle pour jeter les gens, par exemple, en utilisant des caractères Unicode invisibles comme noms d'identifiants, mais voyant qu'il a réussi à générer un nom tel que param0, il est plus probable que le décompilateur ne le fasse ne fonctionne pas correctement. Vous pouvez vérifier cela en regardant le fichier dans un éditeur de texte fait pour la programmation qui affiche tous les caractères.