Je pense que l’on va me dire que je suis geek, mais je n’ai pas pu m’en empêcher : en voyant ce qui ressemble fortement à des commandes linux dans un épisode de la série Chuck (2×13) j’ai fait pause pour vérifier ce que les experts de la série ont bien pu imaginer.

Voici la capture :

Les commandes sont tapées par John Casey, la brute de la série qui ne se soucie que de sa mission et ne comprend rien à l’informatique. Et effectivement, on peut voir cela !

Les commandes sont les suivantes :

123> usr/local/bin chmod +r+w-a
bin/ run ts -a
bin/ ls process

run init.flsh_seq -a. *
>flsh_seq -a.* dev.c enabled… all process READY EXECUTE

Soit ligne par ligne (oui je sais, je suis un malade !) :

Première ligne

123> usr/local/bin chmod +r+w-a

L’utilisateur 123 (nom pas conforme je pense, mais passons) est aux commandes.

Il spécifie d’abord un chemin usr/local/bin qui doit être un interpréteur différent de l’habituel (/bin/bash) et situé dans le dossier /home/123/usr/local/ vu qu’il manque un / pour que usr soit /usr (réflexion métaphysique inside)…

Tout cela pour… changer les droits avec la commande chmod sur aucun fichier. Les options du chmod sont aussi assez saugrenues puisque le -a ne veut rien dire (à ma connaissance). Je pense que ce qu’il faut comprendre ici c’est d’attribuer les droits en lecture (read) et en écriture (write) à tous les user (all) sur un fichier qui n’a pas été spécifié…

La structure correcte serait donc :

chmod a+r+w fichier

Inutile en effet de préciser un autre interpréteur pour changer les droits sur un fichier…

Seconde ligne !

bin/ run ts -a

le bin/ semble vouloir dire que l’on est dans le dossier /bin même si dans ce cas il manque quelques informations… Pour le reste de la commande il faut admettre que run soit un alias pour /bin/bash et ts un script perso contenu dans ledit dossier…

Troisième ligne…

bin/ ls process

Toujours dans le dossier /bin, l’utilisateur fait un ls (qui sert à lister le contenu d’un dossier) dans le dossier /bin/process, qui doit être vide ou ne contenir que des fichiers / dossiers cachés vu qu’il n’y a aucun retour.

Inutile donc indispensable, c’est pas comme si ils étaient entourés par les bad guys hein !

Quatrième ligne

run init.flsh_seq -a. *

Encore une fois il va falloir partir de l’hypothèse que run est un alias de /bin/bash et init.flsh_seq un script perso (remarquez le nom très pro dudit script) avec l’option -a.* qui est un peu bizarre, mais admettons !

Dernière ligne

Il doit s’agir d’un retour dudit script (celui qui tue tout le monde). Le bouton EXECUTE dans le terminal est original ceci dit, vous ne trouvez pas ?

Conclusion

De tout cela on peut déduire deux choses : que j’avais une vingtaine de minutes libres pour faire un article débile là dessus et accessoirement qu’une simple commande aurait pu suffire pour lancer tout ça.

chmod a+x flshseq
./flshseq -a

Qui lance le script qui tue (et que j’ai renommé pour simplifier) après l’avoir rendu exécutable…

Et après on s’étonne que Linux fasse peur… Alors que c’est tout simple !

(J’en profite pour inaugurer les codes inconnus symbolisés par « ??? »)