Salut,
Juste pour répondre à la question :
[quote=nhervagault]
Delphi, il me semble ne fonctionne pas sur une machine virtuelle comme dotnet?
[/quote]
La réponse est : ça dépend. C'est comme pour le C++ : on peut compiler vers du natif ou vers du code intermédiaire dotnet.
Cela ne change pas grand chose au final : on peut "décompiler" l'un comme l'autre, quoique le langage intermédiaire dotnet ou Java se "décompile" mieux que le langage processeur.
Pour ce qui est du cryptage de .exe... Le format des .exe s'appelle le format PE et est détaillé dans un .doc qui se balade sur le net. Peut être
ici.
Un .exe est avant tout composé de sections. Lors que windows démarre l'exe, il charge ces sections en mémoire, à des adresses précisées dans le .exe. Les sections ne peuvent être exécutées qu'à ces adresses.
Pour faire un programme de cryptage d'exécutable, il faudrait donc patcher l'exe en allongeant par exemple la dernière section, et en y plaçant un code de test de mot de passe et de décryptage (Non crypté bien sûr !), et spécifiant l'adresse de ce code comme point d'entrée de l'exe (L'adresse du point d'entrée est aussi spécifié dans l'exe). Au lancement, en cas de bon mot de passe, les sections effectives de l'exe seraient décryptées.
La difficulté technique majeure reste de ne pas crypter une section contenant des informations importante telle la table d'import, qui précise qu'elles dlls sont nécessaire et à chargées au lancement de l'exe.
Une deuxième difficulté consiste en la récupération des fonctions LoadLibrary et GetProcAddress. Ces fonctions sont nécessaires à la récupération des adresses des autres fonctions de l'OS. Il faudrait que ces deux fonctions soient dans la table d'import, ce qui n'est pas obligatoirement le cas d'un .exe quelconque. La création d'une deuxième table d'import est possible (Située elle aussi à la fin de la dernière section), mais il faudrait complèter les adresses dans la table originale avant l'appel du point d'entrée original de l'exe.
Niveau sécurité, je ne suis pas un spécialiste du cryptage, mais il me semble qu'avec un bon algo de cryptage, cette protection serait absolument inviolable autrement que par force brute : on pourrait déssassembler sans problème le code de décryptage, mais cela ne nous donnerait pas la clé.
Le décrypage se faisant en mémoire, il serait assez technique (Bien que réalisable) pour un pirate ayant le mot de passe de produire un fichier .exe correcte à partir de la version en mémoire. Pas à la portée de tout le monde quoi. C'est un avantage sur la version : un .rar + mot de passe : on ne peut pas obtenir de .exe sans mot de passe facilement.
Pourquoi n'ai je pas coder cette solution ? Un .exe crypté de cet manière serait pratiquement inviolable dans le sens ou sans le mot de passe, il serait impossible d'utiliser le .exe. La protection ultime ? Bin non du tout. Il suffit qu'un utilisateur "légal" diffuse son .exe et le mot de passe associé, et tout le monde pourra utiliser l'application...