Re: salt in version probes

[David Fifield <david () bamsoftware com>]

On Tue, May 03, 2011 at 05:38:54PM +0300, Toni Ruottu wrote:
> > These probes are probably fine, but I don't want to add them without any
> > matchlines. It's kind of a minimum barrier to entry to try a new probe
> > against a known server and add a match for it. (And ideally, try it
> > against two different servers, and get distinguishable responses.) I
> > notice that some of the stun-br responses contain the string
> > "Vovida\.org\x200\.96\", which looks like a nice server name and version
> > number for http://www.voip-info.org/wiki/view/Vovida.org+STUN+server. So
> > if you can test that, we'll add the probe.
>
> I think it is impossible to do a regexp that would match the fields
> accurately because they have length prefixes, and the regexp would
> need to take into account that the fields might be in different
> orders, and skip fields. On the other hand we may just have the regexp
> look for string "Vovida.org", but in theory this string might exist in
> some field with wrong type. I suppose we are okay with that?

We match fields with length prefixes all the time. For example, see the
AFP matches. Just use . or .. for the prefix and [\w._-]+ for the
version number part, and it usually works fine.

Yes, conceivably the fields might come in different orders, but if they
do, it means a different server or different version (at least a
different configuration), so it's fine to assume a static ordering in
each match line. Consider that the same ordering problem exists with our
thousands of HTTP match lines.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/