No puede introducir retrasos de manera genérica sin (potencialmente) romper la funcionalidad, ya que algunos / la mayoría de las exploraciones están sujetas a tiempos de espera. Cuando una herramienta desea saber si el puerto X está abierto en el host Y , envía un paquete que se dirige a ese puerto; Si no recibe una respuesta dentro de un tiempo determinado T , decide que el puerto está "cerrado". El período de tiempo de espera comienza tan pronto como la herramienta cree que el paquete se enviará; Si retrasa el paquete saliente desde el exterior, la herramienta considerará que el puerto está cerrado mientras que su paquete aún no se ha enviado.
Si realmente quiere retrasar el envío de paquetes desde el exterior, necesitará herramientas pesadas. Podría imaginar la ejecución de la herramienta dentro de una máquina virtual QEMU modificada, con la emulación opcode-by-opcode; la modificación consistiría en "detener" la máquina virtual con regularidad, es decir, dejarla funcionar solo por diez mil ciclos, luego bloquearla durante dos segundos. Lo que el sistema operativo dentro de la VM considera como el "reloj de tiempo real" también tendría que detenerse, para que la VM no note el paso del tiempo durante sus intervalos de congelación. No hay imposibilidad conceptual en este plan, pero probablemente implicaría una programación bastante complicada y complicada (VM y emuladores no son el tipo de código más simple).
Alternativamente, juegue con LD_PRELOAD
y / o ptrace (estoy asumiendo una máquina similar a Unix) para interceptar El sistema llama y realiza el envío real de paquetes, y agrega demoras en ese punto. Si la herramienta inicia su temporizador inmediatamente después de la llamada al sistema, esto será suficiente; si inicia el temporizador inmediatamente antes de la llamada del sistema, entonces tendrá que modificar la noción de la hora actual del proceso, es decir, también interceptar gettimeofday()
(y, en los sistemas Linux modernos, esto puede ser un poco más difícil porque gettimeofday()
no implica necesariamente una llamada de sistema "verdadera").
Si la herramienta administra varios paquetes en paralelo (lanza un lote completo, luego espera todas las respuestas posibles simultáneamente), entonces estos métodos basados en demoras no funcionarán (no serán satisfactorios o no funcionarán).