On 24/04/2008 04:56, Fyodor wrote:
> It may be OK that windows RAND_MAX is 32K (15 bits), because we only
> use 16 bits per call anyway:
>
> for(i=0; i < sizeof(bytebuf) / sizeof(short); i++) {
> iptr = (short *) ((char *)bytebuf + i * sizeof(short));
> *iptr = rand();
> }
>
> Maybe we should only be doing one byte at a time, since the high bit
> of every 2nd byte we generate may always be zero on Windows. Anyone
> want to test this and make a patch? The patch could check RAND_MAX
> and use that to decide the number of bytes to user per call.
It certainly is the case that the second byte returned by a call to
rand() never has a value of more than 127!! Quite shocking.
I've made an attempt at the change you suggested Fyodor and attached the
patch.
Here's some test results with the patch applied:
$ for i in 100 200 400 600 800 1200 1600 3200 6400 10000 100000 500000 ; do
COUNT=`nmap -n -sL -iR $i | egrep '^Host' | sort -u |wc -l`; echo $i
$COUNT; done
100 100
200 200
400 400
600 600
800 800
1200 1200
1600 1600
3200 3199
6400 6400
10000 9999
100000 99901
500000 495727
One thought that occurred to me is whether it might be a more economical
use of our random numbers if, instead of throwing away 4 bytes each time
a reserved IP address is generated, we drop the first byte, shift the
remaining three along and fetch a single byte to complete a new IP
address. I'm not sure whether this would have any positive or negative
effects on either the randomness or in performance. It might be worth
looking into though?
Regards,
jah
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org
Received on Apr 24 2008
Intro
