L’obfuscation qui n’existe pas (encore) dans le dictionnaire est un mot emprunté à la langue anglaise définissant l’acte de cacher son code source, de le rendre illisible.

Les programmes managés comme ceux issus des langages dotnet et Java, ne sont pas directement compilés en code binaire. Il sont compilés en un langage intermédiaire puis « vraiment compilés » en temps réel en s’exécutant.

Seulement, tout le monde n’adhère pas à l’esprit Open Source, et c’est là que ça devient compliqué.

Ces langages permettent donc de retrouver le code source initial à l’aide de « dé-compilateurs » comme le fameux .NET Reflector.

Depuis la popularisation de cet outil, l’obfuscation n’a jamais autant été à la mode et les obfuscateurs comme ils sont appelés ont cette fois vu le jour.

On peut noter parmi ceux-là, Xenocode Postbuild, SmartAssembly ou encore Babel.

Ils sont souvent payants, ou peu fiables pour certains. On dit d’ailleurs souvent qu’une personne acharnée trouvera quand même le code source même si il lui faut des mois pour décortiquer le code source caché.

Cela dit on arrive donc à un choix double :

  • Payer un programme complet comme SmartAssembly (que je recommande vivement pour une utilisation professionnelle)
  • Utiliser un obfuscateur fait maison très simple qui rendra les programmes comme Reflector non utilisables de façon plutôt fiable

Et je vais vous détailler la seconde méthode tout de suite.

Obfuscation : le faire soi-même

Les pilotes, DLLs et autres fichiers exécutables de Microsoft utilisent ce qu’on appelle un PE (Portable Executable) Header. C’est un entête portable à travers les différentes versions de Windows.

Il est composé de plusieurs parties dont vous je vous passe les détails parce-que je ne les connais pas trop et que ça ne nous servira pas vraiment non plus.

Sachez simplement que Reflector a besoin de cet entête pour « désassembler » le fichier et retrouver le code source. On va donc à l’aide d’un simple bout de code en VB.NET corrompre une partie de cet entête appelée le NT header.

C’est très simple, voici le code en question :

Dim FS As New FileStream("C:Users......fichier.exe", FileMode.Open, FileAccess.Write)
 FS.Seek(244, SeekOrigin.Begin)
 FS.WriteByte(10)
 FS.Flush()
 FS.Close()

Remplacez bien-sûr le chemin par un fichier à obfusquer.

Ce code va donc écrire (remplacer) la valeur à l’adresse 244 qui correspond au début du NT header.

(Je ne suis pas à l’origine de ce bout de code)

obfuscation

Emplacement de l’octet que l’obfuscateur va modifier. Adresse 244.

Essayez ensuite de l’ouvrir avec Reflector, et vous obtiendrez une erreur « Invalid number of data directories in NT header ».

Vous pouvez donc à présent protéger vos programmes à l’aide de cette solution très simple.

Plus d’information pour apprendre à programmer : 5 étapes pour Débuter en Programmation

19 Commentaires. En écrire un nouveau

  • Salut a toi pourrai tu détailler un peux plus se renseignement j’ai pas tous suivi comment faire merci bonne journée

    Répondre
    • Salut, ou est-ce que tu bloques ? Il te faut Visual Studio pour compiler le code et éventuellement .NET Reflector pour tester le résultat. Bien sûr il faut aussi remplacer « C:\Users\…\…\fichier.exe » par le chemin complet du programme à obfusquer 😉

      Répondre
  • Salut, c’est vraiment super !
    Mais connais-tu d’autre méthode (en VB.NET) pour obfusquer ?
    Par exemple, sais-tu comment changer les nom des Class, des variables ?
    Merci beaucoup, j’adore ton site !

    Répondre
    • Salut Jean Félix et merci pour ton commentaire 🙂
      Je vais bientôt reprendre un ancien projet d’obfuscateur et je ferai des articles à ce sujet lorsque j’aurai fini !
      J’ai également regardé du côté du Pe Header si je pouvais utiliser d’autres méthodes, pour l’instant ce n’est pas fonctionnel, et quand ça marche le programme ne se lance plus

      Répondre
  • salut a vous jai bien vu ce que vous avez décris mais en ouvrant avec réflector je peux tj voir mon application pk cdt?

    Répondre
    • Salut Jimmy,
      As-tu bien utilisé le bon chemin vers ton programme (C:\etc…) ?

      Répondre
      • oui tout a fais aucune erreur connue apres je le met peux etre pas au bon endroit alors j’ulise un logiciel qui fonctionne bien et j’en trouve pas pour inverser la confusion donc ca me va

        Répondre
  • […] section du PE Header (dont nous avons rapidement parlé dans l’article sur l’obfuscation) dans laquelle certains malwares (notamment des chevaux de troie) stockent des informations utiles. […]

    Répondre
  • Merci beaucoup Michel, très utile et surtout très simple!

    Répondre
  • Bonjour,

    C’est une bidouille assez sympa à connaitre. Mais je doute fort que ce soit une manière fiable d’obfusquer un programme écrit en .NET.

    Les informations sur la structure du programme seront toujours visible. Ce n’est pas parce que « reflector » ne parvient plus à ouvrir le fichier que ce n’est pas le cas.

    D’ailleurs l’obfusquation elle-même ne fait que modifier le nom des classes, crypter les chaines ect… Le résultat reste toujours « désobfusquable » pour qui veut s’en donner la peine. Une grosse entreprise avec des fonds considérables et une bonne équipe de dev peu aisément obtenir la source d’un programme obfusqué en quelques mois.

    Cette astuce n’est donc valable que pour les débutants qui font des programmes sans grands intérêts et veulent limiter la casse sans avoir à payer entre 300 et 700€ pour une licence d’un obfuscateur digne de ce nom, mais ne convient absolument pas aux programmes commercialisés.

    Répondre
  • Merci Patak mais DotNetPatcher est davantage considéré comme un renamer.;)

    Répondre
  • Bonjour cette méthode fonctionne seulement avec Reflector et pas avec simply assembly explorer, ce qui est dommage, sinon merci pour l’infos.

    Répondre
  • Bonjour Michel et merci pour cette astuce,
    Mais qu’en est il pour les DLL générées des multi-projets?

    Répondre

Laisser un commentaire

Menu