Nmap Development mailing list archives

[PATCH] Additional information when using --version-trace


From: Tom Sellers <nmap () fadedcode net>
Date: Thu, 04 Jun 2009 19:49:07 -0500

When doing service version detection work I sometimes run into a problem where I am
not sure which probe was just sent and when or what match lines are being triggered.  This
doesn't happen often, but when it does it presents quite a problem.  The recent Oracle
fingerprint was an example of this.  Normally, if I cannot read the data at the end of
the Write request line I just have to guess as to which probe was just sent and on what
protocol.

I have attached a patch that displays additional information when --version-trace is used.

Formerly the output might look like -


NSOCK (671.5980s) TCP connection requested to 172.172.33.10:3689 (IOD #2) EID 48
NSOCK (671.5980s) Callback: CONNECT SUCCESS for EID 48 [172.172.33.10:3689]
NSOCK (671.5980s) Write request for 4 bytes to IOD #2 EID 59 [172.172.33.10:3689]: ....
NSOCK (671.5980s) Read request from IOD #2 [172.172.33.10:3689] (timeout: 5000ms) EID 66
NSOCK (671.5980s) Callback: WRITE SUCCESS for EID 59 [172.172.33.10:3689]
NSOCK (671.5980s) Callback: READ SUCCESS for EID 66 [172.172.33.10:3689] (161 bytes)
NSOCK (671.5980s) Read request from IOD #2 [172.172.33.10:3689] (timeout: 4999ms) EID 74
NSOCK (671.5990s) Callback: READ EOF for EID 74 [172.172.33.10:3689]
NSOCK (671.5990s) TCP connection requested to 172.172.33.10:3689 (IOD #3) EID 80
NSOCK (671.5990s) Callback: CONNECT SUCCESS for EID 80 [172.172.33.10:3689]
NSOCK (671.5990s) Write request for 22 bytes to IOD #3 EID 91 [172.172.33.10:3689]: OPTIONS / HTTP/1.0....
NSOCK (671.5990s) Read request from IOD #3 [172.172.33.10:3689] (timeout: 5000ms) EID 98
NSOCK (671.6000s) Callback: WRITE SUCCESS for EID 91 [172.172.33.10:3689]
NSOCK (671.6000s) Callback: READ SUCCESS for EID 98 [172.172.33.10:3689] (161 bytes)

After the patch --version-trace adds a line when a probe is sent and when a match is made.


NSOCK (671.5980s) TCP connection requested to 172.172.33.10:3689 (IOD #2) EID 48
NSOCK (671.5980s) Callback: CONNECT SUCCESS for EID 48 [172.172.33.10:3689]
Service scan sending probe GenericLines to 172.172.33.10:3689 (tcp)
NSOCK (671.5980s) Write request for 4 bytes to IOD #2 EID 59 [172.172.33.10:3689]: ....
NSOCK (671.5980s) Read request from IOD #2 [172.172.33.10:3689] (timeout: 5000ms) EID 66
NSOCK (671.5980s) Callback: WRITE SUCCESS for EID 59 [172.172.33.10:3689]
NSOCK (671.5980s) Callback: READ SUCCESS for EID 66 [172.172.33.10:3689] (161 bytes)
NSOCK (671.5980s) Read request from IOD #2 [172.172.33.10:3689] (timeout: 4999ms) EID 74
NSOCK (671.5990s) Callback: READ EOF for EID 74 [172.172.33.10:3689]
NSOCK (671.5990s) TCP connection requested to 172.172.33.10:3689 (IOD #3) EID 80
NSOCK (671.5990s) Callback: CONNECT SUCCESS for EID 80 [172.172.33.10:3689]
Service scan sending probe HTTPOptions to 172.172.33.10:3689 (tcp)
NSOCK (671.5990s) Write request for 22 bytes to IOD #3 EID 91 [172.172.33.10:3689]: OPTIONS / HTTP/1.0....
NSOCK (671.5990s) Read request from IOD #3 [172.172.33.10:3689] (timeout: 5000ms) EID 98
NSOCK (671.6000s) Callback: WRITE SUCCESS for EID 91 [172.172.33.10:3689]
NSOCK (671.6000s) Callback: READ SUCCESS for EID 98 [172.172.33.10:3689] (161 bytes)
Service scan match (Probe HTTPOptions matched with GetRequest): 172.172.33.10:3689 is rendezvous.  Version: |Apple 
iTunes|8.2||


The new probe line was modeled after an existing "Service scan match..." line that was
already printed when debugging was enabled.  I added the new probe line and changed the
flag on the match line so that it was also printed when --version-trace is used.

Hopefully the change will be useful and harmless.

Tom

Attachment: version.trace.output.txt
Description:


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

Current thread: