Re: Status Report #8 of 17

[ithilgore <ithilgore.ryu.l () gmail com>]

I didn't have the time to do as many things as I would like this week due to the
beginning of university exams, but here's the list anyway:

=== Accomplishments ===

* Implemented some parts of dynamic engine.
* Added cl (minimum connection limit) and CL (maximum connection limit) upon
which (and some dynamic variables) the ideal_parallelism which is the number of
concurrent connections at any time, is calculated.
* Refined some part of the code, adding comments and removing unneeded things
* Made Ncrack's default behaviour to iterate the username list for each password
and implemented option --passwords-first which makes it iterate the password
list for each username. Also removed NextLogin and NextPass from Service and
merged their functionality into NextPair which is the main handler for each of
the 2 ways of list iteration. Renamed every 'login' variable to 'user' which is
more self-explaining - we usually refer to login pairs which comprise of
usernames/passwords.
* Changed default timing templates a bit.
* Fixed configure.ac/Makefile.in issue with openssl libraries - now it can
compile even when no ssl exists on system.
* Ncrack now compiles on Linux, FreeBSD and OpenBSD as much as I have tried it.
* Finished telnet module (which still needs more testing).
* Changed part of timing engine, which now considers the fact that the peer
might have already indicated that it is still alive for the current connection
by having sent a new login prompt, along with the authentication results
(denoting that it waits for another auth-attempt and thus it hasn't closed on us).
* Started documenting ncrack callback handlers. (haven't commited anything
though yet)

What I have learnt through building the telnet module is that the existence of
so diverse protocols can have a major impact in deciding the most generic way of
handling all these different behaviours. Adding that last part to the timing
engine, is proof of that. Considering that fact, new issues might arise with the
introduction of new modules.


=== Priorities ===

* Test telnet module thoroughly.
* Continue with timing engine.
* Perhaps start building additional modules, for the reason explained above.
* I also need to start coding the output options, starting with -oN.


Cheers,
ithilgore



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