Design Project

Revision as of 01:32, 2 October 2009

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,

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.

It is also important to note that I have not added GUI classes in as part of the design study. This is because the main intention is to present the project with a command line interface and so I do not feel the addition of a diagram would provide anything interested to this design project. For clients - such as the command line interface - to interact with the Commander project they should create instances of the services that they require with the IP Address and port number of the Implant that is active. The responsibility for knowing what Implants are active is left to the client. Clients are not expected to create their own Connection objects though there is no rule against them doing so. Clients are also expected to create KeyLoggerFileReader objects to extract information from already created files.

Diagrams

Figure 2: Commander Project Class Diagram

Figure 3: Implant Project Class Diagram

Class Descriptions

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.

Separation of Concerns within Commander Project

This was one of the more challenging parts of the design study. I identified that there were three major responsibilities that existed in the Commander project. These were to manage the flow of data in a connection, managing the services on each individual connection and processing and exporting of the data for each service once it was returned. It seemed natural to employ maxims such as Model the real world to produce the Connection class which dealt only with the sending of raw bytes of data across the stream. However, it was more tricky to determine how exactly to represent the services. Along with the final choice of a Proxy for each service object on each connection I also considered maintaining a single proxy object for type of service. This concept can be seen in BenjaminTaylor Previous Design Work under Design 2. In this alternative design I would only have one KeyLoggerProxy, one RemoteConsoleProxy and one ScreenGrabberProxy. However, this approach contained problems such as

• No clear answer on who would 'own' DataHandler objects for each service. If they are owned by a Connection then you introduce unnecessary coupling.
• In my view it makes the design more difficult to understand. Having multiple proxy objects models more closely what is actually the case across the network.

Again, scalability and efficiency drove me to consider this alternative design but as mentioned previously I decided to avoid Premature optimization and this gave me greater freedom.

Further Discussion on Singleton Pattern

The use of a Singleton in my design is possibly the thing I feel most uncomfortable about. In its defense it has ensured that only one ConnectionFactory will exist in the lifetime of the application. In this sense it has modelled a constraint.

Without a the use of a Singleton I required some way to knit together the service proxy with the factory and through this its connection. I had considered wrapping this up in some sort of CommanderApp class which would piece together everything but felt it added a level of complexity between the Commander and its client. It would essentially mean a client (For example a command line interface) would need to first create a CommanderApp then somehow specify what services it wanted to access. Perhaps further consideration could of yielded up another possibility but I felt a Singleton pattern solved the issue.

On the other hand it also has introduced some negatives to my design. It acts essentially the same as a global variable and so breaks No global variables or functions it also exposes the ConnectionFactory too widely allowing anything in the application to access it. This is not intended in the design.

The decision to use the Singleton came from weighing up both the advantages and disadvantages of this and other alternatives. I have added this as future work because should I find a good alternative to approaching the design I would be much more comfortable removing the Singleton.

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

As mentioned in the previous section it would be worth refactoring my design to remove the Singleton pattern if possible. However, this would require finding a viable alternative and I have not at this stage discovered this. Suggestions would be welcome!

Source Code

Not yet available!

This is a snapshot of the source project as of the due date. Please be aware that most of the functionality is not available as the due date for this project is later than for the design study. However, you should find the source project demonstrates that the design I have presented is grounded in reality.

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!