Adding optional data to UDP-scans

On a recent engagement, we discovered that a packet-filtering device
reacted differently when udp-scanning hosts behind it with nmap v2.5mumble
vs udp_scan from Satan (don't ask!). udp_scan would correctly detect
listening ports on hosts behind the filtering device, while nmap would find
nothing. Watching tcpdumps gave a probable explanation: udp_scan sends UDP
packets with one byte of data (a zero); nmap sends zero bytes of data. The
filtering device was returning unreachables for all no-data packets, but
actually applying its ruleset (and allowing some traffic through) from the
one-byte packets.

Now, that behavior (by the filtering device) probably breaks RFC's. And,
nmap's current default of sending zero-data packets probably has fewer
unintended side effects when poking at badly written UDP services. But,
it'd be nice to have options to nmap to say "stick (some|this many) bytes
of (random|this) data in the UDP packets." I'll work on a lame proof of
concept, but it'll probably not be as flexible as the nicetohave I just
described, nor coded prettily ;)

I'm also curious if some filtering devices have similar properties wrt ICMP
traffic; Ofir are you listening? ;)

--
Hank Leininger <hlein_at_progressive-comp.com>
--------------------------------------------------
For help using this (nmap-hackers) mailing list, send a blank email to 
nmap-hackers-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).