Bonjour à tous,suite à la maj 2.9 de D****, je rencontre de sérieux problèmes dans l'adaptation des fichiers as3 decompilés de façon approximative par le swf decompiler.Aussi j'aimerais avoir l'avis (entre autres^^) de ceux qui ont codé leur bot en as3 et qui ont réussi l'intégration (la connexion) de la nouvelle maj.Le 1er problème se situe dans le "AuthentificationManager.as", avec la fonction "setPublicKey".``` public function setPublicKey(param1:Vector.) : void { var _loc_2:* = new ByteArray(); var _loc_3:int = 0; while (_loc_3 < param1.length){ _loc_2.writeByte(param1[_loc_3]); _loc_3++; } _loc_2.position = 0; var _loc_4:* = new ByteArray(); var _loc_5:* = PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)); PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)).verify(_loc_2, _loc_4, _loc_2.length); this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_4) + "-----END PUBLIC KEY-----"; return; }// end function ```Mis à part les incohérences liées à la décompilation et l'utilisation (inutile ?) d'une sous-sous-classe de ByteArray (AuthentificationManager__verifyKey), je trouve bizarre que la clé publique ait besoin à ce stade d'être décryptée (RSAKey.verify()).Bref, le code actuel retourne un _loc_5 == null et fait planter "verify", ou, si j'utilise le byteArray _loc_2 (qui contient la clé) à la place du byteArray vide dans "PEM.readRSAPublicKey()", j'obtient une erreur de dépassement de longueur du byteArray en arrivant à "DER.parse(...)".Si je court-circuite la partie PEM pour créer la "this._publicKey" comme dans la 2.8, en utilisant directement le ByteArray _loc_2 :``` this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_2) + "-----END PUBLIC KEY-----"; ```... alors la fonction setPublicKey(...) se termine proprement, mais le 2eme problème survient plus loin, dans le "getIdentificationMessage()".Et là, c'est le "this.cipherRsa(...)" qui me plante ici :``` _loc_5 = RSA.publicEncrypt(this._publicKey, _loc_4); ```... comme par hasard, à cet endroit dans le "RSA.as" :``` PEM.readRSAPublicKey(param1) // param1 = publicKey !!! ```... retour à la case départ :( En gros, je patauge grave.- Est-ce-que ma "publicKey" est mauvaise ?- Est-ce-que mes fichiers de crypto (PEM, RSAKey, DER) sont incompatibles ? (j'utilise ceux du package 'hurlant' de 'as3Crypto' et non les décompilés du d*Invoker)- Est-ce-que je dois absolument utiliser le "Base64.as" de "by.blooddy.crypto" plutôt que celui de "hurlant.util" ? (pourtant un Base64 est un Base64...)Alors désolé pour ce déballage brutal, mais vraiment toute piste est la bienvenue, car je m'arrache les cheveux avec toute cette m***e :(Sur ce, bonne soirée et merci d'avance :)Atlantide-Le-Dépressif

**Re: maj 2.9 : probleme d'encryptage à la connexion**Désolé pour ce pavé indigeste que j'ai posté hier...mais j'ai pu cibler un peu mieux l'origine de mon problème.Il vient de la propriété "key" reçue à réception du HelloConnectMessage.Elle semble formatée différemment dans la 2.9 et dans la 2.8et je ne réussis pas faire le bon traitement pour la rendre utilisable dans la fonction setPublicKey() de AutentificationManager.Alors si quelqu'un pouvait me dire comment il a réussi à contourner ce problème, ça m'aiderait vraiment.Merci d'avance.Atlantide

**Re: maj 2.9 : probleme de publicKey**Je n'ai pas exploré completement le problème mais il est possible que les BigInteger contenu dans la clé (voir le fonctionnement du cryptage RSA) soit encodé en big endian et pas en little endian, d'ou le problème.Ce n'est qu'une hypothèse

**Re: maj 2.9 : probleme de publicKey**Sachant que de la 2.8 à la 2.9, la clé a gagné 11 bytes (je crois) donc il ne s'agit pas de ce problème.Sachant que une clé publique RSA fini généralement par 01 00 01 (65 537)Alors que la clé sur 2.9 :10 84 19 EF D6 F1 0D 61 41 5D 35 5F 58 F8 A0 61 C8 B3 45 03 E1 B1 AE 03 4C 22 CD90 11 34 A4 51 42 BB 8F E8 0C 7A 09 DB 29 20 3C 9D 04 AA 8B E2 65 ED 30 42 21 CD 70 09 5C DA 23 2E 50 92 87 36 6B 3F EA 07 D1 68 4C BF 26 FC 86 56 AC 92 84 EB BE C8 95 CD DD F0 77 64 2D 6B 27 EB 3C F4 24 25 B4 FE 1A 3C CB 3F 25 1C FE 71 B9 E1 29 20 65 B8 30 A7 77 00 D3 D1 25 F8 93 FA 0D 8F BA 70 A9 01 D5 5B 94 B5 FA 4E A9 63 57 DB 8C 1F 1D 14 1C 18 4C B9 4D 49 76 0B 52 DA CE DC F5 D9 A1 76 74 D6 DB 8E 97 7E 68 3C 41 06 63 1D E8 5B 61 7D DC 0B 38 2F FD C2 00 23 91 C0 47 37 18 A1 AD EA 03 DC 61 F5 A8 09 F4 8F E0 79 F3 D7 51 57 2B 77 D8 7D 03 E3 BB A1 5E A9 4C A0 52 E2 A4 2B 14 48 92 64 04 2C CA 56 1F F1 29 10 74 2F DF CC 4F 12 F2 0B A7 62 CA D4 51 26 62 D6 60 80 D8 90 5E 80 42 03 16 6D CF DB 95 B5 8E 0B 41 EB 80 C1 6D B8 49 DE C4 67 D9 02 E1 40 AB E7 61 D4 C4 6F C2 7F 57 44 C4 BE B3 A7 25 73 0A 2E 7B 4E 7C 49 6D 11 70 70 6AIl y avait une histoire avec DER ou PEM, a voir?Bon courage !

**Re: maj 2.9 : probleme de publicKey**Merci pour vos pistes, je vais étudier ça :)Mais avant tout, je trouve étrange d'être le seul à qui ce problème se pose.Comment vous (et tous les autres) avez réussi à remettre votre bot à jour sans y avoir été confronté ???Car ça pourrait également être une solution pour moi (pas que le fait de fouiller dans le bytecode me dérange... quoique !)Enfin, je vais me préparer une BigCafetière et me replonger dans les sources :)Atlantide-Nouvel-Espoir

**Re: maj 2.9 : probleme de publicKey**MITM ;)

**Re: maj 2.9 : probleme de publicKey**En faite, ceux utilisant un bot type MITM n'ont pas ce probleme, puisque la connection ne se fait pas grace au bot mais bien par le client.Dans mon cas, j'ai mis en pause mon émulateur, puisque j'ai commencer un autre projet et donc je n'ai pas trop cherché.Sinon, le fait que ca ne marche pas viens du fichier RSAKey, l'erreur se fait dans une fonction appellé verify ou _Decrypt, si mes souvenirs sont bon.Tiens moi au courant !

**Re: maj 2.9 : probleme de publicKey**ok, merci, je te dirai tout çaAtlantide

**Re: maj 2.9 : probleme de publicKey**j'ai essayé de remplacer le package hurlant initial de d**** par d'autres packages hurlant originaux tels que as3Crypto et hurlant_tls, mais aucun changement. Quelquesoit le package utilisé, le plantage s'effectue toujours au même endroit : PEM.readRSAPublicKey()Alors je me dis que ce ne sont peut-être pas les fichiers DER, PEM ou autre qui sont en cause et avant de les décortiquer, il est peut-être utile de regarder en amont.Effectivement, la clé envoyée par le serveur est plus longue que dans la 2.8. Si j'utilise une clé de 2.8, là, le PEM.readRSAPublicKey() fonctionne correctement.Ce qui me pousse à penser que l'utilisation de la clé n'a pas changé, mais qu'il est nécessaire de la décrypter (ce qui est nouveau) avant de pouvoir l'utilliser.... et c'est ce bout de code que je tentais d'ignorer jusqu'alors qui reste un mystère :``` var _loc_5:* = PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)); PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)).verify(_loc_2, _loc_4, _loc_2.length); ```malgré les incohérences de décompilation, on a bien l'exécution d'une fonction "verify" qui est censée décrypter quelquechose... quoi ?et c'est le résultat de cette verif/decryptage qui est ensuite utilisé pour définir réellement la clé publique dont on va se servir.Je suis donc persuadé que si l'on résoud cette énigme, on résoud le problème de la publicKey valide, et donc, de la connexion.Je reposterai ce soir (là je n'ai pas le temps), pour exposer mon début d'analyse de ce code.Mais je pense qu'il faut commencer à chercher de ce côté avant de remettre en question le package hurlantAtlantide

**Re: maj 2.9 : probleme de publicKey**bon là j'ai un peu de temps devant moi, je vais décortiquer la fonction **setPublicKey(param1:Vector.) : void **de AuthentificationManager.as version 2.9afin d'y voir un peu plus clair dans le fonctionnement "théorique" de la création de la publicKey "utilisable".``` public function setPublicKey(param1:Vector.) : void { var _loc_2:* = new ByteArray(); var _loc_3:int = 0; while (_loc_3 < param1.length){ _loc_2.writeByte(param1[_loc_3]); _loc_3++; } _loc_2.position = 0; var _loc_4:* = new ByteArray(); var _loc_5:* = PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)); PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)).verify(_loc_2, _loc_4, _loc_2.length); this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_4) + "-----END PUBLIC KEY-----"; return; }// end function ```1) Analyse des nombres (int) qui vont composer la clé publique``` var _loc_2:* = new ByteArray(); var _loc_3:int = 0; while (_loc_3 < param1.length){ _loc_2.writeByte(param1[_loc_3]); _loc_3++; } _loc_2.position = 0; ```Ici, c'est la partie commune aux versions 2.8 et 2.9.Pas de problème, on parse le vecteur d'int passé en paramètre (param1) pour remplir un ByteArray (_loc_2), qui contient donc le corps de la clé "brute" en binaire.2) Nouveau ByteArray``` var _loc_4:* = new ByteArray(); ```On crée ensuite un nouveau ByteArray (_loc_4). Attention, dans la v2.8, _loc_4 est une String, qui servait à contenir le corps de la clé "brute" encodé en String. C'était suffisant, il restait à ajouter le header et le footer et la publiqueKey était utilisable en l'état.Ici, ce n'est plus le cas. _loc_4 est un ByteArray qui, semble-t-il, est destiné à recevoir le corps de la clé "purifiée", ou "vérifiée" ou "décryptée" (c'est comme on veut). On verra plus loin la "purification".3) Création d'une RSAKey (fictive ???)``` var _loc_5:* = PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)); ```On crée _loc_5 qui, malgré le *, sera de type "RSAKey".Et c'est là le premier problème : créer une RSAKey à partir de rien : ça ne marche pas, et ça donne ... rienCar **(new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)** est égal à "".En effet, la chaine passée en paramètre de PEM.readRSAPublicKey(...) est celle lue dans un ByteArray vierge (de longueur 0). Ca ne donne effectivement pas grand chose ^^Et ça soulève le second problème : l'utilisation du "this._verifyKey", cette propriété de type "Class" qui contient justement la classe AuthentificationManager__verifyKey. Cette classe, qui hérite au second degré de la classe ByteArray, n'apporte rien en plus, ni props, ni méthodes (si l'on s'en tient à sa déclaration)...``` package com.ankamagames.dofus.logic.connection.managers { import mx.core.*; public class AuthentificationManager__verifyKey extends ByteArrayAsset { public function AuthentificationManager__verifyKey() { return; }// end function } } ```Y aurait-il eu un problème de décompilation ? (sait-on jamais)Bref, à ce stade, on est sensé avoir une RSAKey de "référence" dans la variable _loc_5. En réalité ce n'est pas la cas, et _loc_5 a la valeur "null" :(4) "Purification" de la clé "brute"``` PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)).verify(_loc_2, _loc_4, _loc_2.length); ```qui aurait dû être (pour justifier la création de la variable temporaire _loc_5) :``` _loc_5.verify(_loc_2, _loc_4, _loc_2.length); ```C'est donc ici, en théorie qu'on décrypte le corps de la clé "brute" (actuellement sous forme d'octets dans le ByteArray _loc_2) pour obtenir un corps de clé décrypté dans le ByteArray _loc_4 (toujours sous forme d'octets). Je parle de "décryptage" car la méthode "verify(...)" fait elle-même appel à la méthode "_decrypt(...) de la classe RSAKey.La nécessité de décrypter une clé "brute" reçue par le "HelloConnectMessage" pourrait expliquer le fait que la String résultante ait (anormalement ?) gagné en longueur en passant de la 2.8 à la 2.9 (de 396 à 408 : +12 caractères).Evidemment, puisque _loc_5 (notre RSAKey de référence) est "null", ça plante...Mais toujours est-t-il qu'à ce moment là, on est sensé avoir _loc_4, un beau ByteArray rempli des octets d'une clé publique utilisable.5) Finalisation de la publicKey``` this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_4) + "-----END PUBLIC KEY-----"; return; ```Dernière étape : à partir de notre corps de clé "décrypté" dans le ByteArray _loc_4, on crée le corps de clé décrypté sous forme de chaine auquel on ajoute le footer ("-----BEGIN PUBLIC KEY-----") et le header ("-----END PUBLIC KEY-----").On obtient (là c'est encore purement théorique, puisque je ne suis encore jamais parvenu à cette étape) la clé publique : this._publicKey, qui sert à encrypter les données sensibles de la connexion.6) Conclusion (enfin... ouf !)Il se peut que certaines parties de cette analyse soient incomplètes ou inexactes étant donné qu'elle sont issues de ma simple interprétation du code que je ne suis pas en mesure de faire tourner correctement. Alors j'attends vos réactions et vos suggestions.Et je suis sûr que beaucoup sont concernés par les problèmes que j'ai rencontrés, ou qu'ils ont déjà réussi à les solutionner ou à les contourner.Tous les membres de ce forum ne bottent pas en MITM, il doit bien rester encore quelques bots socket traditionnels :)Merci d'avance.Atlantide-Le-Bavard

**Re: maj 2.9 : probleme de publicKey**J'en suis au même problème que toi. On pourrais voir ça ensemble sur skype ? Enfin je veux dire en discuter afin de trouver une solution.Edit: Sais-tu ce que sont que : %, ++, ?, |, :, et tout les autres qui leur ressemble ? Je code en et j'ai du mal à comprendre ça. J'ai chercher un peu sur google mais rien.Je ne comprend pas aussi ça :``` Private _verifyKey As Class ```

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

[resolu] maj 2.9 : probleme de publicKey

Anonymous

Re: maj 2.9 : probleme de publicKey

Teukan a dit : "Si j'ai bien compris le d correspond au résultat de (P-1)(Q-1) à la création de la clé privée."

non, d est calculé à partir de p, q et e :

[url:c8j1pgad a dit : "http://www.apprendre-en-ligne.net/crypto/rsa/[/url]"]
L'instruction d=PowerMod[e,-1,(p-1)(q-1)] de Mathematica permet de calculer d facilement."

mais c'est de la sauce interne, les fonctions qui le font sont déjà écrites.

Sinon, de mon côté, j'ai essayé d'extraire une signature du "key", reçu dans le HelloConnectMessage

avec la classe com.ankamagames.jerakine.utils.crypto.SignatureKey, qui permet ensuite de retrouver la clé publique (quand ça marche ^^)

mais c'est pas encore pour cette fois, car : nouveau plantage :


		public function setPublicKey(param1:Vector.<int>) : void {
			var _loc_2:ByteArray = new ByteArray();
			_loc_2.writeUTF("DofusPublicKey");
			var _loc_3:int = 0;
			while (_loc_3 < param1.length){
				
				_loc_2.writeByte(param1[_loc_3]);
				_loc_3++;
			}
			
			_loc_2.position = 0;
			
			var sk:SignatureKey = SignatureKey.fromByte(_loc_2);            // ------------------>   ça plante ici (déjà ...)  <------------------------
			var rsak:RSAKey = new RSAKey(sk.n, sk.e);
			var _loc_4:ByteArray = new ByteArray();
			rsak.verify(_loc_2, _loc_4, _loc_2.length);
			
			this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_4) + "-----END PUBLIC KEY-----";
			return;
		}// end function

dans la fonction "SignatureKey.fromByte(...)" c'est le 1er readUTF() qui plante (Error: Error #2030: End of file was encountered.), dans la ligne :

_loc_3 = RSAKey.parsePublicKey(param1.readUTF(), param1.readUTF());

donc, si signature il y a, j'ai fait une erreur quelque part, ou alors pas de signature et retour à la case départ :( :(

Alors, je vais continuer à chercher... et pourtant, je suis sûr que c'est un truc tout c** ^^

ça m'énerve, c'est la 1ere fois que mon bot reste HS aussi longtemps, et j'arrive pas à mettre la main sur le grain de sable...

Atlantide

ps : existe-t-il des softs qui permettent de sniffer, non pas des échanges réseau, mais l'exécution du code à l'intérieur d'un programme ?

Anonymous

Re: maj 2.9 : probleme de publicKey

Salut,

certains me connaisse peut-être deja je développe un emu D. depuis quelque temps en C++ (BoraxEmu).Après un pause plutôt longue j'ai voulu reprendre la dev de mon emu et la ben la super blague de la 2.9, comme visiblement personne ou très peux de personnes on trouvé une solution je me suis mis en tète de patché le client et de viré ce foutu cryptage par RSA... Sans résultat en premier temps,mais par la suite j'ai découvert une clé "caché" dans le client, il s'agit d'une clé Publique qui n'est rien de plus que la "VerifyKey" grâce a sa j'ai pu patché le client, et comme je vois que tout le monde galaire avec sa je vais vous expliqué ce qu'il ce passe :

1 - le serveur génère 2 paires de clés (que je nommerais clé1 et clé2)

2 - il signe la clé1(partie public) grâce à la clé2

3 - il envoi le tout au client

(ici commence la partie bot)

4 - le client "vérifie" le contenue envoyé grâce a la fameuse verifyKey, de cette vérification decoule la clé1(partie public)

5 - ensuite le client continu sa route ^^

j’espère avoir été assez clair, ne confondé surtout pas les 2 paires de clés (cf.1) ce sont bien 2 paires de clés différentes.

Pour la VerifyKey il suffi de bien chercher (SWF Decompiler ne vous trouvera rien) s'y besoin est vous pouvez m'ajouté sur Skype : k.o.p.e.t.e

Bonne année d'avance a tous ;)

ToOnS

Re: maj 2.9 : probleme de publicKey

atlantide a dit : "ps : existe-t-il des softs qui permettent de sniffer, non pas des échanges réseau, mais l'exécution du code à l'intérieur d'un programme ?"

windasm , faut aimer l'assembleur , bon courage :mrgreen:

Anonymous

Re: maj 2.9 : probleme de publicKey

C'est nickel, merci :)

et Bonne année à tous !

Atlantide

« Page précédente