Voila, en gros je definit une fonction :
 

 
 
Maintenant, je voudrait copier le 'code' de cette fonction dans un buffer genre char[1024]. Et puis quand il est dans le buffer, l'executer. ( En fait, je le copie dans le buffer a travers le reseaux c pour pouvoir faire une application qui vas chercher ses propres modules )

Alors la, je comprends pas du tout ce que tu veux faire    
 
Pourquoi la copier dans un buffer ?

faire exploser la pile et exécuter du code **malicieux** ?  

Ben parce que j'ai deux ordis.
 
La fonctions je la tape et compile sur l'un même plutot avec de l'assembleur que du code C pour etre sur qu'il a a pas de dependences vers d'autre truc )
 
Et je doit l'envoyer et l'executer sur un autre PC

Non pour faire un buffer overflow, c pas a moi de lancer l'execution, j'aurai qu'a mettre le code en remplacant de l'ancien code executable.
 
 
Le but c d'avoir un prog qui peut downlaoder dynamiquement des extensions.

Ton truc, ça s'appelle du code auto-généré. C'est très en vogue dans le monde des démos, mais je vois mal l'utilité de ce genre de technique au quotidien, hormis pour faire mumuse avec SoftICE pour faire des trucs vilains  

ben c'est pas comme ca qu'on fait...  
windows ou unix ?

windows

dommage    
 
Fin d'une maniere ou d'une autre, quand tu veux utiliser des plugins, tu passes par des bibliothèques partagées, pas par de l'évaluation dynamique de code.
 
Une autre solution, c'est d'inclure un interpreteur dans ton programme et d'écrire les modules dans ce langage interprété. Ca peut se faire assez facilement avec des langages comme Python, Ruby ou Lua.

Mais tu fais fausse route...
Déjà, c'est pas sûr que l'OS permette d'exécuter des données qui ne sont pas dans une page exécutable.
Et même, c'est de la voltige sans filet.

Oui en effet j'ai remarqué ...
 
J'ai reuissi a le faire mais :
 - Faut ecrire le code en assembleur pour etre sur de sa taille et que les appel au api ne dependent pas de la place ou se trouve le code.
 - Faut fixer que le buffer doit etre dans une page executable

pour la page executable :
 
void* buffer = VirtualAlloc(0, TailleDuBuffer, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
 
memcpy(buffer, fun, Taille);
 
typedef void (funtype)();//type de la fonction
funtype* funptr= (funtype*)buffer;
funptr();//exécuter
 
au bout d'une longue série de test je suis arrivé a executer du code de cette maniere, mais c'est extrement dur : en effet, le code ne doit faire appel à aucun autre segment du fichier .exe (pas de segment de données, donc pas de chaines de caractères écrites en dur, pas de ressources, pas de relocation (on peut se débrouiller en appelant directement LoadLibraryA et GetProcAddress par leurs adresses directes, mais le code ne sera alors absolument pas portable : sur chaque version de win ces adresses diffèrent, et également le code à executer peut contenir des 'sauts' du moment qu'ils sont indiqués comme 'saut 3 octets plus bas', mais pas des sauts contenant une adresse (call))
 
(j'écris cela pour un but purement informatif)

Merci bcp

Dans du code source, cela correspond uniquement à un appel de fonction (ctor et operateurs C++ inclus), ou il y a d'autre situations ?

euh ... en général, un appel vers une fonction, si g bien compris, se code comme cela :
 
void MyFunc(void)
{
  // code
}
 
puis, à un endroit dans le code :
 
MyFunc();
 
cela se traduit par un call, mais l'argument de call est un certain nombre d'octets (nombre signé) qui indique la ou doit continuer l'execution.
 
un call avec une adresse, c'est en général pour une API (liée au linkage avec la table d'importation, ou appelée avec LoadLibrary/GetProcAddress)
 
Pour les operateurs C++, je suis désolé mais je ne connais pas bien le sujet, je cherche la dessus en ce moment

BlackGoddess a écrit a écrit : Pour les operateurs C++, je suis désolé mais je ne connais pas bien le sujet, je cherche la dessus en ce moment

Concrètement, ce sont des appels de fonctions déguisés.
Le mecanisme virtuel des classes peut ajouter 1 indirection + 1 indiçage + 1 indirection à l'appel.

lorsqu'on fait par exemple :
 
typedef class _myclass
{
   _myclass(void) {}
   int DoAnything(void) {return 0;}
} MyClass, *pMyClass;
 
puis à un endroit du code :
 
pMyClass MyObject = new MyClass;
 
MyClass est copié de son endroit original de la mémoire pour être exécuté ou c'est juste un "artifice" et en fait on appelle tjs les mm func, aux mm endroits ?

a quoi sert le typedef de MyClass??
 
je veux bien comprendre pour pMyClass,
mais la tu ne serais pas en train de faire
un mix inutile entre C++ et C?
 
de plus je crois comprendre que tu demandes si le code est duplique a chaque instance de MyClass
et je repondrai: heureusement que non parce qu'un  
objet de 1 octet qui compterait un million de lignes de code associees, ca poserait un petit probleme de memoire pour l'instancier plein de fois.  
 
tout ce qui est duplique par objet ce sont les donnees (les membres directs sans indirection) (et un pointeur vers la table virtuelle ou la table de type s'il y a lieu).
 
A+
LeGreg

On apelle toujours les mêmes fonctions.
C++ n'a pas de fonctions/code dynamiques, seulement des appels de fonctions dynamiques.
 
En C++, le typedef n'est plus nécessaire, et le (void) est implicite:

 
simple question, c quoi des pages executable ? (eg quand je fais un call sur un tableau alloué au malloc stdart, ca passe tres bien).  
 
 

 
Il faut que par defaut ce soit supporte par l'OS
et par le processeur.
Ca n'a aucun sens sous windows par exemple
ou sous linux.
 
Par contre ce dont l'OS protege en general
c'est contre les executable stacks
je n'ai pas entendu parler de protection
contre les executable heaps.
 
[OT]Tiens ca me rappelle que je viens de revoir Tron en
DVD. "vous ne pourrez plus executer de code en dehors
du Master Control Program. le Master control program sait ce qui est bon pour vous " [/OT]
 
LeGreg

 
enfin je veux dire que l'utilisation de la pile
pour les exploits etait relativement facile (pour un hacker)  
et proteger contre son execution n'a casse  
aucun programme existant,
par contre proteger le tas de l'execution
a une raison d'etre plus faible (c'est un peu plus
difficile a exploiter comme faille). Et cela risque effectivement
de casser un certain nombre de codes qui reposent la dessus et ne tiennent pas compte d'une eventuelle protection de l'OS.
 
LeGreg

tas = heap ?
et pile = (en anglais) ?
 
parce quer les API sur le sujet prennent les noms anglais, et chui perdu enter les 2 a chaque fois

stack

ah oui c vrai merci

page: bloc de mémoire tel que l'OS l'alloue.
executable: considéré comme contenant du code.
 
Comme c'est déjà dit, un OS pourrait très bien refuser l'exécution de code dans une page non déclarée exécutable, ou qu'il n'a pas lui-même marquée comme telle.
 
C'est le même principe appliqué aux pages read-only qui fait qu'on peut violer une constante globale sous Windows 9x et pas sous NT/2000/Xp.

viole, viole.. mais qui te dit qu'elle n'etait pas consentante ?
 
(la memoire )
 
LeGreg

char* msg = "bla !";
 
cela définit une constante ?????

voué

consentante... constante...
Tu m'as l'air bien parti, voici une friandise licencieuse: http://www-users.cs.york.ac.uk/~susan/joke/polly.htm
Celui qui arrive à le traduire est vachement fort... ou obsédé.
 
Les chaînes littérales sont des constantes, en toute logique il faudrait écrire:

La conversion en "char*" sera dépréciée, mais quand ?

bin ... déjà les maths en francais c pas mon truc ... mais alors en anglais ...