Design Project
m (→Description) |
(→Description) |
||
| Line 46: | Line 46: | ||
=== Description === | === Description === | ||
| − | The application can be divided up into a number of separate projects. The Commander project in Figure 1 | + | 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 ==== | ==== 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 ==== | ==== Implant ==== | ||
| + | |||
| + | The Implant also utilises the [[Observer]] pattern described above which provides many of the same benefits. | ||
=== Justification === | === Justification === | ||
Revision as of 12:53, 23 September 2009
Contents |
COSC427 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. We intend to code using Test Driven Development.
Requirements
More specifically, we wish to achieve the following in our project,
| 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 and screen grabbing 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. |
Design (1)
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.
Justification
Critique
Summary and Learning
Design (2)
Design (3)
Draft Notes - Please Ignore
* What is this project * What specifically are our requirements * What is the language and development tools * What are the intial design sketches * Why have I chosen that initial design * What is wrong with that design * Continued iterations of the design with justifications
