[GH-ISSUE #577] Refactoring packet response handlers to not use GUI as data store

kerem commented

2026-02-27 15:49:56 +03:00

Owner

Originally created by @dwendt on GitHub (Jan 12, 2017).
Original GitHub issue: https://github.com/quasar/Quasar/issues/577

I went to add automated on-connect commands and near the end I realized the majority of packet handling code is directly tied to forms currently being open (GetPasswordsResponse, etc). Rendering that feature I wrote mostly useless.

So, data ingestion/storage in HandlePacket and the views for this data need to be decoupled. This is probably the first step to porting the server to be usable via CLI as well.

I'd propose this design pattern for the refactored handlers, though I'm not a C# pro:

Run a thread to process data into desired format.
Store data into dict/hashmap/list/etc. for the feature, kept in either QuasarServer or CommandHandler or perhaps a new class specifically for feature-data storage/serialization.
Call out to the GUI elements to refresh their data. (either pass the new data or the GUI has access to the data storage singleton?)

Here's a list of handlers that store packet results directly to GUI that need to be modified, ones left out only act as a success-indicator for GUI actions.

HandleSetStatus
HandleSetUserStatus
HandleGetProcessesResponse
HandleGetDrivesResponse
HandleGetDirectoryResponse
HandleDoDownloadFileResponse
HandleGetSystemInfoResponse
HandleGetMonitorsResponse
HandleGetWebcamsResponse
HandleGetWebcamResponse
HandleDoShellExecuteResponse
HandleGetStartupItemsResponse
HandleGetKeyloggerLogsResponse
HandleLoadRegistryKey - might not be needed, but I can see use case where you'd want to pull data from client registries asynchronously using this
HandleGetConnectionsResponse

So that's going to be a weekend project for (me || anyone else who needs this quicker) eventually, I'd love input from people on the project if you'd like to see it implemented differently :)

Originally created by @dwendt on GitHub (Jan 12, 2017). Original GitHub issue: https://github.com/quasar/Quasar/issues/577 I went to add automated on-connect commands and near the end I realized the majority of packet handling code is directly tied to forms currently being open (GetPasswordsResponse, etc). Rendering that feature I wrote mostly useless. So, data ingestion/storage in HandlePacket and the views for this data need to be decoupled. This is probably the first step to porting the server to be usable via CLI as well. I'd propose this design pattern for the refactored handlers, though I'm not a C# pro: 1. Run a thread to process data into desired format. 2. Store data into dict/hashmap/list/etc. for the feature, kept in either QuasarServer or CommandHandler or perhaps a new class specifically for feature-data storage/serialization. 3. Call out to the GUI elements to refresh their data. (either pass the new data or the GUI has access to the data storage singleton?) Here's a list of handlers that store packet results directly to GUI that need to be modified, ones left out only act as a success-indicator for GUI actions. - [ ] HandleSetStatus - [ ] HandleSetUserStatus - [ ] HandleGetProcessesResponse - [ ] HandleGetDrivesResponse - [ ] HandleGetDirectoryResponse - [ ] HandleDoDownloadFileResponse - [ ] HandleGetSystemInfoResponse - [ ] HandleGetMonitorsResponse - [ ] HandleGetWebcamsResponse - [ ] HandleGetWebcamResponse - [ ] HandleDoShellExecuteResponse - [ ] HandleGetStartupItemsResponse - [ ] HandleGetKeyloggerLogsResponse - [ ] HandleLoadRegistryKey - might not be needed, but I can see use case where you'd want to pull data from client registries asynchronously using this - [ ] HandleGetConnectionsResponse So that's going to be a weekend project for (me || anyone else who needs this quicker) eventually, I'd love input from people on the project if you'd like to see it implemented differently :)

kerem

2026-02-27 15:49:56 +03:00

closed this issue
added the
improvement
label

kerem commented

2026-02-27 15:49:57 +03:00

Author

Owner

@chico-depressive commented on GitHub (Jan 18, 2017):

@dwendt good!

@chico-depressive commented on GitHub (Jan 18, 2017): @dwendt good!

kerem commented

2026-02-27 15:49:57 +03:00

Author

Owner

@dwendt commented on GitHub (Jan 24, 2017):

Hey @MaxXor, I've abstracted getting/setting data for unique clients into a Storage singleton. For actually handling the writing/getting/searching in this class a DB makes the most sense. Would you be against a PR that rolls in http://www.litedb.org/ to do this in a local file? This can be extended to connect to and use some real external DB with minimal effort later, but litedb can be rolled in.

Alternatively, if JSON objects are a pain in litedb, maybe https://github.com/praeclarum/sqlite-net

edit: nope, they are not a pain. very simple.

@dwendt commented on GitHub (Jan 24, 2017): Hey @MaxXor, I've abstracted getting/setting data for unique clients into a Storage singleton. For actually handling the writing/getting/searching in this class a DB makes the most sense. Would you be against a PR that rolls in http://www.litedb.org/ to do this in a local file? This can be extended to connect to and use some real external DB with minimal effort later, but litedb can be rolled in. Alternatively, if JSON objects are a pain in litedb, maybe https://github.com/praeclarum/sqlite-net edit: nope, they are not a pain. very simple.

kerem commented

2026-02-27 15:49:57 +03:00

Author

Owner

@life-coder commented on GitHub (Mar 15, 2017):

@dwendt I like your idea, but porting all that would rewrite a big part. I think you want to do something like on client connection, request chrome passwords.? Or? You could fix that by adding a new packet, like: ServerRequestPasswords and create a commandhandler entry for it to save it to a file ;)

@life-coder commented on GitHub (Mar 15, 2017): @dwendt I like your idea, but porting all that would rewrite a big part. I think you want to do something like on client connection, request chrome passwords.? Or? You could fix that by adding a new packet, like: ServerRequestPasswords and create a commandhandler entry for it to save it to a file ;)

kerem commented

2026-02-27 15:49:57 +03:00

Author

Owner

@MaxXor commented on GitHub (Jun 8, 2020):

This has been fixed in https://github.com/quasar/Quasar/releases/tag/v1.4.0

@MaxXor commented on GitHub (Jun 8, 2020): This has been fixed in https://github.com/quasar/Quasar/releases/tag/v1.4.0

Rows
Columns

[GH-ISSUE #577] Refactoring packet response handlers to not use GUI as data store #337