Scapy en Perl: Scaperl

Sylvain SARMEJEANNE wrote:

Bonjour,
Scaperl est un outil permettant de créer des paquets réseaux à la
main, de les envoyer, ainsi que d'écouter sur une interface. Il est
basé sur PCAP et la libdnet. Il a été testé sur NetBSD, GNU/Linux
et Windows XP et devrait normalement aussi fonctionner sur d'autres
plate-formes (FreeBSD, OpenBSD, Mac OS X ou les Unix propriétaires).

Le but est d'avoir une implémentation minimale, portable et efficace
des concepts de Scapy (écrit en Python) avec un code commenté et
documenté.

C'est la première version publique, peu de dissectors et de champs ont
été implémentés pour l'instant.

Bonjour,

je suis un peu décu de voir que tu n'as pas utilisé Net::Packet
pour scaperl. En effet, je viens de le porter sous Windows
(ActivePerl), et j'utilise aussi Net::Pcap et Net::Libdnet (que
j'ai réussis a utiliser sous Windows).

Toutes les limitations que tu cites dans la section sur ton site
sont levées par l'utilisation de Net::Packet.

Les PPM pour installer Net::Packet sous Windows sont ici:
http://www.gomor.org/files/ppm/

Il faudra tout de même installer vcredist_x86.exe, puisque j'ai
compilé les modules avec Visual C++ Express 8.0. Ce
package se trouve sur www.microsoft.com, taper
vcredist_x86.exe dans le champ recherche.

Sinon, le PPM Socket6 de activestate bug, donc il faudra installer
celui qui est fourni sur mon site.

Cordialement,

--
^ ___ ___ http://www.GomoR.org/ <-+
| / __ |__/ Systems & Security Engineer |
| __/ | ---[ zsh$ alias psed='perl -pe ' ]--- |
+--> Net::Packet <=> http://search.cpan.org/~gomor/ <--+

Bonjour,
Scaperl est un outil permettant de créer des paquets réseaux à la
main, de les envoyer, ainsi que d'écouter sur une interface. Il est
basé sur PCAP et la libdnet. Il a été testé sur NetBSD, GNU/Linux
et Windows XP et devrait normalement aussi fonctionner sur d'autres
plate-formes (FreeBSD, OpenBSD, Mac OS X ou les Unix propriétaires).

Le but est d'avoir une implémentation minimale, portable et efficace
des concepts de Scapy (écrit en Python) avec un code commenté et
documenté.

C'est la première version publique, peu de dissectors et de champs ont
été implémentés pour l'instant.

Ceux que ça intéresse peuvent allez jeter un oeil à
http://sylvainsarmejeanne.free.fr/projects/scaperl pour plus d'infos et
pour la doc.

Sylvain SARMEJEANNE

j'ai regardé un peu et je dit : Woaw.
belle prestation merci de l'avoir fait.

--
dominix

Sylvain SARMEJEANNE wrote:

Bonjour,
Scaperl est un outil permettant de créer des paquets réseaux à la
main, de les envoyer, ainsi que d'écouter sur une interface. Il est
basé sur PCAP et la libdnet. Il a été testé sur NetBSD, GNU/Lin ux
et Windows XP et devrait normalement aussi fonctionner sur d'autres
plate-formes (FreeBSD, OpenBSD, Mac OS X ou les Unix propriétaires).

Le but est d'avoir une implémentation minimale, portable et efficace
des concepts de Scapy (écrit en Python) avec un code commenté et
documenté.

C'est la première version publique, peu de dissectors et de champs ont
été implémentés pour l'instant.

Bonjour,

je suis un peu décu de voir que tu n'as pas utilisé Net::Packet
pour scaperl. En effet, je viens de le porter sous Windows
(ActivePerl), et j'utilise aussi Net::Pcap et Net::Libdnet (que
j'ai réussis a utiliser sous Windows).

Toutes les limitations que tu cites dans la section sur ton site
sont levées par l'utilisation de Net::Packet.

Les PPM pour installer Net::Packet sous Windows sont ici:
http://www.gomor.org/files/ppm/

Il faudra tout de même installer vcredist_x86.exe, puisque j'ai
compilé les modules avec Visual C++ Express 8.0. Ce
package se trouve sur www.microsoft.com, taper
vcredist_x86.exe dans le champ recherche.

Sinon, le PPM Socket6 de activestate bug, donc il faudra installer
celui qui est fourni sur mon site.

Cordialement,

Bonjour,
je m'étais effectivement penché sur Net::Packet quand j'ai commencé
à réfléchir sur Scaperl. Mais je pense qu'il n'est pas utilisable en
l'état pour réaliser un clone de Scapy pour plusieurs raisons :

- il met en place un attachement très fort entre un protocole et sa
position en couche. Par exemple, la méthode isIPv6() présente dans
Layer3 et pas dans Layer4 suggère qu'IPv6 ne peut se trouver qu'en
couche 3. Quid du tunneling d'IPv6 dans IPv4 ? C'est précisément un
des concepts de Scapy de pouvoir empiler les couches dans n'importe
quel ordre même si cela n'a pas de sens a priori (cf contournement
d'IDS). Un des exemples historiques de Scapy consitait à mettre à la
suite plusieurs en-têtes 802.1q afin de réaliser du VLAN hopping.

- dans Net::Packet::Frame, je crois comprendre qu'il y a un membre pour
chaque couche en niveaux 2, 3, 4 et 7. Sans demander où sont passées
les couches 5 et 6 ni préciser que les protocoles réseaux actuels ne
suivent pas le modèle OSI, on voit qu'il y a une limitation
structurelle du nombre de couches d'un paquet. Or, dans la doc de
Scaperl dans la partie performance, tu as dû voir que le deuxième
test consiste à créer un paquet de 500 couches. Dans Scapy, une
couche n'est pas équivalente à un protocole. Pour les dissectors des
gros protocoles (genre ceux pour NetBIOS/SMB auxquels j'ai participé),
on va les découper en couches plus fines (typiquement en-tête, corps
et suffixe) pour mieux les mixer.

- utiliser Net::Packet::IPv4 et autres revient à utiliser l'API de
Net::Packet qui est plus délicate à manier pour l'ajout de nouveaux
protocoles.

Sylvain SARMEJEANNE

Tout d'abord, merci de cette réponse. C'est exactement le genre de
retour que j'attend, et que personne ne me donne ;) Donc, merci.

Ensuite, tu as certainement regardé Net::Packet 2.xx, étant donné
que j'ai releasé 3.xx récemment. Dans 3.xx, j'ai fait un gros
effort pour décoreller chaque module composant Net::Packet, afin
de faire ce que tu dis ensuite. Maintenant, il peut rester des
bugs.

Sylvain SARMEJEANNE wrote:
[..]

l'état pour réaliser un clone de Scapy pour plusieurs raisons :

- il met en place un attachement très fort entre un protocole et sa
position en couche. Par exemple, la méthode isIPv6() présente dans

Quand on utilise Net::Packet::Frame, oui.

Layer3 et pas dans Layer4 suggère qu'IPv6 ne peut se trouver qu'en
couche 3. Quid du tunneling d'IPv6 dans IPv4 ? C'est précisément un
des concepts de Scapy de pouvoir empiler les couches dans n'importe
quel ordre même si cela n'a pas de sens a priori (cf contournement
d'IDS). Un des exemples historiques de Scapy consitait à mettre à la
suite plusieurs en-têtes 802.1q afin de réaliser du VLAN hopping.

Cet attachement a une couche peut être contourné. Concernant le
tunneling d'IPv6 dans un IPv4, c'est tout a fait possible avec
Net::Packet.
Concernant le VLAN hopping, c'est aussi possible. Voir
Net::Packet::VLAN.

Sinon, un exemple, pour IPv6 dans IPv4, en pseudo-code:

require Net::Packet::IPv4;
require Net::Packet::IPv6;
require Net::Packet::TCP;

my $ip4 = Net::Packet::IPv4->new(param ...);
my $ip6 = Net::Packet::IPv6->new(param ...);
my $tcp = Net::Packet::TCP->new(param ...);
$ip4->pack;
$ip6->pack;
$tcp->pack;

my $raw = $ip4->raw.$ip6->raw.$tcp->pack.

require Net::Write::Layer2;
my $l2 = Net::Write::Layer2->new(dev => 'eth0');
$l2->open
$l2->send($raw);
$l2->close;

Bon, en testant ca, j'ai trouvé un ou deux bugs ;) mais ce sont
des bugs, donc seront corrigés. Je ne suis pas entré, dans cet
exemple, dans les détails.

Je pourrai aussi montrer comment décoder, mais voici un lien:
http://www.gomor.org/files/mad2.txt
Qui n'a rien avoir avec IPv6 dans IPv4, mais le principe est le
même.

- dans Net::Packet::Frame, je crois comprendre qu'il y a un membre pour
chaque couche en niveaux 2, 3, 4 et 7. Sans demander où sont passées
les couches 5 et 6 ni préciser que les protocoles réseaux actuels ne
suivent pas le modèle OSI, on voit qu'il y a une limitation

Alors, les couches 2, 3 et 4, on va pas revenir dessus, tout le
monde sait ce que s'est. Par contre, la couche 7, la couche
applicative, je ne vais quand même pas l'appeler la couche 5.
La 5, c'est la couche session. Je serai choqué de voir la couche
applicative appelée couche 5.

structurelle du nombre de couches d'un paquet. Or, dans la doc de
Scaperl dans la partie performance, tu as dû voir que le deuxième
test consiste à créer un paquet de 500 couches. Dans Scapy, une
couche n'est pas équivalente à un protocole. Pour les dissectors des
gros protocoles (genre ceux pour NetBIOS/SMB auxquels j'ai participé),

Oui, donc, des dissesctors de couche 7 ; et ca, effectivement,
Net::Packet ne fait pas. Mais c'est pas dur a gérer a coté, ce qui
est plus interessant, c'est d'extraire la 7 du réseau, et
Net::Packet le fait.

[..]

- utiliser Net::Packet::IPv4 et autres revient à utiliser l'API de
Net::Packet qui est plus délicate à manier pour l'ajout de nouveaux
protocoles.

L'argument d'ajout de protocol restera très certainament vrai,
même pour l'avenir de Net::Packet. Même si je trouve pas ca si
dur d'en ajouter ;) mais bon, je suis l'auteur.

En conclusion, je dirai que ce que tu dis est plutot vrai pour
Net::Packet 2.xx, mais plutot faux pour 3.xx.

Sylvain SARMEJEANNE

--
^ ___ ___ http://www.GomoR.org/ <-+
| / __ |__/ Systems & Security Engineer |
| __/ | ---[ zsh$ alias psed='perl -pe ' ]--- |
+--> Net::Packet <=> http://search.cpan.org/~gomor/ <--+

Tout d'abord, merci de cette réponse. C'est exactement le genre de
retour que j'attend, et que personne ne me donne ;) Donc, merci.

Pas de quoi :)

Ensuite, tu as certainement regardé Net::Packet 2.xx, étant donné
que j'ai releasé 3.xx récemment. Dans 3.xx, j'ai fait un gros
effort pour décoreller chaque module composant Net::Packet, afin
de faire ce que tu dis ensuite. Maintenant, il peut rester des
bugs.

Initialement, c'est possible car j'ai réfléchi là-dessus au mois de
mai. Mais même la version 3.xx fait encore penser qu'IP ne peut
apparaître qu'en "couche 3" (cf ton diagramme de hiérarchie des
classes ou les méthodes présentes dans Layer3 et pas ailleurs).

Sylvain SARMEJEANNE wrote:
[..]

l'état pour réaliser un clone de Scapy pour plusieurs raisons :

- il met en place un attachement très fort entre un protocole et sa
position en couche. Par exemple, la méthode isIPv6() présente dans

Cet attachement a une couche peut être contourné.

Tu utilises toi-même le mot "contourné", ce qui signifie que c'est
comme ça de base.

Sinon, un exemple, pour IPv6 dans IPv4, en pseudo-code:

require Net::Packet::IPv4;
require Net::Packet::IPv6;
require Net::Packet::TCP;

my $ip4 = Net::Packet::IPv4->new(param ...);
my $ip6 = Net::Packet::IPv6->new(param ...);
my $tcp = Net::Packet::TCP->new(param ...);
$ip4->pack;
$ip6->pack;
$tcp->pack;

my $raw = $ip4->raw.$ip6->raw.$tcp->pack.

require Net::Write::Layer2;
my $l2 = Net::Write::Layer2->new(dev => 'eth0');
$l2->open
$l2->send($raw);
$l2->close;

Le même exemple avec Scaperl (en supposant écrit le dissector pour
IPv6), sd ("send") étant une méthode d'envoi :
scaperl> sd(IP()/IPv6()/TCP())

Je pourrai aussi montrer comment décoder, mais voici un lien:
http://www.gomor.org/files/mad2.txt

Avec Scaperl :
scaperl> sniff

Alors, les couches 2, 3 et 4, on va pas revenir dessus, tout le
monde sait ce que s'est. Par contre, la couche 7, la couche
applicative, je ne vais quand même pas l'appeler la couche 5.
La 5, c'est la couche session. Je serai choqué de voir la couche
applicative appelée couche 5.

Mais puisque les protocoles réseaux ne suivent PAS le modèle osi...

structurelle du nombre de couches d'un paquet. Or, dans la doc de
Scaperl dans la partie performance, tu as dû voir que le deuxième
test consiste à créer un paquet de 500 couches. Dans Scapy, une
couche n'est pas équivalente à un protocole. Pour les dissectors des
gros protocoles (genre ceux pour NetBIOS/SMB auxquels j'ai participé),

Oui, donc, des dissesctors de couche 7 ; et ca, effectivement,
Net::Packet ne fait pas. Mais c'est pas dur a gérer a coté, ce qui
est plus interessant, c'est d'extraire la 7 du réseau, et
Net::Packet le fait.

Tu te fixes trop sur le modèle OSI, cf ma remarque ci-dessus.

Sylvain SARMEJEANNE

Sylvain SARMEJEANNE wrote:
[..]

Ensuite, tu as certainement regardé Net::Packet 2.xx, étant donné
que j'ai releasé 3.xx récemment. Dans 3.xx, j'ai fait un gros
effort pour décoreller chaque module composant Net::Packet, afin
de faire ce que tu dis ensuite. Maintenant, il peut rester des
bugs.

Initialement, c'est possible car j'ai réfléchi là-dessus au mois de
mai. Mais même la version 3.xx fait encore penser qu'IP ne peut
apparaître qu'en "couche 3" (cf ton diagramme de hiérarchie des
classes ou les méthodes présentes dans Layer3 et pas ailleurs).

Et j'ai montré un exemple ou IP n'est rattaché a aucune couche.

[..]

Cet attachement a une couche peut être contourné.

Tu utilises toi-même le mot "contourné", ce qui signifie que c'est
comme ça de base.

Certe, mais tu joues sur les mots.

Et oui, il y a un comportement par défaut. Mais qui n'est en rien une
contrainte. Axiom Perl:
"Make easy things easy, and hard things possible"
"Rendre simple les choses simples, et possible les choses difficiles"

[..]

Le même exemple avec Scaperl (en supposant écrit le dissector pour
IPv6), sd ("send") étant une méthode d'envoi :
scaperl> sd(IP()/IPv6()/TCP())

Peut-être, mais rien n'empêche que dernière cette ligne de commande,

Net::Packet soit appelé.

[..]

Avec Scaperl :
scaperl> sniff

Même réponse.

[..]

Mais puisque les protocoles réseaux ne suivent PAS le modèle osi...

Et comme j'ai essayé de te le faire comprendre : c'est discutable.

[..]

Tu te fixes trop sur le modèle OSI, cf ma remarque ci-dessus.

Et franchement, je ne vois pas ou est le problème.

Sylvain SARMEJEANNE

Bon, maintenant, c'est ton programme, tu fais comme tu veux. Je
m'en fou moi ;) Et ces échanges avaient surtout pour but de promouvoir

Net::Packet, non pas de te faire reécrire ton programme en
l'utilisant.

Et pour finir comme j'ai commencé (cf .mon premier mail), j'étais
simplement décu de ne pas voir Net::Packet derrière Scaperl.
Mais je m'en remettrai ;)

--
^ ___ ___ http://www.GomoR.org/ <-+
| / __ |__/ Systems & Security Engineer |
| __/ | ---[ zsh$ alias psed='perl -pe ' ]--- |
+--> Net::Packet <=> http://search.cpan.org/~gomor/ <--+