The goal of this assignment is to further develop your C programming skills, and to demonstrate your un-

derstanding of networking and multithreaded programming.  You are to create two programs which together implement a brute-force password cracking system.  One program – crackserver  – is a network server which accepts connections from clients (including crackclient  which you will implement). Clients connect, and pro- vide encrypted passphrases that the server will attempt to crack (recover the original unencrypted passphrase).

Clients  may  also  request  the  server  to  encrypt  passwords  for  later  analysis.    Communication  between  the

crackclient and crackserver is over TCP using a newline-terminated text command protocol.  Advanced functionality  such  as  connection  limiting,  signal  handling  and  statistics  reporting  are  also  required  for  full marks. CSSE7231 students shall also implement a simple HTTP interface to crackserver.

The  assignment will  also test your  ability to  code to  a  particular  programming  style  guide  and to  use  a

revision control system appropriately.

Student Conduct

This is an individual assignment. You should feel free to discuss general aspects of C programming and the assignment specification with fellow students, including on the discussion forum. In general, questions like “How should the program behave if〈this happens)?”  would be safe, if they are seeking clarification on the specification.

You must not actively help (or seek help from) other students or other people with the actual design, structure and/or coding of your assignment solution. It is cheating to look at another student’s assignment code and it is cheating to allow your code to be seen or shared in printed or electronic form by others . All submitted code will be subject to automated checks for plagiarism and collusion. If we detect plagiarism or collusion, formal misconduct actions will be initiated against you, and those you cheated with. That’s right, if you share your code with a friend, even inadvertently, then both of you are in trouble.  Do not post your code to a public place such as the course discussion forum or a public code repository.  (Code in private posts to the discussion forum is permitted.) You must assume that some students in the course may have very long extensions so do not post your code to any public repository until at least three months after the result release date for the course (or check with the course coordinator if you wish to post it sooner). Do not allow others to access your computer – you must keep your code secure. Never leave your work unattended.

You must follow the following code referencing rules for all code committed to your  SVN repository

(not just the version that you submit):

Uploading or otherwise providing the assignment specification or part of it to a third party including online tutorial and contract cheating websites is considered misconduct.  The university is aware of these sites and many cooperate with us in misconduct investigations.

The teaching staff will conduct interviews with a subset of students about their submissions, for the purposes of establishing genuine authorship.  If you write your own code, you have nothing to fear from this process.  If you legitimately use code from other sources (following the usage/referencing requirements in the table above) then you are expected to understand that code.  If you are not able to adequately explain the design of your solution and/or adequately explain your submitted code (and/or earlier versions in your repository) and/or be able to make simple modifications to it as requested at the interview, then your assignment mark will be scaled down based on the level of understanding you are able to demonstrate and/or your submission may be subject to a misconduct investigation where your interview responses form part of the evidence.  Failure to attend a scheduled interview will result in zero marks for the assignment.  The use of referenced code in your submission (particularly from artificial intelligence tools) is likely to increase the probability of your selection for an interview.

In short - Don’t risk it!  If you’re having trouble, seek help early from a member of the teaching staff. Don’t be tempted to copy another student’s code or to use an online cheating service.   Don’t help another

CSSE2310/7231 student with their code no matter how desperate they may be and no matter how close your relationship. You should read and understand the statements on student misconduct in the course profile and on the school website: https://www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism.

Simple encryption and salting

Hashing is a common method of protecting sensitive data such as passwords. Instead of storing or transmitting the password itself (plaintext) where it is at risk of interception, the password is first transformed by passing it through a one-way function called a hash, yielding the ciphertext. A one-way function is one that is easy to apply in one direction (plaintext to ciphertext), but impossible to apply in the reverse.

Because hash functions are deterministic, identical passwords encrypted with a hash function yield identical

ciphertext, which can assist an adversary in compromising a system.  For this reason, the hashing scheme is usually extended with a method called salting.  The plaintext is extended with a random value, or salt, prior to applying the hash function.  The salt is stored along with the encrypted password, as both are required to verify a given password and its hash.

With a sufficiently large possible range of salt values, this helps prevent attackers from building tables that store the hash results of every possible  (salted) password,  increasing security by making the cracking more challenging.

libcrypt is a POSIX library that supports a wide range of hashing functions and salting schemes – in this assignment you will use it in its simplest mode.  Note that this mode is now considered obsolete, and should not be used for protecting data in modern systems.

The crypt() function is all that is required. In the simplest mode it is used as follows:

where plaintext is a pointer to a string containing the plaintext password, and salt is a pointer to a string containing the salt. Only the first 8 characters of plaintext are used, and only the first two characters of salt are used. Any additional characters are ignored.

Additionally, the salt must only contain characters from the following character set:

a  b  c  d  e  f  g  h  i  j  k  l m  n  o  p  q  r  s  t  u  v  w  x  y  z

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T U  V  W  X  Y  Z

0  1  2  3  4  5  6  7  8  9  .  /

The return value from crypt() is a pointer to a static buffer, so the caller must copy this before making any further calls to crypt().  A reentrant version of crypt() called crypt_r() is also available – refer to the man page for details and usage.

Here are some examples:

● plaintext "foobar", salt "AA" → ciphertext "AAZk9Aj5/Ue0E"

● plaintext "dinosaur", salt "0z" → ciphertext "0zD1fV .Yez8RI"

Notice how the supplied salt characters always form the first two characters of the encrypted string.

The crypt() family of functions is declared in , and you will need to link your crackserver with the -lcrypt argument to use them in your programs.

Specification – crackclient

The crackclient program provides a command line interface that allows you to interact with crackserver as

a client – connecting to the server, sending crack and encryption requests, and displaying the results. To implement this functionality, crackclient will only require a single thread.

Command Line Arguments

Your crackclient program is to accept command line arguments as follows:

./crackclient  portnum  [jobfile]

●  The mandatory portnum argument indicates which localhost port crackserver is listening on – either numerical or the name of a service.

●  The optional jobfile argument specifies the name of a file to be used as input commands. If not specified, then crackclient is to read input from stdin.

crackclient behaviour

If an incorrect number of command line arguments are provided then crackclient should emit the following message (terminated by a newline) to stderr and exit with status 1:

If the correct number of arguments is provided, then further errors are checked for in the order below.

Job file error

If a job file is specified, and crackclient is unable to open it for reading, crackclient shall emit the following

message (terminated by newline) to stderr and exit with status 2:

where jobfile is replaced by the name of the specified file. Note that the file name is enclosed in double quote characters.

Connection error

If crackclient is unable to connect to the server on the specified port (or service name) of localhost, it shall

emit the following message (terminated by a newline) to stderr and exit with status 3:

where N should be replaced by the argument given on the command line. (This may be a non-numerical string.)

crackclient runtime behaviour

Assuming that the commandline arguments are without errors, crackclient is to perform the following actions, in this order, immediately upon starting:

●  connect to the server on the specified port number (or service name) – see above for how to handle a connection error;

● read commands either from the jobfile, or stdin, and process them as described below; and

● when EOF is received on the input stream (job file or stdin), crackclient shall close any open network connections, and terminate with exit status 0.

If the  network  connection  to  the  server  is  closed  (e.g.  crackclient  detects  EOF  on  the  socket),  then crackclient shall emit the following message to stderr and terminate with exit status 4:

Note that crackclient need only detect EOF on the socket when it is reading from the socket. It will only do this after it has read a line from the jobfile (or stdin), sent that to the server, and is then awaiting a response. It is not expected that crackclient will detect EOF on the network socket while it is waiting to read from stdin.

crackclient shall interpret its input commands as follows:

●  Blank lines (i.e. those lines containing no characters), and those beginning with the # character (comment lines), shall be ignored

●  All other lines shall be sent unaltered to the server (no error checking is required or to be performed)     Upon sending a command to the server, crackclient shall wait for a single line reply, and interpret it as follows:

●  Response ":invalid" → emit the following text to stdout:

●  Response ":failed" → emit the following text to stdout:

●  Otherwise, the raw output received from the server shall be output to stdout.

Your crackclient program is not to register any signal handers nor attempt to mask or block any signals.

crackclient example usage

The following is an example of an interactive session with crackclient (assuming the crackserver is listening on port 49152). Lines in bold face are typed interactively on the console, they are not part of the output of the program:

Note that not all possible error conditions are present in this example.

The following is an example of a file driven session with crackclient (assuming the crackserver is listening on port 49152). Lines in bold face are typed interactively on the console, they are not part of the output of the program, given that cmd .in has the following contents: