Podczas rozwiązywania niektórych problemów CTF w Internecie natknąłem się na sytuację, w której musiałem brutalnie zmusić serwer. Oto kod, który napisałem:
#!/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
To było niesamowicie, boleśnie powolne . Musiałem wypróbować kombinacje od 1000 do 9999 i zajęło to około 5 sekund na każde 10 prób. Następnie, zgodnie z radą, umieszczam znak „&” na końcu tego wiersza:
echo "a fixed string" $i | nc localhost *port here* >> /tmp/me/dump.txt &
I wypróbował setki kombinacji w ciągu kilku sekund. Byłem bardzo zaskoczony. Czy ktoś mógłby mi wyjaśnić logikę? Co zrobiły „&”?
bash
shell-script
command-line
learnerX
źródło
źródło
&
sprawia, że polecenie działa w tle, to wszystko. Nie przyspieszyło to ani nic. Przeczytaj, jakiej powłoki używasz (zakładam bash) manual.for i in {1000..9999}
wait
na końcu.nc -z localhost 1000-2000
?Odpowiedzi:
Dodanie
&
powoduje odrodzenie się w tle.Jeśli napiszesz
a; b
, uruchomi poleceniea
, zaczeka na jego zakończenie, a następnie uruchom polecenieb
po kolei.Jeśli napiszesz
a & b
, odrodzi sięa
jako proces w tle. Nie będzie czekać na zakończenie i zacznie działaćb
natychmiast. Będzie działać jednocześnie.Możesz zobaczyć, co robi, eksperymentując w powłoce. Jeśli masz
X
zainstalowany,xterm
to dobry sposób, aby zobaczyć, co się dzieje: pisaniespowoduje otwarcie innego okna terminala, a pierwsze zaczeka na jego zamknięcie. Dopiero po zamknięciu odzyskasz swoją skorupę. Jeśli wpiszesz
wtedy uruchomi go w tle i natychmiast otrzymasz powłokę, a
xterm
okno pozostanie otwarte.Więc jeśli napiszesz
nawiązuje połączenie, wysyła ciąg znaków, przechowuje to, co wychodzi z pliku, a dopiero potem przechodzi do następnego.
Dodanie
&
sprawia, że nie trzeba czekać. W efekcie wszystkie dziesięć tysięcy z nich będzie mniej więcej jednocześnie.Twój skrypt wydaje się „kończyć” szybciej, ponieważ prawdopodobnie nie zakończył się w tym czasie. Właśnie wykonał dziesięć tysięcy prac w tle, a następnie zakończył pracę na pierwszym planie.
Oznacza to również, że w twoim przypadku spróbuje otworzyć mniej więcej dziesięć tysięcy połączeń naraz. W zależności od tego, co może poradzić sobie drugi koniec, niektóre z nich mogą się nie powieść. Nie tylko, ale nie ma gwarancji, że będą działać w porządku, w rzeczywistości prawie na pewno nie zrobią tego, więc to, co ostatecznie się skończy,
/tmp/me/dump.txt
jest przypuszczeniem.Czy sprawdziłeś, czy dane wyjściowe są prawidłowe?
źródło
$ cat dump.txt | sort | uniq -u
.. i ukazał mi się wiersz zawierający prawidłowe hasło.nc
bufor zapisu. Gdyby tak nie było, odpowiedzi serwera byłyby prawdopodobnie przeplatane. To znaczy, gdybyś miał bufor zapisu 1 bajt, a odpowiedzi były1111
i2222
, prawdopodobnie zobaczyłbyś coś w rodzaju11221212
raczej niż starannie oddzielonego1111 2222
.Komenda nc (netcat) jest kosztowna, jeśli chodzi o czas. Musi połączyć się ze zdalnym serwerem, wysłać dane, poczekać na odpowiedź i zwrócić ją.
Korzystając z &, po prostu rozwidlasz to polecenie w procesie w tle (nazywa się to „zadaniem”). Samo to nie przyspiesza działania. Ale to znaczy, że twoja pętla nie jest już blokowana i może już wykonać następną iterację (z następnym nc).
Zasadniczo twoje przyspieszenie jest spowodowane równoległym wykonywaniem wszystkich tych zdalnych połączeń, w przeciwnym razie musieliby czekać na zakończenie poprzedniego.
Btw, w zależności od terminala, polecenia echa mogą również spowolnić pętlę (czasami muszą czekać, aż w buforze zapisu będzie miejsce).
źródło