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

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 

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

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