J’avais parlé il y a quelque temps de GHDL, un simulateur VHDL pour GNU.

Aujourd’hui, je vais vous parler de son équivalent pour le Verilog : Icarus Verilog.

Il ressemble à GHDL dans son fonctionnement :

• on lance une compilation (au sens traditionnelle du terme, pas une synthèse) du code et de son test,
• on lance le programme (comme un binaire)
• on lit le fichier vcd ainsi généré avec GTKWave

Comme un exemple vaut souvent mieux qu’un long discours, voici le code, les commandes à lancer et le résultat obtenu dans le cas de la simulation d’une mémoire RAM :

Code de la RAM (RAM.v) :

module RAM( clk, dataIn, address, wren, dataOut );
  // Parametres
  parameter DATA_LENGTH    = 4;
  parameter ADDRESS_LENGTH = 3;
  
  // Entrees / Sorties
  input                            clk; // Horloge
  input [ DATA_LENGTH - 1 : 0 ]    dataIn; // Donnees entrantes
  input [ ADDRESS_LENGTH - 1 : 0 ] address; // Adresse
  input                            wren; // Write Enable
  output [ DATA_LENGTH - 1 : 0 ]   dataOut; // Donnees sortantes
  
  reg [ DATA_LENGTH - 1 : 0 ] dataOut;
  
  // Tableau pour stocker les donnees (c'est le coeur de la RAM)
  reg [ DATA_LENGTH - 1 : 0 ] data [ 2 ** ADDRESS_LENGTH - 1 : 0 ];
  
  always @( posedge clk )
  begin  
    if( wren == 1 )
    begin
      data[ address ] <= dataIn;
    end
    
    dataOut <= data[ address ];
  end
endmodule 

Code du TestBench (RAM_TB.v) :

// Periode de temps a 10 ns
`timescale 10 ns / 100 ps
module RAM_TB;
  
  // Entrees / Sorties
  reg            clk, wren;
  reg [ 3 : 0 ]  dataIn;
  reg [ 2 : 0 ]  address;
  wire [ 3 : 0 ] dataOut;
  
  // Instanciation de la RAM
  RAM ram_inst( clk, dataIn, address, wren, dataOut );
  
  // Sauvegarde du resultat dans un fichier
  initial
  begin
    $dumpfile( "RAM_TB.vcd" );
    $dumpvars; // On sauvegarde toutes les variables
  end
  
  // Horloge a 100 Mhz
  initial
    clk = 0;
  always
  begin
    #0.5;
    clk = ~clk;
  end

  // Stimulis
  initial
  begin
    address = 0;
    dataIn  = 0;
    wren    = 0;
    
    #1;
    
    address = 0;
    dataIn  = 7;
    wren    = 1;
    
    #1;
    
    address = 1;
    dataIn  = 5;
    wren    = 1;
        
    #1;
    
    wren    = 0;  
    
    #3;
    
    address = 1;
    dataIn  = 9;
    wren    = 1;
        
    #1;
    
    address = 0;
    
    #3;
    
    address = 1;    

    #3;
    
    $finish;
  end

endmodule

On lance ensuite les commandes qui vont bien (on remarquera la syntaxe semblable a celle de GCC) :

iverilog RAM_TB.v RAM.v -o RAMSimu
./RAMSimu
gtkwave RAM_TB.vcd

Et on obtient finalement le chronogramme suivant :

Références et liens :

• Site d’Icarius Verilog (en)
• Cours sur langage Verilog + liste de simulateurs libres (fr)

J’avais il y a une semaine posté un article sur le filtrage des commentaires WordPress avec Math Comment Spam Protection.
En commentaires, plusieurs personnes ont mentionné Akismet : il analyse les commentaires et décide s’il s’agit ou non de spam.

Comme Akismet est gratuit (mais demande quand même une clef) et payant pour un usage professionnel, je me suis demandé comment faire un plugin qui soit également capable de filtrer intelligemment les commentaires.

Je me suis donc mis en quête de statiques sur les mots les plus couramment utilisés, mais n’ayant rien trouvé de bien concluant, j’ai décidé d’analyser les 300 dernières pages du Planet, ce qui représente 3000 articles repartis sur environ 1 an.
Les résultats permettent d’extraire les mots les plus utilisés de la langue française et du jargon informatique (du moins, pour nous blogeur).
On pourrait ensuite choisir un certain nombre de ces mots et décider qu’au-dessus d’un pourcentage de mots présents dans le commentaire, celui-ci est valide.

Voyons rapidement, les résultats obtenus.

10 mots les plus utilisés :

de
le
la
et
à
les
un
des
en
pour

En utilisant ses mots clefs du français, on doit sans doute pouvoir détecter assez facilement si le commentaire est bien en français (et pas en anglais comme la majorité du spam).

On peut également regarder les mots en lien avec l’informatique.

20 mots les plus utilisés en rapport avec l’informatique :

version
libre
fichier
logiciel
serveur
Ubuntu
logiciels
système
site
source
fichiers
Linux
commande
données
configuration
libres
réseau
utilisateurs
sudo
web
code
Google
basé
machine
Firefox
Windows
distribution
licence
développement
installer

On pourrait alors éventuellement, mais cela risque d’être assez délicat, utiliser ce type de mots pour savoir si le commentaire parle bien d’informatique.
Les défenseurs du « GNU/Linux, ce n’est pas que Ubuntu ! » pourront noter qu’on retrouve plus souvent le mot Ubuntu que le mot Linux…

Pour finir, on peut regarder par simple curiosité les mots les moins utilisés.

Parmi les mots les moins utilisés, on trouve :

Dannois
Irrlicht
Lithium
Guadalajara
auvergnates
sociopathe
…

Pour ceux que ça intéresse, voici le dump de la liste, sous la forme (mot, nombre d’occurrences) qui contient les résultats.

Vous pouvez facilement la lire en Python avec le code suivant :

#!/usr/bin/env python
# -*- coding:Utf-8 -*-

#################
#### Modules ####
#################

import pickle

# On charge le fichier
fichier = open( ‘ListeOki.dat’ ,’rb’ )
listeMots = pickle.load( fichier )
fichier.close()

# On affiche les 20 iers éléments
print listeMots[ :20 ]

Aujourd’hui j’ai décidé de vous parler de matériel et pas de logiciel.
Rassurez vous, pas un nième article sur l’iPad, mais plutôt sur la création de circuits numériques, et bien sûr de libre.

Nous allons aborder les points suivants :

• Intérêt et utilisation des langages de description matérielle (VHDL et Verilog)
• Logiciels propriétaires
• Les IP’s
• Exemple de solution libre : GHDL et GTKWave
• Quelques composants de base
• Site qui référence de code libre

Intérêt et utilisation des langages de description matérielle (VHDL et Verilog)

Les langages de description matérielle comme le VHDL ou le Verilog sont utilisés pour créer la plupart des composants d’électronique numérique (qui manipulent des 0 et des 1 ie des valeurs quantifiées, par opposition à l’électronique analogique qui manipule des valeurs continues comme des tensions ou des courants).

Ainsi, vos processeurs, les puces qui décodent matériellement les vidéos dans vos téléphones portables ou les puces de vos routeurs ou de vos switchs sont développées avec du code comme si c’était un programme (avec quand même des différences, rassurez-vous !).

Si pour l’industriel la création de composants s’avère très coûteuse, c’est essentiellement car les temps de développement sont assez longs et doivent être accompagnés de temps de tests très très longs : en effet lors de l’envoi en fabrication, les premières réalisations coûtent très cher (j’ai entendu parler de 1 million d’euros) et si un bug a été oublié lors de l’étape de simulation, il va falloir recommencer (et donc payer de nouveau).
Si tout se passe bien, la production en masse pourra être lancée et en vendant beaucoup, l’entreprise pourra être bénéficiaire.
Les forts coûts de développement associés à la concurrence expliquent peut-être pourquoi aucun code issu d’industrie n’est sous licence libre ; je serais curieux et surpris de voir Intel diffuser le code de ses derniers processeurs !

Pour le particulier, qui n’a pas le budget d’une entreprise ni la nécessité de produire ses circuits à grande échelle, des composants programmables (CPLD/FPGA), abordables (environ 60€ pour un petit kit de développement disposant de 100 000 portes logiques, de boutons poussoirs, de switchs, de LED’s, d’afficheurs 7 segments, port PS2, …) permettent d’implémenter son code de façon assez simple.
On pourra par exemple utiliser un FPGA pour de la robotique ou de la domotique.

Les solutions privatrices

Logiciels propriétaires

Les FPGA’s qu’on peut trouver dans le commerce sont toujours fournis avec un logiciel permettant de simuler, de synthétiser (transformer le code en portes logiques, bascules, …) puis d’implémenter (placement + routage) le circuit sur le FPGA. C’est d’ailleurs souvent la qualité de ce logiciel qui aide à vendre le composant (ce qui est souvent le cas avec le matériel).

Si ces logiciels sont souvent multi plate-forme (Windows, Mac OS, GNU/Linux), ils sont cependant toujours propriétaires.

Il existe bien un simulateur libre, GHDL, dont je parle un peu plus bas, mais pour ce qui concerne la synthèse et l’implémentation du circuit, il faudra utiliser les logiciels propriétaires fournis.

C’est forcement, pour nous libristes, une mauvais chose de devoir utiliser ces logiciels. Mais il y a selon moi, une chose bien plus mauvaise que de devoir utiliser ces logiciels pour implémenter son code : c’est que les codes des composants eux-mêmes ne sont jamais libres !

Les IP’s

Dans le domaine des circuits, on parle souvent d’IP’s. Rien à voir ici avec les adresses IP ; on parle ici d’Intellectual property qui sont en réalité des bouts de circuit (donc de code) qui réalisent des fonctions spécifiques (mémoire FIFO, module Ethernet, …).
Ces IP’s, en plus d’avoir un code fermé, sont vendues très cher.

Utilisées dans des composants dont vous n’avez pas non plus le code source, il en résulte qu’il est impossible de savoir comment sont réalisés les composants que nous utilisons ni même ce qu’ils font. Pourquoi alors les défenseurs du logiciel libre ne parlent pas plus souvent de matériel ?

Les 4 libertés fondamentales du logiciel libre ne devraient-elles pas également s’adapter au matériel que nous utilisons ? Parce que justement c’est du matériel et pas du logiciel ? Eh bien non : après tout, il y a quand même un code source derrière, pourquoi n’aurions-nous pas le droit de l’étudier comme on peut le faire pour le code source d’un logiciel libre ?

Je trouve qu’il est assez paradoxal de vouloir des logiciels libres alors que le code du matériel que l’on utilise ne l’est même pas !

Espérant en avoir alerté quelques-uns sur le sujet (un seul serait déjà bien !), nous allons maintenant voir les solutions libres qui existent (même si elles ne sont pas nombreuses…).

Les solutions libres

Exemple de solution libre : GHDL et GTKWave

GHDL est un simulateur VHDL qui utilise GCC.
Il permet entre autres d’analyser son code VHDL, de le compiler (en un binaire, pas de le synthétiser en portes logiques) puis enfin de le simuler pour en vérifier le comportement.
Contrairement aux outils propriétaires, il ne permet vraiment que de tester le code.

Vous devriez l’avoir dans les dépôts de votre distribution.
À noter que si vous devez le compiler, il vous faudra gcc-ada.

Nous allons voir comment avec un petit exemple (compteur 3 bits) simuler le composant pour voir ensuite comment visualiser le résultat sous forme de chronogramme sous GTKWave.

On va utiliser les fichiers suivant :

• countern_en.vhd qui contient l’entité, l’architecture et la configuration du compteur
• countern_en_tb.vhd qui contient les paramètres de la simulation (test bench)

À noter que j’ai eu des problèmes en utilisant des majuscules dans mes noms d’entités…
Je vous conseille donc de les écrire en minuscule.

Ensuite il suffit de faire les commandes suivantes :

• Analyse des fichiers (production des fichiers objets .o) :
  

  ghdl -a countern_en.vhd
  ghdl -a countern_en_tb.vhd
      

• Élaboration (création du programme) :
  

  ghdl -e countern_en_tb
      

• Lancement de la simulation (qui produit en sortie le fichier countern_en_tb.vcd et qui s’arrête après 100 ns) :
  

  ghdl -r countern_en_tb --vcd=countern_en_tb.vcd --stop-time=100ns
      

On notera que ces étapes ressemblent très fortement à la compilation d’un programme classique.
C’est effectivement le cas, car comme dis précédemment, on crée un programme pour la simulation mais on ne fait pas la traduction code – portes logiques.

Ensuite, pour pouvoir visualiser graphiquement les résultats de la simulation, on va utiliser GTKWave.
Il suffit de le lancer avec comme paramètre le fichier de sortie de la simulation :

gtkwave countern_en_tb.vcd 

Ensuite, on sélectionne les signaux que l’on veut visualiser, on les ajoute (append), on clique sur Zoom Fit pour ajuster le zoom et la :

Il peut donc assez facilement utiliser une solution libre pour simuler le code que l’on est en train de développer (il faudra encore cependant passer par un logiciel propriétaire si on veut implémenter ce code sur FPGA…)

Quelques composants de base

J’ai eu l’occasion de faire quelques composants de base en VHDL, je vous les mets à disposition (sous licence GPL), en espérant qu’ils serviront à quelqu’un.

On trouvera :

• Convertisseur little endian/big endian
• Accumulateur
• Mémoire RAM
• Mémoire de type FIFO
• Mémoire CAM
• Calcul de checksum

Site de référence de code libre

Même si on ne trouve pas énormément de code sous licences libres, on trouve notamment des projets sur le web (le plus souvent développés lors de thèses ou projets de fin d’études) et il y a surtout un site (le plus gros) qui regroupe du code libre : OpenCores.org

On y trouve notamment plein de choses utiles comme des cores Ethernet, des contrôleurs I2C et SPI, des fonctions de hachage (MD5, SHA1, …) ; enfin, ce qui vous facilitera la vie lors de la création de projets libres.

Références et liens :

• Article Wikipedia sur le VHDL (fr)
• OpenCores (en)
• Fichiers de test pour GHDL (fr)
• Composants perso (fr)

Petit billet pour vous présenter nos problèmes et notre réflexion à propos du spam dans les commentaires de WordPress.

Au commencement était le spam

Au départ, nous n’utilisions aucun filtrage, nous acceptions par défaut tous les commentaires.
On a vite vu ce que ça a donné : des dizaines de commentaires à la c** en anglais pour vendre que je ne sais quel médicament pour agrandir le petit doigt ; il nous fallait alors une solution efficace et assez peu contraignante pour l’utilisateur.

Et le spam était la poubelle, et la poubelle était le spam

Nous avons finalement opté pour le plugin Math Comment Spam Protection.
Il affiche un champs supplémentaire dans les commentaires de type : quelle est la somme de sept + douze ?
Il suffit alors de taper la réponse (19 !) et ça roule !

Quelques points qui nous ont amené à le choisir :

• Possibilité de changer les nombres pour les calculs : cela permet de les mettre dans sa langue, le français en l’occurrence, ce qui limite les attaques
• Plus agréable à utiliser qu’un horrible captcha et surtout, possibilité pour les personnes mal voyantes de passer le test (qui, sauf erreur de ma part utilisent souvent des logiciels de synthèses vocales)

On peut cependant regretter que, pour une personne non francophone, cela est plus difficile.

Mais finalement assez efficace : 2 spams en plusieurs mois !

Il est toujours agréable d’avoir des miniatures pour ses vidéos.
En tant normal, dans GNOME, c’est Totem qui se charge de ça (enfin, la dernière fois que je m’en suis inquiété, c’était le cas !).
Mais pour les gens qui n’utilisent pas Totem (car ils ne l’aiment pas ou utilisent SMPlayer, VLC, …), c’est embêtant de le désinstaller car on perd les miniatures dans Nautilus…

Une solution pour remédier à ça est d’utiliser un script appelé Mplayer-video-thumbnailer qui charge mplayer de s’occuper de la génération des miniatures.
La dernière version (1.4-1) est écrite en Python mais va moins vite (enfin il me semble) que l’ancienne version (1.3-3) écrite, elle, en Shell.

Je vais donc rapidement vous expliquer comment l’installer :

Il suffit de

• Décompresser l’archive
• Lancer en root le script setup.sh qui va s’occuper en autre de copier le script dans /usr/bin/
• Lancer en utilisateur (donc pas en root) le script gconf.sh qui va configurer GNOME pour qu’il utilise le script précédemment installé pour générer les miniatures des vidéos.

A noter que le type des fichier supportés se trouvent dans le fichier video_ext de l’archive.
J’ai moi même ajouté :

/desktop/gnome/thumbnailers/video@x-matroska
/desktop/gnome/thumbnailers/video@x-flv

Références :

• Site officiel du projet (en)
• Version 1.3-3 du script

Saviez vous que votre gnome élève des poissons en secret ? Soyez gentil, prenez le temps d’en libérer un.

Pour cela, sous gnome uniquement, il faut faire la combinaison Atf+F2 (celle qui permet d’exécuter un programme) et entrer la commande :

free the fish

Et par la magie des cloches de pâques un petit poisson rouge va se balader sur votre écran. Cliquer dessus le fera fuir … mais il va revenir vous hanter jusqu’à la fin de votre journée Les deux seuls moyens de le faire partir définitivement sont soit de mettre un gros coup de canne à pêche sur votre écran, soit d’exécuter la commande

pkill gnome-panel

Le panel se relancera automatiquement si tout se passe bien (la première solution comporte probablement moins de risques pour votre système)

Un autre moyen de trouver cet Easter Egg (Œuf de Pâques) est de faire un clique droit sur un endroit vide d’une barre de menu, de cliquer sur « À propos des tableaux de bord », et d’appuyer 3 fois sur la touche ‘f’ du clavier.

Mais pour comprendre que finalement gnome n’est pas un méchant séquestreur de poissons relous qui veulent pas s’en aller, et que ces poissons vous protègent des tueurs de l’espace intersidérale, dans le lanceur d’application (Atl+F2), il faut rentrer la commande :

gegls from outer space

Le poisson se dirige avec les flèches du clavier, et espace permet de tirer. Ne vous laissez pas envahir !

Source : linuxtutorialblog.com

Aujourd’hui, nous allons voir comment mettre de côté un peu de place (300 Mio) sur une clef USB pour y installer SystemRescueCd.

Qu’est-ce que SystemRescueCd ?

Et bien SystemRescueCd est un liveCD crée dans le but d’être utilisé pour réparer son système.
En plus d’être bien documenté et parfaitement fonctionnel, il offre en plus plein de logiciels utiles dans toutes les occasions.
Citons par exemple les outils :
- Pour partitionner ou récupérer des données effacés (fdisk, GParted, TestDisk, PhotoRec, …)
- Pour réparer ses systèmes UNIX : possible par exemple de booter sur un noyau 32 bits ou 64 bits pour faire un chroot ensuite
- Pour remettre à 0 ses mots de passe Windows
- Pour tout le reste : anti virus, logiciels de backup, gestion de nombreux formats de partitions (dont NTFS), …

Autant dire, tout ce que vous risquez d’avoir besoin un jour ou l’autre !

Mettre ça sur sa clef USB

Le mieux pour ce genre d’outils est, je pense, de l’avoir toujours sous la main (il ne faut pas y penser une fois que l’on n’a plus un seul ordinateur qui boot dans la maison…).
Le mettre sur une clef USB semble donc une bonne chose.

Comme j’utilise aussi ma clef USB pour transporter des données, j’ai besoin qu’elle soit lisible sous Windows (je la mets donc en FAT32).
Mais comme Windows ne sais pas (ne veut pas !) reconnaître plusieurs partitions FAT32 sur un même disque, on est alors obligé de mettre la partition qui transportera les données en 1 et celle de SystemRescueCd en 2 (elle ne sera pas donc pas reconnue sous Windows, mais pas grave !).

Il y a sur le wiki de SystemRescueCd la possibilité de mettre ça facilement sur clef USB en quelques étapes :

root@sysresccd % sysresccd-usbstick listdev
Device [/dev/sdb] detected as [Kingston DataTraveler U3 ] is removable and size=957MB
Device [/dev/sdb] is not mounted
Device [/dev/sdb] has one partition: /dev/sdb1

root@sysresccd % sysresccd-usbstick writembr /dev/sdb
The device [/dev/sdb] seems to be big enough: 957 MB.
–> install-mbr /dev/sdb –force
–> parted -s /dev/sdb mklabel msdos
–> parted -s /dev/sdb mkpartfs primary fat32 0 100%
–> parted -s /dev/sdb set 1 boot on

root@sysresccd % sysresccd-usbstick format /dev/sdb1
The device [/dev/sdb1] seems to be big enough: 956 MB.
mkfs.vfat 2.11 (12 Mar 2005)
Partition /dev/sdb1 has been successfully formatted

root@sysresccd % sysresccd-usbstick copyfiles /dev/sdb1
The device [/dev/sdb1] seems to be big enough: 956 MB.
/dev/sdb1 successfully mounted on /mnt/usbstick
Free space on /mnt/usbstick is 956MB
Files have been successfully copied to /dev/sdb1

root@sysresccd % sysresccd-usbstick syslinux /dev/sdb1
syslinux has successfully prepared /dev/sdb1

Mais je ne sais pas pourquoi, quand j’adapte la méthode pour mon cas, cela vire mon partitionnement et utilise une seule partition qui fait la taille de la clef.
Pas l’idéal…

Voilà donc une méthode dérivée de celle ci pour faire ce que l’on veut (cela fait un peu bricolage mais marche très bien !) :

Commencez donc par sauvegarder les données de votre clef USB, puis partitionner là de la manière suivante (avec fdisk ou GParted ou …) :
- Première partition : FAT32 de la taille totale de votre clef – 301 Mio
- Deuxième partition : FAT32 de 301 Mio

Ensuite, à partir du liveCD de SystemRescueCd :

* On commence par lister les clefs USB disponibles :

root@sysresccd /root % sysresccd-usbstick listdev
Device [/dev/sdb] detected as [Verbatim STORE N GO ] is removable and size=3822MB
Device [/dev/sdb] is not mounted
Cannot identify which partition to use on /dev/sdb

C’est donc /dev/sdb qui nous intéresse ici.

* On formate la partition qui va contenir SystemRescueCd :

root@sysresccd /root % sysresccd-usbstick format /dev/sdb2
The device [/dev/sdb2] seems to be big enough: 305 MB.
mkfs.vfat 3.0.2 (28 Feb 2009)
Partition /dev/sdb2 has been successfully formatted

* On copie les fichiers nécessaires sur la clef :

root@sysresccd /root % sysresccd-usbstick copyfiles /dev/sdb2
The device [/dev/sdb2] seems to be big enough: 305 MB.
/dev/sdb2 successfully mounted on /mnt/usbstick
Free space on /mnt/usbstick is 306MB
Files have been successfully copied to /dev/sdb2

* On installe Syslinux :

root@sysresccd /root % sysresccd-usbstick syslinux /dev/sdb2
syslinux has successfully prepared /dev/sdb2

* On copie la routine d’amorçage (440 premiers octets, on ne supprime donc pas la table des partitions) :

root@sysresccd /root % dd if=/usr/share/syslinux/mbr.bin of=/dev/sdb
0+1 records in
0+1 records out
440 bytes (440 B) copied, 0.0141714 s, 31.0 kB/s

* On lance GParted, et on ajoute le drapeau Boot sur la partition /dev/sdb2.

Et voilà, à vous la belle clef USB pour quand vous aurez tout explosé !

Références :

• Site de SystemRescueCd (fr, en) : vous y trouverez une bonne documentation pour faire pas mal de chose avec la bête plus d’autre façons d’installer SystemRescueCd sur votre clef USB (si vous n’aimez pas ma méthode )

Après avoir lu l’article sur les DNS menteurs sur le blog Geekfault et notamment avoir découvert l’excellente liste de site à bloquer de chez pgl.yoyo.org, j’ai décidé de mettre en place un proxy filtrant sur mon ordinateur.

Cela a principalement 2 avantages :

• Permettre de filtrer les pubs quelque soit le navigateur. On utilise le même proxy filtrant avec Firefox ou Opera. On peut noter en plus que si on a des appareils mobiles du style SmartPhone, on peut aussi l’utiliser pour supprimer les pubs.
• Permettre aussi de remplacer l’extension RefControl de Firefox qui permettait de cacher son referrer (on n’a pas forcement envie que fsf.org sache que l’on vient de microsoft.fr… )

Premier essai avec Polipo :

Cela fait déjà un moment que j’entends parler de Polipo (et de son nom très poétique…) pour faire un proxy cache et filtrant sur un réseau avec un petit nombre de machines (voire éventuellement juste une machine) et ce de manière simple et rapide.
Si c’est vrai que la configuration de Polipo est vraiment très simple, il ne m’a pas vraiment convaincu :

• Il utilisait 2 à 25 % du processeur quand je surfait sur le net (un peu trop pour moi)
• Crasher environ toute les heures

Alors après, je ne sais pas si ma version (1.0.4.1) pose problème ou autre…
Je n’ai pas voulu passer plus de temps la dessus et je suis passé à un autre proxy : Privoxy.

Privoxy :

L’installation s’est faite sans problème (la version 3.0.16 était présente dans les dépôts de ma distribution, Archlinux).

Pour ce qui est de la configuration du logiciel en lui même, tout ce passe dans le fichier /etc/privoxy/config.
Rien de particulier à dire, le fichier est très bien commenté et facile à modifier. Vous pouvez de plus lire l’article de Artisan Numérique pour plus d’informations.
Vous pouvez quand même voir en fin d’article les fichiers de configuration que j’utilise pour Privoxy.

Là où ça commence à devenir intéressant, c’est quand on commence à aller regarder le fichier /etc/privoxy/user.action pour pouvoir modifier les règles de filtrage.
On peut définir des alias pour les règles de blocage. Pour ma part, je me suis contenté de franciser certains alias existants :

# ===================
# === Alias Perso ===
# ===================

# Interdire les cookies
interdiction-cookies          = +crunch-incoming-cookies +crunch-outgoing-cookies
# Autoriser les cookies
autorisation-cookies          = -crunch-incoming-cookies -crunch-outgoing-cookies
# Pour les sites d’e-commerce
boutique                      = autorisation-cookies allow-popups
# Pour les sites fragiles
fragile                       = -block autorisation-cookies -filter -fast-redirects -hide-referer -prevent-compression

Pour les règles, j’ai ajouté quelques règles personnelles pour autoriser/bloquer certains sites :

# ====================
# === Regles Perso ===
# ====================

# Masque le referer pour tous les sites
{ +hide-referrer{forge} }
/

# Site d’e-commerce
{ boutique }
.cdiscount.com
.fnac.com
.ldlc.com
.rueducommerce.fr
.topachat.com
.voyages-sncf.com

# Site fragile
{ fragile }
.ubuntu-fr.org

# Autorise
{ -block }
.pgl.yoyo.org

# Pubs, scripts, … a bloquer
{ +block }
.ad.fr.doubleclick.net
.cybermonitor.com
.friendlyduck.com
.image.jeuxvideo.com/concours
.image.jeuxvideo.com/images_amazon
.image.jeuxvideo.com/ope
.image.jeuxvideo.com/pubs
.statistics.gpotato.eu

On notera la première règle qui masque le referer sur tous les sites.
Et maintenant, pour finir en beauté, en plus des règles de base de Privoxy et quelques règles personnelles que l’on vient d’ajouter, on va utiliser celles de pgl.yoyo.org
On peut par exemple charger la liste sous sa forme la plus simple et rajouter le « . » au début de chaque ligne nécessaire pour bloquer tous les sites de la forme *.example.com/*
On peut faire ça, par exemple, facilement avec sed :

cat liste.txt | sed 's/.*/\.&/g'

Ensuite, on ajoute ça au fichier user.action :

# Liste de http://pgl.yoyo.org/adservers/
{ +block{Liste pgl.yoyo.org} }
.101com.com
.101order.com
.103bees.com
…

Et puis voilà !
Il ne reste plus qu’à régler votre navigateur (typiquement Adresse = 127.0.0.1 et Port = 8118).
Contrairement à Polipo, Privoxy ne prend chez moi qu’entre 1 et 2 % du CPU et n’a pas encore planté pour l’instant !

A vous le surf libéré des publicités et ce quelque soit votre navigateur !

Fichiers de configuration de Privoxy

Références :

• Article sur DNS menteur de Geekfault (2010, fr)
• Article sur Privoxy de Artisan Numérique (2010, fr)
• Liste de serveurs à bloquer chez pgl.yoyo.org (en)
• Manuel de Polipo (en)
• Manuel de Privoxy (en)

(j’ai noté que sur la plupart des articles concernant les proxies filtrant, un débat s’engageait sur le fait que bloquer la pub sur les sites de certains projets prive le développeur du peu de revenu qu’il avait.
Quoique vous en pensiez, rien ne vous empêche de mettre le site en question dans la liste des sites autorisés pour palier à ce problème).

Dans cet article je vais présenter rapidement comment n’utiliser que les ressources inutilisées de son ordinateur (enfin quasiment) en faisant ramer le moins possible les autres applications. Ceci est surtout intéressant pour les systèmes mono-cœur qui ont vite tendance à ramer quand celui-ci monte à 100% de sa charge, et peut s’avérer utile par exemple pour ré-encoder un DVD et garder un système fluide pour les autres applications, ou encore faire ses mises à jours sous gentoo sans se dire « demain je retourne sur ArchLinux  »

L’outil à utiliser est « nice » qui je pense est fourni par défaut sur la plupart des systèmes GNU/Linux. L’option qui nous intéresse est -n prenant en paramètre un nombre entre -20 et 19. 19 étant la priorité minimale, donc celle qui permet de piquer le moins de ressources aux autres processus, et donc de faire ramer le reste du système le moins possible. La priorité est propagée aux processus fils, donc par exemple si on lance emerge avec la priorité 19, tous les processus que lancera emerge auront aussi la priorité 19.

Un petit exemple pour utiliser nice en donnant la priorité minimale à ffmpeg :

nice -n 19 ffmpeg paramètres_de_ffmpeg …

Pour plus d’info sur nice, je vous laisse regarder le man.

Il faut aussi savoir que pour élever la priorité d’un processus (donc donner un nombre négatif à nice), il faut les droits root.

Donner une priorité plus faible à un processus (donner un nombre positif à nice) va aussi ralentir l’exécution de ce processus. Si le système est peu chargé, le ralentissement est négligeable, mais si une autre application lancée en même temps prend beaucoup de ressources, le ralentissement peut être important.

Il est aussi possible de changer la priorité d’un processus déjà lancé avec la commande renice. Je vous laisse vous référer au man de renice.

EDIT : Je remercie nico pour son commentaire qui nous informe qu’il est possible d’utiliser la commande ionice pour faire la même chose mais sur les entrées/sorties, ça peut être intéressant pour les applications qui font énormément d’appels au disque dur.

Les bornes WiFi publiques (celles ou vous ne rentrez pas de clé WEP ou WPA lors de la connexion) peuvent vraiment dépanner, mais présentent aussi un risque non négligeable. En effet, les données que vous échangez avec la borne se baladent dans l’air sans être cryptées, et peuvent très facilement être interceptées. Dans cet article, je vais présenter rapidement la démarche à suivre pour snifer une connexion, et se connecter à la place d’une victime sur son compte facebook.

Pour snifer une connexion WiFi, nous allons avoir besoin des outils suivants : airmon-ng qui est disponible dans la suite aircrack-ng, avec une carte WiFi compatible avec le mode monitor, et de wireshark

Il faut commencer par passer sa carte WiFi en mode monitor avec la commande suivante (à adapter avec le nom de votre carte WiFi)

# airmon-ng start wlan0

Si tout se passe bien, airmon passe alors votre carte WiFi en mode monitor, en disant quelque chose de semblable à ça : « (monitor mode enabled on mon0) ». Il faut alors prendre note du nouveau nom de l’interface, dans mon cas mon0.

Il faut ensuite lancer wireshark, et lancer la capture sur l’interface en mode monitor, mon0 dans mon cas. Wireshark va alors lister tout ce qui passe dans l’air.

Pour les exemples, voilà quelques cas fait sur mon ordinateur en local, mais ceci ne change rien par rapport aux paquets issus d’un WiFi public.

Sur ces screenshots, nous pouvons voir ce qui se passe lors d’une connexion à un serveur FTP, et une connexion à un site quelconque. Et le nom d’utilisateur ainsi que son mot de passe ( « test » sur les images) apparaissent en clair, pas très sécurisé tout ça … Et c’est le cas avec TOUTES les connexions à des site internet n’utilisant pas le ssl (adresse en https://)

Poussons le vice un peu plus loin, certains sites, comme facebook, proposent de rester connecté pour les prochaines visites, on ne verra donc pas le mot de passe. Nous allons donc récupérer le cookie, et le mettre dans firefox pour avoir accès à la page facebook de notre victime, et pouvoir faire ce que l’on veux sur sa page. (testé ce matin pendant un cours, et ça marche ^^)

Pour chercher dans la grosse quantité d’information dans wireshark, il est possible d’utiliser le filtre « http contains facebook ». Il faut alors chercher une page qui contient un cookie, comme la page d’accueil.

Sur la ligne cookie, faire clique droit, copier.

Le cookie de la victime est alors récupéré, il n’y a plus qu’à le mettre dans notre navigateur préféré, comme Firefox (aussi compatible avec Epiphany). Firefox gère les cookies dans des fichiers sqlite, j’ai donc écrit rapidement un petit script pour créer un fichier de cookie et y insère automatiquement les données extraites de wireshark dedans. Le script est téléchargeable ici, et nécessite d’avoir le programme sqlite3.

Il faut l’exécuter en lui donnant en paramètre le domaine du site auquel appartient le cookie, il faut coller le cookie issu de wireshark dans un fichier nommé « cookies.txt » dans le même répertoire que celui du script, et le script créé un fichier « cookies.sqlite ». Pour notre cas :

$ ./dump2sqliteCookie.sh .facebook.com

Il faut ensuite déplacer le cookie généré à la place de celui de firefox dans le dossier « ~/.mozilla/firefox/********.default/ ». Puis relancer firefox, et aller sur la page http://www.facebook.com et vous devriez arriver sur le mur facebook de votre victime avec le possibilité de faire n’importe quoi.

Comme vous pouvez le voir, cette manipulation reste relativement simple, et ne nécessite aucun piratage de machines. De plus, là j’ai présenté une version « artisanale », il doit très certainement y avoir des outils qui font tout ça automatiquement. Il est donc préférable de réfléchir à 2 fois avant d’utiliser un réseau WiFi public, et de ne pas échanger de données sensibles dessus.

Il faut toute fois noter que sur les sites internet en https, il n’est pas possible de récupérer les données de cette manière. Pour protéger la totalité du trafic, on peut aussi envisager de mettre en place un tunnel ssh qui permet de crypter la totalité du trafic entre votre machine, et celle qui héberge le serveur ssh, donc sur toute la zone critique entre vous et la borne WiFi.