TODO:

* For session saving (--resume) consider going to second granularity in the
  filename. This avoids occasions when the file is overwritten because the
  user invoked Ncrack in the same minute and decided to cancel again.

* Start username-list gathering project. Gathering these from email
  addresses may be the most powerful technique.

* HTTP-form auth which will be based on the existing HTTP module and
  will target HTTP forms will have to ideally be able to parse the
  most common web forms out there. The user will also be given the
  choice to specify certain form-related arguments that can make
  Ncrack's job easier.

* We should probably put an Ncrack logo atop the Ncrack page
  (http://nmap.org/ncrack/).  For example, look at the Nping page at
  http://nmap.org/nping/.

* Perhaps improve option -U and -P options
  so that user can give a comma separated list of files that will be
  automatically concatenated by Ncrack.

* Implement option to make Ncrack stop scanning after finding the first
  credential pair (there is such an option in Hydra).

* Add remote desktop (rdp) cracking

* Make free (misc_info) handlers for HTTP protocol.

* Convert telnet module to use new inbuf/outbuf system.

* Take care of portability (endian) issues for --resume option.

* Think about packet trace. Obviously without pcap or something similar,
  we can only print info about TCP payloads or connection
  initiations/endings.
  How can I get the unique connection id from nsock? --> With nsi_id() 

* Extend opensshlib to support SSH version 1, as well as additional
  diffie-hellman algorithms.

* Complete output engine. The main thing left is support for XML output using
  the option -oX.

* Solve the ssh username/password special iteration challenge as mentioned here:
  http://seclists.org/nmap-dev/2009/q3/0119.html

* Handle the case where ftp tells us that it accepts anonymous login only so
  that we don't waste time cracking it.

* If a connection times out continuously for 1 service and the rest of the
  services need to poll for new events through nsock_loop, the fact that
  ncrack_connection_end calls ncrack_probes again won't let that happen
  So for many errors of 1 connection perhaps just toss service into a special
  list so that we can move on for the time being.

* Wider Ncrack promotion

* Complete dynamic timing engine.
 - Some details from SoC application:
   As of yet, the engine is "smart" enough to be able to adapt to some
   trivial end-cases e.g lower the number of parallel probes when we
   get more than a certain number of RSTs from our target in a certain
   amount of time. Of course, the user has the final say on how the
   engine will behave, depending on whether or not he defined certain
   time-related arguments during the initial Ncrack invocation.  The
   engine should ideally be able to adapt more intelligently to the
   given network conditions and the special characteristics of our
   targets. This implies that it will be able to deduce on its own the
   best possible value of parallel probes and other time-related
   parameters (for example, if it should wait between each
   authentication try and for how long). Since Ncrack is based on
   Nsock which is a socket-abstraction layer and we have no access to
   raw sockets or packet-crafting libraries (the user can invoke
   Ncrack without root privileges after all), we only have TCP itself
   as a feedback mechanism for the network conditions. This can prove
   tricky for our work. Our engine might have to based on
   trial-and-error and partial statistical analysis to take some of
   its decisions.

   One idea would be to keep a history of the average performance for
   each target and for each time-related metric. After some
   experimentation with each target and depending on the network
   conditions, our engine will be able to decide which of the
   different set of saved values are most suitable for the
   moment. However, this has to be flexible and prone to be
   dynamically adapted, since network traffic is susceptible to
   change. The "saved history" will mostly be used as a mechanism for
   better decision-taking. Ncrack should be as accurate and fast as
   possible, at the same time. As a result, when increasing the number
   of parallel probes doesn't lead to further increase in the average
   rate of authentication tries, it should back off and try with less
   probes. This is the experimentation-phase we mentioned above. Upon
   seeing that further reduction of the probes leads to decrease in
   performance, it should again try to increase them. All of this
   implies that we define some sort of 'average ideal' performance
   with which the current performance will be compared. This metric
   can be derived from a statistical analysis of our 'saved history'
   so far.

* For -vv verbose mode, possibly save the banner for each service and show it at
  the end. Also we can show a sample session, showing the special patterns used
  in the authentication steps. These may also prove useful for user submissions
  of new exotic patterns for modules, like telnet, that need them.

* SMB support will be quite a demanding and time-consuming task but a
  lot of research of this protocol has already been conducted by
  Ron. Thus, a lot of our work can be based on his NSE-scripts.

* SMTP/IMAP/POP3 - some initial IMAP/POP3 patches have already been
  provided by Balázs Bucsay. Further development of them, as well as
  SMTP support should be one goal to cover the existing email
  infrastructure.

* Consider adding a spec file for distributing RPMs.

* Discuss with nmap-dev about making and distributing a oN2oX converter
  (Nmap Normal to XML output) so that we drop supporting the -iN option (which
  seems to change at times) and instead focus on improving the -iX option.
  The converter program could be in Python (more likely) or Perl and be
  maintained as a common shared package between Ncrack and Nmap.
  ---> For now we will try keeping up-to-date with Nmap's -oN format.

============================= :DONE: =========================================

* Make a CHANGELOG showing the differences between 0.01ALPHA and 0.2ALPHA

* Make 0.2ALPHA release
  o Build Windows, Mac, Source packages
  o Ask David for help with Mac
  o Update web site
  o Send to nmap-dev for testing

* Do a valgrind memory leak and bug audit for all the modules
  (ssh almost done, remaining: ftp, http, pop3, telnet).
  There are still some minor/trivial errors reported by valgrind but most
  of them are 'possibly lost' memory leaks related to Nsock and others are in
  libcrypto (in which we don't have any access and surely don't want to
  manually patch).

* Windows Ncrack testing -- for example see
  http://seclists.org/nmap-dev/2010/q2/435

* Add --disable-pcap option to Nsock so that Ncrack and Nmap may share the
  exact same Nsock version all the time.

* Fix potentially big memory leak.  See this thread:
  http://seclists.org/nmap-dev/2010/q1/1140
  o Note, Fyodor can reproduce scanning against localhost ssh with
    openssh-server-5.2p1-6.fc11.x86_64 on Fedora Core 11 x86_64
  -- Already partially fixed one generic memory leak.

* Update Ncrack License Terms (for year 2010)

* Fully update man page to document the latest version of Ncrack.  For
  example, --user and --pass and --resume options aren't mentioned at
  all.

* Fix configure-issue where ./configure is initially run twice instead of
  just once. This happens for every library (nbase, nsock, opensshlib). Seems to
  be related with an old issue. (See below)
  --> Problem was that I had put two separate AC_OUTPUT directives. One for
  modules AC_OUTPUT(modules/Makefile) and AC_OUTPUT(Makefile) for central
  one. This made autoconf create, for some reason, 2 different 
  CONFIG_SUBDIRS in the configure script. Solution was writing 
  AC_OUTPUT(modules/Makefile Makefile).

* In verbose mode it should tell when a service completes (note that
  in some case a "completion" is really a failure, for example
  "scanme.nmap.org 22")

* Provide a compact and clean way of providing additional information
  (like the credential pairs found so far) in the interactive status
  message.
  - We may have a key users can press at any time, like 'p' for
    passwords, to show the currently discovered credential list.
    Should probably use the same format Ncrack users to print all the
    credentials at the end of its run.  The normal interactive status
    message should probably say something like 'press 'p' to list
    discovered passwords' if at least one valid credential has been
    discovered.
  - May warrant nmap-dev discussion

* Add some real-life examples to the ncrack -h output.

* Add to ncrack -h and maybe -V output a list of the modules
  supported.

* Make sure the -v option parsing works well.  Right now, we get:
  ./ncrack -v -P lists/top50000.pwd localhost:22 scanme.nmap.org:22
  Invalid argument to -v: "-P".
  QUITTING!

* Integrate part of recently leaked hotmail passwords into Ncrack's password
  database.

* Fix -oN importer to work with new Nmap output format

* Integrate nmap's new password lists.

* Solve bug that sometimes causes http module to report as the password
  found the one immediately following the real password found. [This seems
  to be OK since the last changes, but we need to be careful in case it
  comes up again]

* Find a generic way to fix memory leaks of Connection's void *misc_info.
  The problem is that we want a way so that the Connection class destructor can
  remove any dynamically-allocated member, without knowing about the inner
  structure of them (they can be cast to anything since they are void * and
  each module casts it as a completely unique struct)

* Add --resume support

* Integrate Solar Designer's list to Ncrack.
  --> Has been added as separate file, but we are waiting for the
  frequency file to merge the best passwords in our default.pwd.  We
  could always merge it in an equally balanced way by using the same
  frequencies for our current default lst for SD's and merge them.

* We may also need to increase the maximum number of half-open connections in
  Windows: see http://half-open.com/home_en.htm - We could do this by asking the
  user during Ncrack setup if he wants to update the system's imposed limit - if
  he doesn't want to accept the change, then he will possibly suffer a
  performance degradation.
  --> This is way too intrusive and Ncrack isn't really impeded by it.

* Implement option that lets user specify the usernames and passwords directly
  in the command-line, like -u guest,test etc.

* Improve -iX parser to handle more of XML, particularly newlines.

* Await reply from Microsoft for Windows Firewall RFC deviation:
  http://seclists.org/nmap-dev/2009/q2/0774.html
  http://seclists.org/nmap-dev/2009/q2/0780.html
  https://connect.microsoft.com/WNDP/feedback/ViewFeedback.aspx?FeedbackID=470990
  ------> It seems the Microsoft guys found the thing not reproducible but they
  must have tested it under XP SP2 whereas the behaviour seems to be occuring
  only in SP3. I have mentioned that in a comment but they probably won't see
  that again, so perhaps I might have to resubmit the issue. 
  ------> I have resubmitted the bug, pointing out now that it only applies
  to XP SP3:
  https://connect.microsoft.com/WNDP/feedback/ViewFeedback.aspx?FeedbackID=479640
  Microsoft responded - but according to those guys, this behaviour isn't
  exhibited in a clean installation. Ongoing discussion on this one.
  It seems they marked that bug as not reproducible finally.

* Implement feature that can get input from Nmap's output files, to determine
  which services to crack. Both -oN and -oX should be supported. Optionally,
  some additional info could be extracted from version detection, if available,
  to handle specific corner cases with certain servers.

* Test more thoroughly the windows version of ncrack.

* Add IPv6 support

* Search for good username and password lists, or find ways to
  generate them (e.g. web scraping for email addresses or account
  names or whatever). Usernames seems like a relatively easy problem,
  while password lists are more difficult to come by.
  * Assembled a lot of lists. Now need to sort them out.

* Possibly adapt Nmap license headers to Ncrack specifically.
  --> This has been halted for a while, until a unified solution for all
  Nmap tools is found.

* Documentation: write the man page (in Docbook XML, at least for the
  final version)

* Test buffering cases for all modules, when for example we need to search for
  certain patterns but the pattern is split in 2 separate packets due to a
  small window.
  ---> SSH already does that by using the ssh_loop_read function and I have
  already added the Buf class (derived from buffer.c of OpenSSH) that can be
  used to append the replies from each protocol. Now I only need to adapt the
  FTP and TELNET modules to use that instead of the con->buf thing.
  All modules have now been replaced to use the Buf class.

* On a brand-new checkout, configure seems to be running 2 times for the
  libraries nbase and nsock - one time in the beginning of calling ./configure
  and a second time after typing make. Why does this happen? In addition, there
  seems to be a problem when changing the order of linking - if nbase comes
  first and nsock comes second, linking problems between the two arise. However,
  nmap has them in that order without any problems.
  This problem seems to have been automagically solved.

* For future reference on modules like http: consider saving state information
  like the http parsing that needs to be done only 1 time per host inside the
  service, so that future connections can refer to that instead of having to
  redo that work. That will probably add to the speed.
  State information is already used by nearly all modules.

* Make Ncrack packaging - a source tarball for *nix and a Windows installer.

* Fix the false positives/false negative issues we've been seeing
  when scanning over the Internet for http module.

* Add ssl support (through nsock).

* Implement Service timeout, where the user imposes a certain timeout
  after which the service is marked as finished regardless of the progress
  so far.

* Refine interactive Status Report to print an estimate of the time left.

* Change Ncrack's build system so that whenever ssl isn't found on the system,
  the ssh module isn't included/compiled, since it requires (the underlying
  opensshlib actually does) it in order to work.

* Add output info when Ncrack finishes, the way Nmap does it.
  Also -v should print additional info like how many connections were
  initiated etc 
  Example from Nmap:
    (verbose)
    Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds
    Raw packets sent: 1000 (44.000KB) | Rcvd: 2010 (84.440KB)
    (normal)
    Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds

* Refine core engine. 

* Code ssh module

* Test telnet module, thoroughly

* Port Ncrack to Windows

* Complete ncrack callback handlers documentation.

* Appended Nmap license headers to each ncrack file.

* Handle case when connection limit is more than the total passwords/usernames
  in list

* Implement on-the-fly 'Status Report' within interactive Ncrack output.

* Code output.cc and -oN option.

* Implement interactive Ncrack output.

* Implement queueing mechanism for ServiceGroup lists.

* Studied SSH RFCs.

