Design Project

Introduction

As a joint project Douglas Wall and I are developing an Implant and Controller for the Information Warfare course COSC429. This project will be topic of my COSC427 design project. The project consists of an application which allows nefarious activities to be performed on a target machine from the comfort of a separate machine. These activities could include,

• Keylogging
• Screen Grabbing
• Remote access to a command prompt.
• Stealing files
• Executing code

The project is to be developed for Windows operating systems. It will be coded in C# and is being developed in Visual Studio 2008. As the due date of the COSC429 project is further away than the due date of this design study the design of the system will be further ahead than the actual implementation. This is not a comfortable position to be in (I am not one for Big Design Up Front) but is necessary due to time constraints.

Requirements

More specifically, we wish to achieve the following in our project,

Figure 1 : Project Requirements

ID	Requirement	Description
1	Keylogging	Recording and storing the keystrokes of the victim
2	Screen grabbing	Taking one or many screenshots of the victims computer and storing them
3	Remote command prompt	Getting access to the command prompt which will allow browsing of the computer, the deletion and adding of files, running executable code and so on.
4	Multiple implant management	Allowing more than one victim to be managed by one implant.
5	Data analysis	Automated screening of data from keylogging activities to search for interesting information such as passwords.
6	Command line interface	The controller can be used through the command line.
7	Graphical user interface	The controller has an intuitive, tidy GUI.
8	Stealing files	The controller can select a file from the victim and download it to the controller computer.
9	Scalability	One commander could be responsible for a small army of implants.

Opposing Design Forces

In the creation of my design I found that there were competing forces at play that influenced my approach. I have described these below,

On the one hand I made an effort to conform to the Single responsibility principle (SRP) however at times I found this could be argued to conflict with Keep related data and behavior in one place. An example of this was when I made the decision to remove the responsibility of recieving, processing and outputting of service information away from the service proxy and place it in a data handler class. However, in my view what qualifies as "related" is not well defined. On this basis I chose to stick to SRP and extract out a class. A further benefit of this is discussed in my Future Work section.

I also noticed a conflict between the need for efficiency and scalability in contrast to clear and easy to understand design. As the number of implants to one commander could potentially be very large it is important to have a streamlined design. This made be feel very aware of the large number of objects that could be created at run time! However, I stuck with the maxim Premature optimization and this has allowed me greater freedom to plan out my design. This conflict has yet to resolve itself as the program is still not fully implemented and tested but the decision has been made on how to approach it.

Design

Overview

The overall solution is divided up in to a number of projects. The Commander project consists of all the back end code run on the commander machine. The Implant project contains all code intended to run on the victims machine. We have yet to implement a GUI interface but have a third project containing a command line interface. The rest of this section presents each project and provides a brief description of each class and its role. Please note that not all variables and methods are shown as the project is not yet complete. However, there should be enough there to indicate that the design should be a success.

Diagrams

Figure 2: Commander Project Class Diagram

Figure 3: Implant Project Class Diagram

Class Descriptions

Figure 4 : Class Descriptions

Class Name	Description
Connection	Contains the details of a connection and is responbile for sending and recieving raw data streams. Notifies observing services of the arrival of data
ConnectionFactory	Creates instances of Connection. Ensures existing connections are used if they already exist.
IServiceProxy	Defines the interface which service proxies follow. This includes KeyLoggerProxy, RemoteConsoleProxy and ScreenGrabberProxy. Allows services to be turned on and off.
IServiceDataHandler	Defines the interface by which data handlers follow. Each implemented service separates out the responsibility of retrieving data from the connection, processing it and exporting it to the data handler.
KeyLogFileReader	Responsible for parsing created KeyLogger files for instances of passwords.
KeyLogger	Contains the logic for recording keys and sending them back along the connection to the Commander.
ScreenGrabber	Contains the logic for taking screenshots and sending them back along the connection to the Commander.
Remote Console	Contains the logic for executing command arguments and sending the result back along the connection to the Commander.

Maxims, Patterns and General Points of Interest

This section lists the various maxims and patterns used and discusses why.

Patterns

A Proxy pattern provides an interface to services such as KeyLogger and ScreenGrabber. It can be seen in classes such as KeyLoggerProxy, ScreenGrabberProxy and RemoteConsoleProxy. This simplifies GUI and Console interface code by providing interfaces to services that are likely to exist on another machine. It also will hide the way the Commander and Implant communicate by wrapping this up in an interface.

An Observer pattern was used to avoid the Connection having knowledge of the services utilising it. Such knowledge would make the design hard to change if extra services were to be added. During development Doug and I considered the data arriving from the Implant to be analogous to baggages on the conveyer belt at the airport. Utilising this pattern allows the connection to act as the 'belt' and the services as the passengers that collect their luggage. In this way the Connection also avoids having to even understand the data that is being recieved. This is in line with the Single responsibility principle.

In practice a Commander is expected to have a large number of connections. Each connection will have a unique IP address and port number. The Abstract Factory pattern is used to maintain all the current connections. This encapsulates the task of managing connections and ensures only one instance of a specific connection exists at a given time. ConnectionFactory is the class that implements this pattern.

The factory uses the Singleton pattern. This enforces the constraint that there can only be one object who creates and knows about the existence of all connections. The pattern also provides greater ease of access for all services who use it. I generally do not like this pattern and so felt dirty for using it. You can find the discussion for this in Section 5.3.

Future Work

This section exists because the design presented could be further improved. Recognising that the design could always be improved is an important point in my view. These are some of the things to be done in the future,

It is possible that the assignment could benefit from outputting data into multiple forms. For example, it could be useful to export the KeyLogger data into XML. This could be implemented in a number of ways. For example, the KeyLoggerProxy or KeyLoggerDataHandler (To use as example of a service) could have methods to extract to each format. However, this could become unwieldy if a number of formats are required and does not sit well with the Single responsibility principle Another great option could of been to utilise a Visitor pattern but this does would not be suitable as data is being exported to a file as soon as it arrives from the connection stream. It is likely that I would implement the Strategy pattern in this case so that the handler could export data in different ways depending on what is required.

It is likely that the KeyLogFileReader will act as a Poltergeist. This is because it is only encapsulating the behaviour of parsing a file and returns a result so it is likely the object will only be created at the time it is needed and not used afterwards. On this basis it could be aruged that the class has a Lazy class smell and should be refactored using Inline class into KeyLoggerDataHandler. However, in my defense this design is a snapshot of a project that is continuing to be built. As mentioned in the previous paragraph it is possible that XML or other forms of output may be desired and so the tasks of parsing will change. Again, I chose to follow SRP and bring this responsibility out into its own class as it is likely I will want to further abstract and subclass it later.

Other Information

BenjaminTaylor Previous Design Work is a page containing my previous musings on my design project. I just did not want to throw it out!