GSoC 2009 Status Reports
---Status Report #17 of 17---
17 August, 2009
As you probably know, I was away at Har2009 and thus not much was done during this week.
Of course, Ncrack development will continue even after GSoC ends.
Status Report #17 of 17
* Got feedback for first Ncrack release and fixed related issues.
* Discussed with Fyodor about Ncrack input from Nmap.
* Implement more Ncrack features
* Complete GSoC paperwork.
---Status Report #16 of 17---
11 August, 2009
* Completed man page. The man page has also been converted to html format and
currently the latest version is at: nmap.org/ncrack/man.html
* Improved http-module and fixed some related corner-case bugs reported by David
* Implemented Ncrack core engine functionality, that makes Ncrack stop cracking
a service whenever a module reports that it can no longer or there is no point
in continuing to attack the service.
* Made a macosx installer template based on Nmap. David Fifield corrected,
completed and made the final Mac OS X dmg file.
* Updated Ncrack to use the latest nbase and nsock versions. Some changes were
needed for a new signature of a Nsock function, due to Nmap's SCTP support.
* Introduced signal handlers to Ncrack.
* Changed the username/password directory layout. Now the lists use a file
extension according to what they contain (.usr for usernames, .pwd for
passwords) and a name describing what kind of lists they are. For example,
minimal.usr holds a small list of very common usernames, while default.pwd
is the default password list Ncrack uses whenever the -P (specify password
filename) option is not specified.
* Assembled optimal default username list and added some more lists that can
be selected by the users under lists/ .
* Improved ncrack_fetchfile() and fixed a bug reported by Vlatko Kosturjak.
* Updated changes for Windows.
* Introduced experimental IPv6 support.
* Wrote nmap.org/ncrack index.html page and uploaded distribution files.
* Released Ncrack ALPHA release for testing and wrote announcement.
* Discussed with Fyodor about pending issues and updated TODO file.
* Get feedback from testers of Ncrack 0.01 ALPHA release.
* Work on things left at TODO list.
---Status Report #15 of 17---
4 August, 2009
* Completed documentation/paper for opensshlib. The latest version can always be
found at Ncrack's svn repository under ncrack/docs/openssh-library.txt but
copies have also been posted at nmap-dev previously
( http://seclists.org/nmap-dev/2009/q3/0428.html ) and at my site:
* Continued writing man-page. Still some things left to write.
* Added SSL support through Nsock. This has only been tested for the HTTP basic
* Finally converted every Ncrack's module to use the new Buf class (a generic
buffer manipulation class whose code has been derived from OpenSSH's buffer.c)
Changes were made for TELNET and FTP modules.
* Improved FTP module with ftp_loop_read() handler which can now parse every FTP
packet that spans multiple lines and can often be transmitted in separate TCP
segments (as was the case with Filezilla that initially sends 3 packets for
each banner - speak about verbosity)
* Added phpbb password file which contains 500 top cracked passwords from leaked
list. This list was assembled by Brandon Enright.
* Improved Makefile.in which now installs Ncrack and all associated files in
Unix systems using the traditional way of 'make install'. Datafiles (lists and
ncrack-services will normally be saved under /usr/local/share/ncrack/ or
Essentially this marks the ending of the packaging pending issue. Both Windows
and *nix installers are now ready.
* Introduced ncrack_fetchfile() function which is based on Nmap's equivalent
code and is responsible for fetching the username/password lists and the
'ncrack-services' file by looking at multiple locations.
* Improved ServicesTable printing (which is triggered by specifying target
listing with --list or -sL and at least 1 level of debugging) using the
venerable NmapOutputTable class.
* Refined a small part of the output engine concerning the initial and the last
header being printed (at the beginning and end of the output).
* Wrote some thoughts on the --resume option.
* Sent mail about consistency of Nmap's Windows Makefile with Ncrack's
* Read some code about http form auth module.
* Cleaned up and reordered TODO list.
* Reopened bug-ticket about the Windows XP SP 3 Firewall issue:
Let's hope that it works out this time and the MS folks will be able to
reproduce it now, unlike last time (that was tested on XP SP 2 and which seems
not to apply there).
* Discussed some feedback related to the SSH module. Thanks jah.
* Write form-auth module.
* Finish manpage.
* Assemble optimal default password list.
* Discuss with Fyodor about pending issues.
---Status Report #14 of 17---
28 July, 2009
This week was focused on completing and debugging the http basic-auth module.
During the process of testing, I made some fascinating discovery with the help
of Ncrack's high speed cracking engine: bypassing Apache's 2.2 password
protected areas. Apparently, this hasn't been found or disclosed anywhere yet so
an advisory is likely to come up soon. I want to test more versions though and
also try to find where in the code the relevant flaw is. The consequences of
this bug is that all vulnerable Apache versions (which are yet to be exactly
defined) can have any password protected area (at least with basic
authentication, since this the only method I have tried so far) bypassed with
fake credentials. Of course, any file residing in that area can also be grabbed.
Expect to hear more about it in the following days.
Apart from that, mswin32 support has at last caught up with the rest of Ncrack's
supported platforms by porting the opensshlib as well as the latest version of
the rest of Ncrack codebase to Windows XP. In addition, a Windows installer was
made using NSIS and the setup .exe now resides in the svn repository under the
mswin32 folder. So anyone wanting to give a try to Ncrack on his favorite
proprietary platform can now automagically install it and run it on the fly.
Another feature is the service timeout option with which a user can now specify
the time offset when Ncrack stops cracking that particular service regardless of
success so far. This can prove really handy for large networks when scanning
times are restricted by administrator policies or other 'obstacles'. Specify for
example that you want to scan your class C enterprise network for weak passwords
on ssh but are limited only to a certain time period (e.g at night) when users
won't be logging in so that Ncrack's connection probes won't cause an active
hindrance to their usual activities:
$ ncrack 10.0.0.*:22,to=10m
That simple. 10m means 10 minutes, so that will have Ncrack running from now
until 10 minutes later or until every service's cracking is completed (whichever
BTW, 'to' is just an abbreviation for 'time-out', since we want to keep
command-line options short yet memorable.
That feature along with the upcoming --resume which will enable users to save
Ncrack's current state into a file and later continuing from where it left, will
make it a really valuable asset.
I also began writing the manual page and nearly finished documenting the
opensshlib. The latter will come in the form of a paper ( it is going to be
_big_ ) since I am also analyzing various aspects of the SSH protocol and how
that is implemented by the OpenSSH project as well as what hacks were made in
order to convert the entire OpenSSH codebase into a library suitable for use by
Ncrack's architecture and the corresponding SSH module. Probably it will be
ready by tomorrow.
The gathering of username and password lists has gone well so far and I found
out about another great archive of such files here:
However, a proper sorting of all these has to take place. Soon.
The first steps of adding SSL support are also being done and by next week I
hope that will have finished too.
As usual, bugfixes never miss their being mentioned and various patches were
made to better stabilize and even beautify (yes, indentation fixes!) the code.
So to sum up:
----[ Accomplishments ]----
* Discovered Apache 2.2 0day vulnerability which leads to bypassing
* Completed http basic-auth module.
* Ported opensshlib and latest Ncrack version to Windows.
* Successfully built and tested NSIS Windows installer.
* Began writing manpage.
* Almost finished documenting the building process of opensshlib.
* Gathered some good sources of username/password lists.
* Various bugfixes.
----[ Priorities ]----
* Complete writing of manpage.
* Sort and categorize the gathered username/password lists.
* Finish opensshlib documentation.
* Add and test SSL support.
* Write http form-auth module.
* Further investigate Apache 2.2 vulnerability and write advisory.
---Status Report #13 of 17---
21 July, 2009
* Studied about various HTTP authentication methods and began implementing http
* Wrote mini-howto for ssh-module testing.
* Added ncrack command-line options for http path and ssl.
* Improved ncrack's build-system for cases when SSL is not installed in system.
* Improved interactive output format. Now ncrack prints an estimate of the time
Stats: 0:00:10 elapsed; 0 services completed (1 total)
Rate: 5.25; Found: 1; About 4.93% done; ETC: 04:09 (0:03:32 remaining)
* Wrote code for ssh iteration challenge but it proved to be quite complex in
combination with the pair-pool and thus was stalled for the moment.
* Did more testing with the ssh module.
* Solved timeval subtraction bug:
* Finish http module.
* Write documentation on the opensshlib.
* Test ncrack ssh-module and the rest of the updates on Windows.
---Status Report #12 of 17---
14 July, 2009
This week was almost entirely dedicated to debugging the opensshlib and great
progress was made, bringing the ssh module to a working state and entering the
final testing phase.
* Extended debugging of opensshlib:
- caught numerous bugs that were caused by the fact that there were still
static/global variables throughout OpenSSH code.
- removed a bug caused by accidental cleanup of 1 particular compatibility
* Solved buffering issues by implementing an 'ssh_loop_read' function that
gracefully handles cases like when 2 different SSH messages are inside 1 TCP
packet (something which happens almost everytime with many servers at one
particular phase (Server New Keys message))
* Finalized opensshlib API by using the 'ncrack_ssh_state' generic struct that
is passed along all internal handlers.
* Examined numerous different versions of SSH implementation thanks to the ssh
dumps I got (25 unique versions from Brandon Enright and 1 from Luis - thanks
* Cleaned-up a lot of unneeded parts of opensshlib.
* Merged opensshlib-testing branches into main trunk.
* Wrote a mail about some new challenges that came up upon testing SSH. They
mainly pertain to the fact that SSH doesn't let you change a username during a
connection and thus a special kind of user/pass iteration is needed. More
details here: http://seclists.org/nmap-dev/2009/q3/0119.html
* Updated my site and moved my former wiki to a special section here:
* Ported Ncrack to MacOS X.
* Discussed with Fyodor about the new http module.
* Completed GSoC midterm-evaluation.
* Test the ssh module on Windows.
* Solve the user/pass iteration SSH challenge.
* Write documentation on the opensshlib.
* Write mini-howto for ssh-module testing as requested by David.
* Start implementing http module OR/AND continue with dynamic engine.
---Status report #11 of 17---
7 June, 2009
Ncrack is progressing in many fields. The highlight of this week is the
introduction of the opensshlib, a library using OpenSSH code but adapted for
usage with Ncrack and Nsock. The decision that using OpenSSH code to
make a library of our own, instead of using already existing libraries (like
libssh and libssh2), was taken due to the following benefits:
- Code derived from OpenSSH has a BSD license which is less restrictive than
others like LGPL.
- OpenSSH code is much safer, since it is audited by the OpenBSD team.
- OpenSSH supports both SSH1 and SSH2 and also provides many workarounds for
old ssh implementations which have bugs, essentially making it more easily
adaptable against strange-behaving targets.
- We would need to hack the libraries anyway, since they all abstract the socket
operations and we need to have our own control over that using nsock. Instead,
getting to know how the most popular ssh client works behind the scenes, will
effectively lead to more maintainable and better code.
The opensshlib has been tailored to Ncrack's needs specifically. That means,
that I haven't bothered adapting OpenSSH code which deals with anything other
than the steps needed to reach the authentication phase. Perhaps, the most
frustrating thing was that OpenSSH assumes that there will be only 1 connection
(as far as the client is regarded) and thus it keeps state in static and global
variables - something which had to be completely removed in order for it to
provide library functionality.
* Introduced openssh lib on which the ssh module will be based.
* Almost completed the ssh module. There are still some steps to be done before
reaching the authentication part.
* Refined ServiceGroup handling by adding important checks and removing unneeded
ones as well as making code more readable.
* Profiled ncrack with gprof and solved some 100% cpu usage problems with
* Added passwords from nmap/nselib/data/passwords.
* Added per-service credential storage functions/members.
* Removed greppable output format which is deprecated.
* Finished final output for normal (-oN) format. Currently -oN combines an
easily-greppable format, which is also easily readable. This format was
suggested by Fyodor at: http://seclists.org/nmap-dev/2009/q2/0790.html
* Fixed many bugs within core engine.
* Added a generic buffer manipulation class which is based on OpenSSH code.
* Separated modules into their own directories.(this might change in the future)
* Discussed with Fyodor about license issues.
* Adapted Ncrack's build system to compile and link against opensshlib and
openbsd-compat which is needed by some functions in opensshlib.
* And finally the fun-part: added leet-ascii art for Ncrack - a scorpion -
(it is shown after ./configure finishes its job like Nmap does):
00000..0000~ 000000. $0
00..0~0?0::00,?0::?$0. 00 ~
.0. ,0?00000.0$,+,000.00 $00
.0 +00 0+0000 0000=?~0000?00 00
.: .~~ .000=00000~00=000000+0.0~0$$.
00 , ?00.. 000~000000000000.:0.0:0~ 0$00.+
00.0 00 00?~000~000000000+00 + ~0000000000=$0000
$ 00 00. .00,000000000000$.00000. .0000+$+~00
0 00 .0 000000000?~0000000. 0. .0$000000+$0
0 0 0 000:$~0000=0.0000,$. 00 0000000000
0 00 ?.0000 $0 0 . .0000
. $ ?000. 0 0
0. :000000?0 |=------=[ Ncrack ]=------=|
* Complete and test ssh module.
* Write extensive documentation about every aspect of opensshlib, since many
parts of OpenSSH were hacked for Ncrack adaption.
* Test the changes on Windows.
* Find a shell at a MacOSX box to test Ncrack there.
* Also, start thinking about the http module and implementing ssl support
---Status report #10 of 17---
30 June, 2009
* Implemented part of output engine.
* Implemented interactive ncrack output and status report printing.
* Coded queuing mechanism for ServiceGroup lists.
* Fixed various bugs.
* Discussed with nmap-dev about Windows RFC 793 deviation with bogus RST when
firewall is enabled and reported issue to Microsoft.
* Studied libssh and openssh code.
* Studied SSH RFC documents to implement from scratch the ssh module.
* Complete output engine.
* Code ssh module.
* Continue with dynamic engine.
---Status report #9 of 17---
23 June, 2009
* Tested telnet module thoroughly and handled numerous corner-cases and telnet
* Ported Ncrack to Windows.
* Continued implementing dynamic engine and carried out some successful initial
* Documented Ncrack's engine: http://sock-raw.org/wiki/Ncrack/Engine
* Implement output engine.
* Fix a lot of problems residing in my TODO file.
* Make some tests for strange socket behavior in Windows.
---Status report #8 of 17---
16 June, 2009
* 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
* Started documenting ncrack callback handlers. (haven't commited anything
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.
* 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.
---Status report #7 of 17---
9 June, 2009
* Handled case when failing to connect to a host at first try (either by
timeout or RST or no route to host): service will move to services_finished
* Changed parsing according to last discussion with Fyodor: removed the need for
'?' to specify host arguments (now it is only done with commas ',') Also, user
can now specify only the port like 10.0.0.10:22 and the default service name
corresponding to that port will be assigned to it (the equivalent also happens
when user has only specified service name in url-like notation)
* Added timing rate meters using Nmap's timing.[cc,h] classes.
* Ncrack now automatically selects current directory's username.lst and/or
password.lst if options -L and/or -P are not specified by the user.
* ServiceGroup got its own separate file now.
* Ncrack will now check if the connection has been closed by the peer before
trying out a new authentication attempt within that connection. It does that
by issuing a read call (through nsock) with a tiny timeout. If nsock returns
NSE_STATUS_TIMEOUT instead of an NSE_STATUS_EOF, then our connection hasn't
been closed yet by the peer. Of course we check that by using an additional
boolean variable so as to differentiate between normal timeouts and this
particular one. There is not really any other *portable* way to check if our
connection is in CLOSE_WAIT state (e.g Linux netstat just parses /proc and *BSD
use fcntl et al)
* Solved the next login pair problem:
Problem: each service that needs to be cracked holds a pointer to the loaded
username list and password list (they are vector objects). Each time a new
connection is made or a new authentication attempt is going to be tried in the
current connection then we need to call NextPair() which gives us the next
login username and password pair. The normal way to do that would be to just
move the password list iterator each time, and the username list iterator once
the password list iterator has finished one full iteration. However, by using
this crude approach arises the following problem:
-- What happens when a connection is prematurely closed by the peer for one
reason or another (before the current login pair is actually tested)? --
It is obvious that the iterator approach would never really try out that pair,
because it would just forget about the unfinished authentication attempt and
move on giving the next (always unique) pair.
Solution: (still needs to be more tested for some end-cases)
Each time a connection is prematurely closed by the peer, which essentially
means that our current authentication attempt was not completed, then we throw
the current pair inside the service's login-pair pool (which is a stl list).
The next time we are going to ask for a pair from NextPair(), if the pair_pool
is not empty, then it will return us one element from that, giving us the
opportunity to retry that pair once again. The element is removed from the pool
when we extract it from NextPair() and if the authentication doesn't finish
this time either, then we move it back to the list so it can be reused later
once again (and this will go on happening until the authentication finishes
all steps for that pair or any other pair in that situation).
The problem, however, is a little more complex than it first seems:
-- What happens if the username list iteration finishes while we have pending
authentication attempts taking place but the pairs for these attempts had been
extracted from the pair_pool? --
Normally, since the pair_pool has its elements removed and would be
empty at the time the username list iteration finishes, then there is no
way to actually know if the service needs to be moved to the services_finished
list (which should be moved there only after *ever* pair has been tested out,
including everything from the pair_pool).
To be able to account for that, we keep a separate mirror_pair_pool which holds
copies of the current pairs being tested out from the main pair_pool. Each time
a pair has been tested out fully, then we can remove that element from the
mirror_pair_pool (remember that the element from the pair_pool had already been
removed at the time it was returned from NextPair()). If it fails being tested,
then we move back that pair to the pair_pool list only (we already have a copy
at the mirror_pair_pool).
Note down, that all this happens to take care of a highly improbable case, but
which however just *might* happen one day. Also, note that every list involved
in the solution is usually really small so any iterations are not
* Fixed some bugs and end-cases.
* Began building dynamic timing engine.
* Tested ftp-module more thoroughly with multiple hosts.
* Compiled successfully ncrack under FreeBSD-7.2
* Continue implementing dynamic timing engine. (this will probably be the most
complex and important part of the whole project)
* Perhaps start building smtp-module to begin seeing how differently each
protocol needs to be handled as far as timing is concerned.
* Document timing engine's internals (made it imperative this time)
---Status report #6 of 17---
2 June, 2009
* Implemented -g option for global service options.
* Implemented -T timing templates.
* Implemented Ncrack's main timing engine which currently supports:
- connection-limit (per-service and additive)
* Implemented -L/-P options for input of login/password lists.
* Completed ftp-module and testing it against a local-network proftpd server.
* Wrote mail 'Ncrack command-line reloaded' explaining Ncrack's interface.
( http://seclists.org/nmap-dev/2009/q2/0484.html )
* Wrote mail 'Ncrack Timing' explaining Ncrack's timing options and opened
relevant discussion. ( http://seclists.org/nmap-dev/2009/q2/0532.html )
* Start writing documentation.
* Implement 'maximum retries' option in timing engine.
* Make additional tests with ftp-module against different servers.
* Make a ProgressMeter.
* Start coding additional protocol modules.
* (maybe) Begin porting Ncrack to other platforms.
* (optional) Technical analysis on Ncrack's timing engine.
---Status report #5 of 17---
26 May, 2009
* Discussed and brainstormed with Fyodor about Ncrack's final command-line
* Coded ncrack_probes() which will be the basis for initiating new connections
by round-robin through the remaining services.
* Implemented Ncrack's command-line interface. (will write separate mail
explaining and demonstrating options)
Mini-example from Ncrack's interface: (don't worry if you don't understand
everything for now)
/ncrack ftp://10.0.0.20:3000?cl=50,al=20 ftp://10.0.0.40 ssh://10.0.0.30 -sL
-d10 -m ssh:al=30,cd=2000 -m ftp:al=30,mr=2
Starting Ncrack 0.00001ALPHA ( http://ncrack.org ) at 2009-05-26 05:17 EEST
=== ServicesTable ===
ftp:21 cl=0, al=30, cd=0, mr=2
ssh:22 cl=0, al=30, cd=2000, mr=0
telnet:23 cl=0, al=0, cd=0, mr=0
smtp:25 cl=0, al=0, cd=0, mr=0
http:80 cl=0, al=0, cd=0, mr=0
=== Targets ===
ftp:3000 cl=50, al=20, cd=0, mr=2
ftp:21 cl=0, al=30, cd=0, mr=2
ssh:22 cl=0, al=30, cd=2000, mr=0
cl = connection limit
al = authentication limit
cd = connection delay
mr = maximum retries
* Document everything done so far.
* Send email explaining Ncrack's command-line interface.
* Discuss timing options with nmap-dev.
* Write more comments on functions.
* Implement -g option for global service options.
* Implement -T timing templates.
* Upload stuff at my wiki, making some pages write-accessible for nmap-dev to
give direct feedback.
---Status report #4 of 17---
19 May, 2009
* Discussed with Fyodor about Ncrack's command-line interface.
* Wrote part of Ncrack's command-line interface supporting Nmap's advanced
notation and other features according to the suggestions at nmap-dev.
* Brainstormed about module arguments - still more dicussion to be done for
* Cleaned up Ncrack's code and removed libpcap dependence.
* Write draft on timing options for nmap-dev discussion.
* Code module arguments functionality into Ncrack's command-line interface.
* Change nsock's configure.ac so that it can cleanly take a
* Study the way Nmap applies timing options.
---Status report #3 of 17---
12 May, 2009
* Completed build system for Ncrack (configure.ac and Makefile.in)
linking with nbase and nsock
* Merged functionality from Nmap's Target.cc TargetGroup.cc targets.cc into
Ncrack (classes have been trimmed of members that are not going to be used
* Wrote code (mostly reused from Nmap) for options:
-iL : Input from list of hosts/networks
--exclude : Exclude hosts/networks
--excludefile : Exclude list from file
* Wrote a main loop that will be responsible for handling multiple host groups.
* Studied more of service-scan's code.
* Discuss with Fyodor about the Ncrack core_engine - module communication
* Beging writing code for timing options - but firstly fine-tune existing
* Brainstorm with Nmap community about Ncrack's options.
---Status report #2 of 17---
5 May, 2009
* Discussed with Fyodor about Ncrack.
* Studied how thc-hydra works and documented it (inside Ncrack-draft).
* Proposed an initial draft on Ncrack
( http://seclists.org/nmap-dev/2009/q2/0287.html )
* Created an initial testing ncrack version at
svn://svn.insecure.org/nmap-exp/ithilgore/ncrack - IMPORTANT: although this
is a more or less working code, it is just for testing purposes
(to demonstrate the state-machine module structure with a plain poc ftp
* Studied part of service_scan.cc
* Studied part of SVN book.
* Discuss with Fyodor about the Ncrack core_engine - module communication
* Document service_scan.cc (many ideas there)
* Study more about medusa ( http://www.foofus.net/~jmk/medusa/medusa.html ).
* Experiment more with nsock library and make additional ncrack test modules.
---Status report #1 of 17---
27 April, 2009
* Studied part of Ncat code and reviewed http.c
(still haven't finished auditing)
* Committed 3 minor Ncat patches
* Uploaded a wiki on my site: http://sock-raw.org/wiki where I will be posting
updates and notes on Nmap
* Started studying the nsock library and documented some things at
* Refreshed mem on some things from UNP vol 1 (socket options etc)
* Created my own svn branch at
* Discuss tomorrow with Fyodor about the authentication cracking SoC project.
* Read the essential parts of SVN book.
* Experiment with nsock library - write my own test programs and specifically
play with *many* sockets.
* Study service_scan.cc, take notes and see how nsock is used there. Other
candidates are nmap_dns.cc and NSE
* Study thc-hydra source code, get ideas and note down its flaws/problems so
that they are not repeated.
* See how the Nmap congestion-avoidance algorithms can be integrated into the
new project, since they will really make a difference there.
I didn't mention things like compiling Nmap, subscribing to nmap-dev etc or
reading the Nmap book since these had already been done before.