Création manuelle d'un botnet "localisé"

Une méchante idée m'est venue en lisant un article de Slashdot : Cracked Linux Boxes Used to Wield Windows Botnets.

Afin de se composer un réseau de botnets, il serait extrêmement simple à une personne malveillante de vendre des routers ADSL modifiés (rootkités) sur des sites comme Ebay ou Ricardo en Suisse. L'utilisation pour l'acheteur pourrait être strictement similaire, au point qu'il ne se douterait pas que quelqu'un d'autre à la main sur son nouveau routeur.

Dans cet ordre d'idée, on voit de plus en plus de router ADSL se faire rootkiter à la suite d'un piratage d'un ordinateur. La raison principale : un mot de passe par défaut... Idem pour les connexions wireless : on la casse (l'histoire d'une journée pour du WEP avec du matériel correct) avant de s'attaquer au router !

En résumé, il serait presque rentable de se monter un botnet "localisé" et persistant, car placé dans des endroits stratégiques.

Deux petites recommandations pour éviter toutes mauvaises surprises : TOUJOURS modifier le mot de passe de vos routeurs (quitte à le noter dessous, le pirates devant hacker votre webcam et le robot téléguidé du petit frère pour réussir à placer le mot de passe dans le champs de vision de la webcam), et abandonner les connexions wireless...

La surjection, nouvelle maladie ?

La prochaine fois que vous allez chez le médecin, dites-lui que vous souffrez d'une surjection et que je avez besoin d'un injection pour retrouver un état stable de bijection...

Implémentation paresseuse du "Visitor pattern" en PHP

Sans m'étendre sur les bienfaits du Visitor pattern, dont le but est de séparer un algorithme de sa structure de données, je souhaite proposer ici une implémentation paresseuse mais possible en PHP.

En théorie ce pattern repose sur 2 interfaces qui permettent de faire un double dispatch (appeler depuis un objets visitable la fonction lui correspondant dans le visiteur) :

• Visitable qui contient une fonction apply(Visitor $v)
• Visitor qui contient une fonction visit(Visitable $v)
  

Puisqu'en PHP il n'est pas possible de faire de la surcharge de paramètres de fonction (polymorphisme), il faut donc appeler les fonctions différemment selon les types de structure de données.

En Java :

interface Visitor {
    void visit(Wheel wheel);
    void visit(Engine engine);
    void visit(Body body);
    void visit(Car car);
}
abstract class Visitable {
    void apply(Visitor visitor) {
        visitor.apply(this);
    }
}

En PHP :

interface Visitor {
    public function visitWheel($wheel);
    public function visitEngine($engine);
    public function visitBody($body);
    public function visitCar($car);
}
interface Visitable {
    public function apply(Visitor $visitor);
}

On remarque donc qu'en PHP on devra réécrire toutes les fonctions apply pour qu'elles appellent la fonction visit___ correspondant à leur type.
Mais paresseux comme je suis, la redéfinition de la fonction apply pour chaque visitable me parait un tâche trop répétitive et ennuyeuse. L'idée sous-jacente est de faire un dispatch dynamique en fonction du type du visitable, de la façon suivante :

abstract class Visitable {
    public function visit(Visitable $visitable)
    {
        $func = array(&$this, 'visit' . get_class($visitable));
        if (!is_callable($func)) {
            trigger_error('[' . get_class($this) . '] Class ' . get_class($this) . ' has no visit' . get_class($visitable) . ' function', E_USER_ERROR);
        }
        call_user_func($func, $visitable);
    }
}

Ainsi le visiteur devrait implémenter les fonctions standards visitWheel, visitEngine, ... mais leur dispatching devient automatique !

Mis à part la lourdeur de la fonction call_user_func, le reste de cette implémentation dynamique reste intéressante.

Références :
http://en.wikipedia.org/wiki/Visitor_pattern
http://en.wikipedia.org/wiki/Double_dispatch#Double_dispatch_is_more_than_function_overloading

Plus d'information pour les intéressés :
http://www.polyglotinc.com/reflection.html
http://www.javaworld.com/javaworld/javatips/jw-javatip98.html

Offre d'emploi : customer care

Ma petite startup, leader en suisse romande sur le marché des logiciels immobiliers, recherche un nouveau collaborateur afin d'assurer le support technique et la formation de ses nombreux clients.

Plus concrètement, le poste consisterait à répondre par téléphone/email aux questions techniques et d'assurer la formation des nouveaux clients sur les logiciels.

Le profile recherché est le suivant :

• Langue maternelle française, bon niveau en allemand un plus
  
• Excellentes capacités en communication, autant orales qu'écrites
  
• Bonne capacité à comprendre et résoudre les problèmes
  
• Capacité de travailler sur plusieurs tâches en parallèle
• Bonne compréhension de l'architecture client-serveur

Les postulations peuvent être directement adressées à info _A_T_ migtechnology _P_O_I_N_T_ ch.

Algue? piézo-phosphorescente

Mercredi 12 septembre 2007, tard le soir, plage de Vieux-boucaux dans les Landes française.

Nous étions alors en vacances entre amis. Une soirée des plus tranquilles, avec comme il se doit un passage sur la plage pour boire quelque breuvage local. Cadre peu crédible pour la suite de l'histoire si nous n'avions pas été 9 à être témoin du phénomène que nous avons découvert ce soir-là.

C'est en s'approchant de l'océan qu'on aperçut des points lumineux autour de nos pas. Des points d'une légère lumière bleutée s'illuminaient à chaque pression de nos pieds sur le sol dans un rayon d'une vingtaine de centimètres, avant de disparaitre 3 secondes plus tard.
Phénomène qui nous a émerveillé une bonne partie de la soirée, mais qui reste un mystère pour nos esprits curieux...

Une hypothèse d'une algue ou d'un organisme piézo-phosphorescent est de mise, car les points de couleurs apparaissaient dans une zone semblable à la zone de compression imposée par nos pas...

Mais les hypothèses les plus folles ont été imaginées sous cette nuit claire et chargée d'étoiles filantes.

Générateur automatique de visualisation de site

Un nom qui ne donne pas très bien en français, mais j'ai développé avec une petite équipe un générateur automatique de visualisation de site.

Le principe est simple : on donne une url au générateur qui nous retourne une image qui est une copie d'écran du site qu'on aurait eu dans notre navigateur. Le coeur du générateur utilise le moteur Gecko pour le rendu de la page web.

Une démo du service de génération de visualisation de site est disponible en ligne, et l'idée est de développer une puissant API pour interfacer le service. L'idée principale de l'API est d'utiliser une url de callback qui permettra au service directement de retourner l'image une fois générée afin d'éviter au client de devoir poller pour controler si l'image est créée ou pas.

Les possibilités du service sont les suivantes :

• Taille des images paramétrables (120x90, 160x120, 320x240, 640x480, 1024x768)
• Format d'image JPEG ou PNG
• Ajout de délai avant la capture (pour les sites en flash par exemple)
• Mise-à-jour hebdomadaire, mensuelle ou annuelle des captures

Les feedbacks sont bien évidemment encouragés, et d'autres news sur l'API & CO suivront.

Uniqid ou la contre-intuitivité des arguments

D'après le manuel PHP, le prototype de la fonction uniqid est le suivant :

string uniqid ( [string prefix [, bool more_entropy]] )

Le deuxième paramètre à l'air réellement intéressant, dans la mesure où il assure une meilleure unicité de la chaine produite. Une propriété qui de toute évidence nous intéresse si on utilise cette fonction uniqid.

Sans s'étendre sur la probabilité de collision entre les 2 appels (ce que j'étendrai plus longuement dans un autre article), je voulais juste montrer la différence de vitesse d'exécution qu'induisait ce paramètre more_entropy. Un petit script faisant 100 appels à uniqid avec une valeur possible du paramètre, nous donne le résultat suivant (!) :

100 * uniquid(mt_rand()) en 0.799283981323 seconde

100 * uniquid(mt_rand(), true) en 0.00346183776855 seconde

Chose extrêmement intéressante, le temps d'exécution de la fonction est 3 ordres de grandeurs en dessous si on demande une meilleures unicité du résultat.

La question obligée est donc : pourquoi est-ce que cette fonctionne ne prend pas par défaut cette option, puisqu'elle a tous les avantages (meilleures résultats, plus rapide) ?

Types ENUM avec MySQL

Toujours en train de travailler avec MySQL, et encore pour un bon moment, voici une particularité du type enum :

Soit un champ field2 :

`field2` enum('0','1') NOT NULL default '0'

Soit une requête :

SELECT * FROM ... WHERE ... AND field2 = 1

Le résultat de cette requête est intéressant dans le sens où MySQL va sélectionner tous les tuples dont la valeur du champ field2 vaut '0'. Pourquoi cela ? Parce qu'en passant le 1 sous forme d'entier, MySQL va l'associer à la première valeur de l'énumération, '0' donc. Dans le même ordre d'idée WHERE ... AND field2 = 2 sélectionnera tous les tuples dont field2 vaut '1'.

La requête

SELECT * FROM ... WHERE ... AND field2 = '1'

fournira quant à elle la juste réponse. Attention donc avec les types des valeurs, surtout en PHP...

Mysql NT vs Unix : quand les systèmes de fichier font des différences

La question posée ici est la suivante : le nom des tables dans une base de données MySQL est-il sensible à la casse ou pas ?

La réponse dépend du système sur lequel le serveur tourne... Et cette différence vient même d'une manière plus intrinsèque du système de fichier sur lequel repose la base de données.

Explication :

Pour MySQL, une base de données est un répertoire du même nom dans lequel se trouvent des fichiers représentant les tables. Le nom des fichiers est naturellement identique aux tables, à l'extension prêt.

Pour savoir sur une base existe, MySQL va chercher si le répertoire correspondant existe. Du même principe pour accéder à un table il va ouvrir le fichier lié.

Sur un système de fichier Unix, ext3 ou reiserfs par exemple, un fichier base1/table1.MYI n'est pas le même que base1/tAbLe1.MYI, donc une requête "SELECT * FROM table1" ou "SELECT * FROM tAbLe1" ne produira pas le même résultat. Sur un système de fichier NTFS par contre, les chemins ci-dessus pointeront vers le même fichier, et donc les 2 requêtes précédents fonctionneront.

En conclusion, le nom des bases et tables MySQL sont sensibles à la casse sur un système Unix, et non sensible à la casse sur un système Windows.

Citer Montaigne quand on parle d'informatique

Chose pas forcément aisée, mais Jean Véronis, professeur de linguistique et d'informatique à l'université de Montpellier y est parvenu à merveille jeudi 18 janvier, dans la capsule de Monsieur Pain.

"Scrobbler" Tome II, jeudi 18 janvier 2007

La capsule, une émission à écouter et ré-écouter...