[Retro] Nouvelle signature \xc3\xb9 dans les packets envoyés

[Eleko]

Bonjour,

Je reprends mon MITM pour Retro et je vois que maintenant chaque packet envoyé par le client est "signé" par une chaine de caractère encodée commencant par "\xc3\xb9".
Il semble qu'on puisse tout de même envoyer des packets sans cette chaine.

Je voulais savoir si certains en savaient plus sur ça (anti bot ?). Et si quelqu'un sait comment elle est générée ça m'interesse !

Merci

 

[Eleko]

Quelques petites précisions si ça intéresse quelqu'un :
- Il s'agit d'une chaine encodée en base64 (aucune correspondance ASCII)
- Elle est toujours composée d'une première sous chaine de 16 bytes suivie d'une autre de 208
- Elle est encapsulée par le caractère "ù" (\xc3\xb9 )
- Tous les packets envoyés par le client au serveur de jeu sont précédés de cette "signature".
- On peut quand même envoyer des packets sans signature et tout marche normalement.
- Version Retro : 1.39.9 ( je ne sais pas de quand date cet ajout mais c'est relativement récent)
- Toujours différente

Donc à quoi sert cette chaine, comment est-elle générée/encodée, comment la décoder ?

Merci !

 

[intermet]

Salut,
Quand tu examines le loader.swf, cette key est creee par une fonction js de la partie electron du client.
Cette partie electron est codee dans main.jsc qui est du byte code javascript. Pas evident a decompiler.
J'ai l'impression que cette key est plus ou moins random et doit soit surement contenir des donnees de telemetrie.
A+

 

[anon]

ils ont chiffré les paquets AI et HT avec un clé qui est dans le code compilé mais quasi impossible à décompiler donc impossible de récupérer la clé. Avant c'était juste obfusqué donc simple à bypass.

Avant ça fonctionnait comme ça :

https://github.com/krm35/dofus-retro-telemetry

maintenant ils ont juste rajouté un chiffrement sur la donnée en sortie.

 

[Eleko]

Merci beaucoup pour vos réponses !
Mais du coup pourquoi le serveur accepte des paquets même sans cette clé chiffrée ? Vous pensez que c'est temporaire ?

 

[anon]

Merci beaucoup pour vos réponses !
Mais du coup pourquoi le serveur accepte des paquets même sans cette clé chiffrée ? Vous pensez que c'est temporaire ?

C'est seulement le client electron pour jouer sur boune qui chiffre les paquets, le client legacy 32 bits qui est le plus opti ne chiffre rien du tout c'est pour ça, risque de ban sur boune si tu chiffres pas.

 

[Eleko]

Okaaay je comprends mieux !
Merci

 

[Superjudefruit]

Salut @anon merci beaucoup pour ces éléments, c'est un peu chasse gardé sur les mesures anti bot, on trouve pas beaucoup d'info quand on est rookie .

Du coup d'après tes explications les paquets générés via le client officiel devraient être bon. Pourrais tu expliquer pourquoi en mitm le serveur coupe la connexion même si les paquets qui transitent possèdent l'en-tête ? C'est systématique, j'ai dû virer les en-têtes pour continuer à me log.

- Je lance le jeu sans le launcher officiel
- Je hook avec frida

Merci

 

[zouhair]

t'as pu trouver comment décryter les packets ?

 

[oaks85]

aucune info sur le forum concernant ces signatures entre les "\xc3\xb9" (ù) en utf-8 quelq'un a réussi à trouver comment les créer? ça ban si on ne les inclus pas?

 

[Bobby]

De nouvelles infos sur ce packet ? Je serai bien intéressé !

 

[Titus78]

De nouvelles infos sur ce packet ? Je serai bien intéressé !

me too je suis intéréssé

 

[bl0odlaw]

Aux dernières nouvelles tout le code permettant de signer les paquets envoyés était contenu dans le fichier jsc. Ils pré-compilent leur code en bytecode V8 en utilisant un tool qui s’appelle bytenode (qui lui même utilise une fonction native de V8). Une solution envisageable semble être de développer un décompilateur en utilisant les ops codes de la version V8 incluse dans le NodeJs qu’ils utilisent.

Il semble qu’il existe des solutions en MITM permettant d’utiliser le mode débug d’électron afin d’utiliser les fonctions sans avoir à les connaître (ou du moins seulement leur signature).

En full socket il est évident qu’il faut pouvoir accéder à ce code.

On voit bien qu’il y a des bots IG sur Boune qui by-pass tout ça donc avec un peu de travail ça doit être faisable.

 

[dhelm]

Aux dernières nouvelles tout le code permettant de signer les paquets envoyés était contenu dans le fichier jsc. Ils pré-compilent leur code en bytecode V8 en utilisant un tool qui s’appelle bytenode (qui lui même utilise une fonction native de V8). Une solution envisageable semble être de développer un décompilateur en utilisant les ops codes de la version V8 incluse dans le NodeJs qu’ils utilisent.

Il semble qu’il existe des solutions en MITM permettant d’utiliser le mode débug d’électron afin d’utiliser les fonctions sans avoir à les connaître (ou du moins seulement leur signature).

En full socket il est évident qu’il faut pouvoir accéder à ce code.

On voit bien qu’il y a des bots IG sur Boune qui by-pass tout ça donc avec un peu de travail ça doit être faisable.

En supposant que personne n'a réussi à reverse la vm V8 pour la version node de retro:
- Ton MITM doit être écrit avec node.js/electron et que ça doit matcher la version de retro obviously
- Load le main.jsc et appeler les fonctions qui permettent de signer (packetCallbackSignature j'ai oublié le nom). Les symboles sont toujours présents donc tu peux retrouver les fonctions exposées à la scope globale par ce module V8

L'alternative la plus simple et la plus safe c'est d'injecter ton propre SWF sur le client et de hook/patch à ta guise tout ce dont tu as besoin. Si tu cherches bien, tu peux même accéder au debugger electron et faire ce que tu veux du jeu, marshal/faire des bindings AS<->JS et ecrire ton bot en JS sans t'emmerder en actionscript.

 

[intermet]

En supposant que personne n'a réussi à reverse la vm V8 pour la version node de retro:
- Ton MITM doit être écrit avec node.js/electron et que ça doit matcher la version de retro obviously
- Load le main.jsc et appeler les fonctions qui permettent de signer (packetCallbackSignature j'ai oublié le nom). Les symboles sont toujours présents donc tu peux retrouver les fonctions exposées à la scope globale par ce module V8

L'alternative la plus simple et la plus safe c'est d'injecter ton propre SWF sur le client et de hook/patch à ta guise tout ce dont tu as besoin. Si tu cherches bien, tu peux même accéder au debugger electron et faire ce que tu veux du jeu, marshal/faire des bindings AS<->JS et ecrire ton bot en JS sans t'emmerder en actionscript.

Interessant. Comment accedes-tu au debuger electron?

 

[rtab]

Le nom de la méthode utilisée par le client electron c'est : applyPacketToSendPostProcessing(packet)
Perso je n'accède pas au debugger electron directement, je passe par un serveur RPC lié à la fonction.
En gros, mon mitm envoit un lien dans la fenêtre du chat dofus contenant un payload JS qui crée le serveur RPC.
Après ça, j'envoie les paquets au serveur RPC qui me les signent et je les renvoie via mon mitm.

Pour info :

require('@electron/remote').BrowserWindow.fromId(1).webContents.executeJavaScript(`(()=>{const net=require('net');function getFn(){const f=window.applyPacketToSendPostProcessing;if(typeof f!=='function')throw new Error('prob applyPacketToSendPostProcessing');return f.bind(window);}const OPC_APPLY=1;const u32=(b,o)=>b.readUInt32LE(o);const w32=n=>{const b=Buffer.allocUnsafe(4);b.writeUInt32LE(n,0);return b;};const server=net.createServer(sock=>{sock.setNoDelay(true);let buf=Buffer.alloc(0);const sendOK=data=>{const d=Buffer.isBuffer(data)?data:Buffer.from(String(data),'utf8');sock.write(Buffer.from([0x00]));sock.write(w32(d.length));sock.write(d);};const sendERR=msg=>{const d=Buffer.from(String(msg),'utf8');sock.write(Buffer.from([0x01]));sock.write(w32(d.length));sock.write(d);};sock.on('data',chunk=>{buf=Buffer.concat([buf,chunk]);while(buf.length>=5){const op=buf[0];const len=u32(buf,1);if(buf.length<5+len)break;const payload=buf.slice(5,5+len).toString('utf8');buf=buf.slice(5+len);if(op!==OPC_APPLY){sendERR('opcode inconnu');continue;}try{const fn=getFn();const out=fn(payload);Promise.resolve(out).then(res=>sendOK(res)).catch(e=>sendERR(e?.message||e));}catch(e){sendERR(e?.message||e);}}});sock.on('error',()=>{});});const PORT=31339;server.listen(PORT,'0.0.0.0',()=>console.log('[RPC] renderer écoute sur 127.0.0.1:'+PORT,'→ call applyPacketToSendPostProcessing(payload)'));window.__rpcServer=server;window.__rpcInvoke=p=>getFn()(p);'OK';})()`,true)

 

[didolehbal]

mon mitm envoit un lien dans la fenêtre du chat dofus contenant un payload JS qui crée le serveur RPC.
Après ça, j'envoie les paquets au serveur RPC qui me les signent et je les renvoie via mon mitm.

Est-ce que tu peux elaboré comment tu inject le payload js pour cree le serveur RPC ?

 

[intermet]

j'ai pas essaye de l'implementer mais il me semble que le nouveau chat retro permet d'afficher du html. Il suffit d'envoyer un packet de chat avec le code html + js.

 

[rtab]

J'utilise une version modifié du très bon D1Proxy (https://github.com/Aquazus/D1Proxy) et j'envoie un message au client (pas au serveur hein) de type "cs", ce qui permet l'affichage de message de statut (et de lien HTML).
Je fais un base64 du payload que j'ai mis plus haut et après c'est de l'évaluation de code avec un verbe onclick sur le lien.
J'avais essayé de post le module complet sur le site mais Cloudflare bloque (vu qu'il flag ca en XSS).
Donc je mets un pastebin au cas où c'est plus parlant :
https://pastebin.com/DBhciVVW