[GH-ISSUE #554] Client still accessible but keylogger has stopped #314

New issue

Closed

opened 2026-02-27 15:49:49 +03:00 by kerem · 5 comments

kerem commented

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

Owner

Originally created by @ghost on GitHub (Nov 22, 2016).
Original GitHub issue: https://github.com/quasar/Quasar/issues/554

I've been testing quasarrat for a while now, and after almost exactly 10 days the keylogger is no longer outputting any new data. I know the PC is in use, remote desktop surveillance, etc. all work. Is there any way to reset the program remotely to try and fix this? Will remotely executing the executable again work?

Update: I had local access to the desktop in question so I just closed the process and ran the executable again, it's working now. Would still like to know why it stopped in the first place. I know the user sometimes uses a japanese keyboard (in windows) but it never had problems handling that input before (since the key presses are the same regardless).

Update 2: Just noticed today that the system clock on the PC seems to be failing, it was showing a time quite a bit behind what it should be. Would this screw up the keylogger?

Originally created by @ghost on GitHub (Nov 22, 2016). Original GitHub issue: https://github.com/quasar/Quasar/issues/554 I've been testing quasarrat for a while now, and after almost exactly 10 days the keylogger is no longer outputting any new data. I know the PC is in use, remote desktop surveillance, etc. all work. Is there any way to reset the program remotely to try and fix this? Will remotely executing the executable again work? Update: I had local access to the desktop in question so I just closed the process and ran the executable again, it's working now. Would still like to know why it stopped in the first place. I know the user sometimes uses a japanese keyboard (in windows) but it never had problems handling that input before (since the key presses are the same regardless). Update 2: Just noticed today that the system clock on the PC seems to be failing, it was showing a time quite a bit behind what it should be. Would this screw up the keylogger?

kerem

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

closed this issue
added the
bug
label

kerem commented

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

Author

Owner

@MaxXor commented on GitHub (Nov 27, 2016):

It's possible that the failing system clock caused this issue. It's a bit hard for me to debug it cause of the 10 days runtime needed. Maybe you can find out if it's working with corrected system clock. Japanese keyboard should be no problem.

@MaxXor commented on GitHub (Nov 27, 2016): It's possible that the failing system clock caused this issue. It's a bit hard for me to debug it cause of the 10 days runtime needed. Maybe you can find out if it's working with corrected system clock. Japanese keyboard should be no problem.

kerem commented

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

Author

Owner

@Galaden commented on GitHub (Nov 27, 2016):

Nope, nothing to do with the clock

@Galaden commented on GitHub (Nov 27, 2016): Nope, nothing to do with the clock ![time](https://cloud.githubusercontent.com/assets/13715233/20651858/eb13d700-b4f5-11e6-8af2-37e1a76718ce.PNG)

kerem commented

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

Author

Owner

@ghost commented on GitHub (Nov 28, 2016):

I'm assuming now that maybe it was writing to a log file from previous day or something if the clock was actually off, it wasn't something I was paying attention to at the time so I can't really check it now. It hasn't had any problems since I reset it though so I'm not sure what the issue was. I know this wasn't much info to go on, I was mostly just posting this to see if anyone had any thoughts. One thing I should note was that the computer was put in sleep mode every day and not shut down or reset, and it also suffered from some pretty severe network connectivity issues, but I don't think either of those would have affected it (The logging stopped in the middle of a day).

@ghost commented on GitHub (Nov 28, 2016): I'm assuming now that maybe it was writing to a log file from previous day or something if the clock was actually off, it wasn't something I was paying attention to at the time so I can't really check it now. It hasn't had any problems since I reset it though so I'm not sure what the issue was. I know this wasn't much info to go on, I was mostly just posting this to see if anyone had any thoughts. One thing I should note was that the computer was put in sleep mode every day and not shut down or reset, and it also suffered from some pretty severe network connectivity issues, but I don't think either of those would have affected it (The logging stopped in the middle of a day).

kerem commented

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

Author

Owner

@ghost commented on GitHub (Nov 30, 2016):

Another update: I don't think this is the same issue as last time, but when I tried downloading logs today, the window would never update. I checked with the file manager and the log file on the client pc was at 0 bytes, even though I know it had data as of the previous day (in the early AM). I deleted the file and logging started working again. Sadly I lost the data between then and last I checked but it wasn't a big deal.

12/3 Update: Client stopped logging again, just in the middle of typing a sentence apparently. Could problems with the network connection cause this somehow? I know all the logs are generated and then dumped locally, but each time this has happened was around a time when I know the client had network issues. It could have stopped when I last pulled down a copy of the file. Sadly remote executing the client-build doesn't fix this. I think I can probably just create a batch file to restart it though.

@ghost commented on GitHub (Nov 30, 2016): Another update: I don't think this is the same issue as last time, but when I tried downloading logs today, the window would never update. I checked with the file manager and the log file on the client pc was at 0 bytes, even though I know it had data as of the previous day (in the early AM). I deleted the file and logging started working again. Sadly I lost the data between then and last I checked but it wasn't a big deal. 12/3 Update: Client stopped logging again, just in the middle of typing a sentence apparently. Could problems with the network connection cause this somehow? I know all the logs are generated and then dumped locally, but each time this has happened was around a time when I know the client had network issues. It could have stopped when I last pulled down a copy of the file. Sadly remote executing the client-build doesn't fix this. I think I can probably just create a batch file to restart it though.

kerem commented

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

Author

Owner

@ghost commented on GitHub (Dec 11, 2016):

So this keeps happening and I'm not sure what's causing it, the logs never show anything that would be unusual keyboard activity right before it stops logging. Since it's such a nebulous problem I had two suggestions, the first would be a way to get the PID of the process on the remote machine (probably something to implement in an enhanced task manager), and the second would be a way to restart the process remotely. Right now my method is to find the PID and put it in a script that kills the current process and runs the executable again, it would be nice if this was a feature built into quasar just in case the program stops functioning client side.

@ghost commented on GitHub (Dec 11, 2016): So this keeps happening and I'm not sure what's causing it, the logs never show anything that would be unusual keyboard activity right before it stops logging. Since it's such a nebulous problem I had two suggestions, the first would be a way to get the PID of the process on the remote machine (probably something to implement in an enhanced task manager), and the second would be a way to restart the process remotely. Right now my method is to find the PID and put it in a script that kills the current process and runs the executable again, it would be nice if this was a feature built into quasar just in case the program stops functioning client side.