Nelson Shaw Design Project
Contents |
Trojan Project
As part of the COSC429 Information Warfare course, development of a Trojan module is required.
Background
The software should have command and remote modules, which are connected together via sockets. Functionality such as screen capture, key log capture and remote file browsing is required. Due to the complete assignment spec not being available, more functionality will be added later. The command module will be running on the attackers computer, while the remote module will be running on the targeted computer. Bypassing security and installing the remote component onto the targeted computer is not required. It is assumed that the remote module can be installed by a 3rd party and will be constantly running. Therefore, the focus of this design is providing the functionality required and ensuring secure communication.
Design Study
A current log of work spent on the project can be found here Design Project Log
Functionality
Basic
- Remote command channel
- Implant registration with server
- Screen capture
- Keyboard capture
- Target File browse
- File upload/download
Advanced Features
- Cryptographic channel protection
- Implant hiding
- Targer user list
- List of active processes
- Extract web history
- Extract email
- Audit log
Requirements
- Secure - Components and communication of software should be secure and unable to modify
- Maintainability - Easy to add new functionality (e.g. Multiple remote modules)
- Extensible - Add additional software components easily (e.g. Software to deliver remote module onto target system)
Constraints
Remote and control module communication, processing speed and associated overhead costs.
Many of the tasks require use of the Win32 API. I'm not sure how this impacts on the implementation language choice. I know languages such as C# provide relatively straight forward access to this interface, but I'm not so sure it is so simple using Java. If anyone's reading this, I would be very interested to know what you think. You can leave comments at the bottom of the page, under the 'Comments' section. The language I choose to implement in must have support for serialization and an easy Win32 API.
Initial Design
This is my current UML diagram -- a work in progress. I think I have the basic structure, but obviously there are a few class attributes and functions missing.
Description of Classes
ControlUnit ControlUnit is the main class of the control module. An observer pattern is used with the GUI and Controller. It contains a list of data objects which can then be displayed by the GUI. The data objects have a specified type e.g. Picture, Text, ... and so it will be up to the GUI to organise how to display them. Therefore any knowledge of the task from which the data came is unnecessary. The ControlUnit class will also have the appropriate update functions to enable an observer pattern.
Communicator Communicator is used to set up a connection between the control and remote modules. The type of encryption can be set, by passing an EncryptionStandard object. Both the ControlUnit and Remote objects create instances of the Communicator object. The main way the remote and control units will communicate, is by serializing and sending Task objects. Once an object is serialized it is then encrypted and sent. When received it is first decrypted and then de-serialized.
Serializer The serializer class is used to serialize task objects and return them as a byte array. It is also used to de-serialize objects.
EncryptionStandard The use of EncryptionStandard with the various subclasses allows the program to be extended to incorporate various encryption types. For the current implementation, it is expected that "Unsecured" and "RSA" Encryption Standards will be implemented. But in future it is possible to add say, AES encryption. By using the Strategy pattern, each subclass overrides the EncryptionStandard's functions such as encrypt and decrypt.
Task By using the strategy pattern for the Task class, it allows easy modification to add new functionality to the program. Currently, Screenshot and Keylog functionality is provided, but it should be relatively simple to add more. Once a task is performed by the remote program, data is added to the task which is then sent back to the control unit. The data class can be one of various types.
Data Data is a class that carries information produced on the Remote host from performing a Task. It has a type attribute which describes the type of data it is, as well as a text heading.
Design Critique
Displaying of the data by a list of Data objects in ControlUnit is perhaps not optimal? The GUI still has to know about the Data types that are possible, but is this an inevitable coupling?
Design patterns/ideas/principles used
Strategy is used in the Task and EncryptionStandard class design. In both classes, different types of tasks and encryption standards perform various functions differently. Because of this, strategy was used to create subclasses with functions that override that of it's super class.
Open Closed Principle The open closed principle states that the design should be open for extension but closed to modification. Taking the example of Tasks, a new task subclass can be easily added (extension), without the Task object itself being changed (no modification). In saying this, modification will be required in relation to the GUI providing the option to select this new task, but this is an inevitable problem.
Singleton Only one communicator object can exist in each program??
Observer The design pattern used linking the ControlUnit class with the GUI is an Observer pattern. The GUI will look at the list of data objects and display them according to their type.
Separation of concerns The classes are created to capture a single abstraction in each class.
Design Improvements
Here is a slightly more updated version of my UML diagram. The basic structure is correct I think, but many more functions will be added to Communicator once I learn more about socket programming.
Design Critique
There are still a number of design issues with this version. Namely, what's the best way for the GUI to know about display information regarded to each task? At this point I have opted for the GUI to only know about how to display a type T data. The DataType is defined as an Enum - which will be updated as the types of data required become clearer. This may be a unnecessary though, as the GUI is probably going to have to know about the various tasks that can be performed. This would be so that the user could choose which task they want performed.
Another issue is how the Communicator object will communicate with its counterpart object. This is related to how socket programming works, and will be updated once I learn more on the subject.
The design presents a simple version of the Observer pattern. This version is still very much in its infancy, and the specifics will be described once the implementation language is chosen. The basic idea is that once a task is complete, it will add the collected data to it the ControlUnit's taskData list. The ControlUnit will then call notifyGUI, which calls the GUI's update method. The GUI's update method will look for new data to display from the getTaskData method in ControlUnit and display it. In this way, the ControlUnit doesn't have to know what data the GUI is interested in displaying, it only tells it when something changes.
The EncryptionStandard object may not be as extensible as first thought. I originally planned for it to be able to handle all encryption standard types. At the moment I'm thinking the design may be limited to symmetric cryptography. Using asymmetric (public key) cryptography could be more of an issue with key development and negotiation, so at this stage it is based on a shared key system. However, through this design it should still be possible to add public key cryptography later. Effort will have to be made with the way that Communicator connects to its counterpart object, so that the connection procedure does not inhibit any possible key negotiation procedure.
Implementation and another re-design
OK so it turns out that design and implementation are BOTH important parts of the whole software creation process. As Wal was saying in lectures, often it's not until you begin to implement your design that you discover problems. This is probably more exaggerated in my case, as I don't have a substantial OO design background. This meant my design probably had issues I should have seen earlier.
Some things I found when implementing my design:
In order to use serialization to send tasks between the implant and controller, the Task object had to be defined in a common way. This resulted in creating a DLL which included the Task and Serializer classes. This DLL is then referenced from both the Implant and ControlUnit and allows tasks to be sent over the Socket connection and be serialized / de-serialized at each end.
Although it may seem like a duplicate code smell, there are two versions of the Communicator class that must exist. One exists to serve the Implant and the other to serve the ControlUnit. Each version of the Communicator class has a reference to either the ControlUnit or Implant. Although the same class could be used for both, for the Implant Communicator class to have a reference to the ControlUnit would be bad design and vice versa. Instead, the Communicator class is slightly modified for both the ControlUnit and Implant, so that it only has reference to one of them. Another solution would be to make the Implant and ControlUnit subclasses of another class, which could be referenced by the Communicator. This is an inefficient and over-the-top approach to solve the problem (Inheritance for implementation). I believe the solution used is acceptable, especially as the ControlUnit and Implant are actually different programs, so the duplicate code smell does not really apply.
The problem of the GUI and Data class. This basically comes down to the types of data that the GUI will have to be able to display. Originally, the idea was that the Data class would store the information created by performing the Task on the Implant machine. This Data would then be serialized and sent back to the ControlUnit where the GUI would know how to display it. After beginning the implementation, it became clear that there were many different types of data that the GUI would have to display. Examples are: Bitmap, List<String>, TreeNodes and so on. It also became clear that the where and how to display the Data in the GUI was dependent on the Task being performed. E.g. the ScreenShot task has a Bitmap that is displayed in the first tab. The idea of using a Data class seemed to just be creating a redundant accessory which was not needed. Since I am en devouring to "Keep things as simple as possible", I decided that the Data class should be removed and the data itself returned within the Task object. I argue that in order to know how to display the Data, the GUI has to know the type of the Data. This is no different to having to know the type of the Task which is returned. I also don't think it breaks the principle of "One key abstraction per class", as a Task should be able to perform its duty and store the resulting information under this idea. Any approach to this problem, whether using the Data class or not, leads to the inevitable conclusion of the GUI having to find out what type of data it is. This could be solved by the GUI requesting that a given task is performed (e.g. from User click on "Get Screenshot"), and the resulting task object received in the same method. In this way, depending on the button that was clicked, the GUI would always know what type of returning task it would be. This has the unfortunate property of "hanging" the GUI, while the task is performed. If this is something like a file upload/download, this is not acceptable. Because of this, the GUI has to be updated whenever a new task is received. This means that the GUI has to be able to determine the type of the task, in order to display the Data. It also means that coupling exists, as the GUI must know how to display the data given to it by the task. This is an awkward problem, which could only be fixed by the Task object having its own display method. However, this approach would not not obey the "One key abstraction per class principle".
A revised version of the class diagram, as well as source code will be posted shortly.
Comments
Please feel free to leave any comments, criticisms, ideas or problems you have. Speak your mind! :P
Thanks to User: James Ashford for the project page template.
