Décompilation de Delphi (1/3)

En termes simples, la décompilation est l'inverse de la compilation: traduire un fichier exécutable dans un langage de niveau supérieur.

Supposons que vous perdiez la source de votre projet Delphi et que vous n'ayez que le fichier exécutable: la rétro-ingénierie (décompilation) est utile si les sources originales ne sont pas disponibles.

Hm, "sources non disponibles", cela signifie-t-il que nous pouvons décompiler les projets Delphi d'autres personnes? Eh bien, oui et non…

La vraie décompilation est-elle possible?

Non bien sûr que non. La décompilation entièrement automatisée n'est pas possible - aucun décompilateur ne pourrait reproduire exactement le code source d'origine.

Lorsqu'un projet Delphi est compilé et lié pour produire un fichier exécutable autonome, la plupart des noms utilisés dans le programme sont convertis en adresses. Cette perte de noms signifie qu'un décompilateur devrait créer des noms uniques pour toutes les constantes, variables, fonctions et procédures. Même si un certain degré de réussite est atteint, le "code source" généré manque de noms de variables et de fonctions significatifs.
De toute évidence, la syntaxe du langage source n'existe plus dans l'exécutable. Il serait très difficile pour un décompilateur d'interpréter la série d'instructions en langage machine (ASM) qui existent dans un fichier exécutable et de décider quelle était l'instruction source d'origine..

Pourquoi et quand utiliser la décompilation

L'ingénierie inverse peut être utilisée pour plusieurs raisons, dont certaines:

• Récupération du code source perdu
• Migration d'applications vers une nouvelle plateforme matérielle
• Détermination de l'existence de virus ou de code malveillant dans le programme
• Correction d'erreurs lorsque le propriétaire de l'application n'est pas disponible pour effectuer la correction.
• Récupération du code source de quelqu'un d'autre (pour déterminer un algorithme par exemple).

Est-ce légal?

L'ingénierie inverse ne se fissure PAS, bien qu'il soit parfois difficile de tracer la ligne fine entre ces deux. Les programmes informatiques sont protégés par les lois sur les droits d'auteur et les marques. Différents pays ont des exceptions différentes aux droits du titulaire du droit d'auteur. Les plus courants indiquent qu'il est correct de décompiler: à des fins d'interprétabilité lorsque la spécification d'interface n'a pas été mise à disposition, à des fins de correction d'erreurs lorsque le propriétaire du droit d'auteur n'est pas disponible pour effectuer la correction, pour déterminer les parties du programme qui ne sont pas protégés par le droit d'auteur. Bien sûr, vous devez être très prudent / contacter votre avocat si vous avez un doute quant à la possibilité de démonter le fichier exe d'un programme.

Remarque: si vous cherchez des fissures Delphi, des générateurs de clés ou simplement des numéros de série: vous êtes sur le mauvais site. N'oubliez pas que tout ce que vous trouvez ici est écrit / présenté à des fins d'exploration / pédagogique uniquement.

Pour le moment, Borland ne propose aucun produit capable de décompiler un fichier exécutable (.exe) ou la "Delphi compiled unit" (.dcu) en retour au code source d'origine (.pas).

Unité compilée Delphi (DCU)

Lorsqu'un projet Delphi est compilé ou exécuté, un fichier d'unité compilé (.pas) est créé. Par défaut, la version compilée de chaque unité est stockée dans un fichier au format binaire distinct portant le même nom que le fichier d'unité, mais avec l'extension .DCU. Par exemple, unit1.dcu contient le code et les données déclarés dans le fichier unit1.pas.

Cela signifie que si vous avez quelqu'un, par exemple, une source compilée de composants, tout ce que vous avez à faire est de l'inverser et d'obtenir le code. Faux. Le format de fichier DCU n'est pas documenté (format propriétaire) et peut changer d'une version à l'autre.

Après le compilateur: Delphi Reverse Engineering

Si vous souhaitez essayer de décompiler un fichier exécutable Delphi, voici certaines des choses que vous devez savoir:

Les fichiers source des programmes Delphi sont généralement stockés dans deux types de fichiers: les fichiers de code ASCII (.pas, .dpr) et les fichiers de ressources (.res, .rc, .dfm, .dcr). Les fichiers Dfm contiennent les détails (propriétés) des objets contenus dans un formulaire. Lors de la création d'un fichier exe, Delphi copie les informations des fichiers .dfm dans le fichier de code .exe terminé. Les fichiers de formulaire décrivent chaque composant de votre formulaire, y compris les valeurs de toutes les propriétés persistantes. Chaque fois que nous modifions la position d'un formulaire, la légende d'un bouton ou assignons une procédure événementielle à un composant, Delphi écrit ces modifications dans un fichier DFM (pas le code de la procédure événementielle - il est stocké dans le fichier pas / dcu). Afin d'obtenir le "dfm" du fichier exécutable, nous devons comprendre quel type de ressources sont stockées dans un exécutable Win32.