Buffer overflow et shellcodes sous Win

Bon déjà bonjour à tous.

J'espère que ce topic ne sera pas "censuré" en raison de son caractère quelque peu "tangent" au niveau de la sécurité informatique...

Quoi qu'il en soit, j'espère que vous comprendrez que je ne suis ici que pour comprendre le sujet que j'ouvre, et non pour profiter de failles quelconque (surtout que les BOF commencent àêtre dépassés...)

Bref, trève de parlementations superflues, j'ai une question à poser sur ces BOF ( Ha ! enfin !). La voici :
Bien prenons un prog vulnérable basique avec une instruction gets(), tout simplement...

Alors on fait un overflow c'est bien joli, mais on voit souvent qu'il faut remplacer l'adresse de retour de eip par une adresse pointant sur une instruction "jmp esp" contenue dans une dll déjà chargée.

Alors
1) J'ai beau fouiller les dll kernel32, user32,ect... ben rien à faire, je trouve pas ; que je sois sous XP ou Win98...

2) Ensuite, ya t'il une autre manière, c'est à dire, de mettre une adresse qui pointerait directement sur notre buffer... Comment en connaître l'adresse ???
 
Voilà donc deux questions que google n'a pu répondre, on dirai que les shellcodes sont assez mis en veilleuse...
Si vous pouvez m'aider, je vous en serait reconnaisant....

Merci !

il faut remplacer l'adresse de retour de eip par une adresse pointant sur une instruction "jmp esp" contenue dans une dll déjà chargée

non, pas forcément

si tu contrôles eip, tu peux peut-être directe le faire pointer vers l'adresse de ton shellcode en mémoire par exemple ...

Comment en connaître l'adresse

mais, c'est tout l'art du débugage !

Ok pour le debugage, quand t'es en local, pas bien compliqué... Mais si on est en remote, l'adresse de esp (par exemple) de sera pas forcément toujours la même... J'en déduis qu'on ne peut la connaitre autrement et qu'en remote la seule solution reste "jmp esp". Merci en tous cas. Bye

salut,

plutot que de rechercher jmp esp, recherche la suite d'octet de cette operande.
tu auras peut-etre plus de chance...

@++

a seule solution reste "jmp esp"
non
regarde des exploits si tu veux en savoir plus ...

Pour trouver "jmp esp" dans les dll j'ai trouver un prog super pratique : findjmp.

Pour ce qui est des exploits, j'irai chercher sur google... merci en tous cas !

re, push esp; ret; c bon aussi:54h,C3h je ne sais pas si findjmp pense à rechercher d'autres combinaisons. un programme similaire serait simple a faire. mapper la dll rechercher section code calculer la position files de section code rechercher dans section code les différentes chaines utilisables si trouvé convertir la position file en adresse:base section + offset file et afficher les résultats unmapper la dll la solutions pourrait etre de placer les dll en mémoire de manière aléatoire le jmp esp n'est alors plus utilisable. Avec un serveur sensible, il serait intéressant d'améliorer le Peloader. @++