Interpreteur binaire linux

Bonjour,

pour un projet je dois effectuer un chiffrement sur un fichier binaire. Je chiffre donc mon fichier et j'injecter mon code de déchiffrement, celui-ci effectue bien le déchiffrement (un simple xor).

Cependant, lors de l’exécution l'interpreteur (./helloworld), me renvoie une erreur :

Code:

---

illegal instruction

---

Ce qui arrive évidemment car les instructions chiffrées ne représente plus des instructions valides.

Je me suis mis en tête de contourner cette restriction. Pour cela j'insère une interruption (exit), que je modifie ensuite dynamiquement en une interruption inutile.

Malheureusement je n'arrive pas à tromper l’interpréteur, car celui-ci détecte ma modification.

J'ai remarqué un point intéressant :
- Le processeur charge des blocs d'instruction en mémoire (en cache), donc je dois effectuer la modification avant le chargement du bloc.

Je voulais savoir si l'interpréteur linux faisait de même (j'en suis convaincu ;) ), et surtout si il le fait utilise-t-il le processeur ? Ou s'agit-il d'un logiciel de check interne, donc qui peut avoir une configuration différente ou que je peux tenter de tromper.

Je voulais savoir si vous aviez de la documentation sur le sujet.

J'espère avoir été clair sur ce sujet relativement complexe, et je suis disponible pour tout renseignement supplémentaire.

merci d'avance de votre aide

p.s. Je travaille sur :

OS : Linux armadeus 2.6.29.6
Support matériel : APF27

j'aurai plutot pensé faire carrement autrement, faire un binaire autoextracteur style compression+encryptage qui copie un bin en mémoire adressée et l'execute ça ralentit le démarrage de l'appli mais ca marche du coup puisque le code interpreté est "lisible" nativement

comme ça tu travailles qu'en memoire et donc le code "executé" n'est jamais visible par l'utilisateur ni un bot...a moins de faire un dump de toute la ram pile poil au bon moment entre la copie et l'execution, et encore savoir qu'il y a un truc interessant dedans et savoir a quelle adresse etc....bref quasi impossible...

Oui c'est sur quoi je vais me rabattre si je n'arrive pas à gagner ma lutte avec l’interpréteur linux. Par contre le quasiment impossible, je ne suis pas d'accord, les packers demande un minimum de connaissance, mais ils sont largement dumpable ;=)

[EDIT] L'exécutable livré est bien sur entre les mains de l'utilisateur, je travaille sur la mise en place de protection anti Reverse-engeneering. Dans ce cas la faire un dump n'est pas excessivement difficile.

je dis pas que c'est pas dumpable je dis qu'il faut etre déjà sur la bonne machine, et au bon moment, etc...ETc...etc... et même si tu as tout ça il faut encore savoir quoi chercher..... donc .... la probabilité est a peut pres celle de gagner au loto quoi :)

bien sur ca restera eternellement possible tant que l'humain existera.... mais bon il suffit d'éliminer la menace... genre le 21/12/2012 vers 21H30....:ccool:

C’est normal que je ne comprenne pas un mot de cette affaire ? Interpréteur linux ? Mais de quoi parlez-vous ?
Si un code est lancé, il n'y a pas d'interpréteur. Le code binaire n'est pas interprété, il est exécuté directement par le processeur (à quelques subtilités prêts quand même) : soit il est conforme, soit il ne l'est pas.
Si vous parlez du shell, le shell ne fait pas de vérification du code, ni le noyau d'ailleurs. Un code qui fait une illegal instruction émet un code SIGILL et plante. On peut capturer un SIGILL pour faire ce qu'on veut, mais c'est à l'intérieur de helloworld qu'il faut faire le boulot, pas ailleurs.

Citation:

---

Si vous parlez du shell, le shell ne fait pas de vérification du code, ni le noyau d'ailleurs. Un code qui fait une illegal instruction émet un code SIGILL et plante. On peut capturer un SIGILL pour faire ce qu'on veut, mais c'est à l'intérieur de helloworld qu'il faut faire le boulot, pas ailleurs.

---

J'aurai dis pareil en premier temps, mais j'ai pas l'impression que cela se passe vraiment comme ça.

Voila les tests que j'ai réalisé et pourquoi je pense qu'il y a une couche de test avant exécution :

- Si je lance mon programme dans gdb il effectue bien le travail, pas de SIGILL
- Si je trace pas a pas avec IDA-PRO, il effectue bien le travail que je lui demande (dechiffrement de mes opcodes).

Mais je vais quand même faire un dernier test, je vais écrire sur la sortie standard avant ma routine de déchiffrement, si il affiche quelques chose c'est qu'il n'y a pas de pré-analyse et que je foire à quelque part d'autre.

J'ai déjà eu des programmes qui marchait dans gdb et pas ailleurs. C'était du au fait que dans gdb les variables étaient initialisées par défaut à 0.
Après, c'est compliqué d'en dire plus.

J'ai trouvé pourquoi j'avais ce problème, cela vient de l'architecture du processeur ARM.

Il est basé sur un Harvard modifié et non un Von Neumann comme sur Intel. Dans notre cas on s'intéressera à la différence dans la gestion du cache. Car il n'y a pas un cache mais deux différents, et chacun d'entre eux s'occupe d'un type de données :

Le premier les datas
Le second les instructions

Ainsi même lorsque j'essayais de charger mon cache, je ne le faisais que pour les instructions. Il est possible de le faire pour les datas (c'est une méthode très sale, peu portable et lente mais ça marche).

Le mieux est de faire appel à la méthode de gcc :

Code:

---

void __clear_cache(char* beg, char* end);

---

Un article de référence sur le sujet :
http://blogs.arm.com/software-enable...odifying-code/

Félicitations ! Rien d'évident dans des problèmes d'architectures de ce type !