Mientras resolvía algunos desafíos de CTF en línea, me encontré con una situación en la que necesitaba forzar un servidor. Este es el código que escribí:
#!/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
doneEsto fue increíblemente, dolorosamente lento . Necesitaba probar combinaciones de 1000 a 9999 y esto tomó alrededor de 5 segundos por cada 10 intentos. Luego, siguiendo un consejo, pongo un '&' al final de esta línea:
echo "a fixed string" $i | nc localhost *port here* >> /tmp/me/dump.txt &Y, probó cientos de combinaciones en segundos. Estaba muy sorprendido. ¿Alguien podría explicarme la lógica? ¿Qué hizo el '&'?
bash
shell-script
command-line
alumno X
fuente
fuente
&hace que el comando se ejecute en segundo plano, eso es todo. No lo hizo más rápido ni nada. Lea el manual de shell que esté utilizando (supongo que bash).for i in {1000..9999}waitembargo, debe incluir un al final.nc -z localhost 1000-2000?Respuestas:
Agregar
&genera un proceso en segundo plano.Si escribe
a; b, ejecutará el comandoa, esperará a que termine, luego ejecutará el comandob, en secuencia.Si escribe
a & b, se generaráacomo un proceso en segundo plano. No esperará a que termine y comenzará a ejecutarse debinmediato. Funcionará ambos a la vez.Puedes ver lo que hace experimentando en el shell. Si lo ha
Xinstalado,xtermes una buena forma de ver qué sucede: escribiendohará que se abra otra ventana de terminal, y la primera esperará hasta que la cierre. Solo cuando lo cierres recuperarás tu caparazón. Si escribes
luego lo ejecutará en segundo plano y obtendrá su shell de inmediato, mientras que la
xtermventana también permanecerá abierta.Entonces si escribes
realiza la conexión, envía la cadena, almacena lo que sale en el archivo y solo luego pasa al siguiente.
Agregar el
&hace que no espere. Terminará ejecutando los diez mil de ellos más o menos simultáneamente.Su secuencia de comandos parece "terminar" más rápidamente, porque probablemente en realidad no terminó en ese momento. Simplemente realizó diez mil trabajos en segundo plano, y luego terminó el primero.
Esto también significa que, en su caso, intentará abrir diez mil conexiones más o menos a la vez. Dependiendo de lo que pueda manejar el otro extremo, algunos de ellos podrían fallar. No solo eso, sino que no hay garantía de que se ejecutarán en orden, de hecho, es casi seguro que no, así que lo que realmente terminará
/tmp/me/dump.txtes una incógnita.¿Verificaste si la salida era correcta?
fuente
$ cat dump.txt | sort | uniq -uy se me reveló la línea que contenía la contraseña correcta.ncel búfer de escritura. Si este no hubiera sido el caso, las respuestas del servidor probablemente se habrían intercalado. Es decir, si hubiera tenido un búfer de escritura de 1 byte, y las respuestas fueran1111y2222, probablemente habría visto algo así como11221212algo bien separado1111 2222.El comando nc (netcat) es costoso, en cuanto al tiempo. Necesita conectarse al servidor remoto, enviar los datos, esperar una respuesta y devolverla.
Al usar & básicamente está bifurcando ese comando en un proceso en segundo plano (se llama "trabajo"). Por sí solo eso no lo hace correr más rápido. Pero sí significa que su ciclo ya no está bloqueado, y ya puede hacer la siguiente iteración (con el siguiente nc).
Básicamente, su aceleración es causada por hacer todas estas conexiones remotas en paralelo, de lo contrario tendrían que esperar a que se complete la anterior.
Por cierto, dependiendo de su terminal, los comandos de eco también pueden ralentizar su ciclo (a veces necesitan esperar hasta que haya espacio en el búfer de escritura).
fuente