Design Project

Latest revision as of 03:42, 5 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.

An Implant for the purposes of this design is a target machine which is being monitored and exploited by the software. A controller (Or referred to as a Commander also) is the machine controlling the services on implant machines. 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,

Initial Considerations

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

Diagram Notes

Both diagrams presented are not strictly UML. Words above relationship lines represent role names. Multiplicities are not expressly stated but are indicated in one direction by the use of a single (one) or double (many) arrow. I have stated the multiplicities explicitly below.

• ConnectionFactory - Connection is a one to many relationship where connections belongs to ConnectionFactory.
• Observable - IObserver is a one to many relationship where observers belongs to Observable.
• Proxy - DataHandler is a one to one relationship where dataHandler belongs to the Proxy. This relationship describes all proxies and all data handlers for each service.

Please note that there is a mistake in the above diagram. Should be KeyLoggerFileHandler, not KeyLogFileHandler.

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.

The Proxy pattern is reccommended by Martin Fowler in this sort of situation.[1]

Introducing a proxy has also provided a cleaner separation of responsibilities. I have discussed this further in the next section.

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. 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 the later section discussing Singletons.

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.

It was more tricky to determine how exactly to represent the services. In the most basic case I could of not represented services in the Commander Project. This is a very bad choice and could of resulted in problems. It is not clear where the logic for communicating services would go. Possibly it would of lived in Connection making the application inflexible to change and making Connection a God Class. A slightly more advanced concept would be to have a class named after each service in the Commander project. In other words, the Commander project would have a KeyLogger class, a ScreenGrabber class and so on. I would imagine this would be where many people would start. However, this means that the responsibility to process and write data to files would live in the service itself. In my view these are separate responsibilities and so belong by themelves. A Proxy pattern allows me to maintain a clear interface to a service while I place other responsibilities in another class (See my discussion on IServiceDataHandler for more detail on this).

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. I have elaborated on this discussion in the section named Client Interaction.

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.

IServiceDataHandler

The use of a name like DataHandler or Manager is a concern in any design. It can often indicate a Proceedural programming approach where classes become encapsulations for a step in a process. This section attempts to justify the existence of the interface and its implementations in my design.

The primary analogy used for the project was that of a baggage at the airport. From this analogy we can extract a number of responibilities. I list these below,

• The transportation of the bag from one place to another.
• The checking in of baggage.
• The collecting of baggage.

This is similar to our project in that we have messages 'checked-in', collected and transported. Going with the analogy this might lead one to assume that there are two classes here, the service (the person who owns the bags) and the connection (The airplane, of sorts). However, each of these tasks I would argue is a separate responsibility and so by SRP I should separate these each into their own class.

I chose the name DataHandler as it describes its main responsibility. It needs to be able to watch for new incoming data off the connection, identify it as its own data, decipher it and store it. These are all tasks that I do not feel are strongly connected to the specific service and certainly not related to the proxy. Saying this another way, if there was no network connection in this application I would not encapsulate these actions within the service class itself but instead delegate file writing to some other object (perhaps a Visitor pattern). However, I do feel this responsiblity is closely coupled with the service and so is coupled together using composition.

Client Interaction

One major focus of my design was to ensure I clearly defined the interface for clients to interact with the application. Essentially this is a matter of following the Presentation separation idiom as the intended clients of our application are graphical and command line interfaces. Using the Design by contract metaphor, I sought to minimise the preconditions for usage of the backend by the client to ensure the client contract with the system was not overly onorous. This meant there were two key features needed in the design.

• Encapsulation of all key responsibilities so none would spill over to the client
• A clear interface to allow easy interaction between the back end application and the client.

My solution to this was to design the Proxy classes as key interface points for clients to use. It is assumed that the key interest of a client is utilising a service on a certain connection. This means that to use the backend the client only needs to create an instance of a Proxy object and begin interacting with it. The underlying connection and file writing is hidden from the client (but can be tampered with if the client chose to). The client has no need to handle any logic associated with any of the tasks except for maintaining an understanding of what connections currently have running implants (I mentioned this in my Introduction).

As mentioned earlier I am not comfortable with the introduction of a Singleton in my design. In order to avoid this I considered creating a class named CommanderApp. This would be responsible for initially knitting together a service with its connection through interacting with the ConnectionFactory. However, I decided against this primarily to ensure that the interface to the client was as clear as possible. Having a client need to create a CommanderApp object added unnecessary complication to the contract with the client.

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.

Martin Fowler and others reccommend the use of Data Transfer Objects as a means of communicating data over a network. Although I have not addressed this issue in my design adding this feature in could simplify the communication between Commander and Implants.

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

File:COSC429Assignment.zip

This is a snapshot of the code at submission date. It contains the classes mentioned in the design and steps towards knitting it together as a working program. Be aware that the solution does not currently work as not everything has been implemented. This is only submitted to aid the marker in understanding the project should they feel it necessary to trawl through this very incomplete code.

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! It might be useful if you are interested in seeing previous steps in the design process however, I believe that I have covered the points of interest from this in my design study.