Discussion :

[ramzioil]

Bonjour,
J'ai une trace d'exécution d'un proc archi IA32 , il ya des milliers de block
je devrai savoir la relation entre les blocks? pour savoir quels sont les blocks qui me vont etre utiles .. comme vous le savez le proc exécute plusieurs taches en parallele donc ce fichier trace contient les suites d'instruction exécutés par toutes les applications courantes
est-ce que quelqu'un peut m'aider
merci

[Rémi Coquet]

Un peu de contexte permettrait de mieux comprendre ton problème qui peut avoir de nombreuses réponses en l'état...Le proc: Je pense que tu parles du µp
Le fichier trace: Un fichier de debug, organisé comment ? (En plus de la suite d'instructions courante ?)

je devrais savoir la relation entre les blocks?

Bien, tu devrais ou tu ne devrais pas savoir quoi ?
Le PE courant à qui appartient les instructions courantes ?

Si c'est le cas, des outils existent. Si c'est une question d'assembleur, et que tu désires fabriquer un traceur intelligent tu pars du mauvais pied (ou de la mauvaise main).

[ramzioil]

voila, mon problème est d'exploiter la trace d'execution du µproc d'un firewall d'un paquet entrant , donc le premier objectif sera : comprendre les appels de fonctions et les relations entre les blocs d'instructions pour qu'on puisse enfin convertir ces informations là en formules qui pourront nous decrire le comportement du firewall vis à vis du trafic d'entree
la je suis dans la phase de programmation du convertisseur trace d'exec/formules et j'arrive pas a me placer dans la case départ
merci

[Rémi Coquet]

Ce que je comprends en l'état:

- Un PE tiers, le firewall, est tracé par ton PE qui génère un fichier que tu désires organiser pour pouvoir l'exploiter (?)

ou, en faisant le // avec ton premier post:

- Un PE tiers, le firewall, est tracé (ainsi que tous les autres PE en cours d'exécution) par ton PE qui génère un fichier que tu désires organiser pour pouvoir l'exploiter mais les traces des divers PE sont mélangées (?)

Ou encore:

- Mon PE, le firewall, est capable de générer un fichier trace que je désire organiser pour pouvoir l'exploiter mais je ne sais pas ce que mon firewall fait (!!) - (?)

d'exploiter la trace d'execution du µproc d'un firewall d'un paquet entrant

n'est pas d'une compréhension aisée...

[ramzioil]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
block[2154745293;2154745314;         0]={IN: 
0x806ecdcd:  push   $0xd1
0x806ecdd2:  sub    $0x4,%esp
0x806ecdd5:  push   %esp
0x806ecdd6:  push   $0xd1
0x806ecddb:  push   $0x1c
0x806ecddd:  call   0x806eecac
 }
block[2154753196;2154753240;         0]={IN: 
0x806eecac:  xor    %eax,%eax
0x806eecae:  mov    0x4(%esp,1),%al
0x806eecb2:  mov    0x806ee258(%eax),%al
0x806eecb8:  mov    0xfffe0080,%ecx
0x806eecbe:  mov    %eax,0xfffe0080
0x806eecc3:  mov    0xc(%esp,1),%eax
0x806eecc7:  shr    $0x4,%ecx
0x806eecca:  mov    0x806f9088(%ecx),%cl
0x806eecd0:  mov    %cl,(%eax)
0x806eecd2:  mov    $0x1,%eax
0x806eecd7:  sti    
 }

Voici une partie du fichier que j'ai, ceci explique les instructions que le µp du firewall est en train d'exécuter.

[Rémi Coquet]

Les labels pourraient être identifiés sous certaines conditions.

Petit problème de décoration: call 0x806eecac

Si c'est un Call à un PE dont tu as le source, il faut que tu construises une table de conversion (par exemple, mais beaucoup d'autres moyens sont utilisables) de manière à pouvoir "repérer" les portions de code par le "contexte" d'utilisation des (de tes) diverses API. Idem pour les labels.

Ceci dit: Qui (quel PE) génère ce fichier ?

C'est le générateur qu'il faut modifier, sinon tu retombes inévitablement dans les techniques habituelles du RE et du dé-assemblage ré-assemblage.

Apparement le firewall n'est pas une de tes applications. faire un "crochet" de suveillance parait bien compliqué...

Quel est le but ? Précise un peu les données de ton problème car tout cela reste un peu nébuleux dans les détails.

[ramzioil]

a partir du fichier dont je t'ai donné une partie, je dois construire tous les appels de fonction que le µproc du firewall a générer et modeliser ca par les methodes formelles pour mieux déduire sur le comportement du firewall vis a vis du paquet

[Rémi Coquet]

a partir du fichier dont je t'ai donné une partie, je dois construire tous les appels de fonction que le µproc du firewall a générer et modeliser ca par les methodes formelles pour mieux déduire sur le comportement du firewall vis a vis du paquet

Ça c'est la seule partie claire: Le but intermédiaire, comprendre ce que fait le firewall à la réception des paquets. Mais quel est le but final: Recherche de failles de sécurité, "maintenance" ou débug du firewall

Les moyens et la méthode restent aussi nébuleux.

a partir du fichier

Généré par qui ? As-tu la main sur ce processus de génération ou pas ?
Si oui, c'est là qu'il faut intervenir pour encoder plus rationnellement.

µproc du firewall

Le µP exécute du code et parmi celui-ci un PE (le firewall).

- Si ton fichier est simplement du dé-assemblage de ram, nous sommes dans le domaine de l'ingénierie inverse (RE) qui possède ses propres outils et ses propres règles.
- Si tu possèdes le source du firewall, où est le problème de traçage ?
.

[ramzioil]

en fait le firewall il tourne sur une QEMU,
le but c'est de savoir le comportement du firewall avec le trafic
ca peut etre utile dans la validation des firewall
on peut par exemple comparer deux version du meme firewall par l'observation des formules sortante en injectant le meme trafic

[Rémi Coquet]

ca peut etre utile dans la validation des firewall

Je comprends "l'hypothèse" mais tu confirmes donc que tu ne possèdes pas le source du firewall à surveiller (à analyser en fait).

Il te faut donc te tourner vers le RE et ses cites spécialisés (ce n'est pas ce qui manque). C'est là une opinion toute personnelle mais d'autres peuvent te proposer diverses solutions.

Simplement: Pour pouvoir lire plus clairement le code d'un PE sous sa forme dé-assemblée, il te faut substituer aux différents labels (adresses, Lp) de code et de data des noms en clair. Tu peux récupérer les importations/exportations par exemple mais pour cela il faut que tu coures après chacune des dll (et autres PE invoqués par ton PE principal) afin de les dé-assembler et/ou récupérer leurs diverses exportations.
Tu pourras ainsi faire des substitutions plus pertinentes. Ceci dit, s'il utilise (le firewall) les API low-level d'un protocole réseau particulier ou des services/drivers tiers cela risque de t'emmener assez loin dans l'épluchage des différentes documentations appropriées. Il existe des outils de mesure de comportement pour les firewall assez puissants et adaptatifs. Certains mathématiciens proposent des modèles très performants ; cela touche à la mesure, à la qualité du produit mesuré, non à son code ou ses mécanismes proprement dit.

C'est un travail de R&D à temps complet, surtout s'il est question d'analyser des comportements et des fiabilités de plusieurs applications différentes. Pour terminer, si ton firewall se laisse analyser (émulateur ou pas), comme tu sembles le faire, c'est que le mur brûle déjà, justement... Il tolère les dump, même si tu les fais en différés. C'est déjà la preuve qu'il n'est, déjà, pas son propre mur, je vois mal comment il pourrait être celui d'autres... Tu peux d'ores et déjà passer au suivant !

[ramzioil]

oui il doit tolerer les dumps,
exemple: moi je construi un firewall, je doi le testé avant de le mettre sur le marché , je doi m'assurer sur son comportement avant de livrer au gens,

mon approche sera basée sur les méthodes formelles ,
je fais de R&D
mais c'est juste que la partie assembleur n'est pas trop mon truc
merci , c'est très gentil de ta part de répondre très rapidement.