Tout en résolvant certains défis CTF en ligne, je suis tombé sur une situation où j'avais besoin de forcer un serveur. Voici le code que j'ai écrit:
#!/bin/bash
for i in {0..9}{0..9}{0..9}{0..9}
do
echo "Now trying code.."
echo $i
echo "a fixed string" $i | nc localhost *port here* >> /tmp/me/dump.txt
done
C'était incroyablement, douloureusement lent . J'avais besoin d'essayer des combinaisons de 1000 à 9999 et cela prenait environ 5 secondes pour 10 essais. Puis, suite à un conseil, j'ai mis un '&' à la fin de cette ligne:
echo "a fixed string" $i | nc localhost *port here* >> /tmp/me/dump.txt &Et, il a essayé des centaines de combinaisons en quelques secondes. J'étais très surpris. Quelqu'un pourrait-il m'expliquer la logique? Qu'est-ce que le «&» a fait?
bash
shell-script
command-line
LearnerX
la source
la source
&fait exécuter la commande en arrière-plan, c'est tout. Cela ne l'a pas rendu plus rapide ou quoi que ce soit. Lisez le manuel du shell que vous utilisez (je suppose bash).for i in {1000..9999}waità la fin.nc -z localhost 1000-2000?Réponses:
L'ajout
&génère un processus d'arrière-plan.Si vous écrivez
a; b, il exécutera la commandea, attendez qu'il se termine, puis exécutez la commandeb, dans l'ordre.Si vous écrivez
a & b, il apparaîtraacomme un processus d'arrière-plan. Il n'attendra pas sa fin et démarrerabimmédiatement. Il fonctionnera les deux à la fois.Vous pouvez voir ce qu'il fait en expérimentant dans le shell. Si vous avez
Xinstallé,xtermest un bon moyen de voir ce qui se passe: taperentraînera l'ouverture d'une autre fenêtre de terminal et la première attendra que vous la fermiez. Ce n'est que lorsque vous le fermerez que vous récupérerez votre coque. Si vous tapez
il l'exécutera en arrière-plan et vous récupérerez immédiatement votre shell, tandis que la
xtermfenêtre restera également ouverte.Donc, si vous écrivez
il fait la connexion, envoie la chaîne, les magasins ce qui sort dans le fichier, et ne puis passe à côté puis un.
Ajouter le
&fait attendre. Il finira par fonctionner tous les dix mille plus ou moins simultanément.Votre script semble "se terminer" plus rapidement, car il ne s'est probablement pas terminé à ce moment-là. Il vient de créer dix mille emplois d'arrière-plan, puis a mis fin à celui de premier plan.
Cela signifie également que, dans votre cas, il tentera d'ouvrir plus ou moins dix mille connexions à la fois. Selon ce que l'autre extrémité peut gérer, certains d'entre eux pourraient bien échouer. Non seulement cela, mais il n'y a aucune garantie qu'ils fonctionneront dans l'ordre, en fait, ils ne le seront certainement pas, alors ce qui finira par
/tmp/me/dump.txtêtre le cas de tous.Avez-vous vérifié si la sortie était correcte?
la source
$ cat dump.txt | sort | uniq -ula ligne contenant le mot de passe correct m'a été révélée.ncle tampon d'écriture de. Si cela n'avait pas été le cas, les réponses du serveur auraient très probablement été entrelacées. C'est-à-dire, si vous aviez eu un tampon d'écriture de 1 octet, et les réponses étaient1111et2222, vous auriez probablement vu quelque chose comme11221212plutôt qu'une séparation nette1111 2222.La commande nc (netcat) est coûteuse, en termes de temps. Il doit se connecter au serveur distant, envoyer les données, attendre une réponse et la renvoyer.
En utilisant &, vous bifurquez essentiellement cette commande dans un processus d'arrière-plan (cela s'appelle un "travail"). En soi, cela ne le fait pas fonctionner plus rapidement. Mais cela signifie que votre boucle n'est plus bloquée et peut déjà faire la prochaine itération (avec le prochain nc).
Donc, fondamentalement, votre accélération est causée par la création de toutes ces connexions à distance en parallèle, sinon elles devraient attendre la fin de la précédente.
De plus, selon votre terminal, les commandes d'écho peuvent également ralentir votre boucle (elles doivent parfois attendre qu'il y ait de la place dans le tampon d'écriture).
la source