Bonjour à tous,

Je pense que c’est une bonne idée de faire une liste des techniques d’obfuscations pour le .net. J’en ai peut-être oublié donc n’hésitez pas à me le faire savoir.

 

Anti-ILDasm :

  • IlDasm est un décompileur de code .net. Cependant Microsoft a mis au point un code qu’il suffit d’ajouter à votre exe afin que ILDasm ne puisse plus ouvrir votre EXE

Anti-Reflector

  • Cette méthode, aussi appellée Stack Unflow a pour but de faire crasher le décompiler .net reflector. Le but est de pop une valeur de la stack alors que cette valeur est vide. Je pense que .net reflector est le seul à être affecté par cela.

Anti-Decompileur

  • Il existe d’autres techniques pour faire crasher les decompilateur, surtout ceux qui utilisent mono.cecil. La technique étant toujours d’ajouter du code que le décompilateur ne sera pas traduire.

Renamer

  • Le renamer va, quant à lui, renommer toutes sortes de données (module, type, field, methods, ….). Cela peut-être très utile si on load un exe dans un debugger comme WinDBG

Fake Attribute

  • Je n’appellerai pas vraiment ça de l’obfuscation mais de la tromperie. Lorsqu’on utilise des deobfuscateur comme de4dot, celui-ci va checher des « traces » d’obfuscateur comme par exemple un attributes. Donc on peut tromper le deobfuscateur et ajouter un attribute alors que l’obfuscation ne sera pas celle donnée.

Locals Encryption

  • Les locals sont toutes les variables (string, int, byte, bool….) Il est possible d’encrypter la plupart de ces variables pour qu’elles n’apparaissent plus telles quelles.

Control Flow

  • Le control flow va récupérer chaque bloc de votre méthode et va mélanger ces blocks afin que le code soit plus difficilement lisible par l’utilisateur

Reference Proxy/Call Hider

  • Cette protection va cacher les appel à des méthodes internes ou externe. Soit en transformant les call en calli, soit en créant une autre méthode similaire qui sera appellée.

Anti-Tamper

  • Le but est ici d’empêcher la modification de l’exe. Soit en effectuant un check du md5 ou alors en encryptant le method body.

Anti-Debug/Dump

  • Le nom est assez explicite. Le but ici est d’empêcher le debug ou le dump de votre application

Resource Encryption

  • Les resource ssont encryptées puis décryptées au runtime. Rien de plus !

Method Body Encryption

  • Cette protection consiste à prendre chaque méthode et à placer tout le code autre part dans l’application. Au runtime, le code sera décrypté puis restauré à sa place

Virtualisation

  • Cette protection assez récente consiste à ce que l’application lise le code  dans un différent language de programmation pour résumer simplement la chose. En gros, le code ne sera pas compréhensible pour un humain

Il existe encore d’autre technique comme ajouter des instruction invalides, ajouter du code inutile, injecter une fausse metadata, …

 

Je n’ai plus beaucoup de temps pour moi, voilà pourquoi je n’ai pas utilisé d’image pour ce topic. Lorsque j’aurai un peu de temps, je m’en occuperai !

 

Pour toute question : mindlockreverser@gmail.com ou skype : MindSystemm !