Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
939 connectés 

  FORUM HardWare.fr
  Programmation
  Divers

  reverse engineering réseau

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

reverse engineering réseau

n°1507989
wkta1
Posté le 28-01-2007 à 17:35:33  profilanswer
 

Bonjour à tous,
 
Je cherche des info. sur les techniques de reverse engineering appliquées
aux réseaux. Mon objectif est de comprendre les mécanismes d'une application
de type client-serveur afin de développer un client compatible plus performant.
 
Le protocole de communication utilisé m'est inconnu.
J'utilise actuellement Ethereal... avec peu de résultats.

- important -
Le procédé n'est pas illégal dans la mesure où il vise l'interopérabilité de programmes.
voir art. 6 de la Directive de la communauté Economique Européenne.

J'attends vos conseils/liens vers tuto. Ethereal/toute autre chose
que vous jugez utile dans le contexte définit plus haut.
 
Merci d'avance  :jap:  
WKTA.

mood
Publicité
Posté le 28-01-2007 à 17:35:33  profilanswer
 

n°1507992
jagstang
Pa Capona ಠ_ಠ
Posté le 28-01-2007 à 17:45:43  profilanswer
 

avec ethereal du devrais y arriver. de toute façon, tu n'as pas d'autre moyen si t'as pas de doc


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
n°1508056
Tamahome
⭐⭐⭐⭐⭐
Posté le 28-01-2007 à 22:27:10  profilanswer
 

n'importe quel sniffer réseau devrait faire l'affaire

n°1508074
anordem
Posté le 29-01-2007 à 00:00:00  profilanswer
 

Salut,
 
Si tu possèdes les applications client et serveur, il serait plus simple de les analyser directement. Car vouloir comprendre un protocole réseau juste en regardant les paquets, c'est un peu comme vouloir comprendre un algo de chiffrement à partir d'un message chiffré. :)
 
Donc le mieux pour ça est de prendre IDA ( http://www.datarescue.com/ ) et d'étudier les parties du code qui gèrent les communications réseau. C'est à mon avis, la méthode la plus efficace. Un sniffer n'est pas vraiment utile dans ce cas là.

n°1508081
IrmatDen
Posté le 29-01-2007 à 01:43:02  profilanswer
 

Salut,

anordem a écrit :

Donc le mieux pour ça est de prendre IDA ( http://www.datarescue.com/ ) et d'étudier les parties du code qui gèrent les communications réseau. C'est à mon avis, la méthode la plus efficace. Un sniffer n'est pas vraiment utile dans ce cas là.


Sauf que ça, c'est en général franchement illégal :/

n°1508172
pfuitt
Posté le 29-01-2007 à 13:15:55  profilanswer
 

tu as l'outil, il ne te manque que la méthode !
une fois j'ai du faire ce genre d ebidouille pour le meme genre de finalité... tu te fais une liste des fonctions de bases 'simples' qui passent du client au serveur, tu les active, et tu snif pour voir quelle trame correspond à quelle fonction...
tu itères en faisant varier un parametre etc etc jusqu'a ce que tu comprennes le mechanisme de comm... bon c'est brutal, sans garantis mais perso, cela a fonctionné... mais j'avais un truc simple du style  
<enc><bla><fct><para1><param2>... <Cks></enc>
<enc></enc> sont des balises de debut fin,
<bla>un truc typique 'metier',
<fct> un code fonction suivi de ces parametres,
<Cks> pour le checksum...
 
voilo
 

n°1508180
anordem
Posté le 29-01-2007 à 13:36:47  profilanswer
 

IrmatDen a écrit :

Sauf que ça, c'est en général franchement illégal :/


Réponse :

wkta1 a écrit :

- important -
Le procédé n'est pas illégal dans la mesure où il vise l'interopérabilité de programmes.
voir art. 6 de la Directive de la communauté Economique Européenne.


 

pfuitt a écrit :

...
tu itères en faisant varier un parametre etc etc jusqu'a ce que tu comprennes le mechanisme de comm... bon c'est brutal, sans garantis mais perso, cela a fonctionné... mais j'avais un truc simple du style  
<enc><bla><fct><para1><param2>... <Cks></enc>
<enc></enc> sont des balises de debut fin,
<bla>un truc typique 'metier',
<fct> un code fonction suivi de ces parametres,
<Cks> pour le checksum...
...


 
Effectivement, je n'avais pas pensé à la possibilité d'avoir du texte en clair, je pensais plus à des données binaires. Mais pour documenter un protocole complet, c'est quand même plus efficace d'analyser le programme. On est sûr de ne rien oublier. Par contre, évidemment, il faut connaître l'assembleur...

n°1512991
wkta1
Posté le 10-02-2007 à 14:36:55  profilanswer
 

Merci à tous pour vos réponses.
 
Pour l'instant, j'ai réussi à imiter les fonctions de base en sniffant
les paquets réseau et en les recopiant dans mon nouveau programme.
 
Par contre, les fonctions plus évoluées transmettent des données
binaires (codant par ex des valeurs numériques ou des structures complexes)
plus nombreuses et parfois (il me semble) compréssées...
 
Le problème n'est donc pas trivial.
 
Anordem -> penses tu réellement qu'il soit possible de déduire
un protocole réseau à partir d'un code désassemblé ?
Je connais un peu l'assembleur et le désassemblage de programme
mais le contenu de transmissions réseaux est finalement situé à un
haut niveau d'abstraction (couche Application du modèle tcp/ip)
c'est pourquoi je ne comprend pas ta proposition.

n°1512992
IrmatDen
Posté le 10-02-2007 à 14:41:24  profilanswer
 

Tu pourras y trouver l'encodage/compression, si c'est utilisé ;)

n°1513106
anordem
Posté le 10-02-2007 à 22:32:31  profilanswer
 

D'après WikiPedia :

Citation :

un protocole de communication est une spécification de plusieurs règles pour un type de communication particulier.


En ce qui nous concerne, cela précise de quelles façons envoyer des données entre un client et un serveur. Les 2 utilisent les mêmes règles pour se comprendre et savent donc utiliser le protocole pour envoyer et/ou recevoir des données.  
 
Ces données viennent de quelque part et sont mises en forme par des fonctions en respectant certaines règles. Quelque soit la manière d'envoyer ces données, elles ne changeront pas. Seul leur agencement devra respecter le protocole.
 
Donc en étudiant ces fonctions de "mise en forme", on peut retrouver les règles du protocole. Par contre, on ne pourra évidemment retrouver que les spécifications utilisées par le logiciel. En fait, ça revient au même que documenter un format de fichier.
 
Donc pour répondre à ta question, oui il est tout à fait possible de retrouver un protocole réseau, ou du moins la partie utilisée par l'application, à partir d'un code désassemblé. Je dirais même que le reverse engineering sert à ça. :) D'ailleurs, tu parles de structures complexes compressées. Comment connaître l'algorithme de compression utilisé sans analyser le programme ?
 
La méthode que tu emploies peut donner des résultats pour des petits protocole très simples. Mais dès qu'on touche aux choses sérieuses, c'est beaucoup plus rapide et efficace d'analyser directement le programme. Evidemment, cela demande un gros travail d'analyse et les connaissances qui vont avec.
 
Si t'as d'autres questions, n'hésite pas, ici ou même en MP. :)


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Divers

  reverse engineering réseau

 

Sujets relatifs
connexion ODBC BDD_mysql sur un réseau[VBS]Script mappage reseau
reseau IPbatch qui ping toutes les machines d'un réseau
Installer une imprimante réseau via un scriptPPC et Reseau
le transfert de fichier sur le reseau (avec Ada)programmation drivers reseau sous winows
Présentation style powerpoint et contenu dynamique en réseau.C/C++ scan postes et applications réseau
Plus de sujets relatifs à : reverse engineering réseau


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR