tfm secrets leaker

TFM Secrets Leaker

Un utilitaire pour obtenir les secrets codés en dur au sein du client Transformice.

Bâtiment

Pour construire, vous devez utiliser le fichier asconfig.json pour compiler le fichier TFMSecretsLeaker.swf . Cela peut être fait avec vscode-as3mxml ou asconfigc.

Vous devrez également placer les fichiers SWC pour les bibliothèques suivantes dans un dossier lib au même niveau que le fichier asconfig.json :

• as3Commons-bytecode-1.1.1
• as3Commons-Lang-0.3.7
• as3Commons-reflect-1.6.4

Si vous souhaitez vous sauver les tracas, il y a aussi un SWF prédéfini dans les versions de ce référentiel.

Usage

Lors de l'exécution du fichier SWF construit, il trace les secrets obtenus. Ceux-ci peuvent être visualisés dans quelque chose comme FFDEC, bien qu'un script leak-secrets.py utile.py soit également fourni pour obtenir la sortie en utilisant le projecteur de débogage autonome, utilisé comme tel:

 ./leak-secrets.py <path/to/TFMSecretsLeaker.swf>

Lors de l'exécution du SWF, une fenêtre apparaîtra pour un court instant, semble commencer à charger le jeu, puis à quitter. C'est normal.

Malheureusement, cela n'est pas actuellement compatible avec Ruffle car il n'implémente pas actuellement fscommand("quit") .

Les secrets

Le protocole de réseautage de TransformIce utilise plusieurs secrets à codés en dur et à changer fréquemment qui sont contenus dans le client. Toutes les cinq minutes environ, un SWF principal différent est servi pour le jeu, changeant la plupart de ces secrets codés en dur. Par conséquent, il est nécessaire d'avoir un utilitaire dynamique pour obtenir ces secrets automatiquement, car ils changent trop souvent pour obtenir manuellement.

Ces secrets comprennent:

• L'adresse du serveur.
  • Il s'agit de l'adresse du serveur auquel le client se connecte. Cela change et a changé, mais rarement assez pour que je pense qu'il pourrait être codé en dur et redécouvert manuellement lorsqu'il change.
• Les ports du serveur.
  • Les ports du serveur auquel le client peut se connecter. Ceux-ci à ma connaissance n'ont jamais changé, mais théoriquement ils le pouvaient, et nous sommes en mesure de les signaler, et donc nous le faisons. Le client mélangera au hasard ces ports, puis essaiera de se connecter à eux en séquence, passant à la suivante si la connexion échoue.
• La version du jeu.
  • C'est ce que le jeu affiche dans le coin inférieur droit de l'écran de connexion, montrant du texte comme 1.740 . La version du jeu selon laquelle cela rapporte est le composant 740 de cela, et est envoyé dans le paquet de poignée de main que le client envoie au serveur. Cela ne change pas aussi souvent que les autres secrets.
• Le jeton de connexion.
  • Il s'agit d'un ensemble aléatoire de caractères qui est également envoyé dans le paquet de poignée de main. Je crois qu'il a utilisé par le serveur pour identifier les valeurs attendues des autres secrets.
• La touche Auth.
  • Une fois que le client a envoyé le paquet de poignée de main au serveur, le serveur répond ensuite avec un paquet contenant un "token Auth". Il s'agit d'un entier qui est à nouveau utilisé lorsque le client envoie le paquet de connexion. Le client XOR est le token Auth avec la "clé Auth" codée en dur, résultant en un jeton cipré, qui est ensuite envoyé au serveur dans le paquet de connexion.
• Les sources clés du paquet.
  • Certains paquets du protocole réseau de Transformice sont chiffrés, par exemple le paquet de connexion. Le chiffre particulier varie par paquet, mais les clés utilisées sont dérivées d'un tableau d'entiers appelé "Sources de clés de paquet". Ces entiers sont combinés avec un nom de clé, par exemple "Identification", pour obtenir la clé réelle utilisée pour crypter un paquet.
• Le modèle de vérification du client.

  • Peu de temps après que la séquence de poignée de main a été terminée par le client et le serveur, le serveur enverra un paquet au client pour s'assurer que le client est officiel et autrement approprié (c'est-à-dire pas un bot). Ce paquet contient un "jeton de vérification" (un entier) que le client utilisera ensuite dans sa réponse. Le client répondra avec un paquet cipher à l'aide de l'algorithme XXTE avec le jeton de vérification converti en une chaîne comme nom pour la clé. Les données de paquets (en texte brut) commenceront par le jeton de vérification, puis des champs semi-aléatoires et codés en dur, avec le jeton de vérification jeté à nouveau au milieu de celui-ci. Cela ne semble pas changer aussi souvent que les autres secrets, mais cela change.

    Ce que cela rapporte est une chaîne hexagonale représentant une chaîne d'octets du corps en texte clair de ce paquet (en python, quelque chose que vous pourriez utiliser bytes.fromhex on). Au lieu de l'emplacement du jeton de vérification, aabbccdd est utilisé et doit être remplacé par le jeton de vérification réel.

Autres jeux

D'autres jeux Atelier 801 ont des structures très similaires à transformer, et donc cet utilitaire est en mesure de soutenir également les jeux suivants:

• Transformce
• Labyrinthe mort
• Bouboum
• Nékodancer
• Fortoresse

Transformice et Dead Maze sont les seuls jeux qui ont des modèles de vérification des clients. Et donc pour les autres, aucun modèle de vérification du client ne sera retracé.

Pour obtenir les secrets à un jeu particulier, son nom doit être fourni au paramètre de chargeur game . Par exemple, voici comment vous le feriez en utilisant le script de leak-secrets.py :

 ./leak-secrets.py path/to/TFMSecretsLeaker.swf?game=transformice

./leak-secrets.py path/to/TFMSecretsLeaker.swf?game=deadmaze

./leak-secrets.py path/to/TFMSecretsLeaker.swf?game=bouboum

./leak-secrets.py path/to/TFMSecretsLeaker.swf?game=nekodancer

./leak-secrets.py path/to/TFMSecretsLeaker.swf?game=fortoresse

Si aucun paramètre game n'est fourni, alors l'utilitaire va par défaut pour fuir les secrets de TransformIce.