mirror of
https://github.com/quasar/Quasar.git
synced 2026-04-25 15:25:59 +03:00
[GH-ISSUE #277] [Plugin Support] Architecture discussion #133
Labels
No labels
bug
bug
cant-reproduce
discussion
duplicate
easy
enhancement
help wanted
improvement
invalid
need more info
pull-request
question
wont-add
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Quasar#133
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @abdullah2993 on GitHub (Jul 11, 2015).
Original GitHub issue: https://github.com/quasar/Quasar/issues/277
I'm currently working on plugin support for xRat. So far what I have in mind is something like UploadAndExecute where you send the plugin assembly over to the client. The client then execute the Plugin Method and sends the response back to the server where it is handled using the same plugin assembly. The architecture so far is quite messy so I'm open to any suggestion or architectural change.
@yankejustin commented on GitHub (Jul 11, 2015):
Hmmm.
Out of curiosity, what will the plugin support offer that UploadAndExecute won't?
The beauty of the above feature is that we have a basic client we build, then we can execute any custom functionality we wish via the existing UploadAndExecute.
@abdullah2993 commented on GitHub (Jul 12, 2015):
@yankejustin well UploadAndExecute is dumb you give it an exe it downloads it to AppData and the executes it and nothing.
With plugin system you can write any kind of functionality with custom display and whatever and all of this will be in memory first you send your plugin to the client which will load it using Assembly.Load and execute the functionality and sends the response back to the server which will handle it using the same plugin handler.
So it will work as any other feature of xRat like ShowMessageBox, GetSystemInformation etc
@yankejustin commented on GitHub (Jul 12, 2015):
Oh. Implementation of a dynamic loading system is actually easier than UploadAndExecute.
Also, saying UploadAndExecute is dumb because it does exactly what it is named is a bit odd.
Anyways, I would finally like to clarify that this is not like UploadAndExecute. It is dynamic loading and is actually rather easy.
After sending the assembly for the client to load, the client loads it in and waits for another packet. The next packet will contain the name of the method to attempt to invoke, then the client attempts to invoke it.
More extensive dynamic loading is a more difficult task than keylogging, because extensibility and control is emphasized so hard. I wish you luck.
@yankejustin commented on GitHub (Jul 12, 2015):
A relevant idea is to add some form of shadow copying functionality.
@MaxXor commented on GitHub (Jul 12, 2015):
A plugin system would be great, it should be really simple. The Server sends the client the plugin and then it adds new functionality to the client, like it can receive new commands etc.
@ghost commented on GitHub (Jul 12, 2015):
Would it be ideal to load modules dynamically, or would it be viable in this case to store the modules on the client machine to be loaded each time the client has started?
E.g. Send plugin over network to client-side -> store plugin on disk.
If the client is restarted, the plugins are available on the client machine and can be loaded.
Vs.
E.g. Send plugin to client-side -> Load plugin
@yankejustin commented on GitHub (Jul 13, 2015):
@d3agle The client should store it whenever possible.
Whenever a Client receives a plugin use request from the server, it makes sure it exists, requesting the whole thing from the server if it does not.
It would probably be wise to not load these in at Client start unless specified. We should (for performance or to prevent forgotten/bad assemblies from being loaded) load them whenever method related to the plugin is invoked.
Little Example
Server has a module named
TestModule. The module is selected for the Client object (server-side). The Server sends an inquiry to the Client to check if it already has the module. If the Client does not have the module, send it.After the Client (receives and) loads the module in successfully, it informs the Server. The Server will then add the relevant information about the plugin into a
Listor something similar.The rest is actually more a matter of implementing an elegant system to gently guide reflection into making invocation of the desired method as simple as possible.
@yankejustin commented on GitHub (Jul 13, 2015):
Note
We should really make sure to make a separate
Formfor the user. Perhaps we can use aListViewfor the plugins. :)@bitterypaul commented on GitHub (Aug 2, 2015):
Just to clarify, do you want xRAT client to be barebones version and add features like remote desktop, keylogger etc as plugins. Or like adding extra features on top of the existing feature set?.
@MaxXor commented on GitHub (Aug 2, 2015):
@bitterypaul If the plugin system is working great, we can make remove most of the features from the client and add them as plugins.
@bitterypaul commented on GitHub (Aug 2, 2015):
So we can implement the plugin system on top of the xRAT client deployer as mentioned in #102
@bitterypaul commented on GitHub (Aug 2, 2015):
Will the plugin system be only for the client but also for the server? I also think about making the forms for keylogger, reverse proxy etc as plugins for the server so that we can have a fully modular RAT. Also this hides the forms for features in the server which are not supported by the client. This also makes updates for specific features easy.
@MaxXor commented on GitHub (Aug 2, 2015):
Plugins add functionality to the client & server, how are we supposed to use the Remote Desktop for example when we have no Form for it? 😄
Anyways I think making this RAT fully modular with plugin support is a huge step, we should plan this for a complete new release of this RAT maybe. But I think the Client & Server are at a reliable state now, that we could do this change.
@abdullah2993 commented on GitHub (Aug 2, 2015):
@MaxXor the Form for Remote Desktop can be packed within the plugin :)
@MaxXor commented on GitHub (Aug 2, 2015):
@Abdullah2993 Yes of course, lol. That was sarcasm regarding the question from @bitterypaul.
@yankejustin commented on GitHub (Aug 3, 2015):
@MaxXor I definitely agree. This should be for a future version of Quasar as it would require a fair amount of untangling, abstracting, and dynamic plugin addition functionality (making it work, and not allowing it to break easily).
@yankejustin commented on GitHub (Aug 30, 2015):
Modularity and large amounts of abstractions are likely to best be implemented after recreating the user interface using WPF. If we correctly use the concepts of MVVM, abstractions are likely to be necessary at a minimal level and modularity should be exist quite easily. After the switch to WPF, it is likely that this should then be toyed with more.
@rabbitsmith commented on GitHub (Sep 7, 2015):
wpf is not supported on linux.
@MaxXor commented on GitHub (Sep 7, 2015):
@rabbitsmith thanks, good to know!
Anyways, we must put off our plugin system plans. It would require so many changes to the Server & Client that we could start from the beginning. Maybe in Quasar 2.0.^^