Tudor's Status Report - #9 of 17

[Tudor-Emil COMAN <tudor_emil.coman () cti pub ro>]

Hi folks,



I spent the last week solving some bugs and crashes in the IOCP engine after I noticed some bad accuracy results as I 
kept increasing the parallelism level.

That Amazon Instance Brandon gave me access was really helpful in identifying some bad situations.


Firstly there was an issue with the error handling in the sense that when an asynchronous I/O operation was initiated 
if the operation failed the state of the event wouldn't be updated.


ConnectEx has been giving me troubles with the fact that it's not reporting the proper WSA errors  with the 
WSAGetLastError function.

For example instead of WSAECONNREFUSED (10061) it would return ERROR_CONNECTION_REFUSED (1225) which I think it's the 
same error. The problem with that is that the error wouldn't be caught by the connect handler and it would exit with an 
unexpected error. Simply transforming the error into it's WSA counterpart seemed to do the trick.

This bug was documented here: https://svn.boost.org/trac/boost/ticket/10744


Also further attention was needed when handling expired events. For the loop I chose GetQueuedCompletionStatus which 
takes just one completed event from the queue so we are processing just one event per loop (with the expired events 
also). Now it may be the case that a completed event finishes before it is ever taken out and it is marked as expired 
which is would impact performance and even accuracy a lot. I manage to solve this one by writing my own 
process_expired_events in engine_iocp so that my code doesn't interfere with that same function in nsock_core.



As per last week I made some graphs but they should be taken with a grain of salt as it is not finished and the results 
may be flawed.

I did look at the actual scan results almost every single time and they compare pretty good between each other with a 
similar number of tcpwrapped ports, unrecognized probes and detected services but still, the results are way too good 
in favor of IOCP with the Sunday one in particular not looking right, so I'll look into why is that this week.

This week's both graphs are made on the same 5000 live hosts.


I also was working on creating my own script to have more control of the testing due to the fact that Nmap is too 
complex for this.

The scripts in nsock/examples and nsock/tests where all made for Linux so I had to start from scratch and so far I've 
nailed down the compilation part and made a  program that just makes a connection to a target IP. I would extend it to 
send a Get request and use it on a big group of http servers.



Other cases:

Localhost Scanning: I tested if localhost scanning works by doing a service scan on my PC and it worked.

IPv6 Scanning: I scanned the link-local IPv6 address of my old PC with the -6 option and it worked.



I didn't really have an aim this week but I will focus on finishing the engine by the next status report.



Accomplishments:

- Solved a bunch of issues with engine_iocp.

- Started working on a proper example script for it.


Priorities:

- Concentrate on the accuracy of the scans to spot other potential errors.

- Start using SVN instead of git and make a branch or something.

- Finish the example script.

- Investigate possible registry tweaks.



Time really flies doesn't it,

Tudor

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/