Désolé je suis conscient que j'étais un peu vague, j'étais trop plongé dans mon projet quand j'ai écris ce post.
Alors dans l'ordre :
> en effet, tu parles de l’exécution du binaire on peut donc en déduire que c'est un langage compilé
Oui je parle d'un fichier compilé (elf), donc en langage machine (opcode). Pour moi l’interpréteur est le "logiciel" qui lance l'exécutable (commande ./). Si je fais une erreur de sémantique, peux-tu me donner les termes correctes ?
dis nous plus précisément ce que tu fais et avec quel langage, on aura peut-être des pistes pour t'aiguiller.
Donc en gros je récupère un fichier binaire, compilé dans un langage compilé (c, c++...), je le modifie avec un script python pour y injecter du code, en modifiant les sections, segments pour garder la structure du fichier elf. Cette partie fonctionne très bien.
J'aurai bien vu un chargement en memoire le binaire réel généré par le binaire executable et le lancer dans un processus fils tout connement ?? (genre donnée encapsulée dans le binaire executable)...
un peu comme quand on codait des 4kdemos avec vidéos sur atari...
Oui, c'est vers cela que je vais me diriger, mais j'avais envie de comprendre dans les détails pourquoi ma première idée ne fonctionne pas.
Tu modifies tes opcodes de quelle façon ?
Je modifie directement les opcodes chargé en ram.
Ça dépend aussi de ce que tu utilises pour modifier ton fichier. Si c'est un fwrite() ou un fprintf() en C standard, alors tout ce que tu vas écrire va aller dans un tampon propre à ton processus, et l'appel système qui va effectivement modifier le fichier n'aura lieu que plus tard
Je modifie directement le fichier avant l'exécution.
En résumé :
1. Je reçois un fichier binaire compilé
2. Je le patch (chiffrement + modification du point d'entrée, ajout de la méthode de déchiffrement)
3. Lorsque j'exécute le fichier, il est chargé en mémoire et ma routine de déchiffrement prend le relais pour aller modifier les opcodes chargés en mémoire. (Cela fonctionne aussi)
Tout cela dépend donc de beaucoup de points différents, surtout quand on tient compte du fait que le système est en principe conçu pour que ce genre de manip' soit interdite. Donc, il ne faut pas s'attendre à ce que les choses soient faciles.
Justement j'essaie de me documenter sur les limitations que le système met en place ;).
# complément d'informations
Posté par manticore . En réponse au message Fonctionnement interpreteur linux. Évalué à 1.
Désolé je suis conscient que j'étais un peu vague, j'étais trop plongé dans mon projet quand j'ai écris ce post.
Alors dans l'ordre :
> en effet, tu parles de l’exécution du binaire on peut donc en déduire que c'est un langage compilé
Oui je parle d'un fichier compilé (elf), donc en langage machine (opcode). Pour moi l’interpréteur est le "logiciel" qui lance l'exécutable (commande ./). Si je fais une erreur de sémantique, peux-tu me donner les termes correctes ?
Donc en gros je récupère un fichier binaire, compilé dans un langage compilé (c, c++...), je le modifie avec un script python pour y injecter du code, en modifiant les sections, segments pour garder la structure du fichier elf. Cette partie fonctionne très bien.
Oui, c'est vers cela que je vais me diriger, mais j'avais envie de comprendre dans les détails pourquoi ma première idée ne fonctionne pas.
Je modifie directement les opcodes chargé en ram.
Je modifie directement le fichier avant l'exécution.
En résumé :
1. Je reçois un fichier binaire compilé
2. Je le patch (chiffrement + modification du point d'entrée, ajout de la méthode de déchiffrement)
3. Lorsque j'exécute le fichier, il est chargé en mémoire et ma routine de déchiffrement prend le relais pour aller modifier les opcodes chargés en mémoire. (Cela fonctionne aussi)
Justement j'essaie de me documenter sur les limitations que le système met en place ;).
Merci de votre aide