Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[DLL] hook recv ( WinSock 2 ) + Named Pipe

gijutsu

Bonjour,

Je bloque actuellement sur un MITM, j'aimerais comprendre la données que diffuse actuellement ma DLL, et m'assurer que je suis sur la bonne voie :)

[DLL] hook recv

La DLL à pour objectif de hook la function recv ( WinSock2 ). La fonction qui est alors appelée, s'occupe d'envoyer le buffer en entrée ( du recv ) dans une Named Pipe initialisée au préalable.

Named Pipe: https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes

[CLIENT] NodeJS

J'ai mis en place un client NodeJS qui établit une communication avec la DLL injectée grâce au Named Pipe. Je suis alors en mesure de récupérer les données qui transitent.

Seulement après vérification j'ai remarqué que je reçois plusieurs styles de données dont notamment le contenu d'une requête HTTP ( du JSON ), mélangé à probablement des packets Dofus 2.

Questions:

1/ Mon raisonnement est-t-il correcte pour le hook & l'envoie de données dans la fonction recv ?

2/ Comment je pourrais filtrer les données pour n'émettre que les packets basés sur le protocol Dofus 2 ?

Merci d'avance !

Bonne journée à vous

IceRhal

Alors, non l'objectif de la DLL n'est pas de hook une fonction, c'est la DLL qu'on hook (accroche) à une fonction. Et tu hook sur un processus que t'auras cibler, ce qui permet de changer le comportement de la fonction de ce processus.

Si tu parles de No.Ankama.dll (https://github.com/KevinSupertramp/No.Ankama.DLL/blob/master/No.Ankama/dllmain.cpp) la fonction qu'on modifie est Mine_Connect, et on modifie toutes les connections vers les IP d'ankama vers une autre ip (une ip local) ce qui permet d'intercepter les connections et ainsi de crée le MITM (Man In The Middle).

Si tu prends un analyseur de paquet (Wireshark, par exemple) tu verras qu'il y a différents types de protocol utilisé par Ankama, et vers des ip différentes.

Les protocoles HTTP sont utilisés pour le launcher et la boutique mais via une IP différente des serveurs de jeu, ce qui t'intéresse pour un MITM c'est seulement les paquets à destination des serveurs de connection/de jeu, et qui communiquent via le protocol Dofus.

gijutsu

Merci pour la réponse !

Alors lorsque je faisais référence à du hook, je parlais plutôt de la lib détours et de la possibilité de hook des fonctions. Donc ma DLL s'occupe dans un premier temps d'initialiser un named pipe, et également d'hook la fonction recv ( de winsock ).

La nouvelle fonction s'occupe alors d'envoyer au travers de la named pipe, le buffer du recv.

Du coup, je n'utilise pas no.ankama.dll c'est du fait maison :)

J'ai déjà comparé avec les données que je reçois de wireshark ce qui m'a permis à l'heure actuelle de bien comprendre que c'étais le payload que je recevais dans le buffer et non pas tout ce que peut contenir une requête TCP

Donc normalement, si je filtre les paquets à l'aide de l'ip de serveur d'authentification ou de jeu ça devrait ne plus poser de soucis ?

Est-ce que tu saurais si dans le code de dofus, on peut trouver l'ip de ces serveurs ?

IceRhal

Dans config.yml tu as les serveurs de connection

gijutsu

Salut,

Après plusieurs jours de recherche, j'ai finalement pu trouver la source de mon erreur.

int WINAPI MyRecv(SOCKET s, char* buff, int len, int flags) {
    #pragma warning(disable:4996)
    int nBytes = RealRecv(s, buff, len, flags);
    
    sockaddr_in peeraddr;
    int size = sizeof(peeraddr);

    getpeername(s, (struct sockaddr*)&peeraddr, &size);

    std::string ip = inet_ntoa(peeraddr.sin_addr);
    if (
        ip.compare("34.252.21.81") == 0 ||
        ip.compare("52.17.231.202") == 0 ||
        ip.compare("63.34.214.78") == 0
    ) {
        PipeManager::GetInstance()->send(buff, nBytes);
    }

    return nBytes;
}

Dans mon MyRecv ( qui est un hook du recv de winsock ), lors de mon PipeManager send j'avais spécifié comme taille du buffer à lire le len en argument du MyRecv plutôt que le retour du nombre de bytes lu par la vrai fonction Recv de winsock.

Ce qui avait pour effet de m'envoyer des buffer avec une drôle de taille.

Maintenant je récupère bien côté NodeJS les messages réseau qui transite.

Bonne journée à vous !