Patch des exécutables PE Windows

Dans l'en-tête des exécutables PE Windows, l'octet DC sert notamment à indiquer si le programme doit fonctionner en mode graphique (GUI) sans afficher de console, ou en mode ligne de commande.

Or, de nombreux fichiers produits avec le compilateur GCC, souvent des plug-ins de Gimp compilés sans le paramètre LDFLAGS=-mwindows ouvrent une console noire inutile et gênante.

Pour supprimer la console, je me suis longtemps cru obligé de recompiler le plug-in, ce qui est toujours hasardeux sous Windows où il manque toujours quelque chose. Un jour j'ai découvert qu'il suffisait il suffit d'écrire 03 au lieu de 02 à l'octet DC, et j'ai fini par faire ce petit programme, parce que tantôt je ne suis plus sûr de l'adresse de l'octet, tantôt de la valeur qu'on doit lui donner ;)

On charge le fichier (drag-drop possible) et si la dropbox indique 03, on choisira 02 et on cliquera sur "Appliquer".

Un bon nombre d'autres valeurs de l'octet DC sont envisagées également, mais il est vivement déconseillé de les utiliser.

Le drag-drop est peu testé, mais il semble fonctionner.

attention, si le plugin tente d'écrire sur la sortie standard, ça risque de planter...ou pas :D

Citation:

---

Envoyé par Paul TOTH

attention, si le plugin tente d'écrire sur la sortie standard, ça risque de planter...ou pas :D

---

Évidemment, c'est seulement pour les plug-ins qui ouvrent une console noire vide dans la version Windows alors qu'il n'y en a pas dans la version Linux !

Je n'ambitionnais pas là de transformer des exécutables PE CLI en PE GUI (je change l'étiquette, pas le produit), mais à faire face au problème récurrent des plug-ins mal compilés sans LDFLAGS=-mwindows, notamment cross-compilés sous Linux par des gens qui n'utilisent pas Windows. La directive du linker LDFLAGS=-mwindows ne change à ma connaissance que l'octet DC.

Je me rappelle avoir passé une journée pour produire une nouvelle version statique de curl parce que celle de G'mic que j'empaquetais dans l'installeur Inno Setup ouvrait une console ; et David Tschumperlé ne voulait pas de dll ; et moi qui avais déjà appris la veille à utiliser Inno Setup parce que personne d'autre ne se décidait à s'y coller (en fait évidemment j'ai toujours aimé apprendre tout seul, c'est presque un vice), il a fallu que j'apprenne à compiler des exécutables statiques avec GCC.
(Dans G'mic, je ne suis pourtant crédité que comme "testeur", parce que stricto sensu je n'ai pas écrit une ligne du code ; ça m'a toujours un peu frustré : quand j'ai compilé les premières versions de Liquid Rescale pour Windows, Carlo Baldassi, à qui j'ai un peu appris à compiler des dépendances de Gimp pour Windows et qui est devenu autonome en deux jours ;) m'a crédité comme contributeur, fournisseur de paquets précompilés et traducteur. Je viens de découvrir que j'y suis encore !)

Et quelque temps après, j'ai découvert qu'il aurait suffi de patcher ! J'ai alors fait un post sur Flickr Gimp Users, qui est à inscrire dans la liste de ceux qui ont eu le moins d'audience, pour annoncer qu'il fallait patcher l'octet DC avec un éditeur hexa, 2 pour GUI, 3 pour CLI.

Comme on n'a pas souvent besoin de patcher un exécutable PE et qu'il faut qu'un logiciel, même fait maison, serve assez souvent, j'ai ajouté aussi la possibilité de contrôler si l'exécutable PE (exe, dll, ocx, cpl ou scr) est 32 ou 64 bits, ce que je faisais précédemment avec FileAlyzer2 qui ne donne pas directement le résultat.

Cela se fait en deux étapes :

- On doit d'abord lire les octets 3C et 3D du fichier, qui contiennent l'offset de l'information recherchée (à lire dans l'ordre petit-boutien).
- On trouve à cet offset une chaîne qui commence par 'PE' suivi de deux octets à zéro, puis de 'L' (puis $01) pour 32 bits ou des veleurs hexadécimales $64 et $86 pour 64 bits.

Le résultat est affiché dans le deuxième edit à fond vert.

Les exécutables 16 bits sont aussi reconnus à la chaîne NE placée ou non à l'offset indiqué aussi par les octets 3C et 3D. On pourrait affiner cette recherche en étudiant le détail des octets de l'en-tête NE, notamment l'octet situé à offset + $0D, qui donne le système d'exploitation, mais comme l'archéologie m'intéresse assez peu, je me suis contenté de considérer qu'un exécutable non PE comportant MZ ou ZM à l'octet 0 et NE à l'offset était pour Windows et qu'il était pour MS-DOS s'il n'avait pas NE.

Le drag-drop permet de vérifier les fichiers très vite.

Je viens de m'apercevoir d'une erreur fondamentale dans la localisation de l'octet à patcher : il dépend de l'offset de l'en-tête PE et il peut donc changer. L'adresse est en fait à offset + $5C, ce qui la met à $DC dans le cas des exécutables créés par GCC qui m'intéressaient au départ.

J'ai corrigé cela, mais à mesure que ma connaissance des headers s'accroît, ça part dans tous les sens faute d'un plan initial.

J'ai trouvé tout le contraire : une démo super-bein structurée fondée sur une connaissance parfaite du contenu des headers :

http://delphidabbler.com/articles?article=8&part=1

Ça m'a appris la modestie, mais après compilation Delphi, ça ne fait pas ce que j'attendais au niveau des exécutables PE. Mais c'est bon pour approfondir la connaissance des headers MZ non PE non ME.

Il y a à présent toutes les architectures cibles pour les fichiers PE. En revanche la lecture des octets 3 à 6 pour la longueur des fichiers MZ non PE non NE donne des résultats faux avec certains fichiers compressés.