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 « ??? »)
