exécute directement la ressource binaire

Question

lpBuffer est un pointeur sur le premier octet d'une ressource (binaire). Comment puis-je l'exécuter tout de suite sans le jeter dans un fichier temporaire?

HMODULE hLibrary; 
HRSRC hResource; 
HGLOBAL hResourceLoaded; 
LPBYTE lpBuffer; 

hLibrary = LoadLibrary("C:\\xyz.exe"); 
if (NULL != hLibrary) 
{ 
    hResource = FindResource(hLibrary, MAKEINTRESOURCE(104), RT_RCDATA); 
    if (NULL != hResource) 
    { 
     hResourceLoaded = LoadResource(hLibrary, hResource); 
     if (NULL != hResourceLoaded)   
     { 
      lpBuffer = (LPBYTE) LockResource(hResourceLoaded);    
      if (NULL != lpBuffer)    
      {     
       // do something with lpBuffer here    
      } 
     }  
    } 
    FreeLibrary(hLibrary); 
} 

Answer 1

Il n'y a pas de fonction intégrée à Windows pour cela; votre seule option est CreateProcess, qui prend un fichier EXE.

Il est possible d'analyser vous-même le format du fichier exécutable. Vous recréerez effectivement ce que fait la fonction LoadLibrary.

Voici une explication du chargement d'une DLL et des fonctions d'appel: http://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/. Pour l'adapter à votre EXE, vous devez suivre les mêmes étapes de transfert et d'importation. Une fois que vous avez terminé, vous appelez le point d'entrée du fichier EXE. (Le didacticiel explique comment appeler la fonction exportée d'une DLL.)

Selon le fichier EXE, vous pourriez avoir des problèmes pour le charger directement dans un processus existant. Par exemple, votre propre EXE exécute plusieurs codes d'initialisation Win32 et C, et l'EXE embarqué tentera probablement d'effectuer à nouveau la même initialisation. Si cela devient un problème, votre alternative est de mettre l'EXE intégré dans son propre processus; Ensuite, vous êtes de nouveau en train de créer un fichier temporaire et d'appeler le CreateProcess.

Answer 2

Si la ressource est un fichier PE, il n'y a aucun moyen AFAIK. Si c'est une simple procédure compilée, essayez l'astuce Tim.

Edit: Après la mise à jour de la réponse de Tim, il la réponse la plus complète.

Answer 3

Voilà diverses raisons pour lesquelles vous devez laisser le système d'exploitation gérer ceci:

• EXE ne peut pas simplement être chargé en mémoire puis exécuté immédiatement. Certaines tâches doivent être exécutées avant que l'exécution puisse commencer, par exemple en plaçant les segments en mémoire (y compris en installant la pile), puis en ajustant les références de mémoire dans les instructions de la machine à des emplacements mémoire spécifiques (peut-être dynamiquement) chargement des DLL), etc.

• Le format de fichier EXE de nos jours est en fait une multitude de formats, que vous devez tous connaître et gérer en conséquence. Il peut contenir du code exécutable pour DOS (ayant un en-tête MZ/ZM), pour Windows (PE — exécutable portable), ou pour .NET (également PE).

• nouveaux processeurs ont un sans bits d'exécution (google pour par exemple NX bit qui interdit essentiellement l'exécution de code qui réside dans un segment de données. Autrement dit, si vous chargez votre ressource binaire (qui contient le code) dans la mémoire, il résidera dans un segment de données. Si votre processeur a la fonction de bit NX, et le système d'exploitation utilise, vous ne serez pas autorisé à exécuter ce code.

pour toutes ces raisons (et probablement more), il est préférable de laisser le système d'exploitation gérer votre fichier EXE Dans le cas du mécanisme NX (ou similaire), vous n'avez pas d'autre choix, car Le système d'exploitation peut configurer des segments de code. Vous pouvez donc vous débarrasser des deux premiers problèmes mentionnés ci-dessus en choisissant un format exécutable moins puissant tel que .com, mais vous ne pouvez tout simplement pas vous débarrasser du mécanisme NX dans un programme en cours d'exécution dans l'espace utilisateur.