Ok merci, je vois plus clair.
Y a ce site que j'ai trouvé qui explique le principe graphiquement :
http://dn.codegear.com/article/27979 Apparemment, ça pourrait même fonctionner sous Linux :)
Pas du tout, le loader ne lit pas un exe comme un quelconque fichier.
Va lire les specs du format PE, tu verras que ne sont lus que les octets utiles définis dans les structures internes, tout ce qui est au delà est ignoré.
Cette méthode est très utile par exemple pour embarquer une DLL dans l'exe, on la dépose à l'exécution dans le dossier TEMP et on la supprime en quittant.
Oui, sauf que le fichier au quel on colle des octets à la fin est un executable (assez délicat). Le format(age) de l'exe est d'une certaine manière compromis. Un futur loader des applications win32 peut décider d'interrompre le chargement de l'exe s'il trouve que sa taille ne concorde pas avec celle indiquée (j'imagine qu'il y a un tel champ) dans le header PE (pour je ne sais quel raison).
J'ignore si Microsoft a documenté comme quoi l'ajout de données supplémentaires à la fin d'un fichier executable est permis. S'ils l'ont fait, ça voudra dire qu'ils grantissent que ça ne causera pas de problèmes dans le futur.
Sans tenir compte du code de la source que je n'ai pas lu entièrement mais juste sur le principe, il n'y a aucune raison que ça ne fonctionne pas, le format PE n'entre pour rien dans l'affaire.
On colle des octets à la fin d'un fichier (quel qu'il soit) puis un DWORD à la fin indiquant le nombre d'octets, on doit retrouver les octets originaux en les relisant.
Je suis surpris que ce programme fonctionne. Vous ajoutez simplement deux fichiers .exe à la fin d'un autre fichier .exe (le binder) en prenant soin de spécifier la taille avant.
Je ne connais pas très bien le format .exe de Windows (appelé PE) ni à quel point est documenté, mais est-ce que ce programme ne risque pas de cesser de fonctionner sur des versions futures de Windows?
Il me semble que le moyen le mieux documenté est d'utiliser l'API Win32 pour ce genre de programme auto-extractable (voir UpdateResoource());
Surtout que dans : char *file1_name=calloc(256,sizeof(char));
le calloc ne sert à rien, et dans : file1_name=argv[2];
ça ne copie rien d'autre que l'adresse qui est dans argv[2] (argv est un tableau de pointeurs), c'est à dire que cela ne fait que créer une sorte d'alias pour argv[2] !
Il suffit de faire : char *file1_name = argv[2];
Pour copier il aurait fallu faire : strcpy(file1_name,argv[2]);
char *c=calloc(1,sizeof(char));
On n'appelle pas une alloc dynamique pour 1 octet.
char c;
allait tout aussi bien en utilisant idem 4 octets (ici sur la pile) mais sans appel au memory manager.
D'ailleurs dans ta fonction forma(...) tu oublies de libérer la mémoire.
On utilise pas calloc pour 1 octet ni meme pour 256(surtout que quelque lignes plus bas tu fait pointer le pointeur sur autre chose, puis quand tu copie un fichier ne le copie pas octet par octet c'est la cata niveau perfs creer plutot un buffer et tu copie par passe de 1 mo.
26 mai 2008 à 19:08
Y a ce site que j'ai trouvé qui explique le principe graphiquement :
http://dn.codegear.com/article/27979
Apparemment, ça pourrait même fonctionner sous Linux :)
26 mai 2008 à 19:02
Va lire les specs du format PE, tu verras que ne sont lus que les octets utiles définis dans les structures internes, tout ce qui est au delà est ignoré.
Cette méthode est très utile par exemple pour embarquer une DLL dans l'exe, on la dépose à l'exécution dans le dossier TEMP et on la supprime en quittant.
26 mai 2008 à 18:55
J'ignore si Microsoft a documenté comme quoi l'ajout de données supplémentaires à la fin d'un fichier executable est permis. S'ils l'ont fait, ça voudra dire qu'ils grantissent que ça ne causera pas de problèmes dans le futur.
26 mai 2008 à 18:46
On colle des octets à la fin d'un fichier (quel qu'il soit) puis un DWORD à la fin indiquant le nombre d'octets, on doit retrouver les octets originaux en les relisant.
26 mai 2008 à 17:48
Je ne connais pas très bien le format .exe de Windows (appelé PE) ni à quel point est documenté, mais est-ce que ce programme ne risque pas de cesser de fonctionner sur des versions futures de Windows?
Il me semble que le moyen le mieux documenté est d'utiliser l'API Win32 pour ce genre de programme auto-extractable (voir UpdateResoource());