Le 22-11-2010, Kevin Denis <kevin@nowhere.invalid> a écrit :
Bonjour,
j'ai un très longue capture HTTP. Dans cette capture, j'ai des
parties texte (HTML, javascript, etc..) et des parties binaires (jpg,
gif, etc..).
La structure est connue:
HTTP/1.1 200 OK
(..des données d'entête)
<-- une ligne vide
des données (texte ou binaire, donc).HTTP/1.1 200 OK (et entetes, ligne
vide etc..)
J'ai donc bien un délimiteur de début (la ligne vide) et un de fin (le
HTTP/1.1 200 OK ou la fin de fichier).
Avec des outils "classiques" (ni perl, ni python donc) comment extraire
les données?
C'est un jeu ? On a droit à quoi ? awk ? sed ? grep ? head ? tail ?
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Avec des outils "classiques" (ni perl, ni python donc) comment extraire les données?
C'est un jeu ? On a droit à quoi ? awk ? sed ? grep ? head ? tail ?
Pire, c'est un exercice de style. Genre occupation de maso.
Je passe, ayant tendace a utiliser des outils qui me facilitent la vie.
:-)
-- When in doubt, use brute force. -- Ken Thompson
Kevin Denis
Le 22-11-2010, Marc Boyer a écrit :
C'est un jeu ?
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire directement les fichiers échangés par HTTP depuis une capture .cap. Apparement, non. tcpflow permet de reconstruire le flux, d'ou le fichier que j'obtiens, mais pas d'en extraire les fichiers.
Je n'ai pas envie de sortir l'interpréteur de commande pour ça. Autant les classiques (awk, sed, etc..) sont bons pour traiter du texte, autant je me demande comment ils vont réagir lorsqu'il y a du binaire au milieu du texte. D'où ma question. -- Kevin
Le 22-11-2010, Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> a écrit :
C'est un jeu ?
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire
directement les fichiers échangés par HTTP depuis une capture .cap.
Apparement, non.
tcpflow permet de reconstruire le flux, d'ou le fichier que j'obtiens,
mais pas d'en extraire les fichiers.
Je n'ai pas envie de sortir l'interpréteur de commande pour ça.
Autant les classiques (awk, sed, etc..) sont bons pour traiter du
texte, autant je me demande comment ils vont réagir lorsqu'il y a du
binaire au milieu du texte. D'où ma question.
--
Kevin
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire directement les fichiers échangés par HTTP depuis une capture .cap. Apparement, non. tcpflow permet de reconstruire le flux, d'ou le fichier que j'obtiens, mais pas d'en extraire les fichiers.
Je n'ai pas envie de sortir l'interpréteur de commande pour ça. Autant les classiques (awk, sed, etc..) sont bons pour traiter du texte, autant je me demande comment ils vont réagir lorsqu'il y a du binaire au milieu du texte. D'où ma question. -- Kevin
Tonton Th
On 11/23/2010 10:14 AM, Kevin Denis wrote:
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire directement les fichiers échangés par HTTP depuis une capture .cap. Apparement, non.
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire
directement les fichiers échangés par HTTP depuis une capture .cap.
Apparement, non.
Même wireshark ?
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire directement les fichiers échangés par HTTP depuis une capture .cap. Apparement, non.
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire directement les fichiers échangés par HTTP depuis une capture .cap. Apparement, non.
Même wireshark ?
Wireshark le fait très bien. Mais c'est manuel. tshark permet de faire pas mal de choses très intéressantes, mais pas moyen d'automatiser l'extraction des données. Là, j'ai ça à traiter: :~$ capinfos capture.cap File name: capture.cap File type: Wireshark/tcpdump/... - libpcap File encapsulation: Ethernet Number of packets: 237804 File size: 223462448 bytes Data size: 219657560 bytes Capture duration: 5189 seconds Start time: Fri Nov 19 14:48:55 2010 End time: Fri Nov 19 16:15:24 2010 Data byte rate: 42330.26 bytes/sec Data bit rate: 338642.11 bits/sec Average packet size: 923.69 bytes Average packet rate: 45.83 packets/sec
Donc je préfère automatiser un maximum la prédigestion de cette capture plutôt qu'aller la lire dans Wireshark. -- Kevin
Le 23-11-2010, Tonton Th <tth@la.bas.invalid> a écrit :
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire
directement les fichiers échangés par HTTP depuis une capture .cap.
Apparement, non.
Même wireshark ?
Wireshark le fait très bien. Mais c'est manuel. tshark permet
de faire pas mal de choses très intéressantes, mais pas moyen
d'automatiser l'extraction des données. Là, j'ai ça à traiter:
kevin@zipslack:~$ capinfos capture.cap
File name: capture.cap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Ethernet
Number of packets: 237804
File size: 223462448 bytes
Data size: 219657560 bytes
Capture duration: 5189 seconds
Start time: Fri Nov 19 14:48:55 2010
End time: Fri Nov 19 16:15:24 2010
Data byte rate: 42330.26 bytes/sec
Data bit rate: 338642.11 bits/sec
Average packet size: 923.69 bytes
Average packet rate: 45.83 packets/sec
Donc je préfère automatiser un maximum la prédigestion de cette capture
plutôt qu'aller la lire dans Wireshark.
--
Kevin
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire directement les fichiers échangés par HTTP depuis une capture .cap. Apparement, non.
Même wireshark ?
Wireshark le fait très bien. Mais c'est manuel. tshark permet de faire pas mal de choses très intéressantes, mais pas moyen d'automatiser l'extraction des données. Là, j'ai ça à traiter: :~$ capinfos capture.cap File name: capture.cap File type: Wireshark/tcpdump/... - libpcap File encapsulation: Ethernet Number of packets: 237804 File size: 223462448 bytes Data size: 219657560 bytes Capture duration: 5189 seconds Start time: Fri Nov 19 14:48:55 2010 End time: Fri Nov 19 16:15:24 2010 Data byte rate: 42330.26 bytes/sec Data bit rate: 338642.11 bits/sec Average packet size: 923.69 bytes Average packet rate: 45.83 packets/sec
Donc je préfère automatiser un maximum la prédigestion de cette capture plutôt qu'aller la lire dans Wireshark. -- Kevin
Tonton Th
On 11/23/2010 10:41 AM, Kevin Denis wrote:
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire directement les fichiers échangés par HTTP depuis une capture .cap. Apparement, non.
Même wireshark ?
Wireshark le fait très bien. Mais c'est manuel. tshark permet de faire pas mal de choses très intéressantes, mais pas moyen d'automatiser l'extraction des données. Là, j'ai ça à traiter:
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire
directement les fichiers échangés par HTTP depuis une capture .cap.
Apparement, non.
Même wireshark ?
Wireshark le fait très bien. Mais c'est manuel. tshark permet
de faire pas mal de choses très intéressantes, mais pas moyen
d'automatiser l'extraction des données. Là, j'ai ça à traiter:
Tu as regardé : http://bitbucket.org/haypo/hachoir/wiki/Home ?
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Pas vraiment. Je pensais qu'un outil 'tout prêt' permettait d'extraire directement les fichiers échangés par HTTP depuis une capture .cap. Apparement, non.
Même wireshark ?
Wireshark le fait très bien. Mais c'est manuel. tshark permet de faire pas mal de choses très intéressantes, mais pas moyen d'automatiser l'extraction des données. Là, j'ai ça à traiter:
Oui, mais c'est du Python. L'OP a précisé qu'il ne désirait pas utiliser de langages faits pour ça, tel Perl. Qui est un outil "classique", puisqu'il fait partie de l'userland de base de pas mal d'Unix.
Pourtant, son problème se torche en 10 lignes de Perl...
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Tonton Th <tth@la.bas.invalid> wrote:
Tu as regardé : http://bitbucket.org/haypo/hachoir/wiki/Home ?
Oui, mais c'est du Python. L'OP a précisé qu'il ne désirait pas utiliser
de langages faits pour ça, tel Perl. Qui est un outil "classique",
puisqu'il fait partie de l'userland de base de pas mal d'Unix.
Pourtant, son problème se torche en 10 lignes de Perl...
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Oui, mais c'est du Python. L'OP a précisé qu'il ne désirait pas utiliser de langages faits pour ça, tel Perl. Qui est un outil "classique", puisqu'il fait partie de l'userland de base de pas mal d'Unix.
Pourtant, son problème se torche en 10 lignes de Perl...
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Kevin Denis
Le 23-11-2010, Tonton Th a écrit :
Wireshark le fait très bien. Mais c'est manuel. tshark permet de faire pas mal de choses très intéressantes, mais pas moyen d'automatiser l'extraction des données. Là, j'ai ça à traiter:
Oui, comme d'autres outils de 'carving' comme scalpel.
Ces outils sont fait pour "trouver" des types de fichier dans un flux indéfini. Là, je ne cherche pas un type de fichier, mais à récupérer tous les fichiers dans un flux défini. -- Kevin
Le 23-11-2010, Tonton Th <tth@la.bas.invalid> a écrit :
Wireshark le fait très bien. Mais c'est manuel. tshark permet
de faire pas mal de choses très intéressantes, mais pas moyen
d'automatiser l'extraction des données. Là, j'ai ça à traiter:
Tu as regardé : http://bitbucket.org/haypo/hachoir/wiki/Home ?
Oui, comme d'autres outils de 'carving' comme scalpel.
Ces outils sont fait pour "trouver" des types de fichier dans un flux
indéfini. Là, je ne cherche pas un type de fichier, mais à récupérer
tous les fichiers dans un flux défini.
--
Kevin
Wireshark le fait très bien. Mais c'est manuel. tshark permet de faire pas mal de choses très intéressantes, mais pas moyen d'automatiser l'extraction des données. Là, j'ai ça à traiter:
Oui, comme d'autres outils de 'carving' comme scalpel.
Ces outils sont fait pour "trouver" des types de fichier dans un flux indéfini. Là, je ne cherche pas un type de fichier, mais à récupérer tous les fichiers dans un flux défini. -- Kevin
Kevin Denis
Le 23-11-2010, Xavier a écrit :
Pourtant, son problème se torche en 10 lignes de Perl...
bon, s'il faut en passer par là, je prends les 10 lignes de perl. -- Kevin
Le 23-11-2010, Xavier <xavier@groumpf.org> a écrit :
Pourtant, son problème se torche en 10 lignes de Perl...
bon, s'il faut en passer par là, je prends les 10 lignes de perl.
--
Kevin