VB/VB.Net Le protocole de D.
- Auteur de la discussion Wav
- Date de début
De un, je pense que tu n'as rien compris.
De deux, je pense que la seul chose que tu sais faire c'est traduire du code AS3 en VB.net
De trois, tu dis que nous sommes sur un forum qui fournit de l'aide mais pour cela il faut encore prendre le temps de lire les autres
Et enfin si tu veux me donner tort tu as juste a m'expliquer où a tu trouvé dans les sources D. comment décoder les messages envoyé par le serveur, à moins que tu es juste copié les sources de Overedge bêtement sans vouloir comprendre. Pour finir je pense que tout ceci ne s'apparente pas à du leech...
De deux, je pense que la seul chose que tu sais faire c'est traduire du code AS3 en VB.net
De trois, tu dis que nous sommes sur un forum qui fournit de l'aide mais pour cela il faut encore prendre le temps de lire les autres
Et enfin si tu veux me donner tort tu as juste a m'expliquer où a tu trouvé dans les sources D. comment décoder les messages envoyé par le serveur, à moins que tu es juste copié les sources de Overedge bêtement sans vouloir comprendre. Pour finir je pense que tout ceci ne s'apparente pas à du leech...
A
Ouhla, RKYDA qu'est qui t'arrive ? Wav ne leech rien, il ne demande que de l'aide. Va revoir le terme de ce mot.
Wav, les sources de overedge ne sont plus à jour pour éviter ce genre de chose.
Donc déjà il te faut pas mal de connaissance en socket. Quel est le jeu W. sans la censuration, W*O*W ?
Je ne sais pas en quel langage est fait ce jeu, apporte nous un peu d'info et on pourra t'aider.
Wav, les sources de overedge ne sont plus à jour pour éviter ce genre de chose.
Donc déjà il te faut pas mal de connaissance en socket. Quel est le jeu W. sans la censuration, W*O*W ?
Je ne sais pas en quel langage est fait ce jeu, apporte nous un peu d'info et on pourra t'aider.
W*A*K*F*U est fais en java la plupart des sources se trouve dans core.jar facilement décompilable.
Par contre rien d’étonnant il est obfusqué et donc les noms des .java contenu dans le .jar son moins
reconnaissable que dans D. . J'ai eu beaucoup de piste mais aucune n'a aboutie. De ce faite j'aurais
aimé savoir comment le protocole de D. avait été trouvé car on sait tous la forme des paquets sous le quel il
faut envoyé au serveur D. mais personne n'a l'aire de savoir d'ou sa vient...
Par contre rien d’étonnant il est obfusqué et donc les noms des .java contenu dans le .jar son moins
reconnaissable que dans D. . J'ai eu beaucoup de piste mais aucune n'a aboutie. De ce faite j'aurais
aimé savoir comment le protocole de D. avait été trouvé car on sait tous la forme des paquets sous le quel il
faut envoyé au serveur D. mais personne n'a l'aire de savoir d'ou sa vient...
A
Je comprend pas vraiment ce que tu veux dire par comment le protocole de D0fus a été trouvé. Comment le décryptage des packet et tout le tralala a été fait ?
Eh bien déjà moi j'ai débuté avec les source de ToOnS, et c'est comme sa que j'ai tout appris, mais cela doit être le résultat d'une longue recherche. Le décryptage a du être trouvé par des test j'imagine.
Eh bien déjà moi j'ai débuté avec les source de ToOnS, et c'est comme sa que j'ai tout appris, mais cela doit être le résultat d'une longue recherche. Le décryptage a du être trouvé par des test j'imagine.
- Inscrit
- 19 Octobre 2010
- Messages
- 214
- Reactions
- 0
Pour répondre à la question initiale, la compréhension des paquets de D@fus passe par deux techniques complémentaires.
1/ Sniffer : on regarde les paquets qui circulent entre le client et le serveur, on les décode, et on essaie d'en comprendre la logique ou la cohérence.
2/ Sources AS : l'accès aux sources du client permet d'une part de confirmer la structure des messages (et donc des paquets). Mais aussi et surtout, à transcrire en un autre langage (VB, C#, C++ ou autre) - d'une façon plus ou moins automatisée selon la technicité de l'auteur et des outils à sa disposition - la description de tout ou partie des messages (=> Protocol Manager).
En principe l'accès aux sources n'est pas indispensable, mais ça facilite énormément le boulot. De même, la seule connaissance des sources peut en principe suffire, mais c'est très risqué et fastidieux, car cela nécessite une parfaite compréhension de la totalité des sources de D@fus, ce qui est assez indigeste. L'utilisation conjointe des deux - et la simplicité de l'architecture utilisée - rendent l'écriture des bots pour D@fus beaucoup plus facile.
1/ Sniffer : on regarde les paquets qui circulent entre le client et le serveur, on les décode, et on essaie d'en comprendre la logique ou la cohérence.
2/ Sources AS : l'accès aux sources du client permet d'une part de confirmer la structure des messages (et donc des paquets). Mais aussi et surtout, à transcrire en un autre langage (VB, C#, C++ ou autre) - d'une façon plus ou moins automatisée selon la technicité de l'auteur et des outils à sa disposition - la description de tout ou partie des messages (=> Protocol Manager).
En principe l'accès aux sources n'est pas indispensable, mais ça facilite énormément le boulot. De même, la seule connaissance des sources peut en principe suffire, mais c'est très risqué et fastidieux, car cela nécessite une parfaite compréhension de la totalité des sources de D@fus, ce qui est assez indigeste. L'utilisation conjointe des deux - et la simplicité de l'architecture utilisée - rendent l'écriture des bots pour D@fus beaucoup plus facile.