conversion ELF -> EXE

Le 31-01-2008, à propos de
conversion ELF -> EXE,
christophe.4.news@gmail.com écrivait dans fr.comp.lang.c :

Bonjour a tous,

Existe il un outil libre capable de convertir un binaire ELF *statique*
(pas de symboles importes) en .EXE windows (PE) ?

Bonjour,

J'ai vu des trucs capable de convertir des exécutables Windows
en exécutables OS/2 Warp 4.x, mais je ne vois pas trop comment
convertir un exécutable ELF en EXE windows (même en restant sous
architecture de type Intel ou compatible). Parce que si on va par
là, on peut trouver des trucs ésotériques :

fermat:[~] > file /bin/ls
/bin/ls: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for
GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped

;-)

Sérieusement, même liés statiquement, il reste un tas d'appels
systèmes dans le code des bibliothèques liées statiquement qui n'ont
aucune chance d'être disponibles sous Windows (ou avec des API très
légèrement différente du style Posix demande que telle fonction
retourne une chaîne statique et Windows retourne un pointeur alloué
sur une chaîne tout sauf statique). Bref, si ce truc existe, c'est
une usine à gaz et il vaut mieux recompiler si c'est possible dans
une couche d'abstraction Posix comme Cygwin.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

En news:fnr4pr$gk4$1@news.tamu.edu, christophe.4.news va escriure:

Existe il un outil libre capable de convertir un binaire ELF
*statique* (pas de symboles importes) en .EXE windows (PE) ?

objcopy ne sait pas le faire ?


Antoine

Le 31-01-2008, à propos de
Re: conversion ELF -> EXE,
Antoine Leca écrivait dans fr.comp.lang.c :

En news:fnr4pr$gk4$1@news.tamu.edu, christophe.4.news va escriure:

Existe il un outil libre capable de convertir un binaire ELF
*statique* (pas de symboles importes) en .EXE windows (PE) ?

objcopy ne sait pas le faire ?

J'ai beau regarder, je ne vois pas...

objcopy: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux
efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little
elf32-big srec symbolsrec tekhex binary ihex

Pour moi, objcopy transforme un format binaire dans un autre format
binaire exécutable sur le même OS (style a.out vers elf, ou sparc64
vers solaris...). Mais je peux me tromper.

Sous OS/2, l'outil disponible décompilait puis recompilait à la
volée les exécutables pour remplacer _tous_ les appels systèmes et
de nombreux softs ne fonctionnaient pas.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

En news:slrnfq3gqs.3pt.knatschke@fermat.systella.fr, JKB va escriure:

Le 31-01-2008, à propos de
Re: conversion ELF -> EXE,
Antoine Leca écrivait dans fr.comp.lang.c :

En news:fnr4pr$gk4$1@news.tamu.edu, christophe.4.news va escriure:

Existe il un outil libre capable de convertir un binaire ELF
*statique* (pas de symboles importes) en .EXE windows (PE) ?

objcopy ne sait pas le faire ?

J'ai beau regarder, je ne vois pas...

Désolé si je suis frustre, mais je n'utilise pas objcopy courament. Mais il
me semble bien qu'il suffit d'écrire

objcopy -v -O pei-i386 sindarin billou.exe

objcopy: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux
efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little
elf32-big srec symbolsrec tekhex binary ihex

Bon, cela c'est pour vous, sur une machine déterminée, où manifestement le
support des exécutables Windows a été omis (mais on pourrait essayer EFI,
cela serait très approchant.)

Voici le résultat avec ma version courante de objcopy
GNU objcopy 2.13.90 20021005
objcopy: supported targets: pe-i386 pei-i386 elf32-i386 elf32-little
elf32-big srec symbolsrec tekhex binary ihex

Voici maintenant le résultat avec une version de développement (introuvable
ailleurs que sur ma machine)
GNU objcopy (GNU Binutils) 2.18.50.20071112
buxobjcopy: supported targets: pe-x86-64 pei-x86-64 pe-i386 pei-i386
elf64-x86-64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec
tekhex binary ihex

Il y a quelques temps j'avais compilé binutils (DJGPP) avec
enable-targets=all, la liste devrait être encore plus impressionante; mais
je n'ai plus le programme sous la main, désolé.

Pour moi, objcopy transforme un format binaire dans un autre format
binaire exécutable sur le même OS (style a.out vers elf, ou sparc64
vers solaris...). Mais je peux me tromper.

Et où est-ce incompatible avec ce qui précède ? ELF est un format binaire,
PE intégré dans dans EXE est un autre format binaire, donc la conversion de
format devrait marcher en toute bonne logique.
Que le résultat soit utilisable ici ou là est une autre question, qui n'a
pas été posée avec suffisament de détails pour que l'on puisse y répondre.

Sous OS/2, l'outil disponible décompilait puis recompilait à la
volée les exécutables pour remplacer _tous_ les appels systèmes et

C'est clairement BEAUCOUP plus ambitieux.
Je n'imaginais pas que la question initiale supposait que cette opération de
conversion de format puisse en même temps convertir les appels système ou
les références aux bibliothèques système, surtout lorsqu'on sait qu'avec un
seul format ELF, on a déjà une naturelle incompatibilité entre différents
systèmes d'exploitation (au hasard, Linux et FreeBSD.)

de nombreux softs ne fonctionnaient pas.

Autrement dit, avant de se lancer là-dedans, il faut avoir un cahier des
charges plus précis...

De toute manière, une conversion arbitraire ELF vers PE (ou COFF, ou
linux-aout) est vouée à de grandes difficultés, à cause des manières
différentes de traiter les références vers les données des bibliothèques
dynamiques (le système ELF est nettement plus élaboré que les autres.) Même
une conversion vers a.out mode SunOS/*BSD (qui utilise aussi le concept de
GOT) risque d'être TRÈS difficile, sans entrer dans le sujet des appels
systèmes ou de la bibliothèque C. Mais la question initiale excluait
délibérement les bibliothèques dynamiques, donc je pense qu'un outil de
simple conversion de format devrait donner une piste.


Antoine

En news:slrnfq3gqs.3pt.knatschke@fermat.systella.fr, JKB va escriure:

Le 31-01-2008, à propos de
Re: conversion ELF -> EXE,
Antoine Leca écrivait dans fr.comp.lang.c :

En news:fnr4pr$gk4$1@news.tamu.edu, christophe.4.news va escriure:

Existe il un outil libre capable de convertir un binaire ELF
*statique* (pas de symboles importes) en .EXE windows (PE) ?
objcopy ne sait pas le faire ?

J'ai beau regarder, je ne vois pas...

Désolé si je suis frustre, mais je n'utilise pas objcopy courament. Mais il
me semble bien qu'il suffit d'écrire

objcopy -v -O pei-i386 sindarin billou.exe

objcopy: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux
efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little
elf32-big srec symbolsrec tekhex binary ihex

Bon, cela c'est pour vous, sur une machine déterminée, où manifestement le
support des exécutables Windows a été omis (mais on pourrait essayer EFI,
cela serait très approchant.)

Avec le paquet binutils-mutiarch sous ubuntu et probablement debian, il

y a un support PE

Et où est-ce incompatible avec ce qui précède ? ELF est un format binaire,
PE intégré dans dans EXE est un autre format binaire, donc la conversion de
format devrait marcher en toute bonne logique.
Que le résultat soit utilisable ici ou là est une autre question, qui n'a
pas été posée avec suffisament de détails pour que l'on puisse y répondre.

En effet, ça marcherait mais les syscalls seraient inutilisables donc ça

n'a pas enormement d'interet

Sous OS/2, l'outil disponible décompilait puis recompilait à la
volée les exécutables pour remplacer _tous_ les appels systèmes et

C'est clairement BEAUCOUP plus ambitieux.
Je n'imaginais pas que la question initiale supposait que cette opération de
conversion de format puisse en même temps convertir les appels système ou
les références aux bibliothèques système, surtout lorsqu'on sait qu'avec un
seul format ELF, on a déjà une naturelle incompatibilité entre différents
systèmes d'exploitation (au hasard, Linux et FreeBSD.)
C'est plus ou moins le sujet de mon mémoire de licence : je décompile un

programme sparc pour le faire tourner dans une autre architecture,
peut-etre un autre environnement. Mais je m'occupe pas de tout émuler.
Regarde dejà les problemes qu'ont les gens de Wine pour émuler windows
sous linux... Ca doit être le même boxon pour émuler linux sous windows
(alors qu'au niveau compatibilité sources, ça fonctionne)

de nombreux softs ne fonctionnaient pas.

Autrement dit, avant de se lancer là-dedans, il faut avoir un cahier des
charges plus précis...

De toute manière, une conversion arbitraire ELF vers PE (ou COFF, ou
linux-aout) est vouée à de grandes difficultés, à cause des manières
différentes de traiter les références vers les données des bibliothèques
dynamiques (le système ELF est nettement plus élaboré que les autres.) Même
une conversion vers a.out mode SunOS/*BSD (qui utilise aussi le concept de
GOT) risque d'être TRÈS difficile, sans entrer dans le sujet des appels
systèmes ou de la bibliothèque C. Mais la question initiale excluait
délibérement les bibliothèques dynamiques, donc je pense qu'un outil de
simple conversion de format devrait donner une piste.

Je me demande... La très grande partie des softs linux sont libres ou

opensource. Est-ce que les sources de cette application sont disponibles
? ça serait beaucoup beaucoup plus facile de recompiler sous windows
avec mingw ou cygwin plutot que de s'amuser à porter l'environnement.
Au pire des cas, il y a la solution vmware avec un linux integré...
si qemu fonctionne sous windows, il y a peut-etre moyen de lui faire
executer un programme linux (en tout cas ça marche de linux sparc ->
linux amd64)

bonne recherche

Antoine

Merci pour vos reponses!

J'ai effectivement zappe le probleme des appels systemes, shame on me...

Il y a bien la solution du cross compilateur, mais le gcc dont j'ai
besoin (3.2.2, imperativement) ne genere pas de PE windows.
(par contre les Atmel AVR sont geres :-))

Je surement rate quelque chose, mais quoi ?

a+

christophe.4.news@gmail.com wrote on 31/01/2008 19:25:

Il y a bien la solution du cross compilateur, mais le gcc dont j'ai
besoin (3.2.2, imperativement) ne genere pas de PE windows.
(par contre les Atmel AVR sont geres :-))

Je surement rate quelque chose, mais quoi ?

tester une compilo avec une version "express" de Studio ?

Sylvain.

--{ christophe.4.news@gmail.com a plopé ceci: }--

Il y a bien la solution du cross compilateur, mais le gcc dont j'ai
besoin (3.2.2, imperativement) ne genere pas de PE windows.
(par contre les Atmel AVR sont geres :-))

Je surement rate quelque chose, mais quoi ?

De nous expliquer le réel besoin ?

--
...
... Mmmm
...
By the way, all OSes are bloated, no ?

Bonjour a tous,

Existe il un outil libre capable de convertir un binaire ELF *statique*
(pas de symboles importes) en .EXE windows (PE) ?

Merci de votre aide.

Si le but est de faire tourner le binaire sous Windows il faut plus
qu'une conversion...

Il y a un truc qui est supposé faire ça : Lina (je sais pas ce que
ça vaut) :

http://www.openlina.com/