Salut, mes se qui nous pose soucis dans le cas d'un mitm c'est que si tu intercepte les packet transitant vers les serveurs tu ne peut en aucun cas bloquer un packet ou le modifier? ou je me trompe. Car se système est bien pour un packet sniffer mes pour un bot mitm non, peut être que je me trompe car moi j'ai utiliser un wrapper de pcap pour je puis en c# récupéré les packets transitant entre le client -> serveur dofus.
Bases pour faire un MITM en Python (+MacOS)
- Auteur de la discussion Labo
- Date de début
@tifoux Je pense que tu t'en fiches de ne pas pouvoir bloquer ou modifier les paquets envoyés par le client, car le client te sert à ne pas avoir à gérer tous les messages (principal intérêt du bot MITM sur le full socket). Ton bot sert uniquement à envoyer des messages en plus en se faisant passer pour le client (ou alors je me trompe sur toute la ligne) et à lire ceux reçus.
D'ailleurs, est-ce qu'@nkama ne pourrait pas envisager pour bloquer les MITM une vérification par le client des paquets envoyés pour détecter la réponse à un paquet qui aurait été envoyé non pas par lui, mais par le MITM ?
@Munrek Je ne comprends pas la (subtile) différence entre et mais un bot brut va lui-même injecter une DDL (ou autre) alors que le proxy socks ne peut pas le faire tout seul, c'est ça ?
P.S. : @tifoux je pense que un wrapper pcap n'est pas une bonne solution car les paquets ne transitent plus par ton bot et qu'il ne peut plus alors émettre sur le même flux, mais je ne suis pas sûr...
D'ailleurs, est-ce qu'@nkama ne pourrait pas envisager pour bloquer les MITM une vérification par le client des paquets envoyés pour détecter la réponse à un paquet qui aurait été envoyé non pas par lui, mais par le MITM ?
@Munrek Je ne comprends pas la (subtile) différence entre et mais un bot brut va lui-même injecter une DDL (ou autre) alors que le proxy socks ne peut pas le faire tout seul, c'est ça ?
P.S. : @tifoux je pense que un wrapper pcap n'est pas une bonne solution car les paquets ne transitent plus par ton bot et qu'il ne peut plus alors émettre sur le même flux, mais je ne suis pas sûr...
si le wrapper pcap (en fait un sniffer) est dans le bot (comme ici : http://pylibpcap.sourceforge.net/) les paquets passent bien par le bot 
, par contre j'ai jamais reussi (ni jamais trop cherché) a injecter des paquets dans pcap , la seule fois que j'avais essayé j'avais l'impression que pcap etait en "lecture seule" , mais bon c'etait sous windows en basic et forcement avec une autre librairie
, par contre j'ai jamais reussi (ni jamais trop cherché) a injecter des paquets dans pcap , la seule fois que j'avais essayé j'avais l'impression que pcap etait en "lecture seule" , mais bon c'etait sous windows en basic et forcement avec une autre librairiewinpcap peu etre pas et pour apple tout ce qui commence par "win" c'est pas terrible , on parle de pcap , lui il peut injecter : http://www.opensource.apple.com/source/ ... cap/pcap.h
tuto : une fois la fenetre ouvert appuyer sur f3 et taper :
pcap_inject
ou
pcap_sendpacket
:mrgreen:
pcap_inject
ou
pcap_sendpacket
:mrgreen:
@tifoux mais c'est possible avec pcap apparemment.
Vous avez pas répondu à mes questions !
Bon, sinon, j'ai trouvé socket (à utiliser avec select) ou alors socketserver comme bibliothèques sympa pour un serveur TCP.
Mais ce que je ne comprends pas, c'est si ça va marcher puisqu'on parlait de serveur socks.
J'ai par contre au moins réussi à adapter pour m'amuser mon chat en python pour qu'on puisse se parler en TD d'Info
Vous avez pas répondu à mes questions !
Bon, sinon, j'ai trouvé socket (à utiliser avec select) ou alors socketserver comme bibliothèques sympa pour un serveur TCP.
Mais ce que je ne comprends pas, c'est si ça va marcher puisqu'on parlait de serveur socks.
J'ai par contre au moins réussi à adapter pour m'amuser mon chat en python pour qu'on puisse se parler en TD d'Info
A
On a été plus que patients avec toi il me semble ... que tu ne comprenne pas ok mais soit poli au moins.
Non.
Si tu as vraiment besoin d'une bibliothèque pour faire ça en plus de ce qui est déjà fourni dans la lib de base de python, je crois que tu n'as pas compris grand chose à la communication réseau.
SOCKS est un protocol de négociation de proxy, rien à avoir avec un socket ...
Non.
Labo a dit:
Bon, sinon, j'ai trouvé socket (à utiliser avec select) ou alors socketserver comme bibliothèques sympa pour un serveur TCP.
Mais ce que je ne comprends pas, c'est si ça va marcher puisqu'on parlait de serveur socks.
J'ai par contre au moins réussi à adapter pour m'amuser mon chat en python pour qu'on puisse se parler en TD d'Info
Mais ce que je ne comprends pas, c'est si ça va marcher puisqu'on parlait de serveur socks.
J'ai par contre au moins réussi à adapter pour m'amuser mon chat en python pour qu'on puisse se parler en TD d'Info
SOCKS est un protocol de négociation de proxy, rien à avoir avec un socket ...
Ah désolé que tu l'aies mal pris ! Il est dur de faire ressentir le ton d'une phrase à travers un clavier
socket et select SONT dans la bibliothèque de base de python ! Mais socketserver permet de moins s'embêter à manipuler les threads (qui ne servent pas pour le bot, mais pour mon client de chat multi-utilisateurs, mais c'est du hors-sujet).
J'ai à peu près tout compris sur les sockets TCP et j'ai pas mal feuilleté pour l'instant le Pujolle (et je n'y ai rien vu sur les proxy SOCKS ou sur le protocole, désolé).
En plus, depuis le début, je ne comprends pas le rapport entre les protocole SOCKS et D@fus !
D'accord MITM~Proxy~SOCKS donc c'est relié, mais pourquoi utiliser SOCKS ? A priori, c'est utilisé par une application pour communiquer avec le proxy. Mais si on redirige le traffic socket de l'application vers le MITM et qu'on renvoie les sockets vers le serveur et vice-versa, je ne vois pas le rapport avec le protocole SOCKS.
socket et select SONT dans la bibliothèque de base de python ! Mais socketserver permet de moins s'embêter à manipuler les threads (qui ne servent pas pour le bot, mais pour mon client de chat multi-utilisateurs, mais c'est du hors-sujet).
J'ai à peu près tout compris sur les sockets TCP et j'ai pas mal feuilleté pour l'instant le Pujolle (et je n'y ai rien vu sur les proxy SOCKS ou sur le protocole, désolé).
En plus, depuis le début, je ne comprends pas le rapport entre les protocole SOCKS et D@fus !
D'accord MITM~Proxy~SOCKS donc c'est relié, mais pourquoi utiliser SOCKS ? A priori, c'est utilisé par une application pour communiquer avec le proxy. Mais si on redirige le traffic socket de l'application vers le MITM et qu'on renvoie les sockets vers le serveur et vice-versa, je ne vois pas le rapport avec le protocole SOCKS.
Merci beaucoup, maintenant j'ai encore mieux compris le fonctionnement de SOCKS (j'ai pas lu les passages sur le UDP).
Mais j'ai toujours pas compris l'utilisé du protocole SOCKS. Maintenant j'ai compris comment ça fonctionnait (pourquoi c'était suffisant), mais pas pourquoi c'était nécessaire.
J'ai trouvé une autre solution pour socksifier les applications sous linux (et sûrement sur Mac OSX) : http://taz.newffr.com/TAZ/Coding/C_C++/ ... /socks.txt.
J'ai une autre question : comment à partir de ça on gère le multi-compte ? Je veux dire, si on n'utilise pas SOCKS, et qu'on intercepte juste à la volée les sockets, on peut pas vraiment les réémettre, vu qu'il n'y aura plus la séparation des connexions ? Si c'est pour ça qu'on utilise SOCKS, alors j'ai tout compris !
Autre question : ça veut dire que la DLL de Sorrow redirige aussi le trafic vers un serveur SOCKS en local ?
Je suis vraiment désolé de ne pas comprendre...
Mais j'ai toujours pas compris l'utilisé du protocole SOCKS. Maintenant j'ai compris comment ça fonctionnait (pourquoi c'était suffisant), mais pas pourquoi c'était nécessaire.
J'ai trouvé une autre solution pour socksifier les applications sous linux (et sûrement sur Mac OSX) : http://taz.newffr.com/TAZ/Coding/C_C++/ ... /socks.txt.
J'ai une autre question : comment à partir de ça on gère le multi-compte ? Je veux dire, si on n'utilise pas SOCKS, et qu'on intercepte juste à la volée les sockets, on peut pas vraiment les réémettre, vu qu'il n'y aura plus la séparation des connexions ? Si c'est pour ça qu'on utilise SOCKS, alors j'ai tout compris !
Autre question : ça veut dire que la DLL de Sorrow redirige aussi le trafic vers un serveur SOCKS en local ?
Je suis vraiment désolé de ne pas comprendre...
je vais commencer par la 2 ieme question : non pas besoin , le client (le bot) se connecte au serveur distant officiel , jusque la c'est simple , le bot fait semblant d'etre le jeu et il dit au serveur "hey je suis le jeu , depeche toi de me connecter j'ai un donjon bouftous a faire avec ma guilde de THL" , le serveur lui repond "ok tout se passe bien dans le meilleur des mondes" , pas besoin du jeu on peu le desinstaller
maintenant un MITM , c'est exactement la meme chose , il se connecte au serveur officiel en disant la meme chose , le serveur lui repond "ok tout va bien dans le meilleur des mondes des 7 meme si c'est plus du tout le monde des 7 mais des 10 ou 12 je sais plus" , jusque la c'est exactement pareil , le bot est connecté au serveur et tout se passe bien dans le meilleur des mondes. (coté bot <=> serveur officiel pas besoin de rediriger quoi que ce soit , la DLL s'occupe pas de ca)
le petit truc en plus c'est que le MITM il a besoin du jeu donc c'est un bot normal (qui fait comme au dessus) mais avec en plus un serveur en local , jusqu'au mois dernier (ou celui d'avant , on va dire l'année derniere) il suffisait de changer la config du jeu pour lui dire "arrete de te connecter sur le serveur officiel , connecte toi plutot en local sur mon joli serveur de MITM" et ca rouler comme ca , pas de probleme.
on en arrive a la grosse question (et la suite de la 2ieme) :
puis ank@ma s'est dit un jour "oh mais n'importe qui peu se connecter sur n'importe quel serveur (local ou privé) sans passer par chez nous donc sans s'abonner chez nous (dans le cas d'un serveur privé) , on va bloquer le truc qui sert a configurer le jeu , et voila tout le monde sera obligé de passer par notre serveur. hahahaha on est trop malins"
du coup aujourd'hui on est obligé de passer par des magouille pour "attraper" la communication pour nous et pas la faire passer par le cable ethernet comme on peu plus configurer le jeu pour qu'il se connecte ou on a envie , c'est ca le gros probleme et c'est a ca que sert la DLL , "attraper" ce qui sort du jeu et seulement a ca , c'est juste ca que tu dois faire en passant par les sockets ou par de la magie noire , enfin peu importe du moment que le jeu se connecte chez toi sur le serveur du MITM (ou a l'exterieur sur un serveur privé) et pas a l'exterieur sur un serveur officiel ca c'est le MITM (le client) qui le fera.
maintenant un MITM , c'est exactement la meme chose , il se connecte au serveur officiel en disant la meme chose , le serveur lui repond "ok tout va bien dans le meilleur des mondes des 7 meme si c'est plus du tout le monde des 7 mais des 10 ou 12 je sais plus" , jusque la c'est exactement pareil , le bot est connecté au serveur et tout se passe bien dans le meilleur des mondes. (coté bot <=> serveur officiel pas besoin de rediriger quoi que ce soit , la DLL s'occupe pas de ca)
le petit truc en plus c'est que le MITM il a besoin du jeu donc c'est un bot normal (qui fait comme au dessus) mais avec en plus un serveur en local , jusqu'au mois dernier (ou celui d'avant , on va dire l'année derniere) il suffisait de changer la config du jeu pour lui dire "arrete de te connecter sur le serveur officiel , connecte toi plutot en local sur mon joli serveur de MITM" et ca rouler comme ca , pas de probleme.
on en arrive a la grosse question (et la suite de la 2ieme) :
puis ank@ma s'est dit un jour "oh mais n'importe qui peu se connecter sur n'importe quel serveur (local ou privé) sans passer par chez nous donc sans s'abonner chez nous (dans le cas d'un serveur privé) , on va bloquer le truc qui sert a configurer le jeu , et voila tout le monde sera obligé de passer par notre serveur. hahahaha on est trop malins"
du coup aujourd'hui on est obligé de passer par des magouille pour "attraper" la communication pour nous et pas la faire passer par le cable ethernet comme on peu plus configurer le jeu pour qu'il se connecte ou on a envie , c'est ca le gros probleme et c'est a ca que sert la DLL , "attraper" ce qui sort du jeu et seulement a ca , c'est juste ca que tu dois faire en passant par les sockets ou par de la magie noire , enfin peu importe du moment que le jeu se connecte chez toi sur le serveur du MITM (ou a l'exterieur sur un serveur privé) et pas a l'exterieur sur un serveur officiel ca c'est le MITM (le client) qui le fera.
D'accord je pense avoir bien compris, j'avais en fait du mal à comprendre le principe du SOCKS qui n'est qu'un artifice qu'on utilise pour attraper le traffic. Merci
Mais qu'en est-il du multi-compte ? Il y aura plusieurs instances du serveur SOCKS qui vont tourner en même temps ?
Au cas où quelqu'un voudrait aussi programmer un bot en Python, voici le lien le plus utile pour comprendre 1° Les Sockets 2° Les Threads : http://python.developpez.com/cours/TutoSwinnen/?page=page_20#L18.
Mais qu'en est-il du multi-compte ? Il y aura plusieurs instances du serveur SOCKS qui vont tourner en même temps ?
Au cas où quelqu'un voudrait aussi programmer un bot en Python, voici le lien le plus utile pour comprendre 1° Les Sockets 2° Les Threads : http://python.developpez.com/cours/TutoSwinnen/?page=page_20#L18.
J'ai une autre question !
Même si j'ai presque fini mon serveur SOCKS, je me demande quand même : on utilise SOCKS pour utiliser un socksifier qui va directement communiquer avec notre serveur. Mais est-ce que ce ne serait pas plus "propre" de s'inspirer du fonctionnement du socksifier pour intercepter directement les données, sans utiliser SOCKS ?
Même si j'ai presque fini mon serveur SOCKS, je me demande quand même : on utilise SOCKS pour utiliser un socksifier qui va directement communiquer avec notre serveur. Mais est-ce que ce ne serait pas plus "propre" de s'inspirer du fonctionnement du socksifier pour intercepter directement les données, sans utiliser SOCKS ?
Oui, ça pour l'avoir dit, tu l'as dit !
Mais je me suis dit : si le logiciel qu'on utilise pour rediriger le traffic arrive à le faire avant d'établir la connexion avec le proxy SOCKS, alors c'est qu'il y a moyen de rediriger le traffic sans passer par SOCKS ! Autrement dit, il s'agit de reprendre le fonctionnement du "socksifieur" pour rediriger le traffic vers le MITM, et ce sans utiliser SOCKS ou une DLL. Est-ce envisageable ?
J'ai aussi peut-être trouvé comment rediriger le traffic avec la ligne de commande (voir ci-dessus), et je voulais vous le faire partager, vu que ToOns l'avait évoqué plus haut.
Mais je me suis dit : si le logiciel qu'on utilise pour rediriger le traffic arrive à le faire avant d'établir la connexion avec le proxy SOCKS, alors c'est qu'il y a moyen de rediriger le traffic sans passer par SOCKS ! Autrement dit, il s'agit de reprendre le fonctionnement du "socksifieur" pour rediriger le traffic vers le MITM, et ce sans utiliser SOCKS ou une DLL. Est-ce envisageable ?
J'ai aussi peut-être trouvé comment rediriger le traffic avec la ligne de commande (voir ci-dessus), et je voulais vous le faire partager, vu que ToOns l'avait évoqué plus haut.
Nouvelle petite question : comment on sait au lancement à quel serveur le client va se connecter ? Il y a 2 IPs dans la liste.
Edit : Mon sniff avec Wireshark a fonctionné, il y a eu 2 ips, la première était celle en ...39 (dans le xml il y a 39 et 40), puis quand je me suis connecté à mon serveur de jeu, c'est passé à la .85. Est-ce que l'IP du serveur est fixe ?
Parce que comme ça j'aurais juste à ajouter une option de choix de serveur !
Edit : Mon sniff avec Wireshark a fonctionné, il y a eu 2 ips, la première était celle en ...39 (dans le xml il y a 39 et 40), puis quand je me suis connecté à mon serveur de jeu, c'est passé à la .85. Est-ce que l'IP du serveur est fixe ?
Parce que comme ça j'aurais juste à ajouter une option de choix de serveur !
Bon, j'ai posé ma question sur la redirection à l'aide d'une commande comme iptables ici : https://discussions.apple.com/thread/5852264.