Re: Should nmap.set_port_version support name_confidence?

[David Fifield <david () bamsoftware com>]

On Fri, Oct 24, 2008 at 11:38:59PM -0500, Kris Katterjohn wrote:
> On 10/24/2008 11:13 PM, Brandon Enright wrote:
> > My only counter-argument to setting the fingerprint is that the -sV  
> > engine doesn't set it when it finds a match and if the NSE script  
> > doesn't get a match the probe->response fingerprint structure and  
> > semantics of -sV don't correspond to any moderatly complex script.
>
> This is in contrast to something like C/C++ APIs (like older MS ones) that
> have multiple "reserved" parameters for functions which you must pass NULL
> into for no reason other than them possibly implementing an option to be
> passed there in the future.  In the case of the fingerprint setting, if it
> defaults to nil so that not specifically setting it along with the other
> service information in a script doesn't break anything, it's always there for
> somebody who finds a use for it.

It's a little more complicated than that, because usually you will be
calling nmap.set_port_version with the same port table that the action
function received, which would already have the service_fp set. You
would have to explicitly set it to nil before calling
nmap.set_port_version. Otherwise, (I guess?) you would see the port
identified correctly in the output but then also see a service
fingerprint and an invitation to submit it.

But you're right, the magical handling of service_fp is non-orthogonal.

David Fifield

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