Appeler g++ depuis Qt

Version imprimable

2 pièce(s) jointe(s)

Bonjour,
Dans le cadre de mes études je souhaite développer un programme permettant de sélectionner un executable ou autre fichier, puis de faire un tableau d'octet contenant ce fichier. Ainsi, je pouvais l'afficher sous forme hexadécimale.
Exemple:
Pièce jointe 472535
Jusqu'ici tout fonctionnait, seulement, j'ai pour intention de modifier le contenu de ce tableau de fichier (ce qui reviendrait à modifier le programme), puis de recompiler le tout.
J'effectuait la compilation grâce à cette méthode:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 void Generator::compiler(QString output) { QString path = "C:/Users/user/Documents/Qt/test.cpp "; char cmd[500]; memset(cmd,0,sizeof (cmd)); strcat(cmd, "g++ "); strcat(cmd, path.toLocal8Bit()); strcat(cmd, "-o "); if(strcmp(output.toLocal8Bit(),"")==0){ strcat(cmd, "myGoodProg.exe"); } else { strcat(cmd,output.toLocal8Bit()); } system(cmd); }
Cependant, après de nombreux tests directement via console windows et en tapant la commande g++, je me suis aperçu de nombreuses erreurs liées aux librairies Qt.
Exemple:
Pièce jointe 472530

J'ai cru comprendre que du fait que cette compilation se faisait dans un environnement différent de Qt, les librairies associées n'étaient plus trouvées par le compilateur. J'ai donc essayé, tant bien que mal, de réduire l'utilisation de ces librairies un maximum. J'ai retapé certaines parties du code en C++ dont la lecture de mon fichier et je n'arrive plus à obtenir l'affichage du contenu du fichier sous forme hexadecimale.
De plus, je ne puits enlevé plus de librairie, celles restantes étant essentiel au fonctionnement de mon programme.

Existerait-il une solution pour passer les librairies Qt dans g++ ? J'ai essayé l'option -L sans grands succès.
En m'excusant si mon problème n'est pas suffisemment clair je ne poste pas fréquemment. Merci d'avance pour vos futures réponses.

07/05/2019, 14h00
koala01
Citation:

Envoyé par bebreizh

Bonjour,
Dans le cadre de mes études je souhaite développer un programme permettant de sélectionner un executable ou autre fichier, puis de faire un tableau d'octet contenant ce fichier. Ainsi, je pouvais l'afficher sous forme hexadécimale.
Exemple:
Pièce jointe 472535

Jusque là, pas de problème

Citation:

Jusqu'ici tout fonctionnait, seulement, j'ai pour intention de modifier le contenu de ce tableau de fichier (ce qui reviendrait à modifier le programme), puis de recompiler le tout.

Ca, par contre, c'est un très mauvais plan, et pour plusieurs raisons :aie:

D'abord, parce que tu es limité par la taille, non pas de ton tableau de byte, mais bien celle de l'interprétation faite par le processeur des différents bytes. Je m'explique:

Une application compilée, c'est :
1. différentes sections de données
2. une pile d'appels
3. le code exécuté par les différentes fonctions qui ont été codée
(je simplifie au maximum, en évitant les détails trop triviaux ;) )

Le code exécuté par les différente fonctions correspond quant à lui à:
- un certain nombre de byte (clairement défini) qui correspond à l'instruction exécutée par le processeur (et que l'on peut associer aux instruction "assembleur")
- un certain nombre de bytes correspondants à un "certain nombre de données" requises pour permettre au processeur d'effectuer l'instruction demandée
Le gros problème, c'est que chaque instruction requière un nombre de donnée qui lui est tout à fait spécifique :
- Certaines instructions n'ont besoin d'aucune donnée
- d'autres instructions en requièrent seulement une
- d'autres instructions en requièrent deux, ou trois, voir quatre.
Et, pour couronner le tout, il me semble que certaines instructions (comprises par le processeur, s'entend) acceptent "différents nombres" de données (parfois deux, parfois trois), selon le contexte.

Sans compter que certaines données correspondent à des registres, d'autres à des adresses mémoires, et d'autres encore correspondent "simplement" à des valeur numériques (entières ou réelles, selon le cas).

Enfin, bref : tout cela pour dire que, si tu vas modifier un byte quelconque dans une application, tu as très largement intérêt à savoir ce que tu fais, car cela peut très facilement rendre le programme totalement inutilisable :aie:

En outre, si j'étais de nature ne serait-ce qu'un tout petit peu suspicieuse, j'en viendrais immanquablement à m'interroger au sujet de ta bonne foi. Car, soyons clair dés le départ: ce que tu souhaites faire, c'est très souvent (j'hésite à utiliser le terme "toujours") associé à des pratiques illégales, comme la création de virus ou de cracks (comprends : la modification d'un programme de manière à contourner les restrictions mises en place pour inciter les gens à payer une licence).

Or, de telles pratiques sont absolument bannies sur ce forum, et susceptibles de sanctions pour ceux qui tenteraient de les promouvoir :aie:

Cependant, je décide de te laisser le bénéfice du doute, et croire que ce que tu veux en réalité, c'est permettre à ton application de se mettre à jour, mais que tu ne t'y prends simplement pas de manière correcte.

La manière "correcte" de s'y prendre consiste à "subdiviser" ton projet en différentes parties, de manière à fournir à son utilisateur plusieurs fichiers comme:
- un fichier exécutable pour lancer l'application
- une ou plusieurs "dll" qui fournissent les fonctionnalités spécifiques à certains aspects utilisés par l'application (ex: la gestion du son, la gestion des graphiques, la gestion de l'IA, que sais-je)
- un ou plusieurs types de fichiers "ressources" (exemple : des sons, des images, des données "3D", des animations, des scripts, que sais-je)
Ceci se fait dans le but que, si tu décides (te trouve dans l'obligation) de corriger le système de son, par exemple, tu puisse te contenter de générer une nouvelle version de la dll qui s'occupe de la gestion du son, et la fournir à l'utilisateur en remplacement de l'ancienne version, sans être dans l'obligation de lui transmettre l'ensemble de l'application. De même pour les fichiers ressources et / ou pour l'exécutable "de base".

Cela présentera en outre un très gros avantage pour toi, car cela t'obligera effectivement à clairement séparer ce qui n'a aucune raison d'être interdépendant, et cela facilitera donc énormément la maintenance à long termes ;)

Mais, du coup, si tu as "quelque chose" à corriger, ou pour lequel tu souhaites fournir une nouvelle fonctionnalité, tu peux travailler sur "la partie de l'application" qui a besoin d'être corrigée (ou pour laquelle tu souhaite ajouter une fonctionnalité), puis ne compiler à nouveau que cette partie, (ou sauvegarder des images, tes sons, tes animations, tes scripts), et ne transmettre que cette nouvelle version, ce qui te permettra de réduire énormément le volume de données à transmettre.

il "suffira" alors que ton application ait "quelque part" la liste des version des différents fichiers qu'elle utilise à un instant T, de lui permettre de récupérer la liste des "dernières versions" proposées de ces fichiers, de faire en sorte que ton application soit en mesure de déterminer quels fichiers locaux sont obsolètes (d'une version antérieure à celle qui est disponible), et de lui faire télécharger la dernière versions des fichiers ainsi trouvés, de manière à ce qu'elle puisse remplacer la version locale par la dernière version obtenue ;)
07/05/2019, 14h39
bebreizh

Avant tout, merci beaucoup pour cette réponse rapide et riche d'informations.

Citation:

La manière "correcte" de s'y prendre consiste à "subdiviser" ton projet en différentes parties, de manière à fournir à son utilisateur plusieurs fichiers comme:
un fichier exécutable pour lancer l'application
une ou plusieurs "dll" qui fournissent les fonctionnalités spécifiques à certains aspects utilisés par l'application (ex: la gestion du son, la gestion des graphiques, la gestion de l'IA, que sais-je)
un ou plusieurs types de fichiers "ressources" (exemple : des sons, des images, des données "3D", des animations, des scripts, que sais-je)

J'ai déjà tenté de "subdiviser" le projet en plusieurs fichiers distincts mais sans résultat concluants (m'y serais-je mal pris ?). Une solution me semblait cohérente, est-il possible de demander à G++ d'intégrer les librairies de Qt ? Je précise que dans mon cas, je code avec Qt Creator et donc l'exécutable est générer automatiquement pour l'application disons "GUI/IHM". Cette application quand à elle appelle une seconde fonction de compilation présentée dans mon précédent poste pour compiler d'autre fichiers et créé un second exécutable indépendant (je ne suis pas sûre d'être plus clair).

Pour ne rien cacher, mon mémoire porte en effet sur un sujet plutôt sensible quant à la manipulation d'un exécutable. Je suis dans une école de cyber sécurité et donc mon mémoire doit porter sur cet aspect cyber. La méthode que j'étudie ici est celle du runPE.
Tes explications sont intéressantes, mais ne portent donc pas forcément sur le bon sujet. S'il n'est pas possible de répondre pour des raisons que je comprends parfaitement, serait-il néanmoins possible d'avoir une piste en privé ? Ce projet est simplement réalisé dans un but éducatif, je ne tiens donc pas à risquer un bannissement sur le site si j'en parle trop.
08/05/2019, 22h44
koala01

Citation:

Envoyé par bebreizh

J'ai déjà tenté de "subdiviser" le projet en plusieurs fichiers distincts mais sans résultat concluants (m'y serais-je mal pris ?).

Très certainement :aie:

J'étais parti sur toute une dissertation concernant l'approche MVC, mais, comme elle nous écarterait du problème actuel, je ne crois pas qu'elle soit vraiment utile ;)

Citation:

Une solution me semblait cohérente, est-il possible de demander à G++ d'intégrer les librairies de Qt ? Je précise que dans mon cas, je code avec Qt Creator et donc l'exécutable est générer automatiquement pour l'application disons "GUI/IHM". Cette application quand à elle appelle une seconde fonction de compilation présentée dans mon précédent poste pour compiler d'autre fichiers et créé un second exécutable indépendant (je ne suis pas sûre d'être plus clair).

A partir du moment où tu récupère un ensemble de bytes à partir d'un fichier binaire, il n'y a -- à mon sens du moins -- rien qui ne t'empêche de maintenir cet ensemble de byte dans la collection "qui va bien" (un std::vector, par exemple), afin de pouvoir modifier les bytes "à ta bonne convenance" avant de les enregistrer à nouveau sous forme de fichiers binaire.

Tu n'as, à mon sens, absolument aucun besoin d'avoir recours à Gcc.

Le seul cas qui pourrait poser problème serait le fait que le programme vérifie lui-même sa propre somme de hashage (quelle qu'en soit la forme) lors du lancement, surtout si elle est enregistrée en dur dans le programme, car il faudrait arriver à répercuter le changement occasionné par les modifications de manière satisfaisante

Cependant, je ne crois sincèrement pas qu'il soit possible pour un programme d'avoir, dans une de ses sections, la valeur de sa propre clé de hashage (mais je suis pas particulièrement au fait de ce point :aie:), et je présume qu'elle serait plutôt fournie, sous une forme ou une autre, dans un fichier séparé ;)

Citation:

Pour ne rien cacher, mon mémoire porte en effet sur un sujet plutôt sensible quant à la manipulation d'un exécutable. Je suis dans une école de cyber sécurité et donc mon mémoire doit porter sur cet aspect cyber.

Oui, mais, quant tu auras tout dit, je saurai tout :D

Citation:

La méthode que j'étudie ici est celle du runPE.

C'est une méthode que je ne connaissais absolument pas juqu'à il y a quelques minutes ;)

Mais, recherche faite, je te confirme que tu n'as absolument pas besoin de recourir à Gcc pour la mettre en oeuvre ;)

Citation:

Tes explications sont intéressantes, mais ne portent donc pas forcément sur le bon sujet.

Ben non, mais, en même temps, comment aurait il pu en être autrement avec les informations que j'avais, sachant que tu es sur un forum tout à fait généraliste, et non sur un forum dédié aux crackers ou à la cyber-sécurité :question:

Citation:

S'il n'est pas possible de répondre pour des raisons que je comprends parfaitement, serait-il néanmoins possible d'avoir une piste en privé ? Ce projet est simplement réalisé dans un but éducatif, je ne tiens donc pas à risquer un bannissement sur le site si j'en parle trop.

Je le ferais volontiers si c'était du domaine de mes compétences. Mais ce n'est déjà pas le cas, donc, je ne te serai d'absolument aucune aide ;)

Peut être que d'autres seront d'avantage en mesure de t'aider sur ce coup là ...

Ceci dit, je ne crois pas que la simple étude (surtout surtout si elle est justifiée) de la technique provoquerait ton bannissement (essaye quand même d'avoir l'avis d'un modérateur en fonction à ce sujet). Au pire, le sujet sera modéré, ce qui provoquera sa disparition (temporaire ou définitive) du forum ;)
09/05/2019, 15h12
bebreizh

1 pièce(s) jointe(s)

Je te remercie beaucoup pour tes réponses. :D
Je me contenterais d'un dernier post (sait-on jamais si ça peut aider)

Citation:

C'est une méthode que je ne connaissais absolument pas jusqu’à il y a quelques minutes

Mais, recherche faite, je te confirme que tu n'as absolument pas besoin de recourir à Gcc pour la mettre en oeuvre

Dans mon cas, j'ai souhaité utiliser Qt Creator pour créer simplement une interface graphique plus "jolie" à présenté pour le mémoire. Une version de base se contentait de plusieurs fichiers en C/C++.
Cette version générait finalement un exécutable en compilant avec G++.
Qt Creator se charge très bien de la compilation mais uniquement pour l'aspect Qt Creator et donc l'IHM. Donc, tandis que je souhaiterais un fichier peGenerator.exe qui me sort à la suite un executableTest.exe, je n'ai que le premier.
Une seconde solution me viens, j'ai ici mes fichiers faisant partis d'un seul et même projet:
Pièce jointe 473473

Est-ce que en séparant en deux différents projets le packer et le peGenerator, cela pourrait régler le problème de la seconde compilation réalisé par la fonction dans peGenerator ?
Le packer interviendrait donc comme une librairie inclut dans peGenerator.

Encore merci pour toutes ces réponses, j'en apprend beaucoup ;)
09/05/2019, 18h07
koala01

Sous Qt, tu devrais peut-être t'intéresser à la notion de fichier ressources, car il y a deux éléments à prendre en compte :

le premier est le programme qui s'occupera de l'injection (qui contient une fonction main, et qui doit être compilée), et, de l'autre, tu as ... le fichier qui contient les données à injecter (qui est, typiquement, un exécutable "patché" ou non) qui sert de ressources.

Tu auras, effectivement, besoin de Gcc pour compiler ta foncton main (et toutes les fonctions connexes, bien entendu), mais c'est ton "ressource compiler" (rcc) qui se chargera de fournir les ressources utilisées.

L'énorme avantage, c'est que, aussi longtemps que tu gardera le même nom pour le fichier contenant les données d'injections, il te "suffira" de recompiler les ressources (et d'appliquer l'ensemble des étapes qui suivent cette recompilation et qui mènent à la création d'un exéctuable fini).

Mais, sauf erreur de ma part, cela devrait se limiter à l'édition de liens ;)
10/05/2019, 09h48
bebreizh

Je vois, merci beaucoup pour cette réponse ca m'éclaire.
J'avais en effet oublié cet aspect et vais tenter d'approfondir vers cette direction. ;)