[Shiro]

Bonsoir,

Je viens vers vous car je suis confronté a un problème que je n ' arrive pas a résoudre.
Merci d ' avance de votre attention et de votre ai possible

Je suis en ce moment en phase entreprise , et on m ' a donné un projet réseau a faire(alors que je suis dev  mais bon , j ' ai pas trop le choix)

Le problème est le suivant:

Un serveur  envoi une requête  utilisant un protocole propriétaire sur un autre serveur.
Je suis censé analyser cette requête et la décoder en format compréhensible pour pouvoir l ' exécuter  directement via un telnet.

J ' ai donc capture la trame sous wireshark pour l ' analyser, mais tout est crypté (même si j ' arrive a retrouver quelque données que j ' ai envoyées de mon serveur)

Ma question est : est - il possible de décoder la requête même s ' il s ' agit d ' un protocole propriétaire(donc normalement impossible a décrypter)?

J ' ai tout essayé : la conversion en binaire, hexa ou ebcdic , mais ca reste incompréhensible.
Ca m ' a tout l ' air d ' être un projet qui requiert des compétences de hacking(puisque je ne dispose pas de clés publiques ou privées).

Je n 'ai pas trop de mal sur le développement , mais sur le cryptage je dois avouer que je connais pas grand chose.

Quel est votre point de vue a ce sujet ?


Merci beaucoup de votre aide

[_o_]

Ma question est : est - il possible de décoder la requête même s ' il s ' agit d ' un protocole propriétaire(donc normalement impossible a décrypter)?

Tu confonds plusieurs notions.

Le terme propriétaire ne signifie absolument pas que le flux est chiffré, mais seulement qu'il n'est pas documenté publiquement. Autrement dit, ça peut être n'importe quoi, et plus probablement, c'est du binaire, auquel cas il est très difficile de déterminer ce qui passe dedans sans connaître les structures des paquets, les valeurs possibles et leur signification, etc...
Note que dans la tête d'un responsable marketing ou d'un directeur, un flux binaire est un flux chiffré puisqu'il ne le comprends pas. C'est ce qu'on appelle de la sécurité par l'obscurité, mais ça ne fonctionne pas.

D'autre part, qu'il soit chiffré (respectivement propriétaire) ne signifie pas qu'on ne peut pas le casser (resp. décoder). Ça doit pouvoir se deviner en connaissant les fonctionnalités qui passent dans le flux, et en étant maître de générer différentes requêtes. Mais c'est très compliqué, et ça peut prendre très longtemps.

Cela dit, j'ai l'impression que tu ne nous dis pas tout, car je ne vois pas bien l'intérêt de «décoder en format compréhensible pour pouvoir l'exécuter  directement via un telnet» (ce qui en soit n'a pas grande signification). Je suppose qu'il s'agit d'un flux réseau entre un client et un serveur. En admettant qu'on puisse reverser ce flux pour le comprendre, le transmettre de façon «compréhensible» (je suppose que tu veux dire, dans un protocole orienté texte) au serveur n'a aucun sens.

[Shiro]

Merci de ta réponse.
C ' est vrai que je me suis mal exprimé concernant l ' intérêt de ce décodage.

Pour faire simple , j ' envoi un message a partir d ' un client sur un serveur de messagerie.
L ' envoi de ce message se traduit par une requête de ce fameux protocole propriétaire.
Or le client effectue d ' autres actions indépendantes en parallèle , ce qui prend un temps assez conséquent avant d ' envoyer la requête et génère tous un tas de superflu(log,traces etc...)

On me demande justement de pouvoir décrypter ces requêtes pour pouvoir directement les balancer sur le serveur et ainsi gagner de précieuses secondes.

Pour cela , j ' ai capturé via wireshark les trames qui m ' intéressent et je les ai affichés en format ebcdic ce qui donne le résultat qui suit.

http://img832.imageshack.us/f/testga.png/

J'arrive a comprendre les quelques informations qui apparaissent quant je regarde le document ssl de la boite, mais le reste(les caractères non imprimable) me bloquent même en passant sous format hexa.

Si je comprends bien ce que tu dis , il est possible de faire du reverse engineering dessus et j ' aimerai justement bien connaitre les moyens de comment procéder pour y arriver (j ' ai cherché des tutos sur internet , mais sans succès).


Par ailleurs , que veux tu dire par "être maître de générer différentes requêtes"?
Merci de ton aide

[_o_]

Pour faire simple , j ' envoi un message a partir d ' un client sur un serveur de messagerie.

Lotus Notes ou Microsoft Exchange ?

On me demande justement de pouvoir décrypter ces requêtes pour pouvoir directement les balancer sur le serveur et ainsi gagner de précieuses secondes.

Donc, il s'agit de comprendre le protocole pour créer un client simplifié, quoi.

Pour cela , j ' ai capturé via wireshark les trames qui m ' intéressent et je les ai affichés en format ebcdic ce qui donne le résultat qui suit.

Ce qui ne donne pas grand chose, parce que le protocole est probablement binaire. Ce qu'il faut bien savoir, c'est que tous les protocoles ne sont pas orientés texte comme HTTP, POP3, etc. Essayer de simplement activer l'affichage ASCII ou EBDIC ne servira pas à grand chose, c'est le binaire en mode raw qu'il faut regarder.

Ton image ne donne rien : on ne sait pas ce que tu as fait pour générer la requête. On ne sait pas si par hasard les caractères ASCII pourraient correspondre à quelque chose (un nom d'utilisateur de la messagerie ? Un mot de passe ? Des commandes dans le protocole ?). Ce n'est malheureusement pas comme cela que ça marche.

J'arrive a comprendre les quelques informations qui apparaissent quant je regarde le document ssl de la boite, mais le reste(les caractères non imprimable) me bloquent même en passant sous format hexa.

Le document SSL de la boite ? Que veux-tu dire par là ? Le flux est chiffré par SSL ?

Si je comprends bien ce que tu dis , il est possible de faire du reverse engineering dessus et j ' aimerai justement bien connaitre les moyens de comment procéder pour y arriver (j ' ai cherché des tutos sur internet , mais sans succès).

Parce qu'il n'y a pas de méthodes miracles. Je dirais que c'est justement un truc de hacker. Faire joujou avec le système, l'observer, avoir de l'intuition, faire des tests, peut-être comprendre. Mais rien n'est garanti.
Certains y arrivent : on peut prendre l'exemble de Samba (SMB/CIFS) : http://fr.wikipedia.org/wiki/Samba_%28informatique%29 . D'autre pas : à ma connaissance, personne n'a réussi à vraiment comprendre ce qui se passait vraiment dans Skype (il faut dire que les concepteurs semblent veiller particulièrement à rendre secret le fonctionnement).

Par ailleurs , que veux tu dire par "être maître de générer différentes requêtes"?

Ce n'est pas en général en regardant UNE requête particulière que tu comprends un protocole, mais en en générant plusieurs dans lesquelles on fait varier à chaque fois des petits paramètres. Ces petits changements de paramètres peuvent provoquer des petits changements dans le flux, ce qui peut permettre de comprendre où sont stockés les informations dans le flux, et comment. Note qu'il y a beaucoup de conditionnels dans mes phrases.

[Shiro]

Merci encore de ta réponse.

En fait , on utilise nos propres clients  développés en interne pour envoyer et recevoir les messages sur nos serveurs Jboss  .

Donc, il s'agit de comprendre le protocole pour créer un client simplifié, quoi.

Exact. J ' ai déjà fini de développer le client(communication par socket et envoi de flux hexa to binaire), il ne me reste plus que la requête a décoder et a l ' envoyer via mon client.

Le document SSL de la boite ? Que veux-tu dire par là ? Le flux est chiffré par SSL ?

Autant pour moi désolé , une faute de frappe , je voulais parler bien sur des dsl(spec logicielles) qui contenait quelques indices sur des informations susceptible d ' apparaitre dans la requête.

Parce qu'il n'y a pas de méthodes miracles. Je dirais que c'est justement un truc de hacker. Faire joujou avec le système, l'observer, avoir de l'intuition, faire des tests, peut-être comprendre. Mais rien n'est garanti.

Compris. 
Je pensais qu ' il y avait deja des méthodes fiables pour décoder ce genre de requête.Mais étant donné que les requêtes dépendent directement du protocole propriétaire, il est logique qu ' aucune méthode infaillible de puisse permettre de les décoder.

Ce n'est pas en général en regardant UNE requête particulière que tu comprends un protocole, mais en en générant plusieurs dans lesquelles on fait varier à chaque fois des petits paramètres. Ces petits changements de paramètres peuvent provoquer des petits changements dans le flux, ce qui peut permettre de comprendre où sont stockés les informations dans le flux, et comment.

Merci beaucoup !!!
Je n ' y avais en effet pas pensé du tout 
Grâce a ce précieux conseil( en modifiant quelques éléments inhérents a mon message) et en s ' aidant de la dsl , j ' ai pu décrypter le corps du message ^^.Me reste plus que l ' entête( mais la je ne vois rien du tout a part des caractères non imprimables) a décoder.

Merci de ton aide 

[_o_]

Me reste plus que l ' entête( mais la je ne vois rien du tout a part des caractères non imprimables) a décoder.

Là, c'est probablement le truc le plus difficile. Les choses comme l'émetteur, le message, etc... sont en général relativement faciles à localiser et à décoder puisqu'on peut facilement les modifier. Pour le reste... Faut regarder pour voir s'il ne s'agit pas de choses du genre type de message, taille des données, sommes de contrôle, voir même trucs qui ne servent à rien (Aaaaah, les champs reserved for future use). Le plus chiant, c'est qu'il peut suffire qu'une des valeurs soit erronée pour que la requête soit refusée en bloc. Ça risque donc de tenir de la devinette.

En tout cas, si le protocole est assez simple, ça doit être quelque chose de sympa à faire.
Je dirais même plus : ça me donne des idées de challenge...

[Shiro]

Faut regarder pour voir s'il ne s'agit pas de choses du genre type de message, taille des données,

Encore une fois grand merci 
Les 4 premiers bits correspondait effectivement a la taille des données - 4 et j ' ai identifié les suivants comme appartenant probablement a la version du client utilisé.J ' ai pas encore trouvé le type de message , mais il doit forcement  y être car quant j ' envoi le message , je peut choisir son type en effet(confidentiel,urgent etc..)

voir même trucs qui ne servent à rien (Aaaaah, les champs reserved for future use)

Encore touché merci :p
J ' avais effectivement une ligne entière de bits a 0 qui correspond si je suis bien  le DSL a des champs"Not used" dont je n ' ai pas a m ' en préoccuper pour l ' instant.

Le plus chiant, c'est qu'il peut suffire qu'une des valeurs soit erronée pour que la requête soit refusée en bloc. Ça risque donc de tenir de la devinette.

Exactement  . Pour l' instant j ' ai essayé de balancer  au serveur des requêtes avec des paramètres au pif , mais j ' ai été jeté a chaque fois. Faudra attendre de décoder entièrement la requête pour qu ' il l ' accepte.

En tout cas, si le protocole est assez simple, ça doit être quelque chose de sympa à faire.
Je dirais même plus : ça me donne des idées de challenge...

Oui en effet , c ' est vraiment un travail d ' investigation qui mise tout sur la découverte et les sens de raisonnement( avec un peu de chance aussi parfois  . Et ravi que j ' ai pu te donner des idées de challenge car ce genre d ' investigation est toujours utile pour quant l ' on y sera confronté un jour ou l ' autre.

Merci de ton aide encore , il me reste un peu plus d ' une 10 aine de ligne a décoder et je pourrais terminer plus tôt que prévu le projet(étant donné que j ' ai déjà terminé le client de test).


Thx a lot