Non è possibile introdurre ritardi in modo generico senza (potenzialmente) funzionalità di interruzione, poiché alcuni / gran parte della scansione è soggetta a timeout. Quando uno strumento vuole sapere se la porta X è aperta sull'host Y , invia un pacchetto che indirizza quella porta; se non riceve una risposta entro un certo tempo T , decide che la porta è "chiusa". Il periodo di timeout inizia non appena lo strumento ritiene che il pacchetto debba essere inviato; se si ritarda il pacchetto in uscita dall'esterno, lo strumento riterrà che la porta sia chiusa mentre il suo pacchetto non è stato ancora inviato.
Se vuoi davvero ritardare l'invio dei pacchetti dall'esterno, avrai bisogno di strumenti pesanti. Potresti immaginare di eseguire lo strumento all'interno di una QEMU macchina virtuale modificata, con emulazione opcode-by-opcode; la modifica riguarderebbe "lo stallo" della VM regolarmente, cioè lasciandola girare per soli diecimila cicli, quindi bloccarla per due secondi. Ciò che il sistema operativo all'interno della VM considera come "orologio in tempo reale" dovrebbe anche essere bloccato, in modo che la VM non si accorga del passare del tempo durante i suoi intervalli congelati. Non vi è alcuna impossibilità concettuale in questo piano, ma probabilmente implica una programmazione piuttosto complicata e complicata (VM ed emulatori non sono il tipo di codice più semplice).
In alternativa, gioca con LD_PRELOAD
e / o ptrace (presumo che una macchina simile a Unix) intercetti le chiamate di sistema che effettuano l'invio effettivo di pacchetti e aggiungono ritardi a quel punto. SE lo strumento inizia il suo timer immediatamente dopo la chiamata di sistema, allora questo sarà sufficiente; se avvia immediatamente il timer prima della chiamata di sistema, allora dovrai modificare la nozione del tempo corrente, cioè intercettare gettimeofday()
(e, nei moderni sistemi Linux, questo può essere un po 'più difficile perché gettimeofday()
non implica necessariamente una "vera" chiamata di sistema).
Se lo strumento gestisce più pacchetti in parallelo (avvia un batch completo, quindi attende tutte le possibili risposte contemporaneamente), allora questi metodi basati sul ritardo non funzioneranno (non in modo soddisfacente, o del tutto).