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:
- [PATCH] Additional information when using --version-trace Tom Sellers (Jun 04)
- Re: [PATCH] Additional information when using --version-trace David Fifield (Jun 08)