Ike-scan Desired New Features

From royhills
Revision as of 16:15, 1 September 2008 by WikiSysop (talk | contribs) (Features Implemented in SVN)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page contains a list of the desired features for future versions of ike-scan. Please add proposals for new features to the discussion page.

For a list of changes for each ike-scan release see Recent Changes.

Features Implemented in SVN

The following features have been implemented in the SVN copy of ike-scan, but not yet formally released. Unfortunately the SVN version is not publicly available, but it may become available in the future.

These new features will be present in the next version of ike-scan.

This list comes from the NEWS file, which is part of the ike-scan distribution.

  • The function that converts strings to numbers is now stricter, and no longer permits any invalid characters. This improves error reporting in some invalid cases that previously gave no error, e.g. using "1=7/256" in an advanced transform specification.
  • New backoff patterns for Cisco PIX 7.0
  • New vendor ids for Windows 2008 server
  • ike-scan now uses the OpenBSD strlcat and strlcpy functions instead of the standard strcat, strncat, strcpy and strncpy functions. This reduces the chance of buffer overflow bugs.

Features on the To-Do List

The following features are on my To-Do list. This list comes from the TODO file, which is part of the ike-scan distribution.

  • Write custom packet creation code. This would allow an arbitrary IKE packet to be created and sent. The generation rules would be some sort of specification file as command-line arguments are not flexible enough for this task. Probably parse with yacc/lex to avoid having to write C string handling and pattern matching. This would override any command-line options that define the packet such as --aggressive, --auth, --trans, --dhgroup Etc.
  • Add option for XML output for easier machine readability.
  • Decode the currently unhandled ID types: ID_IPV6_ADDR, ID_IPV6_ADDR_SUBNET, ID_IPV6_ADDR_RANGE, ID_DER_ASN1_DN, and ID_DER_ASN1_GN (I've never seen these used though).
  • Use Token Bucket algorithm for packet transmission to allow higher output rates, esp. when minimum select() wait is relatively large.
  • Allow --trans options to be specified as inclusive ranges. This would add a host entry for each transform attribute in the range, which could be used to determine which attributes a server supports.
  • Add an option to include all known vendor IDs to the outgoing packet. Suggested by Max Kosmach. This would require a more complex structure to hold the vendor IDs as the current one only contains the pattern to match which cannot simply be used as the outgoing VendorID as it may contain metacharacters.
  • Allow a variable number of packets in the UDP backoff pattern. Some VPN servers will return different numbers of packets, but still have a unique pattern.
  • Add support for Main Mode PSK cracking using a MitM attack. Suggested by Anton Rager.
  • Allow an id file to be specified, which would contain multiple identities (usernames). Each identity would create a separate host entry, with a pointer to the associated ID so that it could be correctly displayed.
  • Increase PSK cracking speed by using faster hash functions. Possibilities include Jean-Luc Cooke's MD5crk MD5 cores which use SIMD instructions.
  • Allow sending of zero values for all the various parameters. For 1 and 2-byte sized parameters, this can be achieved by using int instead of unsigned and using -1 to represent the default rather than 0. For 4-byte values, it requires a separate flag variable. Another option is to define a struct like:
struct value {
   int flag;
   unsigned val;
  • Add support for multiple psk-crack processes using MPI for inter-process communication. This should enable psk-crack to run much faster on multi-core CPUs.
  • Support custom transforms for IKEv2.
  • Display notification of NAT-T encapsulation. Currently there is no indication if a received packet is in NAT-T format with Non-ESP marker, or if it is the standard IKE format.