Design Project

From CSSEMediaWiki

(Difference between revisions)

Revision as of 08:33, 1 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. We intend to code using Test Driven Development.

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 reponsibility 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

Diagrams

Class Descriptions

Maxims, Patterns and General Points of Interest

Separation of Concerns within Commander Project

Draft Notes Please Ignore

Deciding between

1) 1 proxy object to 1 connection 2) 1 proxy object to many connections speaking via the factory

1) Advantages

Easy to implement

Disadvantages

Object explosion! Produces an inflexible design harder to add new services

2) Advantages

Easy to add new services due to loose coupling with the connection Great reduction on numbers of objects

Disadvantages

No clear answer as to who now handles data coming out (I chose to split this reponsibility and have one data processing object for each service on the connection. Can only instantiate what I need at the time)

Design (3)

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!

@@ Line 56: / Line 56: @@
 === Separation of Concerns within Commander Project ===
-== Design (1) ==
-[[Image:Commander.jpg|centre|frame|Figure 1 : Commander Project Class Diagram]]
-[[Image:Implant.jpg|centre|frame|Figure 2: Implant Project Class Diagram]]
-=== Description ===
-The application can be divided up into a number of separate projects. The Commander project in Figure 1 manages connections with Implants and provides an interface for services (for instance a KeyLogger) running on the Implants. The Implant project in Figure 2 contains the logic for each service and also manages its connection back to the Commander. There is also a project named CommanderConsole and another named CommanderGUI which handle the console and GUI elements of the Commander interface. I have chosen not to show these projects in diagrams in this iteration. The following sections outline the design decisions made for each project.
-==== Commander ====
-A [[Proxy]] pattern provides an interface to services such as KeyLogger and ScreenGrabber. 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 [[Flyweight]] 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.
-==== Implant ====
-The Implant also utilises the [[Observer]] pattern described above which provides many of the same benefits.
-=== Critique ===
-The primary issue with this design is that it is incomplete. Many of the services are not yet implemented. It also does not yet address how the services are to use the connection to send data. This would seem to require the connection to be associated with the service. It is likely this is how I will approach the problem but I have yet to make a decision on this. Some of the requirements are not met in this design. For example, there is no way to analyse data that is recieved - or even process the data in the first place! These issues will be amended in later iterations of the design.
-There is also no obvious means of knitting together the services to their connection. At the present moment I am assuming that the GUI or Console interfaces will be responsible for this task but would break the [[Presentation separation idiom]]. I would like to explore other possibilities such as using an [[Abstract Factory]] which could create the services and register them as observers at the same time.
-I am not sure whether [[Flyweight]] is an appropriate choice of pattern in the project. It appears to be a tidy way to maintain the list of connections but I need to do further reading on the pattern to make sure it is what I want.
-=== Summary and Learning ===
-I have made a start on the design of the system and need to elaborate further. I also need to clarify my understanding of Flyweight to ensure it is being used appropriately in my project.
-== Design (2) ==
-[[Image:Commander2.jpg]]
 Draft Notes Please Ignore

Design Project

Revision as of 08:33, 1 October 2009

Contents

Introduction

Requirements

Opposing Design Forces

Design

Overview

Diagrams

Class Descriptions

Maxims, Patterns and General Points of Interest

Separation of Concerns within Commander Project

Design (3)

Other Information

Views

Personal tools

Navigation

Search

Toolbox