C'est une très bonne initiative, je me suis déjà inscrit et je vous invite à faire de même. Le but cette année est d'attirer l'attention sur le problème de la PAUVRETE en publiant le 15 octobre un billet dans ce sens....allez-y, faite de bonnes choses, même minimale :)
C'est par là : blogactionday.org/fr
Read it in english with google

En revoyant quelques archives, je suis tombé sur un article qui me fait toujours rire :)
C'est ancien, mais ça ne s'use pas....je vous laisse lire et rigoler :)
Lors d’une conférence donnée au ComDex en 1998, Bill Gates, pour conclure, osa une comparaison entre les industries informatique et automobile : "Si General Motors avait eu la même progression technologique que l’industrie informatique, nous conduirions aujourd’hui des autos coûtant 25 dollars et qui parcourraient 1000 miles avec un seul gallon d’essence."
Si cela impressionna l’assistance, la réaction de General Motors ne se fit pas attendre : Son PDG M.Welch en personne donna une conférence de presse où il énonça : "Si General Motors avait développé sa technologie comme Microsoft, les voitures que nous conduirions aujourd’hui auraient les propriétés suivantes :
- Votre voiture aurait un accident sans raison compréhensible 2 fois par jour.
- Chaque fois que les lignes blanches seraient repeintes, il faudrait racheter une nouvelle voiture.
- Occasionnellement, une auto quitterait l’autoroute sans raison connue. Il faudrait simplement l’accepter, redémarrer l’auto et reprendre la route.
- Parfois, lors de manœuvres particulières, comme par exemple prendre une courbe a gauche, l’auto ferait un simple tout droit puis refuserait de repartir. Pour cela, il faudrait procéder à un échange standard du moteur.
- Les autos ne seraient livrées qu’avec un seul siège, car il faudrait choisir entre "Car95" et "CarNT". Chaque siège supplémentaire devrait être commandé à l’unité.
- Macintosh développerait des voitures fonctionnant à l’énergie solaire, fiable, cinq fois plus rapides et deux fois plus légères. Mais elles ne pourraient emprunter que 5% des routes.
- Les témoins d’huile, de température et de batterie seraient remplacés par un unique témoin "Défaillance Générale". Les sièges exigeraient que chaque passager ait la même taille et le même poids.
- L’airbag demanderait "Êtes-vous sûr ?" avant de s’ouvrir. Occasionnellement la condamnation centralisée de la voiture se bloquerait. Vous ne pourriez alors la rouvrir qu’au moyen d’une astuce, comme par exemple simultanément tirer la poignée de porte, tourner la clé dans la serrure et d’une autre main attraper l’antenne radio.
- General Motors vous forcerait à acheter avec chaque voiture un jeu de cartes routières Deluxe de la société Rand McNally (depuis peu filiale de GM), même lorsque vous ne souhaitez pas ou n’avez pas besoin de ces cartes. Au cas ou vous ne prendriez pas cette option, la voiture roulerait 50% moins vite (au mieux). A cause de cela, GM deviendrait une cible fréquente de procès.
- A chaque fois que GM sortirait un nouveau modèle, chaque conducteur devrait réapprendre à conduire, car aucune des commandes ne fonctionnerait exactement comme dans les modèles précédents.
- Enfin, il faudrait appuyer sur le bouton "Démarrer" pour stopper le moteur."
J'ai trouvé à travers ce post un article sur les 13 messages d'erreurs les plus drôles...et c'est vraiment drôle :).... et d'expérience, il ne faut pas trop se fier aux messages d'erreurs (s'il y en a déjà ! ) qu'on debug un problème....surtout les applications maison !
PS: j'ai appelé ce genre de post "Billet Flash" pour désigner des articles très courts sur des liens ou des astuces que je trouve durant ma veille techno...ça peut aider...et ça fait vivre le blog :)
Il y a quelques semaines, suite à l'agitation qui a entouré la découverte de la vulnérabilité de cache poisoning des serveur DNS, un ami m'a envoyé une capture réseau (fichier pcap) de la sortie Internet où il bosse afin que je jette un coup d'œil pour voir s'il y a d'éventuels trucs louches (tentatives d'attaques ou signes de compromission). La taille de la capture est de presque 120 Mo sur moins d'une heure...ça travail fort chez eux :)Alors, je lance la capture avec wireshark, et après quelques secondes il s'arrête en me disant qu'il y a un paquet avec une taille anormale.
Laissons tomber les interfaces graphiques et voyons en noir et blanc :)
Voyons tout d'abord les informations sommaires de la trace en question :
$ capinfos trace.pcap capinfos: An error occurred after reading 77202 packets from "trace.pcap": File contains a record that's not valid. (pcap: File has 2870302190-byte packet, bigger than maximum of 65535)
Humm...un paquet de 2870302190 octets, plus de 2.5 Go !!! ça sent le fichier corrompu.
Alors, peut être que dans le monde magnifique d'Internet, il y a des petits outils qui nous réparent ce type de problème...allo... Google ? j'ai besoin d'aide :)
Malheureusement, pas grand chose pour les premières pages, uniquement des gens qui se plaignent (si parmi vous, quelqu'un a un petit lien, je suis preneur :)). Mais je trouve un lien sur un blog de mon top 3 de meilleurs blogs.
Même pas ici...Richard ne fait que constaté et apparemment ne cherche pas à aller plus loin...dommage.
Je fait quoi maintenant ? je laisse tomber ?
Ce n'est pas vraiment important...mais je ne peux pas m'empêcher d'essayer de voir de plus près si je ne peux pas tirer quelque chose de cette trace (la partie corrompue).
Tout d'abord, il faut isoler le bon du mauvais :)... se taper chaque fois, avec tshark ou tcpdump, presque 30s pour arriver aux paquets qui nous intéressent est une perte de temps. (si quelqu'un connait une option pour allez directement à un paquet donné ça m'évitera la gymnastique qui suit)
On prend la partie valide :
$ tshark -c 77201 -r trace.pcap -w trace_ok.pcapOn obtient une trace de 60289623 octets....il suffit maintenant de copier à partir du 60289624 ème octet en utilisant "dd" :
$ dd bs=60289623 skip=1 if=trace.pcap of=trace_fail.pcapOn a notre fichier trace à traiter, avec une taille de 62896232 octets
On remarquera en passant que les deux parties sont presque de la même taille.
Mais à ce niveau, on a un petit problème, voyons ce que donne tshark :
$ tshark -r trace_fail.pcapSi c'était le premier message d'erreur ça serais normal...mais là c'est le format du fichier obtenu qui est en cause. D'accord, voyons la structure d'une trace pcap. le fichier pcap.h nous dit ça entre autres :
tshark: The file "trace_fail.pcap" isn't a capture file in a format TShark understands.
struct pcap_file_header {Il faudra alors ajouter le pcap_file_header, 24 octets au début du fichier (pas le temps de me casser la tête ... on utilisera ceux du fichier valide) :
bpf_u_int32 magic;
u_short version_major;
u_short version_minor;
bpf_int32 thiszone; /* gmt to local correction */
bpf_u_int32 sigfigs; /* accuracy of timestamps */
bpf_u_int32 snaplen; /* max length saved portion of each pkt */
bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
};
Pour ça "xxd" est là :
$ xxd trace_fail.pcap | xxd -r -s 24 > trace_bad.pcap (ajouter le header, des 0)Maintenant c'est reconnu comme trace pcap, mais on doit commencer à travailler les paquets pour qu'ils soient valides.
$ echo '00: d4c3 b2a1 0200' | xxd -r - trace_bad.pcap (modifier le header)
La structure de l'entête de chaque paquet est du genre :
/*On va utiliser la même valeur du "ts" que dans la trace valide et mettre une valeur commune pour "caplen" et "len".
* Each packet in the dump file is prepended with this generic header.
* This gets around the problem of different headers for different
* packet interfaces.
*/
struct pcap_pkthdr {
struct timeval ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
};
on met pour tous les packets ts = "0400 0000 0000 0000 0000 ffff 0000 0100 0000 e203 8748 cf24 0800"
Patchons le premier paquet (le paquet 77202 de la trace initiale) :
$ echo '06: 0400 0000 0000 0000 0000 ffff 0000 0100 0000 e203 8748 cf24 0800' | xxd -r - trace_bad.pcapC'est reconnu comme paquet, mais apparemment les champs sont bousillés aussi...modifiant ce qui parait sûr ou fort probable :
$ echo '38: 0800' | xxd -r - trace_bad.pcap (type de protocole : IP)
$ echo '3a: 4500' | xxd -r - trace_bad.pcap (version, longueur du header et service diff)Et maintenant ?.... toujours des champs avec du n'importe quoi...je crois que c'est mort pour la récupération...c'est du vrai corrompu :)
j'ai renommé le fichier en trace_corrupt_to_resolv_one_day.pcap :)...un jour, avec de la corrélation, de la IA,...etc on trouvera une réponse peut-être :)
Et alors, pourquoi ce billet me diriez-vous ?!!
En fait c'était amusant et intéressant pour moi, et j'espère que quelques uns le trouveront aussi...sinon, je compte aussi utiliser mon blog comme aide-mémoire accessible de partout, d'ailleurs je vais commencer de poster des billets sur des outils que je test chaque fois pour mes besoins professionnels et personnels.
C'est un billet qui consiste en une simple réorganisation du billet Etat des DNS Algériens....part II
Il me parait que j'ai "noyer" de nouvelles données, intéressantes je pense (surtout la contribution de tixxDZ dans la réécriture du script en perl). Alors, je leurs consacre un billet dédié tout en les laissant dans l'ancien billet....alors à vous les mises à jour (pour suivre il vaut avoir lu le billet cité au début)
J'ai failli déroger à une règle bien établie chez nous Algériens .... se comparer toujours à nos voisins :)
Alors, j'ai adapté les scripts pour les domaines marocains (ma) et tunisiens (tn)
Les résultats sont dans les archives maroc_dns.tgz et tunisie_dns.tgz
Un petit comparatif : (respectivement dz - ma - tn)
- Nombre de domaines / sous-domaines : 558 - 815 - 907
- Nombre de serveurs DNS autoritaires : 155 - 524 - 4
- Nombre de domaines gérés par le Registrar : 274 / 558 - 140 / 815 - 804 / 907
- Nombre de serveurs en version 9 : 69 / 155 - 243 / 524 - 2 / 4
- Nombre de serveurs en version 8 : 17 / 155 - 6 / 524 - 0 (les deux autres sous PowerDNS)
- Nombre de serveurs récursifs : 72 / 155 - 161 / 524 - 0
- Nombre de serveurs récursifs et vulnérables : 35 / 155 - 61 / 524 - 0
Vous remarquez qu'on est globalement les "moins bons" :)
Une chose intéressante ou étonnante est le quasi monopole du service DNS en Tunisie par l'Agence Tunisienne d'Internet !!!!!
je voudrais ajouter aussi la contribution excellente de tixxDZ, qui a porté et optimiser mon script shell en script perl appelé dnschk . Il y a plein d'améliorations ...mais on reste ouverts à toute nouvelle suggestion :)
Merci encore tixxDZ (il contribue avec pertinence dans forumdz)
En suivant et observant des débats sur forumdz, j'ai vérifié encore une fois l'exactitude d'un constat fait par certains amis :
"il y a deux domaines ou sujets où la majorité (tous ?) des algériens se considèrent, ou du moins agissent comme, experts : la religion et la politique".
Qui n'a pas assisté, sans le vouloir vraiment mais tout simplement en buvant un thé dans un café populaire, à une critique (pas analyse) de la politique nationale tous domaines confondus (santé, éducation, sport, affaires étrangères...) ? et quelques fois, même les questions internationales sont traitées :)
Cerise sur le gâteau, dans la plupart des cas, on donne même "les recettes magiques" qui nous sortiront de la crise multidimensionnelle qu'on vit actuellement....les "politilogues" ne manquent pas apparemment :)
Sur la même table du même café, on aura certainement droit à un débat sur des questions religieuses, de préférence en FIQH (jurisprudence islamique : فقه), où de grands savants (OULAMA) hésiteraient à donner une réponse aussi promptement !
Bien sûr, dans toutes ces discussions, TOUT LE MONDE A RAISON .... avez-vous déjà croisé un algérien qui admet s'être trompé ?! :)
Et pour les autres domaines, qu'en pensent les algériens ? pensez à une nouvelle théorie mathématique ou à une découverte en physique par exemple :)
Là, TOUS LE MONDE SE TAIT.... on respecte la spécialisation ben quoi... à chacun son domaine :)
Si je revient à forumdz (que j'apprécie toujours et j'y resterais inchallah), les modérateurs ont limité les contributions dans la section "religion" après quelques dérapages apparemment. Personnellement, je ne suit pas cette rubrique, non que je ne m'intéresse pas à la religion (au contraire), mais tout simplement que, primo, je sais qu'il n'y a pas de spécialistes, alors je ne vais rien apprendre, et secondo, tellement notre société est politisée à fond, les débats vont certainement déraper vers des chamailleries entre "courants politiques"
Moi je propose qu'on supprime carrément cette rubrique "religion", en attendant une maturité, malheureusement, encore absente !


