TODO:

* We should probably include the Microsoft Visual C++ 2010 Redistributable Package 
  in the Windows installation setup file, since after moving to Visual Studio 
  C++ 2010 Express, Windows systems demand msvcr100.dll in order for Ncrack
  to run.

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

* Implement connection retry (cr) timing option.

* Fix a SSH module bug as described here:
  http://seclists.org/nmap-dev/2010/q3/517

* Consider adding an option for excluding cracking certain accounts. This
  is important when we want to avoid locking out a critical account by
  trying too many times. See discussion at:
  http://seclists.org/nmap-dev/2011/q2/292

* Handle username validation for services.  For example, if an FTP
  server is anon only or if we enumerate SMB users, or some service
  gives a user does not exist error, we should probably not waste time
  trying to crack such users against those services.  We need to
  figure out how this works when multiple services/hosts are being
  cracked at the same time.

* 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.

* Discuss improvements on password/username-list manipulation.
  e.g combo-lists, special format with which you could specify the
  username/password to be tried reversed, or a username to be tested
  as password, like this for example:
  %username% #to test the user name as a password
  %rev username% #username reversed
  %%username%% #to test for %username% 

* 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.

* RDP module TODOs:
  o provide generic endianess by coding a framework which is
    endianess-agnostic. This will also be helpful for the .restore
    file portability (see relevant task).
  o check if RDP cracking can go faster by issuing more than 1 pair of
    credentials per connection (which is what happens now). This will
    require the sending of special scancodes which will instruct the RDP
    server to 'delete' the previous username/password (usually only needed
    for the username if it is changed, since the password is automatically
    deleted by the server, when wrong). A scancode (usually 'tab')
    for switching between username and password will also have to be sent.
  o see if it is possible to send an 'empty' password. This is currently
    not easy to do, since the RDP server ignores an 'empty' password sent in
    the initial client_info packet, and it has to be manually entered later
    by the user. In order to automate this, special scancodes must be sent
    like above. Windows Vista and above also require you to select the user
    first, before being able to type the password. Automating this can be
    hard.
  o Support NLA: http://seclists.org/nmap-dev/2010/q3/526
  o Figure out why it isn't working against Windows 7 for Thomas
    Buchanan: http://seclists.org/nmap-dev/2010/q3/505
    --> According to the discussion at this nmap-dev thread, it appears that
    the problem Thomas has been describing only appears on his Windows 7
    version which comes from a public release candidate of Windows 7. No other
    Windows 7 version displays this behaviour. We are waiting to see if other
    people come across this problem, since so far this bug can't be replicated.
  o See what's wrong with: http://seclists.org/nmap-dev/2010/q3/643
    

* Convert telnet module to use new inbuf/outbuf system.
  --> It already does, but needs some fixes.

* 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() 

* Discuss about an option that will make Ncrack do a round-robin attack when
  targeting many hosts in parallel. For example, suppose you crack 5 different
  services (perhaps from the same subnet): then Ncrack will do 1 authentication
  attempt against the 1st host, then the 2nd, then the 3rd, ... and then start
  from the 1st again. This is to avoid possible lockout mechanisms. Note,
  that you could emulate this behaviour (but not in the exact same way) by
  configuring the option of 'connection-delay' for all hosts. However this will
  result in bursts of packets if the connection-delay is the same for all hosts
  and it would be too much of a trouble to assign and calculate a
  different 'connection-delay' for each host (so as to emulate the round-robin
  behaviour).

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

* 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.

* Take care of portability (endian) issues for --resume option.
  Currently it stores integers and the like in the system binary
  format.

* 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

* 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 be 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.

* 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.

* Improve SMB module, adding NetBIOS support etc.

* Consider adding a spec file for distributing RPMs.

* Discuss whether Ncrack should use different default username/password lists
  based on the protocol/service it is trying to crack.
  
* Consider collecting/assemblying protocol-optimized username/password lists.

* Consider extending Buf()'s class functions so that you can push and pop
  data in layers. Right now, you can only append data, but for example 
  you cannot leave some empty space and come and fill it in later. 

* Think about making Ncrack distributed (e.g with one master, several agents)

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

* Write Ncrack Developer's Guide. 

* Update CHANGELOG to note changes since last release

* Make new post-soc Ncrack release with SMB and RDP

* Remove excess verbosity in RDP cracker module (e.g. don't print
  "Account credentials are NOT valid." for each test unless in high
  debugging mode)

* Add remote desktop (rdp) cracking. Ithilgore says there are few
  rdesktop crackers out there.  Need to think about whether this makes
  most sense in Ncrack, NSE, or both.

* Improve current scorpion logo on the Ncrack page. An SVG file would be best.

* 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.

* Implement option to make Ncrack stop scanning after finding the
  first credential pair (there is such an option in Hydra).  We should
  probably provide 2 different versions of the option. One would
  finish Ncrack after finding 1 password regardless of how many
  services it is cracking in parallel. The other would finish Ncrack
  after finding 1 password for every service it is cracking. We have
  two ways of doing this: either with a separate switch (e.g -f and
  -F) or using the already existing module option subsystem (-m, -g,
  per-host e.g $ ncrack 127.0.0.1:22,f=yes) [we decided on -f to mean
  "quit each service after one credential found" and -f -f for "quit
  after any credential is found on any service".

* Find a way to parse a 'blank' password from the command-line (--pass option).

* We also should find a special way for treating the 'blank' password.
  We decided to treat it the same way as Nmap--use a blank line in the
  file as the designator for a blank password.

* Improve the font on the current Ncrack page logo so it isn't so
  lumpy (it's been resized or something which is causing the problem).

* 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.

* 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/. 

* 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

* Make free (misc_info) handlers for HTTP protocol.

* 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.