Design Project
| Line 42: | Line 42: | ||
In the creation of my design I found that there were competing forces at play that influenced my approach. I have described these below, | 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 | + | 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. | 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. | ||
| Line 55: | Line 55: | ||
=== Separation of Concerns within Commander Project === | === Separation of Concerns within Commander Project === | ||
| + | |||
| + | == Future Work == | ||
| + | |||
| + | This section exists because the design presented could be further improved. I think this is an important point to make. 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. | ||
| + | |||
== Other Information == | == 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! | [[BenjaminTaylor Previous Design Work]] is a page containing my previous musings on my design project. I just did not want to throw it out! | ||
Revision as of 08:42, 1 October 2009
Contents |
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 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
Diagrams
Class Descriptions
Maxims, Patterns and General Points of Interest
Separation of Concerns within Commander Project
Future Work
This section exists because the design presented could be further improved. I think this is an important point to make. 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.
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!
